Hi Emily, On Fri, 8 Nov 2019, Emily Shaffer wrote: > It seems to me that the friendly template text we prefill when someone > opens a pull request in github.com/git/git isn't being fully appreciated > by many interested contributors. That is probably due to our confusing use of the template as a stop sign ;-) > For some time now, Johannes has been slogging through the list to try > to narrow it down to folks who are still interested in contributing, > and yesterday on #git-devel said he was pretty happy with the progress > so far. I don't mind it, and quite honestly, it does not take a lot of time, most of the time. > But to me, this seems like a sort of Sisyphean task - more folks will > want to make contributions and not read the template text, and we will > have more PRs being ignored forever, especially if Johannes decides he > doesn't want to shepherd those changes anymore (I would have decided > that long ago, in his shoes). The PRs are not bad. What is bad is all those comments on commits coming in as of recent, some developers thinking that they do not need to research the best way to reach the Git contributor community and instead just assuming that adding comments via GitHub's UI is a valid way. I should probably refrain from trying to help those developers because it makes me very cranky, but I just don't want Git to be an unfriendly project. > To that end, I wonder if we should add an Action to automatically > close PRs on that repo. It looks like > https://github.com/dessant/repo-lockdown would do the trick. We could > close incoming PRs automatically with a kind, maybe more succinct or > prescriptive version of the prefill text encouraging folks to open the > exact same PR against gitgitgadget/git instead. I am rather certain that that would not be a good thing to do. There are some people who open git/git PRs solely for the PR builds, others to facilitate code review, and yet others just because it is the intuitively obvious way to contribute to Git. Even some long-running PRs are worth keeping open, e.g. the Plan 9 support (which will just take time), the GET_OID_GENTLY one or the one clarifying the documentation of `git submodule update` (which both need to wait for a time when the respective contributor is less busy), and the likes. > Here's the prefilled template now: > > Thanks for taking the time to contribute to Git! Please be advised > that the Git community does not use github.com for their > contributions. Instead, we use a mailing list (git@xxxxxxxxxxxxxxx) > for code submissions, code reviews, and bug reports. Nevertheless, you > can use GitGitGadget (https://gitgitgadget.github.io/) to conveniently > send your Pull Requests commits to our mailing list. > > Please read the "guidelines for contributing" linked above! > > Maybe we can close PRs with something like this: > > Thank you for taking the time to submit a patch! > > However, Git does not accept submissions via GitHub pull requests. > > You can open an identical pull request to this one against > https://github.com/gitgitgadget/git and follow the instructions there > to submit it to the Git mailing list, where reviews are performed. > > If you don't want to subscribe to the mailing list, you can keep an > eye on your patch at https://public-inbox.org/git, or by watching > comments on your GitGitGadget pull request. > > More info on GitGitGadget: https://gitgitgadget.github.io > > I was aiming for "same message, but firmer", and "write down something > so we have a place to start". I look forward to the discussion. > > - Emily > > PS: Today we have 17 PRs open against git/git, and I think all of them > have been nudged by dscho in comments to open against GGG instead. Many > are in a state where dscho is sending a ping every few weeks to see if > the committer is interested in following through. > > https://github.com/git/git/pulls They all have been nudged, sometimes to clean up the patch first, or to suggest that maybe the goal of the PR might not be all that desirable. Some of the PRs probably can be closed, but as I said, I would like to think of Git as a friendly project, a helpful one, so I want to err in favor of talking to the contributors rather than shutting the door in their face, so to say. Ciao, Dscho