iamerikjolson / github-issues-process Goto Github PK

Update process for...

Assign Feature Testing issues directly to the project's tester. That will result in GitHub notifying the tester that there is action to be taken.

This repo appeared in my GitHub activity feed, just figured you'd might be interested in this microservice I recently built specifically for the purposes of displaying GitHub labels in markdown:

https://github.com/rtsao/gh-label-svg

Cheers!

This repo should eat its own dog food by using the appropriate state labels.

• Add a Production Bug label
• Change Bug to Dev Bug
• Remove Track Time

1. Make changes to https://github.com/thisisarray/GitHub-Issues-Process
2. Add to the script
3. Apply the changes to all org repos
4. Ensure that any repo that still has In Development instead uses In Progress

• Add Code Review step
• Use draw.io, and commit the HTML file that draw.io produces to this repo.

Things like:

• Use Google Doc to create a PRD.
• The PRD contains the following sections:
  • Vision
  • Background
  • Risks
  • Issues
  • Individual Requirements
• Requirement names in the format, "[Noun] - [Action]". Ex: "Users - Add/Edit"
• The client signs off on v1 of the PRD. Save a PDF signed copy in the project folder in Google Drive with the intent that it is "frozen" and will not be modified. Number it version v1.0.
• Create one GH issue per requirement.
  • GH Issue title should be named "[req name] (req #)", ex: "Users - Add/Edit (req #15)".
  • Add a deep link to the requirement in the Google Doc version of the PRD. Create a deep link by click on the requirement heading in the Google Doc and adding a bookmark (Insert menu >> bookmark), then copy the URL to the bookmark and paste into GH.
• Create milestones two weeks apart from one another.
  • Milestone name v0.01, v0.02, etc. (leading up to the same version of the PRD, so when all milestones are done the last minor version will be changed in Production to match the PRD version it was built against).
  • Set due dates.
• Assign issues to each milestone.
• Use milepost to create an overall project schedule. Send to the team and client.

Versioning the PRD

If a change is needed then a decision needs to be made whether the change should affect the code currently being developed.

If yes = Minor PRD versioning (e.g, v1.1)

Update the previously approved PRD (e.g. v1.0) by:

• Modify the document as needed.
• Annotate change in the revision log. A revision log is only needed after the PRD for a major version. Ex: In PRD v1.0, no revision log is needed. In PRD v1.1, the revision log will have one entry and clarify what was changed between v1.0 and v1.1. Include one entry for each subsequent minor revision. All increments should be in ".1"s.
• Annotate the current version on the cover page
• Update the file name of the Google Doc (not the PDF) to the new version number.

If no = Major PRD version (eg v2.0)

Create a copy of the Google Doc PRD and use it as the basis for documenting the future changes.

• No revision log required
• Change the version number on the cover page and Google Doc file name.
• Modify as needed.

Note: Do not modify the previous major version of the Google Doc PRD, otherwise you will modify the expectation of the work that is currently being developed.

Since GH now supports multiple assignees per issue, keep the developer who worked on an issue assigned to the task even though the task has progressed to Feature/Integration Testing and is assigned to the Tester. That way if the tester fails the fix then the tester just needs to remove themselves as an assignee and set the appropriate status labels.