On Wed, Jun 16, 2021 at 10:48:59AM -0700, Ido Rosen wrote: > I’d suggest limiting the feature set to automatically responding to GitHub > PRs with a link to a tutorial on how to contribute patches etc. Doing too > much for them may create more harm than good in the long run because it > removes the incentive to learn the contribution process. I do understand that sentiment, to a degree; in fact, I often compare our process to submitting a paper to a peer-reviewed journal. You can't just email your napkin thoughts -- it must be formatted in a very specific way, list its references in a very specific way etc, etc. However, that is not a perfect analogy. Our code review process must also allow for what is effectively a "report a typo" link. Currently, this is extremely onerous for anyone, as a 15-minute affair suddenly becomes a herculean effort. The goal of this work is to make drive-by patches easier without also burying maintainers under a pile of junk submissions. > An exception to this would be documentation patches and typo fixes: the > GitHub web editor makes it very easy to edit documentation and other > changes that don’t require compilation to test (e.g. spelling errors in > comments, man pages, txt files, etc.). Or it could be a tiny change in the driver string output, so I'm not sure it makes sense to limit this to just docs (especially with many docs being sourced straight from .c files). -K
