Suggestion to slightly improve Julia development

[Keno]

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).

[Ronis_BR]

@Keno

Isn’t that basically what packages are?

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).

[Keno]

@Ronis_BR

Some packages are much more “welcoming” than Julia

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 ;).

[Oscar_Smith]

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.

[Ronis_BR]

@Keno

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 ;).

Yes, this is also a fair point

@Oscar_Smith

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.

I totally agree with this.

[Ronis_BR]

@Oscar_Smith

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.

Or, we adopt my proposal only for the docs as a testbed

[dilumaluthge]

@ChrisRackauckas

I think that one way to do this right is to have more officers and designations of ownership in certain areas. If you look around enough you can figure out who “owns”/maintains LinearAlgebra, but it’s not very accessible. It would be nice to have a file that gives a little bit more structure to this.

GitHub has the CODEOWNERS file, which could be one way for us to implement this.

[dilumaluthge]

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.

[antoine-levitt]

@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

[antoine-levitt]

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.

[Keno]

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.

[Oscar_Smith]

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?

[mauro3]

I usually write a line at the bottom with the tags, e.g. Needs tags: bug, performance

[Tamas_Papp]

@Ronis_BR

It took roughly 1 year.

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

@Ronis_BR

has been opened for 13 days without any feedback at all.

It is natural that these things are done in batches.

[Ronis_BR]

@antoine-levitt

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.

This should be good, somewhat the equivalent to good-first-issue.

@Tamas_Papp

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.

Hi @Tamas_Papp,

Unfortunately, I think you see this as an outlier because people that faced things like this just stopped contributing.

@Tamas_Papp

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.

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.

@Tamas_Papp

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

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.

[antoine-levitt]

This should be good, somewhat the equivalent to good-first-issue .

Maybe just “needs-review”?

[Ronis_BR]

@antoine-levitt

Maybe just “needs-review”?

What about “needs-review” and another tag meaning that this is a minor thing or documentation change? (I thing we already have those)

[logankilpatrick]

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.

[Ronis_BR]

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.

[logankilpatrick]

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