Update CONTRIBUTING with team practices #83
Conversation
mikeubell
requested review from
edmundonm,
kerrieyee,
n8snyder,
shawnvarghese and
umadesai
CONTRIBUTING.md
Outdated
| new team members aren't surprised by assumed expectations of their colleagues. | ||
|
|
||
| At our sprint reviews, we demo work that has reached the "Done" column and is of | ||
| interest to our users or teammates. |
There was a problem hiding this comment.
do we have sprint reviews?
| @@ -30,3 +36,133 @@ to review and merge. | |||
| For UI changes, please include screenshots to help reviewers. | |||
|
|
|||
| Once approved, the author may merge the Pull Request. | |||
|
|
|||
|
|
|||
| ## "Sprint" rituals | |||
There was a problem hiding this comment.
I don’t think we want to talk about sprints. I think we can rephrase this without talking about sprints
There was a problem hiding this comment.
Sure, do you have a suggestion? Just "Rituals"?
|
|
||
| ### Kanban board | ||
|
|
||
| Because we don't really time-box our work in Sprints, we lean more towards |
There was a problem hiding this comment.
I have no idea what “time-box our work” means.
There was a problem hiding this comment.
In Scrum (the most common agile methodology), Sprints are fixed time (time-boxed) iterations, e.g. two weeks. Usually you'll do a Sprint Planning meeting at the beginning of the Sprint to set the goals and what work you plan to get done in the Sprint.
Given that we are a volunteer organization, time is difficult to predict. Some week's 3 people might put in 1 hour, one week eight people might put in 8 hours. This sentence is trying to explain that we aren't using fixed time iterations.
Would this be clearer?
Because team availablity is difficult to predict from week to week, we don't plan our work in Sprints (fixed-time iterations) and lean towards Kanban agile methodology.
| - There's capacity available to work on the story (e.g., this column is a buffer | ||
| of shovel-ready work). | ||
|
|
||
|
|
There was a problem hiding this comment.
Don’t think we need to have limit.
There was a problem hiding this comment.
We can remove the limit, but I find that it's easy for volunteers and new Brigade members to take on too many issues and then work stalls. Work-in-progress limits help to make sure people finish what they start.
| - Follows documented coding conventions. | ||
| - Automated tests have been added and are included in Continuous Integration. | ||
| - Pair-programmed or peer-reviewed (e.g., pull-request has been merged). | ||
| - Test coverage exists and overall coverage hasn't been reduced. |
There was a problem hiding this comment.
We don’t have any tools doing test coverage.
There was a problem hiding this comment.
I can remove the bullet item or create an issue to add test coverage (not that its a priority).
|
@mikeubell can we merge this and then other folks can make suggestions in future PRs? |
|
@adborden I'd like to see the current comments resolved. In particular: |
We should document our team practices. I've mostly borrowed this from past projcets and tailored it to what I think our practices are.
Goals: