Hi Junio, On Thu, 7 Jan 2021, Junio C Hamano wrote: > We may not be able to automate the thinking part to decide when > submitter may want to get help, but an automation can help by giving > the submitter cues and clues when to ask for help and from whom. I fear that we're striking the balance on the side of expecting too much knowledge about project-specific lore from contributors. My goal with GitGitGadget was to allow competent contributors to focus on addressing their pet peeve with Git, to produce a stellar patch with an outstanding description and get that integrated into the next major Git version, and not have to learn about the culture and mechanics of our patch review process for what may very well be their single contribution to Git. Just look at the wall of text GitGitGadget first-time users _already_ have to read through, and it does not even catch half of what is relevant for every single contributor: https://github.com/gitgitgadget/gitgitgadget/blob/HEAD/res/WELCOME.md Note that this wall of text does not even begin to answer questions such as "how do I know when this patch is accepted?". The suggestion that the contributor should Cc: you explicitly when the contribution is supposedly ready to advance (according to a set of rules that is not formalized anywhere that I know of) could potentially be added to that wall of text, but I doubt that it will make it easier to contribute even for the most advanced and dedicated software engineers. > Is there a point in the end-user experience flow, starting at the > time when they push their proposed change to their repository, throw > a pull request at GitHub, say "/submit", and then GGG finally sends > out a patch e-mail, where the GGG machinery can inspect the change > and give the user (preferrably before the user says /submit) a hint > that says "you may want to add Cc: to these people in such and such > case, and if you think the situation falls into these cases, tell me > so by saying /submit-with-suggested-cc instead of the usual > /submit"? > > And "these people" may include those who touched the affected code > within the past 6 months, and it may also include the maintainer > when the pull request is in its second or later iteration. We already have a ticket suggesting to add reviewers: https://github.com/gitgitgadget/gitgitgadget/issues/219 With this suggestion, too, we could go and extend that wall of text even further and expect contributors to just know what they are supposed to do. But I don't see how that would make this process more inviting to new contributors. BTW I get the sense that many Git mailing list regulars have this idea that making the review process easier for one-time contributors would invite too many low-quality contributions. However, I see the exact opposite: professional software engineers I talk to refuse to jump through all those hoops, even if they would be quite capable of producing a stellar patch within no time. At the same time I see a lot of less experienced developers delighting in the struggle^Wchallenge to set up `git send-email` correctly _just_ to earn bragging rights to have their typo fix in Git's commit history. I am exaggerating here, of course, to make a point. And I think this is a very valid point. We lose contributions (and potential future reviewers) because we make it harder than necessary to contribute to Git. Ciao, Dscho
