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 , 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.
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.
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 .
The tease is real, I’m eagerly awaiting an update :o
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.
Hey, 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 !). We just got a 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 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 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.
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 @anonymous_user_431284c7’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] [/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:
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 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.
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
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] [/MENTION] and [MENTION=9] [/MENTION] for handling all this feedback so well and passing it on to the right ears.
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 ) 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, most likely will and will make sure to bring it to my attention.
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.
