Add document describing review prioritisation

Mbed-TLS / mbedtls-docs

Version-independent documentation for Mbed TLS

Apache License 2.0

21 stars 28 forks source link

Add document describing review prioritisation #25

Closed daverodgman closed 2 years ago

daverodgman commented 2 years ago

Signed-off-by: Dave Rodgman dave.rodgman@arm.com

daverodgman commented 2 years ago

Open question to reviewers: the top priority here includes items that are scheduled for the current quarter, i.e. could be delivered in up to three months time. Is that too broad, and do we need a level for things that are to be done as soon as possible (e.g., urgent bug-fixes)? We could always add something later so I'm inclined to stick to these options for now, WDYT?

tom-cosgrove-arm commented 2 years ago

We can always add priority-critical at a later date if we find we need it, so let's just go with H M L for now

gilles-peskine-arm commented 2 years ago

the top priority here includes items that are scheduled for the current quarter, i.e. could be delivered in up to three months time. Is that too broad, and do we need a level for things that are to be done as soon as possible (e.g., urgent bug-fixes)? We could always add something later so I'm inclined to stick to these options for now, WDYT?

“We're definitely actively working on it” (“priority: high”) and “we absolutely want it in the next release” (which we aren't tracking in a systematic way, only through certain epics and from one special case, the regression label) are different concepts. If we're using labels for these, I'd prefer:

priority: high is only for things that we want to release ASAP. Not for something we want to do quickly because it's a prerequisite of a prerequisite of a prerequisite of a delivery scheduled in six months.
And then we introduce a priority: commitment for things we've committed to delivering, which are important but not urgent.

laumor01 commented 2 years ago

what about mirroring ARM commitments levels: Committed = High priority = Must Do (label assigned to issues/PRs that are required for a committed/diamond Epic) Tentative = Medium Priority = Should Do (label assigned to issues/PRs that are required for a tentative/orange Epic) Requested = Low Priority = Could Do (label assigned to issues/PRs that are required for a Requested/lemon Epic)

daverodgman commented 2 years ago

what about mirroring ARM commitments levels: Committed = High priority = Must Do (label assigned to issues/PRs that are required for a committed/diamond Epic) Tentative = Medium Priority = Should Do (label assigned to issues/PRs that are required for a tentative/orange Epic) Requested = Low Priority = Could Do (label assigned to issues/PRs that are required for a Requested/lemon Epic)

I think this would work for people within OSS/Arm, but less meaningful for people in the broader TF.org or general community. It obviously maps very well onto internal roadmap items, but it doesn't cover non-roadmap work like security fixes, tech debt, community review, CI work, releases, etc etc. The aim here is a broader Mbed TLS prioritisation process that is usable from our internal project management perspective, but also addresses community needs & priorities.

My thinking on this mapping was that all of our must and should do items would be priority-high. Within the team we would then highlight the diamond commitments in weekly calls etc, but don't need to capture the distinction on GitHub.