Backlog prioritization

I would like to propose that we begin to operate against the backlog of open issues and feature requests in a manner similar to how the kubeadm team works. They categorize the open issues into “buckets”, and each bucket is assigned an overall priority:

  • P0 (priority zero) - critical - must get in the release
  • P1 - soon - should get in the release
  • P2 - long-term - try to get in, but ok to punt it out
  • P3 - backlog

Here is a possible list of buckets and possible priorities:

  • Data Model - P0
    • Machine states and bootstrapping
    • Remote node references
    • Control plane lifecycle management
  • Upgrades - P1
    • For Cluster API itself
    • For clusters provisioned by Cluster API
  • Status - P2
    • Health reporting
    • Progress reporting
  • Security - P3
    • Certificate storage

If we can all agree on buckets, we can have a session where we go through all the open issues and assign them to buckets. We can also work on establishing the relative priority within each bucket.

I’d like to discuss this at Wednesday’s meeting, but please feel free to comment here before then if you’ve got any thoughts.


I think it’s important to point out that the buckets are not terribly important. The only thing that really matters is agreeing on the p0. That’s the thing that must go into the next release. All the other issues can have a priority so signal how the community is generally feeling, but the p0 is the thing that would make the release deadline slip.

If folks see a feature they care about in a lower priority bucket, don’t worry! You can absolutely work on it and get it in the next release above some other higher priority item, just so long as it’s finished in time.

edit: This post is assuming we do end up adopting a style similar to kubeadm.

I’d like to propose s/Data Model/Common Functionality/ to avoid any confusion with previously defined workstreams.

This is meant to be forward-looking and encompass all possible aspects of work. I’d hope that the fact we previously had a workstream called “data model” wouldn’t confuse anyone. And I’d rather be more specific than “common functionality” if possible. It may be that data model isn’t the right phrasing?

I would also add that as we talk about prioritization, if there is a feature that is initially bucketed as a lower priority and it is of higher importance to you (or your organization) and you are willing to commit to delivering it for the release, then the priority of that item can be increased during planning.