The bolded didn't come through, but I'm guessing it's here: *If the contribution does not have a single author, please ask that the contribution be separated into multiple separate pull requests (one per author with their contributions) that may have (non-cyclical) dependencies, each following the same standard naming convention of JIRA: JIRA Description (e.g. METRON-123: Foo all the Bars).*
I'd recommend against multiple PRs. Creates all kinds of difficulties reviewing and testing. The changeset should be reviewed and tested as a single unit. If there is more than one author, simply don't squash. -D... On Fri, Jan 27, 2017 at 5:44 PM, Casey Stella <ceste...@gmail.com> wrote: > It is important for every contribution to attribute the author, our git log > is a legal papertrail for attribution. As a consequence of that, I > recommend the Development Guidelines section 1.2 be amended to the > following (bolded change): > > Everyone is encouraged to review open pull requests. We only ask that you > try and think carefully, ask questions and are excellent to one another. > Code review is our opportunity to share knowledge, design ideas and make > friends. The instructions on how to checkout a patch for review can be > found here <https://github.com/nickwallen/metron-commit-stuff>. > > When reviewing a patch try to keep each of these concepts in mind: > > > > - Is the proposed change being made in the correct place? Is it a fix in > a backend when it should be in the primitives? In Kafka vs Storm? > - What is the change being proposed? Is it based on Community > recognized issues? > - Do we want this feature or is the bug they’re fixing really a bug? > - Does the change do what the author claims? > - Are there sufficient tests? > - Has it been documented? > - Will this change introduce new bugs? > - *Does this contribution have a single author?* > > > *If the contribution does not have a single author, please ask that the > contribution be separated into multiple separate pull requests (one per > author with their contributions) that may have (non-cyclical) dependencies, > each following the same standard naming convention of JIRA: JIRA > Description (e.g. METRON-123: Foo all the Bars).* > > Also, please review if the submitter correctly flagged impacts to the > following (if exist): > > - System Configuration Changes > - Metron Configuration > - Metron Component Configuration (sensors, etc) > - Tech Stack Configuration (Storm, Hbase, etc) > - Environmental Changes > - Helper Shell Scripts > - RPM Packaging > - Ansible, Ambari, AWS, Docker > - Documentation Impacts > - Changes to Wiki Documentation > - Revisions in Tutorials > - Developer Guide > - Expansions in readme's > - Changes to System Interfaces > - Stellar Shell > - REST APIs > - Etc... > > > Thoughts? Better way to handle this scenario while still maintaining > unambiguous authorship? > > Casey >
