Projects life cycle example

Every new issue will be labeled as triage This issue may need triage. Remove it if it has been sufficiently triaged.

To do the initial triage and remove the triage label, the following conditions should be fulfilled/considered. It’s okay if not all of these are always considered. Treat this non-exhaustive list as a guideline, not a hard checklist:

  • The issue should make sense, that is, it should present a problem.

    • For example, if an issue isn’t clear or has no goal; the issue should be closed

  • Check if this issue is a duplicate of earlier-reported issues.

    • If you are certain this is a duplicate, close this issue as a duplicate of the earlier issue. Make sure this is obvious in the backlink of the earlier issue, or explicitly link to the duplicate issue.
    • If you are not sure, you can still leave a comment to indicate the other issue is possibly a duplicate, similar, or related.

  • Add appropriate labels.

  • S-*: The status of an issue.

    • S-needs-repro: Status: This issue has no reproduction and needs a reproduction to make progress.
    • S-blocked: Status: Blocked on something else such as an RFC or other implementation work.
    • S-waiting-on-review: Status: Awaiting review from the assignee but also interested parties.
    • S-tracking-forever: Status: Never to be closed.

  • P-*: Priority labels.

    • P-critical: Critical priority.
    • P-low: Low priority.
    • P-medium: Medium priority.
    • P-high: High priority.

  • No type: Issues with no type

  • Bug: An unexpected problem or behavior.

  • Feature Request: A request, idea, or new functionality.

  • Tracking Issue: A tracking issue for an RFC or an unstable feature.

  • Cleanup: PRs that clean code up or issues documenting cleanup.

  • Discussion: Discussion or questions that doesn’t represent real issues.

  • Enhancement: An issue proposing an enhancement or a PR with one.

then it can go for a “final-comment-period” In the final comment period and will be labeled as (merge, postpone, close) soon unless new substantive objections are raised.

disposition-merge: This issue / PR is in FCP with a disposition to merge it.

or

go for “disposition-close” This PR / issue is in FCP with a disposition to close it.

or

goes for “disposition-postpone” This issue / PR is in FCP with a disposition to postpone it.

Notes from varies different companies

Rule #1 is: Write them in whatever form makes the most sense for the particular project.

what non-goals are. Note, that non-goals aren’t negated goals like “The system shouldn’t crash”, but rather things that could reasonably be goals, but are explicitly chosen not to be goals. A good example would be “ACID compliance”

Design docs should be sufficiently detailed but short enough to actually be read by busy people.

Road map for full year inside it there is quarter plans

Think about bots, changelog management, and releases management design briefs in design, success plans in sales)

talk about writing culture and quality writing

You MAY use RFC2119-style MUST, SHOULD and MAY language to help clarify your intentions.

When your RFC is ready to be commented on, mark you PR as “Ready for review”

adding “-Authors: /Owner: [TBD: your name]” to the meta data

Don’t get bogged down trying to make a document perfect before sharing it—just make it good enough to convey your point. It’s important to have co-workers help guide the process.

Six-week cycles

First, we work in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The majority of our new features are built and released in one six-week cycle. 2 weeks cool down

non-goals: are impoaten

we should draw protoypes and breadboards: https://basecamp.com/shapeup/1.3-chapter-04 | https://sep.com/blog/breadboarding-a-simple-way-to-prototype/

about bug managemnt when it comes to the 6 week fouces time https://notes.nicolevanderhoeven.com/Fork+My+Brain and maybe dedicate a whole cycle to fixing bugs “bug smash”

on cycles we need to be laser focesed

example

What “Shape Up” Recommates Instead:

  1. Betting on Projects, Not Roadmaps:
    Every 6 weeks, stakeholders (leaders, product managers, etc.) “bet” on a small set of projects that fit the company’s appetite (time budget) and strategic goals. No long-term commitments—only the next cycle matters.

  2. Fixed Time, Variable Scope:
    Instead of planning what to build over months, teams define how much time they’re willing to spend (e.g., 2 weeks vs. 6 weeks). Projects are shaped to fit this appetite, ensuring they’re manageable and focused.

  3. No Backlogs:
    Ideas that don’t get bet on are archived. If they’re important, they’ll resurface naturally in future cycles. This avoids the “zombie tasks” that haunt traditional roadmaps.

  4. Dynamic Prioritization:
    Each cycle starts fresh. Teams only work on what’s been explicitly chosen, avoiding the distraction of theoretical future work