-
Notifications
You must be signed in to change notification settings - Fork 87
Software Development Process
When submitting issues in GitHub, choose an appropriate issue type and fill out the corresponding template. Be as complete as you can.
We use a GitHub Kanban-style project board to organize and track issues being worked on. Issues that are in the "To do" column are available to be selected by developers. If you feel interested in and qualified to work on an issue in this column, assign it to yourself and drag it into the "In progress" column.
Once the code is tested and ready, and you've created a Pull Request (PR) for it, the issue can be moved to the "Code review" column, where it will be reviewed by the community, as well as core committers. Additional changes may be required. Once a core committer approves the PR and merges it to the master branch, the issue can be moved to "Done".
Newly created issues appear in the "For consideration" column and will be spec'd and reviewed by the core team before being moved to "To do".
Issues may have any number of labels attached to them. See the reference list of labels.
For a higher-level view of our priorities, see the roadmap.
If you are a new contributor to this project, consider picking issues labeled as Good First Issue or Easy.
Please adhere to stated styleguides. e.g. We follow the AirBNB styleguide for Javascript. One of the easiest ways to remain compliant is to use an automated linter in your code editor.
Where no styleguide is explicitly stated, follow the prevailing style in an existing file or ask a core committer or the community when creating a new file.
Good automated tests are part of good code. We encourage Test-Driven Design (TDD), whether or not tests are written first. i.e. When designing new code, make sure that you are doing so in a such a way that the code will be easy to test.
We use unit tests (using jest) to ensure that the individual parts are working and integration tests (using Puppeteer) to ensure that the parts work together correctly.
Whenever a bug is found, the first thing we do is write a regression test that would have caught that bug, making sure the test fails, and then we implement the bug fix, making sure the test now succeeds.
- Development tips
- Using Git/GitHub: using feature branches, branch names, commit messages
- Creating Pull Requests: use of PR template, author responsibilities
- Reviewing Pull Requests: giving feedback, reviewer responsibilities
- Issue resolution: what happens next, integration with Archive.org code base