search

jupyterhub / repo2docker

Turn repositories into Jupyter-enabled Docker images
https://repo2docker.readthedocs.io
BSD 3-Clause "New" or "Revised" License
1.62k stars 362 forks source link

Creating more contributor and reviewer on ramps #856

Open betatim opened 4 years ago

betatim commented 4 years ago

A proposal for creating an on ramp for contributors.

Tag issues as "new contributor only" (precise name of the tag to be decided). These issues would be for people who have had less than N (maybe 2-3??) PRs merged. People with more merged PRs would not be allowed to tackle these issues. They'd also have (very) concrete instructions for what needs doing and where to go looking to make those changes (not: "this is somewhere in the the conda buildpack" but a link to the line in the file that needs changing/adding to).

Another bottleneck in most open-source projects is having enough reviewers. So we could have PRs which are made by experienced(?) contributors that are then labelled as "first reviewers only". The idea being that these are PRs with which you can practice your reviewing of PRs. Like with the new contributor issues they'd be off limits for experienced reviewers and come with concrete instructions on what needs reviewing and promises of support in reviewing.

The idea of also having "new reviewers only" PRs was mentioned to me by @sgibson91 who said the Turing Way (I think) project had just introduce this idea. I like the idea so copying it :)

WDYT?

GeorgianaElena commented 4 years ago

I really like the idea of offering support for new reviewers :yellow_heart: Though it's not clear for me where the review instructions shoulb be: in the PR itself?

The idea of having a "new contributors only" issues to be solved by new contributors is also very nice :yellow_heart: I would however name the label "new contributors recommended" or some other word that doesn't seem so restrictive like "only". Also, I don't think we should set a limit or evaluate a contributor's knowledge thorough the number of merged PR. Some people might feel comfortable tackling more complex issues after 2 small contributions and some maybe after 5. I believe that should be up to them to decide and don't set expectations from our part. What do you think?

sgibson91 commented 4 years ago

Though it's not clear for me where the review instructions shoulb be: in the PR itself?

I'd recommend putting them in your contributing guidelines file, then you can set up/edit your PR template to publish a link to the longer instructions.

betatim commented 4 years ago

I am not sure yet how the "Practice your reviewing" PRs would work yet. Would they be made by people who are otherwise seasoned reviewers? Or are they PRs made by "anyone" where a seasoned reviewer thinks "ah this looks like one that people can use to level up their reviewing skills"? Or some completely different mechanism?

We currently don't have a PR template for this repo so we could add one based on https://github.com/alan-turing-institute/the-turing-way/blob/master/.github/PULL_REQUEST_TEMPLATE.md (in particular the "where to concentrate reviewing effort" and "summary"). (Having a simple, short, focussed PR template might be a nice thing to have independent of this discussion.)

The reason I suggested a fairly objective criteria for "are you eligible or not?" was that well prepared and specced issues are like fast food for experienced contributors. (Certainly for me.) Everything you need to quickly make a contribution and get that reward of "woah I got something merged!!". But really you should have left it for someone else. I also see the point that not everyone will feel the same level of confidence after a fixed number of PRs.

Another thing I was wondering regarding "PR review": we can't make people contributors (at least we haven't so far) so that they can press merge on a PR. How would people signal their "I reckon this can be merged"?