Writing Documentation
Bridge the gap between your brain and the rest of us.
Think you’re ready for the big leagues? Prove it by rebasing onto main
before continuing work.
Ironically, this page is a work in progress. The jokes just write themseves, don't they?
TODO:
- Project Board Setup
- Appropriate channels of communication
Finding Your Type
Whether it's in real-life, or here online, you have to be able to find the right type for you!
Luckily, we can help you out with that! Well, at least for making sure your contributions to the project are in the right format!
Finding the correct type for your commit, issue or pull request can sometimes seem difficult. To help you out with this, we've created a few definitions to help you out:
| Label | Description |
|---|---|
fix | A bug fix in the project (e.g., fixing an errant hyperlink in the docs) |
feat | New feature(s) being added to the project (e.g., creating a calendar feature) |
docs | A new addition or update to the docs site and/or documentation (e.g., adding a new docs site page) |
test | New tests being added to the project (e.g., new Playwright tests for the mobile docs site) |
chore | Tasks that don't modify any code and that help maintain the project (e.g., updating dependencies, reorganizing file structure, renaming files, etc.) |
style | Changes that do not affect the meaning of the code and that improve readability (e.g., adding only white-space, adding indents, adding comments, etc.) |
refactor | A change that improves the readability of code itself without modifying behavior (e.g., renaming a variable, creating a helper function, renaming a function, etc.) |
perf | A code change that improves code performance (e.g., changing a function to be more memory-efficient, fixing code to improve runtime, etc.) |
build | Changes that affect the build system or external dependencies (e.g., upgrading dependencies, adding a new dependency, etc.) |
ci | Changes to our CI configuration files and scripts (e.g., adding a new script to the CI) |
revert | Reverting a previous commit (e.g., reverting a commit that caused a bug) |
Be sure now to double-check your work and make sure you're using the correct type for your contributions!
GitHub issues guidelines
GitHub issues serve as the gateway to get things going and bring your ideas to life. It's a useful tool for documenting any potential project ideas. For proper documentation of issues, here are a couple of guidelines to keep in mind when writing issues:
- Title: The title of the issue should be
issue-type(issue-scope): issue title(unless it's an[ADR]or[BUG]). - Description: Follow the issue template and stay problem-specific when writing issues (except
[ADR]or[BUG]). - Labels: Use labels to categorize the issue. This helps in organizing and prioritizing issues for the project board.
- Assignees: Assign the issue to the appropriate person(s) who will be responsible for working on the issue (most of the time this would be yourself).
Here is an example of a well-documented issue: Issue #49
Last updated on