Nodejs.dev: Flow: Milestoning OKRs

Created on 21 Mar 2020 · 4Comments · Source: nodejs/nodejs.dev

Explainer

OKRs are proving very useful to many projects in the Node.js community and the ecosystem at large. Since we recently decided to jump on the waggon, some may have notice a disconnect between what we are putting in our OKRs and the efforts we are pushing forward.

Such disconnects imho are expected when making changes to any process, and more so in our case since we're reigniting efforts after months of disruption, thanks to the many awesome new members and returning members of our team.

It is hard, at least for myself, to see project boards connecting the dots from threads to Os or KRs, since that will require individuals to refer back to project boards to get more insights on what is going on.

Instead, I was tempted to experiment with milestones. I created the Netlify?! milestone and linked it to all associated threads.

There are a few knits (imho which I think GitHub can improve on):

Milestones do not nest
Milestones do not card

For now, I propose that we think of KRs as milestones, and would love to hear everyone's thoughts please!

Todo

[ ] Define procedures for using "Linked Milestones" to meet Key Results in https://github.com/nodejs/nodejs.dev/blob/staging/CONTRIBUTING.md

Note — We likely want to land CONTRIBUTING.md on master and drop it from staging since community health documents should be single sourced from the default branch (see #538).
[ ] Create "Linked Milestones" under each Key Result in https://github.com/nodejs/nodejs.dev/blob/master/OKR.md

contributing discussion planning wip

Source

SMotaal

All 4 comments

We should definitely get our OKRs in more measurable and trackable shapes. I think milestones are a good way to do that. So +1 for that.

It's for this issue a bit off-topic but on another hand, I don't really understand the rush towards Netlify. Update me please if I missed discussions about that. No doubts that Netlify has a good service. But I think a workflow, where we define the pain first, then evaluate solutions and eventually decide together what's the best fit, is a better and way to go than rushing temperamentally for a service. :]