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

Open
bradreeder opened this issue May 22, 2017 · 0 comments
Open

Workflow #12

bradreeder opened this issue May 22, 2017 · 0 comments

Comments

@bradreeder
Copy link

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

You can use this repo to copy dwyls labels into your repo: https://github.com/dwyl/labels

  1. Create an issue for the task you are working on:
  • reference the issue number of the user-story it relates to ("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 proposed tech stack #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 and add the label 'in-review' to the PR.
  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.
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

1 participant