Good software development lifecycle (SDLC) is an endless journey, but it’s hard to make progress if you don’t know where you’re going. This document is intended to be a checklist for ROOST projects to work through as they mature.
Document status: Working draft. Suggested categories, checks, and priority below.
To start, ROOST projects should use main as the branch for development, and use the GitHub Release feature (via semver-tagged commits) to denote releases. This will need to be revisited as projects mature and have to handle backporting patches, but the ethos is “minimum viable complexity.”
* Identify big features on 12 month timeline. These are substantial changes (think blog headline). * Estimate delivery time in quarters of big features and group features with similar timelines together. Bundle breaking changes when possible. * Add minor features/changes to timeline. Bundle together for as consistent cadence as possible. * Patch versions can be cut at any time as needed for bug fixes.
All projects/repos must have a README file in markdown format. At minimum, the README must have a description of what the project does, information for how to start using it (can link to longer getting started documentation), and links to the CONTRIBUTING.md and Code of Conduct.
P0
AGENTS.md
Add a markdown file to guide AI coding assistants following the open AGENTS.md format
P1
API format
Projects should follow the [TBD] API description format
All projects must have a CONTRIBUTING.md file at minimum. By default this is inherited from ROOST’s .github, but can be updated at the per-project level. Additional documentation for first time contributors describing project conventions and code quality expectations is recommended.
P0
CODE_OF_CONDUCT.md
All projects must have a CODE_OF_CONDUCT.md with the ROOST Code of Conduct. This is automatically inherited from ROOST’s .github and should not be changed.
Determine what surfaces or characteristics of surfaces should be fuzzed and at what cadence (including planning for triage and remediation at that cadence)
How can this be automated or less burdensome, and identify priority?
P2
Code review guidance
Project documentation should include a section on how to help with code review, and highlight any particular areas code reviewers should pay attention to
Following semver, breaking changes go in Major versions. This policy is about when it’s appropriate to introduce a breaking change and how it should be communicated to users (timeline, expectations, support)
P1
Long term support (LTS) policy
How many versions back does the community support?