As the project grows in complexity and the speed of updates, we're finding a real need for changelogs and a reduction in the number of commits. At this time, creating a changelog over even a short period of time is a tedious and time consuming activity, and it is making even incremental updates difficult for us here at Comcast.
I would like to propose the following: * Each PR must have a linked jira issue. This is as simple as creating the ticket and then adding [TC-XXX] to the beginning of the PR title. The jira ticket title should briefly describe the fix or new feature in a manner which lends itself to inclusion in a changelog. * Large changes should have as much information as possible about the nature of the change and how this change affects the system. * Testing should be done on all changes before the PR is submitted! Please do not submit anything that has not been fully tested, regardless of how simple or obvious it may seem. You are the first line of defense against bugs! If the work is not yet complete, be sure to add [WIP] to the title of the PR. * Commits should be squashed as much as possible before the PR is submitted. 27 commits for minor changes make review and later analysis very difficult. Commit messages should be descriptive so it is clear what was changed. * New features or changes to functionality should include documentation changes whenever possible. * Integration testing should be included whenever possible - we now have automated integration testing, so this is another valuable method to isolate bugs before they hit the field. * When in doubt, be clear about what you are doing! I would also like to propose that if these requirements are not met without specific reasoning, PRs should be rejected until they are corrected. Derek
