Contributing
Thank you for considering contributing! There are many ways you can help.
What to Work On
All issues with Screwdriver can be found in the screwdriver repo. To see what we’re currently working on, you can check out our digital scrum board in the Projects section of the Screwdriver API repo. If you’re not sure what repositories you need to change, consult our Where to Contribute doc. For pointers on developing, checkout the Getting Started Developing docs.
General Guidelines for Contributing
Please try to:
- update issues you’re working on with a daily summary
- open a Slack channel with the issue number and feature in the channel title (e.g.
#911-subdirectory-support) and discuss work in there - submit a design doc if applicable
Submitting Pull Requests
Patches for fixes, features, and improvements are accepted through pull requests. Here are some tips for contributing:
- Write good commit messages in the present tense (“Add X”, not “Added X”) with a short title, blank line, and bullet points if needed. Capitalize the first letter of the title and any bullet items. No punctuation in the title.
- Code must pass lint and style checks.
- All external methods must be documented. Add README docs and/or user documentation in our guide when appropriate.
- Include tests to improve coverage and prevent regressions.
- Squash changes into a single commit per feature/fix. Ask if you’re unsure how to discretize your work.
- Whenever possible, tag your pull request with appropriate Github labels.
Please ask before embarking on a large improvement so you’re not disappointed if it does not align with the goals of the project or owner(s).
Commit Message Format
We use semantic-release, which requires commit messages to be in this specific format: <type>(<scope>): <subject>
| Keyword | Description |
|---|---|
| Type | feat (feature), fix (bug fix), docs (documentation), style (formatting, missing semi colons, …), refactor, test (when adding missing tests), chore (maintain) |
| Scope | anything that specifies the scope of the commit; can be blank, the issue number that your commit pertains to, or * |
| Subject | description of the commit |
Important: For any breaking changes that require a major version bump, add BREAKING CHANGE: <message> preceded by a space or two newlines in the footer of the commit message. The rest of the commit message is then used for this.
Example commit messages:
- For a bug fix:
fix: Remove extra space - For a breaking change:
feat(1234): remove graphiteWidth option
BREAKING CHANGE: The graphiteWidth option has been removed.
The default graphite width of 10mm is always used for performance reasons.