Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Workflow reminder #14

Open
jsms90 opened this issue Feb 8, 2017 · 1 comment
Open

Workflow reminder #14

jsms90 opened this issue Feb 8, 2017 · 1 comment
Assignees

Comments

@jsms90
Copy link
Contributor

jsms90 commented Feb 8, 2017

Just a helpful reminder for the workflow that @bradreeder specified last week. As before, please indicate that you guys have read through this again with a thumbs up 👍

  1. Create an issue for the task you are working on:
  • user-story: "as a... I want... so that..."
  • list the technical tasks involved in completing it, either within the issue itself, or as separate issues that refer to the main issue and are given a 'technical' label.
  1. Estimate how long it will take you to finish the issue and add the appropriate time label (t1h = 1 hour, t1d = 1 day, etc). If a user-story will take you longer than a day then its too big. Break it down into smaller issues.
  2. Give the issue a priority label.
  3. Assign yourself to the issue you're working on and add the 'in-progress' label.
  4. When you make commits give appropriate descriptions of the technical task it completes and refer to the issue number in the commit message. (e.g. 'related add hapi server boilerplate #7'). Aim for small commits that complete a single task.
  5. When the PR is ready for review:
  • Assign to your team-mates to review first (if you aren't pair programming)
  • Assign the PR to @jsms90 and change the issue label to 'awaiting-review'. Give the PR an appropriate description listing the technical tasks it completes.
  1. When the PR is closed, and once you're satisfied an issue is complete and on the live version of the project, change the label to 'please-test' and assign it to your product owner. This is to indicate to the product owner that they should check if they are satisfied the work is done.
  • If they are not satisfied, they should detail in the issue what needs to change. Un-assign them, remove the please-test label, and return to step 2.
  • If they are satisfied, they can close the issue.
@RhodesPeter
Copy link
Member

😊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants