Skip to content
This repository has been archived by the owner on Feb 8, 2023. It is now read-only.

(WIP) Project Management Process document #131

Merged
merged 13 commits into from
Aug 18, 2016
Merged

(WIP) Project Management Process document #131

merged 13 commits into from
Aug 18, 2016

Conversation

haadcode
Copy link
Member

@haadcode haadcode commented Aug 3, 2016

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.

@whyrusleeping
Copy link
Member

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 yeah +1 for making the goals result-oriented and properly actionable.


### Project Managers
TODO

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

@flyingzumwalt flyingzumwalt mentioned this pull request Aug 5, 2016
- 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?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

@jbenet
Copy link
Member

jbenet commented Aug 6, 2016

It seems to me this model (in a more lossy, succinct description, just to get an overview) is:

Work units hierarchy

This is a breakdown of the work into different granularity.

Projects

  • may contain other projects
  • have a project leader who "roadmaps" (decides what are goals and milestones, and when they should happen)
  • has a roadmap

Roadmap (not a work unit, attached to a project)

  • attached to a project
  • has a list of milestones, ordered by completion time

Milestones

  • measurable unit of progress
  • contains a list of goals, ordered by priority
  • usually but not always sequentially ordered
  • have a deadline

Goals

  • an individual actionable unit of work
  • may have other Goals as dependencies
  • may have parts
  • may have parts big enough to merit own Goals (which become dependencies)

Kanban (Progress Pipeline)

This is a view into the "Progress Status" (stage in the progress pipeline) of a Goal (maybe Milestones too).

Stages:

  • Icebox / Future Work - the goal is identified and being fleshed out. It is not ready to be carried out at this moment.
  • Backlog - the goal is well defined and ready to be carried out, but not being actively worked on.
  • In Progress - the goal is actively being worked on, this moment.
  • Blocked - the goal cannot proceed as another goal must be Done first.
  • Done - the goal is completed. No further action is necessary.

@flyingzumwalt
Copy link
Contributor

@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?

@haadcode
Copy link
Member Author

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Member Author

@haadcode haadcode Aug 15, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@jbenet
Copy link
Member

jbenet commented Aug 12, 2016

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
Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member

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-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

@daviddias
Copy link
Member

daviddias commented Aug 12, 2016

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest adding https://github.com/philschatz/gh-board as a possible alternative to waffle or at least talk about it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

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!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ipfsify!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@haadcode
Copy link
Member Author

Commented on all the things. Next: revisit the document and address feedback and comments.

@haadcode
Copy link
Member Author

@diasdavid

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

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:

  • as per the discussion above, put all most urgent issues (perhaps all Milestone 2 goals?) in a "Ready" section. this gives one place, one "column" in waffle, to look at. if the view is via GH issues, you can direct contributors to a link that lists all issues in MS2. if you use waffle, you'll have all those goals in MS2 column AND you can show priority (not sure how one could do that in GH issues search). direct new contributors to check whichever is better and instruct to prefer grabbing goals at the top of the list (as per priority).
  • all Milestone 3 & 4 to "Backlog", sorted by MS3 first, then MS4. this would give the "not now but later" view to everyone and make it clear that while we're not yet actively working on these goals, they are planned and on our roadmap.
  • everything else in "Future Work" (icebox)

Does that make sense?

@daviddias
Copy link
Member

@haadcode re: #131 (comment)

Does that make sense?

Yes, but things like all Milestone 3 & 4 to "Backlog", sorted by MS3 first, then MS4. are unfortunately not feasible, unless things are labeled and automated, otherwise it is a huge timesink.

@flyingzumwalt
Copy link
Contributor

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

@jbenet
Copy link
Member

jbenet commented Aug 18, 2016

I'm ok with that :)
On Wed, Aug 17, 2016 at 18:52 Matt Zumwalt notifications@github.com wrote:

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 https://github.com/em-ly and I
move the document towards a final draft with new PRs. @haadcode
https://github.com/haadcode @diasdavid https://github.com/diasdavid
@whyrusleeping https://github.com/whyrusleeping @jbenet
https://github.com/jbenet


You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#131 (comment), or mute the
thread
https://github.com/notifications/unsubscribe-auth/AAIcoRaES13pN6ifeLbIVhwQskc6sVF8ks5qg5CzgaJpZM4Jbt7N
.

@haadcode
Copy link
Member Author

Absolutely fine with that! Thank you for picking this up. Hopefully with the doc in the repo, others can join the writing effort.

@daviddias
Copy link
Member

Sounds good :)

@flyingzumwalt flyingzumwalt merged commit a4176a7 into master Aug 18, 2016
@jbenet jbenet removed the status/in-progress In progress label Aug 18, 2016
@jbenet jbenet deleted the processdoc branch August 26, 2016 01:24
@flyingzumwalt flyingzumwalt modified the milestone: Implement New Project Management Model Aug 26, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants