-
Notifications
You must be signed in to change notification settings - Fork 5
Development Process
Smaller, one-off issues that don't require careful coordination and planning can just be created as an issue. Please tag them with relevant tags!
What constitutes a large project? This is somewhat subjective; there's no hard and fast rule for what needs a technical specification (tech spec) or not. In general, if you're going to expect it to be more than three distinct issues, it probably needs a tech spec. If in doubt, feel free to discuss it with the team.
A project starts off with a tech spec, where one or more members join forces to scope out the project and what it would take to implement it. This is done via GitHub Discussions, where there is a template with various prompts to consider when scoping it out. The goal of the tech spec is to ensure that there is no ambiguity when it comes to how the system will be designed, how the feature will be rolled out, and how it will be implemented at a high level. Doing so reduces the chances of mid-project pivots, where efforts are wasted and engineers frustrated.
Once written a tech spec should be reviewed by the team, where team members will ask clarifying questions, suggest alternatives (though the ones writing the spec should try to evaluate all options to avoid thrash). During this time, the tech spec may be edited, which is normal during this process.
Once approved, the tech spec authors will then break the tech spec into smaller, individual pieces of work, called "Tickets". Tickets are created as GitHub issues, and specify what the task itself is, alongside any dependencies. It also specifies "Acceptance Criteria", or AC for short, which is a list of statements that, when all of which are true, is an indicator that the job is done.
Once tickets are created, it's off to the races with development! See the GitHub Workflows page for more guidelines on how to take on tasks.