I personally don't think that we should require a Jira for every single PR. I think blanket statements like "you must create a Jira ticket for each PR", while made with good intentions, are too hard to enforce, don't take every situation into account, and are sometimes a deterrent to new contributors. If Joe somebody from the internet wants to submit a PR, we should welcome it and not say "we are not accepting this without first creating a Jira account and then creating a Jira ticket".
The changelog thing is a real problem. We had a plan to have an auto-generated changelog, but that was reliant on us moving to full github which we haven't done yet. I think maybe the changelog conversation might need to be re-visited. Have you taken a look at our contributing guide[1] on github? It already outlines a lot of the things you are proposing here and I think its the best place to have our PR requirements. I like Jason's idea, though not sure if it is possible. [1] https://github.com/apache/incubator-trafficcontrol/blob/master/CONTRIBUTING.md Thanks, Dave On Tue, Jul 18, 2017 at 8:08 PM, Jason Tucker <[email protected]> wrote: > Do you know if the the apache jenkins instance supports PR-triggered > builds? If so, then repo branches can be protected so that PRs can only be > merged if the build status is successful. Might be a good safeguard to have > in place, if we have the ability to enable it on the jenkins side. > > __Jason > > On Wed, Jul 19, 2017 at 12:19 AM, Gelinas, Derek < > [email protected]> > wrote: > > > 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 > > >
