Issue PR Protocol

Michael-

• Issue is assigned to an "owner" (issue lead?) who is responsible for making sure it progresses to a resolution
• PR is assigned depending on stage (development, testing, code review, etc)
• PR's label is assigned depending on stage (development, testing, code review, etc)
• When creating a PR, the first comment should include a link to the issue
• When creating a commit, the commit memo should include a link to the issue
• Comments about the (PR) should be on the PR
• Comments about the overall "issue" should be on the Github issue
• Whenever something doesn't fit into an exact scenario described, use your discretion about what to do which makes the most sense in that particular instance, but don't post multiple times for the same thing (ie on both the issue and PR).

Steve-

• PR is assigned depending on stage (development, testing, code review, etc)
• PR's label is assigned depending on stage (development, testing, code review, etc)
• The issue should remain with the owner and be labeled according to what the issue is for (Bug, Enhancement, etc) and priority
• Comments for testing should be on the PR

Ashish-

• One PR per issue
• Comments should always be on the issue unless a clear cut list can be made for comments that can go into a PR. Things such as error in testing (this can also be of many varieties as the error could be specific to the PR or specific to the issue) can go in the PR but things such as detail about the code related to the issue at large should be in the issue. This is the reason I suggest all comments should be on the issue. PR related temporary comments can be deleted from the issue once the issue is closed.
• Comments about specific lines of code should be added to those lines, not in the main PR screen.
• Generic comments in the PR only if an issue can have multiple PRs.

Ben-

Issues

• Assignee: Start as unassigned, but should remain with assigned person, unless someone else is leading a PR for it.
• Reproducing the issue.
• Line comment: If it is old.
• Helpful info regarding a conversation; sometimes it's just a status.

PRs

• Assignee: Changes according to Current Person working on it.
• Reproduce PR issue – Usually new issues being produced, but if issue exists without PR, then make sure to add to Issue as well.
• Line Comment: If it is new.
• Code Review.
• Conflicts with code.
• Merge conflict.
• Concept conflict – could be a possible-conflict with another PR, deprecated operations.

Slack

• Asking about a status of an issue or PR.
• Credentials & private information is obviously held privately or in a closed group.

Arnaud-

Issues

• Assignee(s): the person who creates the issue is the issue owner and is responsible to make sure that the issue progresses. Then there's a second assignee who is supposed to work on the issue (development) if the issue owner won't fix it himself.
• The issue is used to describe the issue (problem, conditions, steps to reproduce, etc.) and is not used to discuss PRs.
• The issue is also used to describe the desired solution/end result.
• The issue is labeled according to the nature of the issue (bug, conflict, enhancement, new feature, etc.).
• The issue is also labeled according to the priority of the issue (low, medium, high).

PRs

• Assignees: the person who submits the PR is the PR owner and is responsible to make sure that the PR is followed up on. Then there's a second assignee who is supposed to work on the issue (testing, code review, merging).
• The PR is used to discuss the solution (fix) to the issue.
• The PR is labeled according to its progress (needs testing, testing completed, needs code review, etc.)

Slack

• Used to ask about the status of an issue or PR.
• Used to share private credentials and other sensitive information.