More open discussions behind PRs

Hey @VictorLerp and anyone for whom it might be relevant. On GitHub I have seen the linear increase of the pull requests, seemingly without stop. I have been wondering if there’s anything the community can do in order to help shrink the number which is getting close to 800. According to some feedback on some requests, there are discussions about some of these in Epic’s private JIRA, however, many of them seemingly get stuck without resolution(?), and we only know about the summary of these discussions if we ping EpicMonte directly. Is there any way the JIRA tickets for PRs can be more open? So for example if I can see that developers find a solution of mine too dangerous - I might just find another way to implement the request, which might be evaluated much easier.

I don’t want to burden anyone unnecessarily, it’s just that the current methodology seems to be unsustainable, and it might drive some people away from committing time into great PRs if some previously created ones are just lying there for years without any feedback. It’d be great to find a solution without putting more on the developers’ shoulders.



just my 2 cents: :slight_smile:

I guess it depends on the type of PR.
If there is a PR that brings a whole new subsystem to the engine, chances are very small that it will be adopted.
In case of a minor bugfix with only a few lines of code touched, it might have better chances of being picked up.
I remember Nick Penwarden briefly commenting on that during a stream a while ago.
The issue seems to be manpower. Thats why large PRs arent really touched.
The manpower is needed because Epic does not integrate PRs lightheartedly and always checks the implications of a suggested solution.
Imagine how many people you would need to audit all those PRs, always with the chance that the PR is not fitting in what EPIC has in mind.


Of course, and although I understand the physical limitations, my problem is unsustainability. If “large PRs” or “PRs of specific topics” cannot be evaluated due to manpower limitations, then let’s state it clearly, so that people don’t work on them unnecessarily - both in the documentation and in the GitHub readme.

Also, this thread aims to find a solution for those requests, which die silently after being looked at initially, without the request creator knowing (and ones which are really small, just forgotten).