Download

Easing community contributions

Hi!

With such a massive amount of open pr’s, I would like to suggest defining a tag system on github. This would allow your devs to spend less time swimming through a sea of pr’s without a way to prioritize them, which would mean some pr’s can be accepted sooner.

new feature, refactor, bug fix, documentation are a couple of tags off the top of my head.

The ‘bug fix’ tag is an interesting one, which brings me to my second suggestion. I know you use Jira for your bug tracking purposes. Please find a way to make your bug tracking public. I love everything about your decision to go free and open up your engine for contributions. There’s a huge community of people that would like to help you make UE4 into the best engine on the planet. Enable them to do so.

Also, similarly to paragon, I’d like to see some regular blogposts on which direction the engine is going and why. I frequent the UE4 roadmap trello, which is a really cool communication tool, but it can only convey so much.

Thanks for reading!

Hi Slabilo,

Thanks for the feedback.

Regarding Github tags; I’ve looked into it and there are some existing Labels that aren’t getting utilized. We’ll look into the possibility of using these to help keep things organized. I can’t say for sure whether it will have an impact on processing them sooner, but it’s worth a shot.

Regarding public bug tracking; we are actively working on this and hope we have something to unveil within the near future!

As for Engine development blog posts, no guarantee but I’ll discuss this with our community team. However, I recommend you tune into our Twtich streams for the most up-to-date information.

Cheers

Hi [MENTION=9]Stephen Ellis[/MENTION]

I’m seeing a lot more labels being used which is great, thanks for listening!

What I was actually hoping for is allowing contributors to add one of the existing tags to prs. What do you think about that? The real benefit with using a label system imo is that you guys can sort prs without having to open them first. So potentially I can fix a bug, label it as such, and thus my pr would be seen sooner by you guys than e.g. a new feature.

The tease is real, I’m eagerly awaiting an update :o

I believe this may be a limitation of Github, that submitters cannot set labels; only the repository owner.

https://help.github.com/articles/repository-permission-levels-for-an-organization/ [MENTION=9]Stephen Ellis[/MENTION]

I think creating and deleting labels is a different matter, but adding/deleting existing labels on a pr is an option that is currently turned off

Entering the Epic hive mind…

Can’t upvote this enough! Roadmap / Trello are not super great indicators of Epic’s mindset or priorities.
By now many devs expected things like vehicle fixes, DGI, Runtime Terrain, Large-World MP support etc.
But that hasn’t happened. Clearly Epic have different priorities and an open Blog would help address this.

Otherwise it just fuels unnecessary speculation / endless begging wishlists for features that won’t happen.
That leads to frustration! Alex P etc is good at listening to feedback and logging it and saying thanks etc.
But beyond Paragon etc, its not apparent which areas really interest Epic key decision makers or why…

I imagine that a request like that could come across as a bit scary to meetings @ HQ.
Central Banks / The Fed don’t like to give out much info either, but they’re changing.
Indicators of sentiment, observations about the ever changing industry, would be nice…

Twitch streams can be lengthy, net connections get interrupted etc. Its not the ideal route.
Even a loose Blog talking about general or possible directions of UE4 would be insightful.
Would Tim S ever do such a blog? His posts are insightful, but hit and miss in frequency!

100% agree.

Take a look at this PR. There’s a comment which I’ll quote here: “Thanks for the pull request. We are in the middle of a large refactor of OSS [online subsystem] in our dev branch, I will add this there when the dust settles. It shouldn’t take too long.”

This kind of stuff must’ve been planned. Keeping a contributing community involved imo means being transparent in planning and execution. (I really do apologize for taking a wrong example if this was an announced change, but the example is not the point). The image trello conveys is too blurry, even more so if it conveys outdated information. We’d like to know what the dev team is doing, before it is doing it, not after.

I hope a blocking factor is not the fear of making fake promises. I understand the need to deliver accurate information, but when a community is trying to walk beside you in this endeavor, I think it’s better to have us stumble over a cancelled idea rather than let us walk off a cliff because we’re blind to the future. Please, share your plans, share your vision. It’s been nothing short of epic (!), but there’s room to improve here.

Thanks for listening!

