Without this patch applied the example commit message in the CONTRIBUTING document is not a concrete example. This is a problem because the contributor is left to imagine what the commit message should look like based on a description rather than an example. This patch fixes the problem by making the example concrete and imperative. The first line is a real life imperative statement with a ticket number from our issue tracker. The body describes the behavior without the patch, why this is a problem, and how the patch fixes the problem when applied.
Without this patch it's not very clear how to create a topic branch. This has been a problem in the past because we often get pull requests from the master branch to the master branch which can be confusing when working outside of the GitHub Web UI. This patch addresses the problem by providing a concrete example of how to create a reasonable topic branch and start using it with two commands.
The previous CONTRIBUTING.md was verbose and prone to change as branches changed. After discussion on puppet-dev I've cut it down a lot and changed the policy for which branch to target to be a "prefer master" policy where it is up to the merger to make sure it will go on the right branch.
Previously, the short version/checklist at the beginning did not line up with the rest of the document, and was presenting information in a confusing order. Now it reflects the way the information is organized in the larger document, and serves as a good checklist for going through the process.
Remove the pieces of the document that say we support email and Redmine patches, instead of just saying that we strongly discourage these. Also change the places where we say "we recommend" when what we really mean is "we require". Lastly, make a few small changes that were brought up on the PR. <firstname.lastname@example.org>
While CONTRIBUTING.md makes it clear that GitHub is the best method for submitting changes, it's important that we be honest about the fact that Redmine and email patches have a tendency to get lost (sometimes forever). Hopefuly this change will encourage people even more to use GitHub as apposed to other methods of contributing. <email@example.com>
Prior to this commit, it was unclear if it was required to have a Redmine ticket before submitting a pull request. Now it is clear that this is a requirement in order to help us keep track of submissions. Also add details about looking for already existing tickets that are either duplicates or related. This should help with the issue of having tons of tickets all related to one bigger issue which cannot be tracked easily. <firstname.lastname@example.org>
Priror to this commit, CONTRIBUTING.md did not reflect our current process in regards to where changes should be targeted. Now it is clear on these issues so that it will be easier for community members to target their submissions to the right location, and prevent us from frequently having to kick back pull requests that need to be rebased and retargeted. <email@example.com>
We have historically had the preferred contribution process on the Redmine wiki, however this is not obvious to people that don't already know it is there. By adding this document to the repository itself, it becomes much easier for new contributors to find what the preferred contribution methods are. By having the preferred contribution method in the repository also means that it becomes a "curated" document, which must go through the same submission/review process that other changes to the repositories go through. Reviewed-by: Nick Fagerlund <firstname.lastname@example.org> Reviewed-by: Nick Lewis <email@example.com>