Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[BEAM-6122] Update committer guidelines #7129
Update guidelines per discussion in https://lists.apache.org/thread.html/6d922820d6fc352479f88e5c8737f2c8893ddb706a1e578b50d28948@%3Cdev.beam.apache.org%3E
Follow this checklist to help us incorporate your contribution quickly and easily:
It will help us expedite review of your Pull Request if you tag someone (e.g.
Post-Commit Tests Status (on master branch)
In general, I believe that manual processes should be made as simple as possible and have failure-modes which give timely and actionable feedback.
Some of these policies (like tagging a JIRA on every commit) would be very easy to validate in a pre-commit (the website build.gradle gives an example of interacting with Git from Gradle). But, the workflow for fixing up commit messages takes some degree of Git mastery (
A simpler failure mode would be something like: "If each commit is tagged with a JIRA, individual commits will be retained during merge; otherwise commiters should squash and merge a single commit with JIRA information from the PR."
I really like Scott's latest points. Another aspect here is that the instructions for new contributors should be primarily helpful and welcoming, and avoid being prescriptive or pedantic. And concise. We want them to have an easy onramp, so we need enough tips, but we also don't want to discourage their contributor either by excessive demands or an intimidatingly large amount of instruction. My biggest goal is for them to open a PR and have a good interaction with a reviewer. I don't want to put anything in the way of that. That's why rules for policing our more experienced members should be clearly separate. As an extremely common special case, if someone thinks they already know how to open a PR, I want to get out of the way and let them do that, and work out the rest once we are in conversation. Putting this stuff in Jenkins is great not only for the usual reasons for automation but also because it makes iteration on it self-service.
Knowledgeable committers can take on additional chores and/or chat with the contributor about things on the PR. I do think Beam committers can be expected to know
On the automation front, just noting that we have 1575 non-merge commits on