View Issue Details

IDProjectCategoryView StatusLast Update
0006012unrealdocumentationpublic2021-12-06 13:50
Reporterprogval Assigned Tosyzop  
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
Fixed in Version5.2.3 
Summary0006012: The contribution process is not documented

It is usually assumed by Github users that sending pull requests is ok to contribute patches or start a discussion on simple changes.

However, from my understanding of a discussion on IRC a few month ago, Unreal development requires an open issue on this bug tracker first.
This is not documented anywhere, causing many proposed changes to be ignored forever as open pull requests:

In fact, the documentation even implies PRs are fine: "If you are a coder: fix bugs from the bug tracker, issue PR's on GitHub, .."

So I think it would be nice to:

1. update the documentation I linked above to explain it, or add a link to a longer contribution guide
2. add a file called or in the git repository, so github users can see it in the main repo view, and when opening a PR
TagsNo tags attached.
3rd party modules



2021-11-28 11:50

administrator   ~0022211

Just wanted to clarify: there's no relationship between the PR's laying around for a few months and the issue you bring up here (using GitHub vs bug tracker). The lack of response or action on PR's has other reasons (some good, some bad I am sure). I have now gone through all the PR's. Some of the low-level reasons are mentioned in the individual PR's now. On a higher level it (also) has a lot to do with the move from 5.x to 6.x in terms of developer attention. We have a small team and have been (and are) focused on getting an UnrealIRCd 6 out with a certain featureset which should be stable and tested. This required a lot of effort, designing, coding, documenting, testing. That means that, at some point in time, one has to focus purely on that and stop making other changes that are also "nice to have" (there are so many of those!). Every change has the potential to break things, delay a release or even force a new bugfix release.
Anyway, enough about that, such a statement from me does not really belong here (OTOH I don't see where else).

Back to what this actual bug report is about: clarifying the contribution process (eg What should be a PR and what is more appropriate as a bug tracker item) and the suggestions on how to do that (your two points at the end). These are good points.
It is even more appropriate these times, now that we have 5.x and 6.x development going on concurrently, as people will need to know what to do and what to expect, eg what branch to make a PR for.
I will see if I can write something up next week, or at least in December. Doesn't have to be long, just needs to be clear.


2021-11-28 12:23

reporter   ~0022212

I see, thanks!


2021-12-06 13:50

administrator   ~0022237

We now have a file in both 5.2.x and 6.x which refers to The main website also contains a link to this as well, as well as the left-nav of the docs.

Thanks again for the suggestion!

Issue History

Date Modified Username Field Change
2021-11-27 19:42 progval New Issue
2021-11-28 11:50 syzop Note Added: 0022211
2021-11-28 11:51 syzop Assigned To => syzop
2021-11-28 11:51 syzop Status new => acknowledged
2021-11-28 12:23 progval Note Added: 0022212
2021-12-06 13:50 syzop Status acknowledged => resolved
2021-12-06 13:50 syzop Resolution open => fixed
2021-12-06 13:50 syzop Fixed in Version => 5.2.3
2021-12-06 13:50 syzop Note Added: 0022237