On 5/12/2021 5:14 PM, Antoine Pitrou wrote:
On Wed, 12 May 2021 17:05:03 -0400 Terry Reedy <tjreedy@udel.edu> wrote:
Yet you always see it: new people not knowing where to start, highly skilled contributors drowning and intermediate contributors moving slowly
I have multiple times strongly recommended that people review issues and PRs, and sometimes given details, but most won't or don't.
I don't know who "people" are in your sentence, but reviewing issues and PRs generally requires a high familiarity with a project, and
Much can be done without what I think you mean by 'high familiarity'. Bug issues: bpo: "On macOS with 3.8.3 I see this buggy behavior" If not enough info to reproduce, ask for it. If there is, try to reproduce on lastest release or even better, repository build. Sometimes, trying on a different OS is helpful. PR: make local PR branch and test whether proposed fix works. Enhancement issues: bpo: if proposal is for core python or a module one has used, does proposal seem like an actual improvement? enough to be worth the likely bother? PR: does the PR work as promised? Do you like it? PR Python code: read it. See any possible improvements?
enough confidence to speak with a voice of (seeming) authority.
I prefer honesty to pretend authority. Nearly 2 years ago, a 'new contributor' commented on a IDLE PR, "Would x be better?" It was a minor improvement, but a real one, so I made it, thanked the person, and encouraged further efforts. That person did so and is now a core developer. I would welcome more eyes on IDLE patches and use testing thereof.
I'm not convinced it's generally easier than submitting a patch for a particular issue you're comfortable with.
Some review actions are easier, some are not. But the only way to learn to review other people's code is to do it, and it is a skill we need in at least some new coredevs. -- Terry Jan Reedy