docs(sdk): Add Linear project description template#17861
docs(sdk): Add Linear project description template#17861christophaigner wants to merge 15 commits into
Conversation
…book Add a structured project description template with copyable markdown, split required project fields into MUST/SHOULD/MAY tiers, and expand the Closing Out section with an artifact checklist, communication checklist, and follow-up reminders. Also add a cross-reference from the planning-scoping DoD standard to the new artifact checklist. Co-Authored-By: Claude <noreply@anthropic.com> Co-authored-by: Cursor <cursoragent@cursor.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
…ng-linear-projects.mdx
The dash placeholders inside the markdown code block were being rendered as list items on the page, breaking the visual appearance of the template. Co-Authored-By: Claude <noreply@anthropic.com> Co-authored-by: Cursor <cursoragent@cursor.com>
Co-Authored-By: Claude <noreply@anthropic.com> Co-authored-by: Cursor <cursoragent@cursor.com>
Move artifact and communication checklists from a separate Closing Out section into the project description template as grouped sub-sections (Have we updated / Have you thought about / follow-up issues). Update the cross-reference in planning-scoping.mdx accordingly. Co-Authored-By: Claude <noreply@anthropic.com> Co-authored-by: Cursor <cursoragent@cursor.com>
Co-Authored-By: Claude <noreply@anthropic.com> Co-authored-by: Cursor <cursoragent@cursor.com>
Co-Authored-By: Claude <noreply@anthropic.com> Co-authored-by: Cursor <cursoragent@cursor.com>
Co-Authored-By: Claude <noreply@anthropic.com> Co-authored-by: Cursor <cursoragent@cursor.com>
| - [ ] In-product prompts/onboarding | ||
| - [ ] Internal adoption/usage dashboards | ||
|
|
||
| ### Have you thought about doing a |
There was a problem hiding this comment.
this could also be automated ... once checked here ... create a Linear issue for it
There was a problem hiding this comment.
Definitely, we can have a look at this in a follow-up then 👍🏻
Summary is a dedicated field in Linear (below the title), so it belongs in the required attributes list rather than inside the description template. Co-Authored-By: Claude <noreply@anthropic.com> Co-authored-by: Cursor <cursoragent@cursor.com>
|
another thing that came to my mind, is that for almost all SDK alignment projects ... the template also applies to the initiative and we usually just point to the initiative description, assets b/c the per SDK differences are mostly minimal |
Co-authored-by: Alex Krawiec <alexanderkrawiec@gmail.com>
For projects under a shared initiative, the per-SDK description can reference the initiative and only document SDK-specific deviations. Co-Authored-By: Claude <noreply@anthropic.com> Co-authored-by: Cursor <cursoragent@cursor.com>
|
nice 👍 |
|
|
||
| - **Customers**: link relevant customer accounts or support tickets that motivated the work | ||
| - **Resources**: add relevant references (especially for larger initiatives) — design documents ([RFC](https://github.com/getsentry/rfcs), DACI, PRFAQ), Slack channels, related projects, and so on | ||
| - **Milestones**: define intermediate delivery milestones for longer projects to track progress incrementally |
There was a problem hiding this comment.
Maybe also linking to existing/creating new initiatives if required?
| Use this template as a starting point for the project description. For cross-SDK rollout projects where the initiative already covers the shared context (motivation, scope, outcomes), the per-SDK project description can reference the initiative and only document SDK-specific deviations (e.g., different scope, additional risks, platform-specific dependencies). | ||
|
|
||
| ```markdown | ||
| ## Why are we doing this? |
There was a problem hiding this comment.
Including customer signals/anecdotes is usually what helps me understand the issues the best. Could be a smaller comment/addition here.
| ## Risks | ||
| <!-- What's most likely to go wrong? What's the mitigation? --> | ||
|
|
||
| ## Definition of Done |
There was a problem hiding this comment.
Do we want to template this, or allow every project to define their own definition of done - e.g. closed issues, deployed, tested etc?
There was a problem hiding this comment.
Looking at the section below it looks like there is already a section for project-specific ones?
DESCRIBE YOUR PR
Preview is here.
Expands the Managing Linear Projects playbook with more prescriptive guidance on project setup and close-out.
Changes:
MUST(title, initiative, lead, status, target date, team, description, resources) /SHOULD(customers, milestones)Once merged, we can also add a Linear project template for it.
IS YOUR CHANGE URGENT?
PRE-MERGE CHECKLIST
Made with Cursor