### Why How we arrive at commitments and what they are is currently a source of confusion. ### What We need to make it more clear in our handbook: - How to know if something is a commitment (explicitly say that ~Deliverable label is the SSOT of whether we are committed) - Criteria for when this label can be applied - issue _must_ be refined by an engineer and labeled ~"workflow::ready for development" - issue must be weighted - blockers identified - other refining tasks etc - What to do if you get assigned a ~Deliverable and after some time in the milestone realize it cannot be achieved by the date - Option to cut scope as defined in [iteration CREDIT value](https://handbook.gitlab.com/handbook/engineering/workflow/iteration/) - > You should always attempt to provide feedback as early as possible to product management if you can see opportunity to cut scope and deliver a smaller change no matter where you are at in the planning/development lifecycle. TODO: keep adding to this issue, this is a rough outline