(WIP) Project Management Process document #131
Conversation
…cument. Add examples of project roadmaps.
|
Overall looks good to me, i'm looking forward to having more structure. My only questions are about tooling, what sort of format do you see the roadmaps being done in? would they be a public webpage? a waffle board? something custom? |
| - Example 2: "js-ipfs should have API Documentation" | ||
| - TODO: what is a good name for a goal? | ||
| - Description | ||
| - What the problem is and how this goal solves it |
There was a problem hiding this comment.
I usually emphasize that the description should tell you how you will know that the problem has been solved or the goal has been achieved. The description should give enough info to finish the statement "You will know this is done when..."
Related: it's important to emphasize that goals should always have a clear completion state. Example: "Better test coverage" and "Improve UX" are bad goals.
There was a problem hiding this comment.
👍 yeah +1 for making the goals result-oriented and properly actionable.
|
|
||
| ### Project Managers | ||
| TODO | ||
|
|
There was a problem hiding this comment.
We should also add the roles from the current README.
### Roles
#### The Sprint Master
Ideally, there should be a sprint master who knows every participant's tasks and projects intimately, helps moderate work loads, checks in when a task has been taking long than expected, sets the sprint goals, and adds any urgent or incoming business to the sprint. Realistically, this is done by the discussion leads and the team as a whole. The sprint administrator was created to minimize the sprint master's admin, and to help the discussion leads.
#### 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; the admin should have already filled out the Etherpad 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 Administrator
The sprint administrator (normally [@RichardLitt](//github.com/RichardLitt)) is responsible for the sprint process every week.
** GitHub tasks**
- 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.
** Sync tasks**
- Begins each 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. The best way to choose who goes first is to go off of a first-post-first-sync method, where all participants add their updates to the old PM issue, and the first to do so generally syncs first in the IRC channel.
- Closes up by making sure everyone who needs to has gone.
** Discussion tasks**
- Sets up the videos and moderates them, using the process outlined in [hangouts.md](hangouts.md).
In particular, I'm curious how the sprint administrator will change (me).
| - Description | ||
| - What the problem is and how this goal solves it | ||
| - Type | ||
| - Describe the type of this goal: is it a bug? a new feature? something else? |
There was a problem hiding this comment.
i'd be wary of introducing types as a construct. i think just leave it out. Issues will have different "types", "tags", "labels" and that will be clear/implicit in the descriptions. removing the notion from this model will simplify the model without losing anything ("type" does not get used anywhere else in this document)
|
It seems to me this model (in a more lossy, succinct description, just to get an overview) is: Work units hierarchyThis is a breakdown of the work into different granularity. Projects
Roadmap (not a work unit, attached to a project)
Milestones
Goals
Kanban (Progress Pipeline)This is a view into the "Progress Status" (stage in the progress pipeline) of a Goal (maybe Milestones too). Stages:
|
|
@haadcode @RichardLitt could you look at what we're cutting out of the README and grab anything that should be pulled into this doc? @RichardLitt already suggested the part about roles (Sprint Master, Sprint Administrator, etc.) Is there anything else? |
|
Updated the document and the new revision should address most of the feedback. Tried to reply to each individual comment with a 👍 or details. Added the sprint roles @RichardLitt suggested. Added a tl;dr section based on @jbenet's break down of the units of work. Tweaked the descriptions as per @flyingzumwalt and Juan's comments. Let me know if I missed anything. Will continue to work on this to fill in the missing sections. |
| The IPFS Project Management Process uses Pipelines to process goals towards a release. Pipelines are a simple way to describe the workflow of a project and move Goals between the different stages in their lifecycle. | ||
|
|
||
| #### Stages | ||
| Pipelines are sequential stages through which a Goal goes during its lifetime. The different stages are broken down per the workflow of each project. On high level the stages can be described as: `Not Done ──> In Progress ──> Done`. Different projects might have different stages in their development pipeline and it is up to the project lead to identify and define the stages her project uses. |
There was a problem hiding this comment.
i dislike this characterization of "pipeline" here because
- it doesn't fit the general idea
- i'm going to use "pipelines" to track things beyond individual Goals' "not done -> in progress -> done".
- maybe use "Progress Pipelines" to denote the pipelines that track progress according to this model (goals, etc?). OR just mention the "Kanban Pipeline" ?
For example, i will create concrete pipelines to handle publishing talk materials, which will look like this: https://ipfs.io/ipfs/Qmb4EXZ8uWBrFGpa8GDvFkvvtL5GN2TSuq2gtMXc6zwUng/#README.md -- there's multiple pipelines, that will span multiple people, with multiple pieces of work, across multiple repos. I've no idea yet how this kind of pipeline would be instantiated (mechanics), but this is a very different sort of pipeline that does not follow the model of "in progress
I can imagine other pipelines that would fork (i.e. items go different directions depending on what they are).
There was a problem hiding this comment.
See this comment first: #131 (comment)
i dislike this characterization of "pipeline" here because
it doesn't fit the general idea
Can you elaborate on this? Which parts doesn't fit what general idea?
i'm going to use "pipelines" to track things beyond individual Goals' "not done -> in progress -> done".
You mean you'll track things on more granular level than "not done" -> "done"?
maybe use "Progress Pipelines" to denote the pipelines that track progress according to this model (goals, etc?). OR just mention the "Kanban Pipeline" ?
I'm not a fan of the "Kanban pipeline" as Kanban adds a very specific meaning to it (mainly adding the "production limit" to a stage) and I would like to not tie us to that particular meaning. "Progress pipeline" on the other hand, imo, doesn't add more meaning to it: a pipeline, by nature, displays progress. Perhaps, if something needs to be added to clarify "pipeline", then "Production pipeline" would be more suitable?
i will create concrete pipelines to handle publishing talk materials, which will look like this... but this is a very different sort of pipeline that does not follow the model of "in progress
This is why I proposed that we let individual projects decide on the "production" pipeline part: they may have very different steps to other projects. That being said, what you describe in your "talk pipeline" example is still "not done" -> "done" at the highest level: you have something in the backlog that you want to turn into value and that values gets released along the pipeline in multiple nuggets (talk delivery, online follow up, material assets: slides/video, etc.). The concrete value is not in "done" as it is for most software production pipelines. You could also consider the granular steps in your example as checklists for the high-level stages (first picture).
In general, it's better to keep pipelines as simple as possible and add detail (stages, sub-pipelines) only when it really makes sense, it's easier that way.
this doc is progressing awesomely \o/ super good to have this. |
| ## Introduction | ||
| TODO: describe the purpose of this document | ||
|
|
||
| - this is an opt-in process, nobody in the community is *required* to use this process |
There was a problem hiding this comment.
However, it also should not be exclusive. It is important to preserve a view of things that members of the community can quickly jump into and hack to contribute.
There was a problem hiding this comment.
What do you mean by exclusive?
There was a problem hiding this comment.
Saying that something is opt-in and not required should not be the same as you don't have to buy in into the process, but if you want to understand how to contribute, you have to buy in
|
This is looking pretty solid, thank you everyone that have been working and reviewing it exhaustively ❤️ I like how kanban was augmented with our project roadmaps and discrete milestones, I'm also happy that we are keeping sprints to ensure velocity. The only thing I'm missing the most is with regards to our open source contributors, we need to have a way to understand what is open for help and that is important that energy is invested on that right now (aka milestone specific ready state issues that are not being handled by someone). The more clear we make this, more contributions we will have. |
| - automation | ||
| - Generating milestone documentation: https://github.com/ipfs/pm/pull/131#discussion_r73778673 | ||
| - github | ||
| - waffle |
There was a problem hiding this comment.
I suggest adding https://github.com/philschatz/gh-board as a possible alternative to waffle or at least talk about it
There was a problem hiding this comment.
We can make it so that it knows how to cache things and only use the requests to manipulate the issues. Would love to be able to have the board offline!
There was a problem hiding this comment.
We can make it so that it knows how to cache things and only use the requests to manipulate the issues.
It also does quite a lot of this, it tries to cache the request in local storage so if you revisit it, it does not have to redo all the requests.
|
Commented on all the things. Next: revisit the document and address feedback and comments. |
In your projects, do you know 100% what are the most important issues to be worked on now that you could point every new contributor to? If so, how many of those goals are not goals for the next milestone in that project? If you have that information (even in your head), would the following make it clear to understand:
Does that make sense? |
Yes, but things like |
|
Is everyone ok with me merging this document as-is (It's in the 'drafts' folder) and closing this PR? That way the comment threads here won't get lost when we edit the associated lines in the document -- we will still have this PR for reference while @em-ly and I move the document towards a final draft with new PRs. @haadcode @diasdavid @whyrusleeping @jbenet |
|
I'm ok with that :)
|
|
Absolutely fine with that! Thank you for picking this up. Hopefully with the doc in the repo, others can join the writing effort. |
|
Sounds good :) |
Here's a working document for defining the project management process for IPFS. Discussion has happened here: #125.
Currently only the structure has been written down (excluding Backlog section).
Feedback on the sections that don't say TODO would be highly appreciated. Also, let me know if there's something important missing from the structure part or otherwise.