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 #22

Closed
bradreeder opened this issue Jan 31, 2017 · 1 comment
Closed

Workflow #22

bradreeder opened this issue Jan 31, 2017 · 1 comment
Assignees

Comments

@bradreeder
Copy link
Collaborator

bradreeder commented Jan 31, 2017

Please thumb up this to indicate you understand. Raise questions in this issue if you run into any problems or come find me.

  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 Child user story #4 - sleep #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 @des-des 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

I am closing this issue now as we have come to the end of the project.

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