https://wiki.dlang.org/Contributing_to_Phobos mentions: > Smaller additions like individual functions can be merged directly after > @andralex approves
The arguments for having all changes go through one person have been presented here [1]. However this is how I see things: * if phobos is supposed to be batteries included (https://forum.dlang.org/post/mfrv29$t21$1...@digitalmars.com), it should be able to grow fast; looking at past changelogs, this has not been the case, each release only comes with a handful additions to phobos at most. * let's look at the D survey answers to the question 'what went wrong' while contributing code to dlang on github: https://github.com/wilzbach/state-of-d-2018/blob/master/13c:%20What%20went%20wrong%3F 45 answers out of 69 mentioned the review process was too slow and PR's lingering forever after all comments are addressed. A common theme is PR lingers while waiting for approval from leadership [2] * This creates a vicious cycle which diminishes number of contributors since PR review is so inefficient; as a result a bug fix / useful addition never gets merged. * I'm not sure if there are many examples of large projects where every addition/symbol overload has to be approved by a single person; this would be more bearable if response time was fast; however as noted in survey answers, response time is often in weeks/months, sometimes years. pinging by email also doesn't always work: here was the response I got: > Thanks. This will need to wait - we're busy with DConf for the time being. if one is unavailable, one should delegate Given all this, my recommendation would be for PR's to be merged after all checks have passed and it was approved by 2 committers. --- [1] https://forum.dlang.org/post/ncp5g8$20hr$1...@digitalmars.com > I just asked for a stdlib addition to be pulled back at > https://github.com/D-Programming-Language/phobos/pull/4025. Such decisions > are difficult because the risk is them to be interpreted as stifling > creativity. That is not the case. The only reason for all library additions > to go through one person/small group is to preserve a cohesive vision and > style. At the opposite end, nobody wants a library that's a mishmash of > styles and approaches, even if that includes some of theirs. Please make sure > I know of library additions. I've been on vacation and even when I'm not I > can't monitor and review all library work - it would be a full-time job that > wouldn't leave me time for anything else. Please just email me directly > related pull requests. I always tend to my email. [2] here are some illustrative answers: * PR's linger forever after all comments have been addressed; not enough committers create a bottleneck from andrei/walter (not enough trust/delegation); style issues are a waste of time (we should use tooling instead); negative bias towards 'small' improvements * Andrei Alexandrescu had way too much influence in areas outside his core competency, too many bad decisions made for religious/philosphical reasons relying on the "sufficently powerful compiler" fallacy and appeal to authority * PRs have a tendency to grow stale, especially when waiting on a response from Walter or Andrei. * There is sometimes a tendency for PRs to languish - sometimes for years, particularly if there's any disagreement or if it requires input from Walter or Andrei. Obviously, that doesn't always happen, but it's not entirely uncommon either. * Community is very negative. Leadership seems very unengaged. There is not enough delegation/trust. * I'd say "The whole process was an uphill battle", but that's a huge understatement. Endless "perfect is the enemy of good". Endless pushback and arguing on whether things should even be done at all (especially from MartinNowak - nothing personal, and no offense, but that one alone doubles the amount of arguing that needs done to get anywhere, will object to seemingly anything, and frequently just leads the debate in circles). And long periods with no response. * Still no response to my pull request after fixing it 2 weeks after the initial feedback (more than a few months of waiting now) * It's very hard to get significant improvements to D's weakest areas accepted, because of concerns about breaking changes and/or excessive complexity of proposed solutions. As a result, broken stuff just stays broken. * Mixed experience. Sometimes too much of a "don't touch our project" attitude. (advice: give the contributing developer some ownership of the project. Yes that means making compromises on your own opinions)