Hey everyone, Stephen gave me a ping that there were some concerns about transparency/forward vision with UE4. We’re definitely not trying to obscure engine development from the community, so lets talk about how to fix that impression asap.

I can for sure say that we’re going to be a lot more transparent as far as what is being done about past requests/reports and where their status is thanks to the new (upcoming) public bug tracker (Yay! Thanks Nick Darnell!). We just got a chance to show it on the livestream and talk about the features that will help Epic get a better pulse on what is the community’s priority. Voting, auto-adding links that mention the bug and real-time status updates should all help, but I (and Nick D) always want to hear if there are ways to improve our methods.

As for a regular blog update on what is being done and where Unreal is headed, I wonder if that would be more helpful if the roadmap trello was to have more details/infomation and more frequent updates instead. My thought here being that the blog would be an amalgamation of what several teams are planning, which is basically what the trello should convey alreadt. If the roadmap is lacking in information and forewarning, then that’s probably the issue that needs to be addressed. If that doesn’t sound like it would help, then let’s talk about what a better solution would look like.

GitHub tag control being more public/submitter-driven is an interesting idea and I’m going to ask about if there would be any potential for issues or abuse. If there isn’t any good reason, I’ll see about getting that done.

If there is anything else that you can think of that would improve the experience of making PRs or seeing what we’re up, just let me know.

Hi Alex … 2c:

A central summarized Blog here on the forums would still be helpful (the old Roadmap thread is long dead).
Something updated even 4 times a year, just as long as it was really updated quarterly and didn’t just die off.
A Blog covering the broad direction of UE4, and a progress report on big ticket items Devs want / Epic wants.

You can extrapolate from Trello & Github, but its takes work and 3rd-party sign-ons, and updates can still crawl.
There’s also Twitch, but that didn’t even work for me today. (Maybe next decade they’ll dump Flash for Html5).
Did you answer any thread questions? (Hoping you’d see the post about customizing Blueprints for better clarity)…

Like many I’m heavily invested in Unreal coming from over from UDK, yet I still have no idea where UE4 is going.
In private I’ve heard similar views from some of the old guard with the same concerns, and that’s a little scary…
You see Paragon getting pushed to the top, and it makes you wonder where is the engine going, and what’s next?
Is it going away from UDK, or the best crossover between a game engine and a modding tool in terms of ease of use.

You’re incredibly receptive and tireless at taking suggestions and being open to feedback and I applaud you for that.
But 2 years out, there’s still little official word on: Vehicles / DGI / Runtime-Terrain / Large-World Multiplayer etc etc.
It would be nice to be able to plan. To be able to say, ok that feature won’t happen, time to go design something else.
So overall it’d help to know if UE4 is morphing / leaning in a particular direction, to allow user projects to flow better.

Hey Alex,

For me the single biggest change that would vastly improve pull requests is better communication on the PR’s themselves. Most of the current PR’s have no replies from Epic devs, and are not assigned to anyone. If you go to “Pulse” section you can see there has not been a single PR accepted in over a month (it’s been longer than that, I checked it a month ago with the same results). (see @Slabilo’s post below, TIL pr’s aren’t accepted via Github)

The communication I mean doesn’t need to make promises about when it will be merged, I know that can change on the fly. I’m more interested in knowing what stage the PR is in, such as just submitted, being considered, being tested, needs updating, waiting on other teams, ready to merge, etc, just to give us some idea of what’s happening.

I understand the process takes time and know many of them will eventually get accepted, it would just help to have some better communication to know where things stand. Thanks!

The PRs aren’t being accepted via github, so the pulse section doesn’t convey the actual turn-over on accepted PRs.

+1, very good feedback.

[MENTION=8]Alexander Paschall[/MENTION] the bug tracker looks really really cool, awesome stuff!
I agree that an improvement to the trello would be better. I’d like to take a step back, change some unfounded comments I made and make some remarks about trello as the gateway into the UE4 dev minds.

  • the trello does reflect what is planned, something I have raised concerns with, particularly this:
    Screen Shot 2016-07-15 at 15.27.19.png
  • activity information is vague. the tags (e.g. ‘July’) are useful indicators, but they don’t provide accurate information, like whether work on an item has stalled, or started at all.
  • completed items clutter the current view. it’s useful information, but there’s no good place to put it in the roadmap trello.
  • eventual dev decisions regarding item prioritisation are properly reflected on the trello, but their reasoning is not (which was originally something I would’ve like to see in a blog)
  • the trello votes are by and large being neglected. We’re not expecting the dev team to jump on every issue that gets more than 100 votes, but I would like you to consider starting an open dialogue with us somewhere regarding highly-voted topics, inviting collaboration on seeing these highly-desired items on the community’s wishlist implemented.

