(WIP) Project Management Process document #131
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,287 @@ | ||
| # IPFS Project Management Process | ||
|
|
||
| **Status: work in progress, not even a full draft yet** | ||
|
|
||
| ## Introduction | ||
| TODO: describe the purpose of this document | ||
|
|
||
| - this is an opt-in process, nobody in the community is *required* to use this process | ||
|
|
||
| ## Table on Contents | ||
| - [TL;DR](#tldr) | ||
| - [Projects](#projects) | ||
| - [Roles](#roles) | ||
| - [Product Owners](#product-owners) | ||
| - [Project Leads](#project-leads) | ||
| - [Project Managers](#project-managers) | ||
| - [Structure](#structure) | ||
| - [Overview](#overview) | ||
| - [Goals](#goals) | ||
| - [Backlog](#backlog) | ||
| - [Milestones](#milestones) | ||
| - [Project Roadmap](#project-roadmap) | ||
| - [Organization Roadmap](#organization-roadmap) | ||
| - [Workflow](#flow) | ||
| - [Pipelines](#pipelines) | ||
| - [Stages](#stages) | ||
| - [Flow](#flow) | ||
| - [Example](#example) | ||
| - [Weekly Updates](#weekly-updates) | ||
| - [Roadmap Updates](#roadmap-updates) | ||
| - [Implementation Guideline](#implementation-guideline) | ||
|
|
||
| ## TL;DR | ||
|
|
||
| The IPFS project management process has the following **cadence**: | ||
|
|
||
|
|
||
| Weekly Updates | ||
|
There was a problem hiding this comment. nit: can we make these headings bold? |
||
| - once a week (2 weeks?) | ||
|
|
||
| - discuss last week's progress | ||
| - discuss the plans for next week | ||
|
There was a problem hiding this comment. The bigger focus should be on plans for next week (like 1/3 of the time last week and 2/3 on next week). There was a problem hiding this comment. Agreed, I'm missing that part from our weekly and would much rather discuss who's doing what this week instead of going through what happened last week. |
||
|
|
||
| Roadmap Updates | ||
| - every 3 months | ||
|
There was a problem hiding this comment. at last team gathering, there was a proposal to move it to 4 months, shall we consider that before getting the pm doc in stone? There was a problem hiding this comment. Spinning this particular topic of quarterly vs. third-ly into its own ticket so it doesn't block this PR. See #142 There was a problem hiding this comment. Having thought about this a bit more, I think we should try to drive towards a process where a quarterly meeting doesn't have too significant meaning and rather the work (that would be done in such a meeting) would take place on much more regular rhythm, ie. the roadmap could be updated weekly. Having the roadmap update tied to a 3 month cycle is bad for variety of reasons (@jbenet articulated this well #somewhere else) and we need to be able to adjust faster and generally have more flexibility. There's also the logistical part that just doesn't work for an organization like this: timezones, physical locations, etc., so a better approach would be to do that work async and online. What I think is still important is to review that roadmap together and have the project leads / projects discuss it to make sure dependencies are identified and people generally understand the whys of the organization roadmap a little better (in addition to their own roadmap). Like, main work of generating the milestones for each project should happen before an "official" meeting so that when a meeting is had, people and projects are already prepared. Not sure yet what/how exactly this works out, but I think we should have that mindset as we develop the process. There was a problem hiding this comment. That approach to Roadmaps might work for the contributors writing the code. Something to be cautious about: it gives more flexibility at the cost of predictability for people relying on the software (or deciding whether to commit to relying on it) and for employers who need to justify allocating developer time to open source contributions. We might be able to close this gap by putting the burden of communication & Roadmap stabilization on PMs. Just wanted to flag this very important point of tension between flexibility and predictability. |
||
| - identify, discuss and plan the next steps for the organization as a whole | ||
|
|
||
| The IPFS project management process defines the following **units of work**: | ||
|
|
||
| Projects | ||
| - may contain other projects | ||
| - have a project leader who "roadmaps" (decides what are goals and milestones, and when they should happen) | ||
| - have a roadmap (list of milestones and goals) | ||
|
There was a problem hiding this comment. Can you have milestones in the backlog? There was a problem hiding this comment. No. Backlog contains goals, roadmap contains milestones. |
||
| - have a backlog (list of goals) | ||
|
|
||
| Milestones | ||
| - measurable unit of progress | ||
| - contains a list of goals, ordered by priority | ||
|
There was a problem hiding this comment. A milestone, etymologically, is a waymarker on the road marking distance travelled. Goals are destinations. It seems to me that goals should have milestones, not the other way around. There was a problem hiding this comment. @RichardLitt "goals" would be each step you take in that terminology. And goals would be huge and few (maybe 1-1 with projects?). So not the best metaphor...
There was a problem hiding this comment. I don't think it is a good metaphor, and I think tasks would be better, if we made sure that they are action orientated. I don't think that depending on the lexical semantics of goal having an end-state as opposed to task is a useful distinction, because this really is something that we need to work on, as writers of goals/tasks: instead of relying on there being an end state because of it should be a goal, we should work to make sure that every task is actionable and completable. Put in other words, I don't think the tradeoff will cause us to work less, and I think that having 'task' instead of 'goal' will push us to define our terms better. This is something we have not previously done well as a team, and we'll need to grow to do it right. There was a problem hiding this comment. i hear you. i still i disagree though, i've seen many teams perform differently with small reminders like "this is supposed to be a goal, what is the goal, how do we know we've achieved it?" There was a problem hiding this comment. 'Tasks' are notoriously bad units of work as they make you "do a thing". Goals frame the context differently by providing an end result to drive towards to, possibly including multiple 'tasks' to perform to reach it. Tasks are also way too micro-level to manage, there's no need to track things at such a granular, individual and detailed level. When you reflect on progress and ask "what did we achieve this month?", more meaningful and measurable to answer that question with goals than with tasks: "we improved the API documentation" vs. "we worked on the API documentation". We don't want to measure whether something was worked on for the sake of working on it, but to quantify the output. And what @jbenet says above about the subtle difference being a factor in the output is very true and I've seen that happen multiple times. Task is "mundane work that you need to perform" whereas a Goal is "something to aim for, to desire, to reach and accomplish". While we're not limited to "standard" terminology, it's also good to keep in mind that (all of?) these terms are standard ways to describe project management related activities and changing the meaning of the terms will be a knowledge barrier to entry for new projects and contributors. There was a problem hiding this comment. This is a really important thing to make sure to capture on a PM FAQ. I generally agree that we don't need a super fine grained micro-level units of work to manage, but we also should not ban it if people like to describe their goals with micro tasks, for some (myself included) it is extremely useful to write down all the things that a goal needs in order to be finish and then go through each of those items and put a ✔ on it. Tasks can appear just when checking in that the goal was completed. |
||
| - usually but not always sequentially ordered | ||
| - may have a deadline | ||
|
There was a problem hiding this comment. I would like to always have an 'Estimated dates of delivery', and an update each time the dial moves. There was a problem hiding this comment. I would like to introduce that with full buy-in into a small project, not all-projects-wise. In my experience, this can easily turn into meaningless dates, guilt-inducing-work-blocking dates, or constant-overhead-to-upkeep dates. Before imposing it on everyone, i'd love to see it working well in one team. maybe the js-ipfs team can be the shining example on this. There was a problem hiding this comment.
There was a problem hiding this comment. I'm strongly against requiring having dates of delivery. It is good to have an idea of "to implement feature X, it will take us roughly Y days". But in my experience having to figure out dates and explicit timelines is a huge time sink and at the end only causes frustration because the timelines are pretty much never accurate. There was a problem hiding this comment. Perhaps "Due date" and "Deadline" imply too much of a required completion time. I wanted to have something that describes expected or estimated completion time. I agree with all you said above re. dates and their failures and didn't mean to introduce a hard requirement here. The thing with milestone dates is that you always slip and it becomes a matter of adjusting the milestone content to hit the date or adjust the date to finish everything you wanted to finish for a milestone. Let's make sure that we have that possibility and that milestone dates (if any) are not set in stone. Perhaps "Estimated completion date" is better? There was a problem hiding this comment. I feel much more confident having a "Estimated Completion/Delivery Date" and then adjusting it if need be, than having to timeline at all and not have a way to understand how much we have derailed. I understand that deadlines have a bad connotation, but they also give us signals of where we need to put more energy and establish priorities. |
||
|
|
||
| Goals | ||
| - an individual actionable unit of work | ||
| - may have other Goals as dependencies | ||
| - may have parts or sub-goals | ||
| - may have parts or sub-goals big enough to merit own Goals | ||
|
|
||
| The IPFS project management process, planning and tracking work is done with the following **tools**: | ||
|
|
||
| Roadmaps | ||
| - are attached to a project | ||
| - have a list of milestones, ordered by completion time | ||
|
There was a problem hiding this comment. Does this mean milestones MUST HAVE a chronological order? Can there be cases where they are happening in parallel? There was a problem hiding this comment. Milestones don't HAVE to have chronological order and they can happen in parallel. Will try to make this more implicit in the document. There was a problem hiding this comment. That being said, a milestone in itself doesn't "happen" along a time axis, it's merely a specific point in time. The work on the goals in different milestone, however, can happen in parallel. |
||
|
|
||
| Backlogs | ||
| - are attached to a project | ||
|
There was a problem hiding this comment. like the ROADMAP? Such as BACKLOG.md? There was a problem hiding this comment. Could be BACKLOG.md, could be GH Issues (personal preference), could be a spreadsheet, could be a database, could be a post-it board, could be back of a napkin :) |
||
| - have a list of all goals for a project, ordered by priority | ||
|
There was a problem hiding this comment. "...list of all unfinished goals..." ? |
||
|
|
||
| Pipelines | ||
| - have a set of stages through which goals move (the steps between "not done" and "done") | ||
| - show what has been completed, what's being worked on at the moment and what will be worked on next | ||
|
|
||
|
|
||
| ## Projects | ||
| TODO | ||
|
|
||
| ## Roles | ||
| TODO | ||
|
|
||
| #### Project Leads | ||
| TODO | ||
|
|
||
| #### Product Owners | ||
| TODO | ||
|
|
||
| #### Project Managers | ||
| TODO | ||
|
There was a problem hiding this comment. I'm interested in knowing what goes here. A item list of the things you want to describe would be good enough to start There was a problem hiding this comment. Having thought about this, I would actually leave out the Product Owners part (not used anywhere else in the document and can be different per project, and as an organization, who's a product owner and who's not?). Perhaps leave out the project managers part, too as this would be more an individual roles on the participating organizations. Or should we try to describe the roles of project managers? |
||
|
|
||
|
There was a problem hiding this comment. We should also add the roles from the current README. In particular, I'm curious how the sprint administrator will change (me). |
||
| #### 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. | ||
|
There was a problem hiding this comment. This is now the templates/agenda-for-project-sprint-calls.md. |
||
|
|
||
| #### Sprint Administrator | ||
|
|
||
| The sprint administrator (normally [@RichardLitt](//github.com/RichardLitt)) is responsible for the sprint process every week. | ||
|
|
||
| ***TODO: Link to a document with the specific tasks*** | ||
|
|
||
| ## Structure | ||
|
|
||
| ### Overview | ||
| The project information across the organization is tracked with the structure described in this section. At the highest level, we have an Organization Roadmap, which lists all projects and their milestones. Each project contains a set of milestone and milestones contain one or more goals. Goals are the basic unit of work and they describe everything from bugs and new features to general tasks. Goals are collected and tracked in a Backlog. | ||
|
|
||
| ``` | ||
| Organization | Project 1 Project 2 | ||
| | | ||
| Roadmap | Roadmap Roadmap | ||
| | | ||
| Milestones | Milestone 1 Milestone A | ||
| Milestone 1 | Goal 1 Goal A | ||
| Milestone 2 | Goal 2 Milestone B | ||
| Milestone 3 | Goal 3 Goal B | ||
| Milestone A | Milestone 2 Goal C | ||
| Milestone B | Goal 4 Goal D | ||
| Milestone C | Milestone 3 | ||
| | Goal 5 | ||
| Projects | | ||
| Project 1 | Backlog Backlog | ||
| Project 2 | Goal 1 Goal A | ||
| Project 3 | Goal 2 Goal B | ||
| | Goal 3 Goal C | ||
| | Goal 4 Goal D | ||
| | Goal 5 | ||
| ``` | ||
|
There was a problem hiding this comment. I don't understand this chart. Where is Project 3? Why is there a mixture of numbers and letters? Why are milestones under the Roadmap, and under projects - shouldn't they just be under projects? Can goals be in multiple milestones? There was a problem hiding this comment.
There was a problem hiding this comment.
My questions aren't so much "I don't understand" as they are "This is confusing and may confuse people, we should adjust it accordingly." Laying out your points in the text would help. There was a problem hiding this comment. My original goal for this graph was to show how the information hierarchy works between projects and organization and how the organization derives its roadmap from the projects, not necessarily "belongs to" or "is in 1" relationship. Fail, obviously. I'll try to improve this, thinking of lines and arrows or an explanation text to describe what you see in the graph. Suggestions appreciated! As for milestones vs. goals:
I would say no. A goal should only be in one milestone. If there are cases where a goal would belong to two milestones, then that goal should be broken down. I can't think of a case where you would need a goal in two milestones at the same time, any examples you can give?
Not sure which part you mean. Can you provide an alternative text? |
||
|
|
||
| ### Goals | ||
| At the heart of each project are the goals. They are the basic unit of work. Goals can be anything that ***adds value to a release***. This includes issues reported by users, feature requests, bugs, Pull-Requests, general tasks such as refactoring, documentation or research. Goals are collected, maintained and tracked in the backlog by the project lead. | ||
|
|
||
| A goal description includes the following: | ||
| - Name / Summary | ||
| - Describes what the goal is on high level | ||
| - Example 1: "Reduce the size of the go-ipfs executable" | ||
| - Example 2: "js-ipfs should have API Documentation" | ||
|
There was a problem hiding this comment. These are worded very differently. We should have a section about actionably wording names. There was a problem hiding this comment. NB: I'm not sure if this is injecting too much of my methodology here, but I would push back against these issues if they were in my repo so I'm skeptical of using them as examples here. I recommend changing the examples to read more like this: Example 1: "Reduce the size of the go-ipfs executable to 850kb or less" This is because with the current wording you could satisfy both of these goals by doing something trivial. They aren't adequately clear about the work that needs to be done or how you will test whether it has been done. FWIW, this article, The Definition of Ready in Scrum, frames a big part of how I tend to think about whether a ticket/goal is adequately framed and ready to work on (they must be clear, testable and feasible). Is that too Scrum-specific? There was a problem hiding this comment. 👍 to @flyingzumwalt's comments. would love to make our goal titles clear, testable, and feasible. There was a problem hiding this comment. 👍 to have goals with clear ways to assess their completion. |
||
| - Description | ||
| - What the problem is and how to achieve this goal | ||
|
There was a problem hiding this comment. Why not two sections? These are two very different things. There was a problem hiding this comment.
There was a problem hiding this comment.
This is hugely important point. I don't think forcing anything, be it a template or otherwise, will help us get off the ground. A lot of the "best practices" will come over time as we do it and get a feeling of what matters and what doesn't. And individually we'll become better at wording them as we enter new goals and tasks for our projects (eg. how to word a task as a goal but still have a "task" in the backlog). |
||
| - Should tell you how you will know that the problem has been solved or the goal has been achieved | ||
| - 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) |
||
| - Status | ||
| - The status should signal the goal's status towards completion | ||
| - What is the current state of this goal? Is it to-be-reviewed? In progress? Blocked? Done? | ||
| - A goal can be in only one state at a time | ||
| - Dependencies (where applicable) | ||
|
There was a problem hiding this comment.
|
||
| - Links to other goals that must happen before or concurrently with this one | ||
| - Any additional information that helps to reach this goal (optional) | ||
|
|
||
| TODO: a clear example | ||
|
|
||
| ### Backlog | ||
| Backlog is the collection of all goals in a project. It should be as comprehensive as possible, including everything that needs to happen or should happen in a particular project. The backlog indicates priority by order: the items that have the highest priority are at the top of the list. The backlog is owned and maintained by the project lead. As part of daily work, the backlog gets updated and a general grooming should happen on weekly basis. | ||
|
There was a problem hiding this comment. What's the difference between daily work updating, and general grooming? There was a problem hiding this comment. In my head the difference is that daily work usually involves a particular set of goals that are being actively worked on --> more attention, daily grooming. General grooming == goals that are not being worked on actively but still need attention (eg. preparing goals to be ready to be worked on, updating their status as discussions evolve, etc.). Or changing goal priorities is grooming work that falls outside the "daily work". Does that make sense? There was a problem hiding this comment. From my perspective (and what I typically do and apparently similar to @haadcode's version) it is:
|
||
|
|
||
| A backlog has the following information: | ||
| - All goals of a project | ||
| - Priority of goals in sorted order | ||
|
|
||
| While the backlog is usually one big list of goals, it may sometimes become convoluted. In this case, the backlog list can be split in two: ***Backlog*** and ***Future Work***. The future work section lists goals that will probably not be worked on anytime soon, or are not ready to be worked on yet, whereas the ready section contains the goals that are ready to be worked on or "approved". If split, together they are called "the backlog" while *Future Work* is referenced only in its specific meaning. The split and maintenance of both lists are done by the project lead. | ||
|
There was a problem hiding this comment. (oh wow, I totally remember writing this before but now i can't find it in prior comments so maybe i didn't...)
There was a problem hiding this comment. I agree that I would also like to have an One thing that I feel missing, is a way to communicate if something is in our roadmap, but just not right now. e.g: I've been deferring all the examples + tutorial issues with the label Milestone 4, this way I can show our intent to handle it during the expected timeline defined by the roadmap, but also not make it distracting by being on the backlog, nor in the Future Work area, which might sound it was forgotten. Note: I believe I understand that from the process defined, that this demonstration of intent, but need to defer could be done by ordering the issues on the backlog, as it is described above, however, think in projects like js-ipfs or go-ipfs with hundreds of issues/items, it gets very hard to be very efficient digging through and finding where a given issue/request/action item is going to land. There was a problem hiding this comment. Clarifying: @haadcode originally had the terms "Backlog" and "Icebox" in this paragraph. I commented that in the Hydra Project we called the Icebox "Future Work" because we were a sassy bunch, but we all knew it was the icebox. @jbenet liked the term more than I expected so @haadcode switched it. "Icebox" is more honest. "Future Work" is basically subterfuge, letting you seem to say yes to lots of things without actually committing to do them. It also creates the exact semantic confusion you're discussing here. There was a problem hiding this comment.
There was a problem hiding this comment. Regarding @diasdavid's comment
I think that is the purpose of Milestones -- to show that certain work is on the roadmap, and where it is on that roadmap. By contrast, the backlog and the Icebox/Unstaged will both contain lots of stuff that's listed in Milestones. The milestones show you the Roadmap view so you can answer questions like
Meanwhile the pipeline with Icebox, Ready, In Progress, etc. gives you the working view so you can answer questions like
Given that, could you clarify what you think is missing? Are you saying that the Roadmap should have milestones that are marked "Future Work", indicating that they're things we haven't explicitly scheduled but we have them on the long-term Roadmap? There was a problem hiding this comment. Not quite, let me clarify my point of view then. It is important to categorize our project visitors with regards to what they are looking for when they come to 'visit' the project. I believe there are mainly two classes (that some groups may overlap over the two): The Users/Consumers The groups that want to use project X or are already using project X and therefore want to know when they can have the feature Y, so for that, the Roadmap with milestones is perfect 👌. The Hackers/Contributors The community members that want to help the project form itself, that want to learn with it and have energy available to invest in the development of the project. These groups will appreciate the Roadmap, however, when they will need to understand how these Roadmap milestone/goal items map to each repository (i.e. the collection of issues), so they can understand more how to participate on that specific endeavour. To solve this, what I did for js-ipfs was creating issues to track each of this goals (e.g ipfs/js-ipfs#58, ipfs/js-ipfs#51, ipfs/js-ipfs#60, ipfs/js-ipfs#92) so that I had a live thread for each goal inside milestones. This seemed to work well. It also enabled me to tag issues with difficulty and what was 'blocked' or 'unblocked', it was just great 👌 Now, coming from another way, instead of being a person that just eagerly wants to hack on something, actually has an issue that they would like to get solved (or an example they would like to see written), but unfortunately, that is not part of our Roadmap until the 4 milestones after. It might be clear for us that issue needs to be postponed, but since we only have a way to label it 'backlog' or 'future work', it might not be clear if we 'froze it' or how long are we deferring it. These last two points is where I feel something is missing from the pm doc. In js-ipfs, I felt the need to patch that hole by creating the tracking issues and by labelling issues with the milestone numbers. Here is an idea, we define a metric, like 'number of contributions' over a unit of time of length Z and we see how that metric evolves. My guess is that each project Captain will have specific last touches when they apply the Model to their Mechanics, once those are in place and we have metrics, then we can revisit what makes a project really good to invite collaborators in and understand how we can do to optimize for that across the board. There was a problem hiding this comment. Well they would be able to see the milestones too and what milestone it belongs to, right? Presumably the goal carries information as to why it's slated for that (far) milestone. if it doesn't they could ask and find out. if it's dependencies, they can hack at those, if it's just low prio, they can tackle it right away. There was a problem hiding this comment. Re. the naming. I feel "Backlog" should be a term for the place where all goals are collected in. Further, much as the backlog provides a mechanism for priority information, it can contain sections too, such as "Future Work" or "Ready", but they'd be more like categories within/inside the "Backlog". That way we allow flexibility for projects to decide how they want to categorize their goals in the backlog, if any. Some might want to have an icebox, some may have more detailed "not done" process within the backlog, between "inbox" and "ready". What do you think? There was a problem hiding this comment. More on that: I like "TODO" and "Ready". I would use them so that I pull goals for this week from the backlog to "Ready". This would give an idea what is going to happen very soon, what is happening atm, what was recently done and the full backlog of what is coming/might come/etc. at some point in the future. There was a problem hiding this comment.
This could be communicated via the roadmap, right? I think that would be the best place to communicate it. And if we decide we don't want the roadmaps to include the individual goals, there's surely a way to view the backlog in a way that answers those questions. (If we assume that "Issues" in GH is our backlog, then perhaps there's a way to search/otherwise to display (using labels?) goals per milestones sorted by milestone ETA. The "Milestones" section in GH does this nicely out of the box.) |
||
|
|
||
| ### Milestones | ||
| A milestone is batch of goals that together achieve a significant improvement to the product or project. Each project has a set of milestones. A milestone is completed when all goals associated with it have been completed. Milestones are tracked in the project roadmap by the project lead. | ||
|
There was a problem hiding this comment. maybe "significant, measurable improvement" or something |
||
|
|
||
| A milestone has the following information: | ||
| - Name | ||
| - Example 1: "Release go-ipfs v0.5.0" | ||
| - Example 2: "Working prototype of Pubsub implementation in go-ipfs" | ||
| - Example 3.1: "go-ipfs and js-ipfs implementations can interoperate" | ||
| - Example 3.2: "go-ipfs and js-ipfs clients use the same network" | ||
| - Description | ||
| - List of goals attached to it | ||
| - Progress indicator | ||
|
There was a problem hiding this comment. In cases where a milestone needs a bit of description, or links to related docs, does this go into an optional description section in the milestone or does it go somewhere else? There was a problem hiding this comment. Does the Progess Indicator really belong in the model specifically? The progress indicator seems to be just (# of Goals done / # of Goals total). This can likely be measured similarly within a Goal (as Goals will likely have subparts, though not significant enough to track in this model). There was a problem hiding this comment. I would like to see a progress information tied to each milestone. Without it, there's no real way to track the status on higher level as it would be either "done" or "not done". I would like to be able to look at a project and answer the questions "how far are we from completion?" as there's a big difference between 2 / 10 and 9 / 10 goals completed. Perhaps it could be described as "Status" instead of "Progress indicator"? |
||
| - Deadline (where applicable) | ||
| - List of dependencies and related material (where applicable) | ||
|
|
||
| The Project Lead keeps current milestones up to date on weekly-basis. New milestones should be generated and old milestones updated before the quarterly planning meeting. Prepare new milestones in good time before quarterly planning. | ||
|
|
||
| Milestones help make Roadmaps achievable, and they give the team and users a clear sense of progress. There's no hard and fast way to decide what a Milestone's boundaries are. It is up to the project leader to select what Goals constitute a Milestone and what Milestones constitute a Roadmap. Sometimes it will be clear how to break down a Roadmap into manageable pieces. Sometimes it will be clear which goals to bundle in a Milestone. The important thing is to make manageable groups (not too big) that provide a significant enough sense of progress through the Roadmap. | ||
|
|
||
| TODO: a clear example | ||
|
|
||
| ### Project Roadmap | ||
| The milestones are tracked in project's roadmap. The project lead owns the roadmap and is responsible for generating, updating and tracking the milestones. To make sure the roadmap is up to date, the project lead should go through the current milestones on weekly basis. | ||
|
There was a problem hiding this comment. Where do Releases fit? Are Releases tracked as Milestones or do they get separate treatment? There was a problem hiding this comment. I'm not sure, but:
|
||
|
|
||
| The Roadmap Document contains the following information: | ||
| - List of current milestones | ||
| - Sequentally ordered, eg. by expected due date (where applicable) | ||
| - Next upcoming milestone at the top | ||
| - Current status of the project, ie. milestone progress | ||
| - List of previous milestones | ||
|
|
||
| The roadmap can be a high-level overview of milestones and project's progress, so details such as list of goals per milestone can be omitted. However, if omitted, the roadmap must contain links to the detailed break down. | ||
|
|
||
| Examples: | ||
| - [js-ipfs roadmap](https://github.com/ipfs/js-ipfs/blob/master/ROADMAP.md#ipfs-javascript-implementation-roadmap) | ||
| - [Orbit roadmap](https://github.com/haadcode/orbit/blob/master/ROADMAP.md#orbit---roadmap) | ||
|
|
||
|
|
||
| ### Organization Roadmap | ||
| An overview of all projects across the organization is tracked in organization's roadmap. This is similar to a project roadmap, but collects all milestones from all projects into one place. | ||
|
|
||
| Organization roadmap contains the following information: | ||
| - List of all projects | ||
| - List of all current milestones and their progress in each project | ||
| - List of links to old milestones | ||
|
|
||
| The organization roadmap is owned by project management and project managers are responsible for generating and keeping the roadmap up to date. The roadmap should be updated in the quarterly planning meeting as old milestones are reviewed and the project leads commit to new milestones. | ||
|
|
||
| TODO: a clear example | ||
|
|
||
| ## Workflow | ||
|
|
||
| ### Pipelines | ||
| 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
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)
Can you elaborate on this? Which parts doesn't fit what general idea?
You mean you'll track things on more granular level than "not done" -> "done"?
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?
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. |
||
|
|
||
| ***Proposal: Unify "Future Work", "Backlog" and "Done" stages for all projects, let project leads define stages of the "Development" phase.*** | ||
|
There was a problem hiding this comment. Hmm not sure about this. I do think that for "tracking progress" and for "knowing what's blocked" it will be VERY useful to have a single pipeline we all agree to support (i.e. the kanban progress pipeline). So that we can have the invariant that i can always go to Other pipelines can go in their own secondary waffle boards, like There was a problem hiding this comment.
I'm not sure this is possible with Waffle. If two boards use different labels as their pipeline stages, would waffle be able to handle that? A issue is in "Backlog" in one and in "Milestone 1" in the other? |
||
|
|
||
| #### Flow | ||
| Goals move from pipeline's entry stage towards the completion stage and a Goal can be only in one stage at a time. Usually goals move one way, in sequential order, but sometimes goals can move back between the stages (eg. `In Progress ──> Review ──> In Progress`). Sometimes a goal can't progress due to something preventing it to move to the next stage. To ensure surfacing blockers, each pipeline should have a ***"Blocked"*** stage where blocked goals are moved as soon as they occur. | ||
|
There was a problem hiding this comment.
No, this does not fit ALL pipelines ever. Some pipelines are not for tracking blockages, or progress at all. Please either:
There was a problem hiding this comment. En example of a pipeline NOT to track "development progress": There was a problem hiding this comment. I think we need to drill into the terminology here again as I feel there's a difference of perspective to its meaning. I think you're coming more from the perspective of "everything is a pipeline", eg. non-development pipelines such as "hiring pipeline", meaning the full process of a particular area. Am I correct? What I mean with a pipeline in this context is the mechanics of how value gets produced within a project, ie. how a goal gets from the backlog to a release, to "not done" to "done". It's the "assembly line" or the "production line" of producing an artifact.
Can you give an example what you're thinking here? I see it the opposite: every pipeline, while not (explicitly) for tracking progress, gives you progress information.
That's why it's should and not must. If you consider a pipeline a away to process goals and tasks, then it's highly beneficial to make sure the pipeline processes those goals as fast as possible, no? A blockage creates friction and causes the pipeline to output slower, so it is in your best interest to know asap and as clearly as possible if something is not moving, right?
As an example here, while you could consider the "Block bad bits from Gateway" as a pipeline, it could also be considered a checklist, eg. a quality criteria or a task list to move to the next stage. You could still model it as a production pipeline, and simplify the stages to: Backlog ("Receive report") -> "In Progress" (from "validate" to "Test Block" ) -> "Done". There was a problem hiding this comment. This is a tough one. I agree that it'd be better to have "one model" for all projects, because it makes everything so much easier: getting into a project without knowing the context for their specific pipeline, reducing clutter for first-time visitors and enable automation to be written quickly (eg. if all projects use the same labels, we can easily grab a collection of goals per label across all repos). However, it limits individual projects to adapt to their needs. If we allow customizing or rather defining the stages per project, it'll make automation harder and require extra acclimatization when looking at a new project. But it does allow everyone to be flexible and manage their projects the way fits them the best. There was a problem hiding this comment. Giving feedback as requested. I could expand on this a ton, but compressing:
|
||
|
|
||
| #### Example | ||
|
|
||
| ***An example pipeline could have the following stages:*** | ||
|
|
||
| ``` | ||
| ╭─────────────────────────────────── Pipeline ──────────────────────────────────────╮ | ||
| │────── 1. ────│──── 2. ───│─── 3. ──│────── 4. ─────│─── 5. ───│──── 6. ───│── 7. ─│ | ||
| │ Stages │ | ||
|
|
||
| ╭────────────╮ | ||
| ──> Future Work ──> Backlog ──> Ready ──> In Progress ──> Review ──> Release ──> Done ──> | ||
| │ │ │ │ │ | ||
| ╰─────────────╯ │ │ │ | ||
| ╰───────── Blocked ────────╯ | ||
| Phases | ||
| │───────── Backlog ────────│──────────── Development ───────────│──── Complete ─────│ | ||
| ╰───────────────────────────────────────────────────────────────────────────────────╯ | ||
| ``` | ||
|
|
||
|
|
||
| 1. Future Work - the goal is identified and being fleshed out. It is not ready to be carried out at this moment. | ||
| 2. Backlog - the goal is well defined but not planned to be carried out at this moment. | ||
| 3. Ready - the goal is planned to be carried out, waiting to be worked on. | ||
| 4. In Progress - the goal is actively being worked on, this moment. | ||
| 5. Review - the development of the goal is done, but a review needs to happen before it can be included in a release. | ||
| 6. Release - the goal is waiting to be inckuded in a an official release. | ||
| 7. Done - the goal is completed. No further action is necessary. | ||
|
|
||
| * Blocked - the goal cannot proceed as something is preventing it to move down the pipeline. | ||
|
|
||
| ### Weekly updates | ||
| To review and discuss progress of each project and the organization as a whole, we hold weekly update meetings. | ||
|
|
||
| TODO: describe our weekly process. don't call it a "Sprint" anymore(?) | ||
|
|
||
| ### Roadmap updates | ||
| To review and discuss progress of each project and the organization as a whole, we hold quarterly roadmap update meetings. | ||
|
|
||
| TODO | ||
|
|
||
| What: | ||
| - Event to update and plan the organization's / project's roadmaps. | ||
| - Identify projects' / organizations' needs and main efforts. | ||
| - Commit to efforts and goals. | ||
| - Produce a high level overview of a roadmap. | ||
|
|
||
| Who: Product Owners, Project Leads, Project Managers | ||
| How often: Every 3 months | ||
| Output: Organization Roadmap (responsible: PM) | ||
|
|
||
| This could be also a constant process instead of doing all that work tied to quarterly event. If the work was constant, we could still have an update event to go through the updated/new roadmap(s). | ||
|
|
||
| ## Implementation Guidelines | ||
| TODO | ||
|
|
||
| - 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.
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. |
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean by exclusive?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Saying that something is
opt-inandnot requiredshould not be the same asyou don't have to buy in into the process, but if you want to understand how to contribute, you have to buy in