dwyl / dwyl/contributing

Update repo to include Github Projects

Open
#110 1 comment 0 reactions 0 assignees View on GitHub
discuss
Dominant language
No language data
Stars
91
Forks
9
PR merge metrics
No merged PRs in 30d

Description

In #109, @nelsonic proposed the following columns:
![tcm-workflow-with-blockers](https://user-images.githubusercontent.com/194400/31735912-26fa7892-b43b-11e7-9da1-75547a348f89.png)

+ Ideate: Define User Story
+ Create UX/UI Wireframe/flow
+ Tech Spec (add checklist)
+ Estimate Time
+ Ready for Dev
+ In Development
+ Ready for Review
+ In Review (Pull Request)
+ Ready for Test
+ In Test
+ Ready for Signoff (Business)
+ Done 🚀

In _practice_ we have been using a more simplified structure, essentially skipping the first 4 proposed columns above and starting from 'Ready for Dev':
+ Dependencies/Open Questions
+ Project backlog
+ Sprint backlog
+ In progress
+ Awaiting review
+ Awaiting testing
+ Done

Whilst this may seen simpler, in reality it means that more often than not, adding tech spec and time estimates just **doesn't get done**.

For internal dwyl projects and for our client projects, usually the PO is the final decision maker and provides sign off, so my only proposed modifications to this as a starting point would be:
+ Ideate: Define User Story / Project Backlog
+ Create UX/UI Wireframe/flow
+ Ready for Tech Spec (this is not something we currently add to anything other than very complex issues, we may need to provide some good examples)
+ Estimate time
+ Sprint backlog (things can only be moved here once they are time estimated)
+ Alternatively we use milestones only to demarcate sprint and this becomes the prioritised project back
+ In ~Development~ Progress (these can sometimes be questions
+ ~Ready for~ Awaiting Review
+ In Review (Pull Request)
+ We trialled this column in the CI project and it was never used, but my hypothesis is that this was because QAs don't go through the Projects, they look at what is assigned to them only - if adding the `in-review` label _automagically_ moved the issue into this column, then we could keep the column
+ Ready for Test
+ ~In Test~ - Even our best POs have not in the past moved any issues in the Project. Unless there is a dedicated Tester, I would vote that we remove this column for simplification - the issue is either awaiting test, has a bug or a question or is 'done'
+ ~Ready for Signoff (Business)~ - I would also suggest we remove this column as for now, the vast majority of our issues go from `Awaiting Testing` to `Done` as the PO/tester also provides sign off
+ Done 🚀

I suggest we _add_ a 'Dependencies/Open Questions' column to this list because it is useful for the dev team and POs to keep track of what's blocking work.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.