Thanks!

Please consider @DotCam’s feedback!

Hey again, just wanted to give a quick update on how things are going.

I’ve been working with Tim Lincoln and he’s made a bunch of new labels that can be applied to GitHub PRs that should help with status updates.

I’m working on getting faster responses still and my next big push is for a more thorough Trello board.

This is really solid feedback and I’m going to bring up these points up to our roadmap team and see what kinds of solutions we can make.

I think that’s why I’d like to make the Trello more like a rolling mini-blog in the form of small updates on cards and details that can be added on the fly by individual developers/teams. If there was a blog instead, there would be limits to how frequently the developers would be able to say what their goals are. Epic can pivot pretty quickly and if a pivot happened, the blog would be very deceiving until the next quarter (or month even).

Also, I saw the forum post, but figured you would have seen the new UMG interaction component we showed off, which would have answered your questions about menus/triggers. Basically, the new component will allow you to trigger any 3dwidget in a somewhat similar fashion to UDK triggers. It’s a component you just add to the character now to allow that interaction. Still looking into the wire/node changes, but it’s possible since the full source is there, I just don’t know the specific functions off the top of my head.

Ok, off to do more things, will report back later! Have a great weekend :smiley:

That makes sense. I realize we were talking about slightly different things. I was hinting at Bigger Picture…
Like broad engine direction, and if UE4 was being geared up more towards MOBA or other genre games?
Because some areas like vehicles are getting less love, whereas in UDK they were a big part of the engine.

Understood. I was really just checking if color-coding BP was something that was already in the pipeline.
Thanks for the UI component tip. You’ve uploaded the stream to YT anyway, so I’ll check it out. Cheers!

The thing is, the trello roadmap is awesome, but it will always be just a reflection of your internal project management. A real solution would be to become truly transparent; public project management. This becomes quite a mess when there are multiple teams involved, that could potentially use different tools etc, but the benefit of creating direct communication between your devs and the community vastly outweighs the cost. I’d love to see this happen so much. Please let me know what you guys think of the idea, and if I can help make it happen in any way, please let me know.

All in all, thank you [MENTION=8]Alexander Paschall[/MENTION] and [MENTION=9]Stephen Ellis[/MENTION] for handling all this feedback so well and passing it on to the right ears.

Hi everyone,

I just wanted to pop in briefly to thank you all for your feedback regarding labels on Pull Requests. We sometimes operate in a little bubble of what we think is helpful to the community, and without feedback like this we don’t often have the opportunity to find new ways to make improvements that provide more information to the community. The Labels on GitHub are currently in a somewhat experimental phase, but I think they will be helpful in the long run. The first set of labels (Bug Fix/New Feature) were fairly easy to get added to the currently open Pull requests. The status labels will probably take a bit longer to make it onto the Pull Requests, but once they are in place it should be fairly straight-forward to keep them up-to-date. I don’t have any plans to add labels to any Pull Requests that are already closed, so unless there will be some significant benefit to doing so, don’t expect to start finding labels on those (any currently open Pull Requests with labels that get closed will keep the labels they had when they were closed).

Please keep the feedback coming. Over the next few weeks, please let us know how the Pull Request labels help or hinder on GitHub. If I don’t see your comment, Alex most likely will and will make sure to bring it to my attention.

Tim

PS. I would like to apologize in advance for the colors on the labels. I am a programmer, and I essentially picked colors at random for the labels. It is somewhat likely that the colors may change over the course of the next few days/weeks.

We know that the direction the engine can pivot on a dime WHICH is why we want to be told what the plan currently is and we would want an update when something happens you could just say we have pivoted and debrief us when you can. The whole we can change at any time without a current plan available can be a large turn off for us. Thanks.