diff --git a/README.md b/README.md index c7c1b233..8b2a4869 100644 --- a/README.md +++ b/README.md @@ -17,7 +17,7 @@ We are still tweaking how our sprints work, see https://github.com/ipfs/communit - [The discussion leads](#the-discussion-leads) - [Sprint Discussion Schedule](#sprint-discussion-schedule) - [Stage 3: Sprint Allocation](#stage-3-sprint-allocation) - - [The GitHub sprint master](#the-github-sprint-master) +- [The GitHub sprint master](#the-github-sprint-master) - [Working Hours](#working-hours) - [Active Contributors](#active-contributors) @@ -25,9 +25,9 @@ We are still tweaking how our sprints work, see https://github.com/ipfs/communit IPFS is adopting a sprint cycle. Each sprint gives us a manageable amount of work per person, to be completed within the cycle. It adds a heartbeat to our development. We will seldom add or drop work mid-sprint, though exceptions may emerge. This means incoming PRs or new issues may not be addressed until the next sprint. We will try to make sure things don't get backlogged for long periods of time. -If you'd like to join a sprint, let `@jbenet` know how much time + and what you'd like to take on. It is recommended to take things off the backlog, and check in with the team at the daily "sprint checkin". +If you'd like to join a sprint, let [@jbenet](//github.com/jbenet) know how much time and what you'd like to take on. It is recommended to take things off the backlog, and check in with the team at the daily "sprint checkin". -Each sprint lasts one week, and will be synthesized into an issue in this repo, as described in https://www.zenhub.io/blog/how-the-zenhub-team-uses-zenhub-boards-on-github/#keepingarecordofsprints +Each sprint lasts one week, and will be synthesized into an issue in this repo. This process is based off of Zenhub's, described [here](https://www.zenhub.io/blog/how-the-zenhub-team-uses-zenhub-boards-on-github/#keepingarecordofsprints). ### Sprint Planning @@ -45,21 +45,23 @@ The **Sprint Planning** meeting happens semi-synchronously. Some of it is synchr **How**: This takes place semi-synchronously on the IRC channel #ipfs. -The sprint checkin is a quick sync-up to fine tune the sprint. It helps the sprint master know what's progressing, what's blocking people, and what adjustments need to be made. This sync is critical to ensure the success of the sprint as a whole. +The sprint checkin is a quick sync-up to fine tune the sprint. It helps the sprint master - and the team - know what's progressing, what's blocking people, and what adjustments need to be made. This sync is critical to ensure the success of the sprint as a whole. -Before the sync (ideally), put your updates for the previous week in the previous week's issue. That way, it is easy to see what was intended to get done, and what gone done. After the previous sprint is over, add your blank to dos to the new sprint issue. If you cannot make it to a sprint checkin, leave your update and comments on the previous Sprint's issue (not on IRC, as it will get lost) before the sync happens. +Before the sync (ideally), put your updates for the previous week in the previous week's issue. That way, it is easy to see what was intended to get done, and what gone done. After the previous sprint is over, add your blank To Dos to the new sprint issue. If you cannot make it to a sprint sync, leave your update and comments on the previous Sprint's issue (not on IRC, as it will get lost) before the sync happens. Each participant gives an update on their assignment, what got done, what didn't, and discusses successes and failures. Participants, the sprint master, and whoever is interested should discuss ways of improving task definition, allocation, and implementation to increase future successes and avoid failures. If you are a partipicant, the normal way of showing assignments is to copy and paste your list from the previous sprint, with `[x]`, `[ ]`, and `[~]` indicating items done, undone, or in progress, respectively. Be sure to copy and paste in small chunks, or IRC may kick you out for flooding the channel. Lines of 5 seems to work well. +The first to update their lists on the sprint issue are the first to go, and so on. The sprint master makes sure everyone knows who is up next. + (This used to happen over a Google Hangout, but it wasted a lot of time to keep >10 people synchronized while people gave individual updates that not everyone was interested in. IRC has been working ok.) ##### The sprint master -- Prepares the sprint's etherpad and posts it to GitHub and IRC ahead of time. To open an Etherpad, go to https://etherpad-mozilla.org. -- Begins Sprint Planning with a roll-call to ping people on IRC. This list can be taken from the members of the previous sprint. + +- Begins sprint sync with a roll-call by pinging active contributors (listed below) on IRC. - Prompts everyone who participated in the previous sprint to update on their work. -- Closes up by making sure everyone who needs to has gone, and posts a link to the Etherpad again, opens the next issue for the coming sprint, and then pings reminders to people to add their items to the Etherpad over the course of the day so that a new issue can be copied over early on Tuesday morning. +- Closes up by making sure everyone who needs to has gone. #### Stage 2: Sprint Discussions @@ -72,7 +74,8 @@ Our sprints cover many different subject areas, that interest distinct but overl The sprint discussions give a high throughput (video call) environment to talk about status, next goals, problems, solution approcahes, and so on. They're mostly free form, but should endeavor to identify a set of tasks to do, even if those tasks won't all get done this sprint. ##### The discussion leads -Each discussion has a lead, and each lead is responsible for preparing for that talk before hand. There is a [sprint-issue-template](sprint-issue-template.md) available for discussion leads to add into an Etherpad for their sprint. Afterwards, notes should go into the current sprint issue. + +Each discussion has a lead, and each lead is responsible for preparing for that talk before hand. There is a [sprint-issue-template](sprint-issue-template.md) available for discussion leads to add into an Etherpad for their sprint; the GitHub sprint master should have already filled out the etherpade with the template, and linked to your Etherpad in the sprint issue. After the discussions, the lead should add the notes directly into the current sprint issue. ##### Sprint Discussion Schedule @@ -102,10 +105,19 @@ Everyone signs up for tasks in the GitHub sprint issue by writing and commenting All tasks are assumed to be commitments, unless it is tagged (inline) with `hope:`. For example: `> - [ ] hope: merge IPLD into go-ipfs`. This should allow some breathing room. -The sprint master should add a short backlog of relevant issues to take up. These can be taken by anybody. If you decide to take it on, please "sign yourself up for it" (move it from the backlog section to be under your name). +The sprint master should add a short backlog of relevant issues to take up. These can be taken by anybody. If you decide to take it on, please "sign yourself up for it" by adding it to your To Do list in your own comment. + +### The GitHub sprint master + +A GitHub sprint master should be responsible for the sprint process every week. The GitHub master: + +- Opens a new issue for the sprint on GitHub, and posts a link to it on IRC ahead of time. To open an Etherpad, go to https://etherpad-mozilla.org. +- Opens an etherpad for each discussion and copies in the [sprint-issue-template](sprint-issue-template.md) to each etherpad, making sure that the etherpad URL matches the discussion link in the new sprint issue. +- Pings each of the discussion leads to remind them to prepare for their talks the next day, preferably by writing an agenda +- Asks people to drop their updates in the old sprint issue before the sync +- Reminds people to drop their TODOs in the new sprint issue after the discussions. -##### The GitHub sprint master -A GitHub sprint master should be responsible for the sprint process every week. This involves: making the new sprint issue, asking people to drop their updates in the old one, reminding people to drop their TODOs in the new one. This does not mean the IRC syncup, but rather the github setup and reminding people. This role should be different than the IRC sprint master, who basically moderates the Monday sync. +This role is different than the IRC sprint master, who basically moderates the Monday sync. ### Working Hours