Likewise, a slow PR process has the exact opposite effect.
A number of PR's have either 0 reviews or are waiting for a merge or further comments after all comments are addressed; then time passes by and bitrot happens, causing them to be un-mergeable even if they initially were when they were last updated.
What can be done to improve this?
we can always revert; impact will be small so long revert happens shortly after the merge and in between 2 releases. Obviously CI prevents "obvious" bad merges already. IMO the benefit of increased velocity in getting PR's merged outweighs the cost of occasional PRs that need to be reverted.
I suggest to nominate the maintainers responsible for the individual components of the compiler. Maintainers responsibility would be to maintain up to date roadmap wiki page of the component and review/merge PRs and test them to make sure there are not many regressions. If regression has appeared it is their responsibility to fix it. Araq has the last vote, he reviews what has been already reviewed by the maintainers.
Roughly list of the compiler components.
I have likely missed a couple of components.
One maintainer can cover multiple components if he can cope. Araq can be maintainer of some components himself.
P.S. Araq is on vacation as far as I can tell. We should not discuss it without him.
Araq is on vacation as far as I can tell
And that should not be a reason to have zero commits, zero merged pull requests, and zero closed issues* for four days.
OP is exactly about that: if Araq is busy or absent, this should not put the whole project to a halt!
* Besides three issues closed by their authors
the simplest for that is: in each directory you add a OWNERS (or CODEOWNERS) file, eg:
https://github.com/dlang/dmd/blob/master/CODEOWNERS (easily machine-parseable in case we need tooling) that way it's version controlled and ppl can put themselves out when they no longer want to be involved in some part of the code
OP is exactly about that: if Araq is busy or absent, this should not put the > whole project to a halt
In Ruby you have to discuss specific feature requests on the bug tracker; and matz is the final authority for approving or rejecting.
I do agree in regards to bugs and fixes to documentation, but I would strongly disagree and suggest to not bypass changing functionality after extensive discussions.
I also highly doubt that 4 days (!) of open PRs causes people to go away. What's the next claim, 1 hour after a PR people leave?
If perceived slowness happens because of people upstream being busy, you could always try to delegate further downwards. Linus does this too; Matz in ruby does this as well to some extent (e. g. the main guy who works on mjit has quite a lot of freedom to operate without having to constantly ask whether this or that change is ok now, as long as the larger picture is kept in mind).
We can add a Github issue template
+1
This should standardize what a good issue looks like (e.g. the code that fails, its output, the expected output, etc.) and it will make it easier to reproduce, test, and finally fix it.
+1
A practical incentive is better than making it mandatory.
The template should also contain a code template for a test showing the expected result config (the discarded raw string header, btw.: is that thing documented somewhere?). PR submitters know about this, people who only report issues probably don't.
Revisiting this thread after 2 years:
Some interesting stats on number of PR's merged etc over past 30 days, for several popular language's github repos: https://github.com/timotheecour/Nim/issues/642
Nim isn't doing too bad compared to other languages; but we should continue encouraging more people to contribute, more people to review, and keep the review quality bar high and the review cycle fast.
A lot of recent PRs have been minor refactoring/documentation fixes though, some of which explode line counts despite how simple they are (like single backticks). Standard library inclusions also usually mostly help to save lines from user code because they get written a lot, which would also imply that they are simple to write.
The most important changes seem to me like compiler/language changes, maybe fixes, error messages, finishing features. I don't personally know about this, I have worked a minimal amount with the compiler, but maybe the compiler code looks a bit eldritch to possible contributors? If there's a way the compiler can be changed or refactored to be more streamlined and understandable, or if it can be further documented how it works then maybe that could help. Are there any first hand accounts on this? I don't mean to be greedy.
So what I as a newcomer am missing is a little guide on how to start contributing > Also some piece of information on reviewing would be cool
for both, see https://nim-lang.github.io/Nim/contributing.html
which is also mentioned in the README in https://github.com/nim-lang/Nim
Also an introduction to the compiler would help, or a general tutorial an how some should work on fixing an issue.
see https://nim-lang.github.io/Nim/intern.html, or recent PR's that fix compiler bugs