Isn’t that basically what packages are? We need to move more things out of Base julia in general, but there’s some technical limitations there still (that are being worked on).
14 Likes
I think not. Otherwise, we would not have the problem I am trying to describe here. In fact, it is the contrary. Some packages are much more “welcoming” than Julia (please, I do not want to complain here, just that for a newcomer developer, Julia is sometimes not that receptive). Thus, when someone that was used to make small contributions to those packages tries to make contributions to Julia, they sometimes had this problem again.
Anyway, all this discussion is just an attempt to improve peripheral areas. For peripheral areas, I do not mean things like new libs in stdlib, but small bug fixes, small improvements in some functions, an allocation reduction, etc. However, I am sure you understand much more than I do about what is really the problem 
My testimony is only to try help this language that is really important to me (95% of my work today that requires programming is done in Julia, 5% is bash).
5 Likes
Right, but I would contend that that is exactly evidence that splitting things into packages work. Imagine an alternative universe (aka Julia like 7 years ago), where all packages lived in the base julia repository ;).
8 Likes
Part of the problem might be that docs are part of the repo. We honestly would probably have much better docs if we used a wiki model that made contributions really easy.
15 Likes
Yes, this is also a fair point
I totally agree with this.
8 Likes
Or, we adopt my proposal only for the docs as a testbed 
5 Likes
As @Keno says above, one of the improvements that we can make is to move more stdlibs into their own GitHub repos.
For example, Pkg, Statistics, and Tar are examples of three stdlibs that have their own GitHub repos. And, in my experience, pull requests are reviewed very quickly in those repos.
Also, another benefit of putting stdlibs into their own GitHub repos is that you can give someone commit access to a single stdlib repo without needing to give them commit access to anything else.
In contrast, there is no way to give someone commit access to only part of Base Julia.
9 Likes
@Ronis_BR I think there’s no need to have a “blessed” set of reviewers. Anybody can look at PRs and add a review (I actually didn’t know this). So possibly the following (independent) things would be helpful:
- CI gets fixed
- non-core devs should feel free to add reviews
- we have an informal channel (slack channel?) for people to ping non-core devs for reviews of “forgotten” PRs
- somebody on the core dev teams volunteers to be the contact point for PRs with one completed review, accepts to be pinged on the completion of a review and commits to proceed forward (merge, request a second review, reject) quickly
4 Likes
Also, from an idea of @Ronis_BR on slack : a specific tag for “sounds like a good idea, needs a review and then should be good to merge”, which “second-ring” people could then look to to find things to review.
3 Likes
I also just remembered that GitHub has a “Triage” permissions level, which is basically read-only + labels and issue closing. I’d be comfortable giving that to basically anybody who wants to, since it’s easily undone if something goes wrong, though of course if we wanted to go that way it’d need to be formally proposed to the committers group.
19 Likes
I definitely would have appreciated the ability to add tags to issues for some of my recent PRs. Maybe a good standard for giving that out would be 2-3 merged PRs?
4 Likes
I usually write a line at the bottom with the tags, e.g. Needs tags: bug, performance
5 Likes
I understand that making a contribution and not getting it merged (or even looked at) can be frustrating.
But at the same time, I think that 1 year is an outlier. My experience is that PRs that fix bugs and do not change the API get merged relatively quickly, also doc improvements and optimizations.
In contrast, API extensions — however minor and relatively uncontroversial — do require a consensus because they will need a continuing commitment from the core devs. When bandwidth is limited, it is to be expected that other priorities take over.
Every PR is important to someone (at least the person who made it), but roughly 200–250 PRs are made every month. So I would not make an issue of the fact that some PR
It is natural that these things are done in batches.
1 Like
This should be good, somewhat the equivalent to good-first-issue.
Hi @Tamas_Papp,
Unfortunately, I think you see this as an outlier because people that faced things like this just stopped contributing.
For this kind of thing, I completely agree. However, there are counterexamples. I will not list here because I do not want to disclose the people that talked to me.
That does not mean much. It can be 250 PRs from core developers. Is it possible to obtain how many PRs per month we have from people that have submitted less than 10 PR? I am really not good at obtaining statistics from Github.
4 Likes
This should be good, somewhat the equivalent to
good-first-issue.
Maybe just “needs-review”?
1 Like
What about “needs-review” and another tag meaning that this is a minor thing or documentation change? (I thing we already have those)
2 Likes
It would not be that much work to make a “community-reviewers” slack channel that posts the link to PR’s on Slack. The challenge is that it will be all PR’s by default. Though, this seems like the same exact probelm/use case as something like the “stackoverflow-feed” channel. Sometimes you will know the answer, other times you won’t and Bougmil and co. will answer the question 
or review the PR in this case.
If someone wants to build this, see Slack.jl and GitHub.jl.
1 Like
What an amazing idea!
What about adding a label like @antoine-levitt mentioned called “community review requested”. Hence, this bot can link those PRs in that channel. Furthermore, it can scan for PRs without activity and bumping it again at that channel also.
3 Likes
The challenge with that (maybe not a challenge at all given what @Keno said) is that everyone needs triage permission then. If I’m a first time user or new contributor, then how will I get that label on the PR? I can’t add it myself