diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 4f72e67..eec9e1e 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,13 +1,16 @@ -# Contributing to this theme +# Contributing -🙇‍♀️ Thank you for contributing! + + -We love issues and pull requests from everyone. If you're not comfortable with Github, you can email use your feedback at . +The Standard for Public Code is [community governed](https://github.com/standard-for-public-code/standard-for-public-code/blob/develop/GOVERNANCE.md). + +Join our [community calls](https://community.standardforpubliccode.org/), come say hello on our [discussion board](https://github.com/standard-for-public-code/standard-for-public-code/discussions), or feel free to leave an issue on any of [our repositories](https://github.com/orgs/standard-for-public-code/repositories). ## Problems, suggestions and questions in issues -Please help development by reporting problems, suggesting changes and asking questions. To do this, you can [create a GitHub issue](https://help.github.com/articles/creating-an-issue/) for this project in the [GitHub Issues](https://github.com/publiccodenet/jekyll-theme/issues). -Or, sign up to the [mailing list](https://lists.publiccode.net/mailman/postorius/lists/jekyll-theme-discuss.lists.publiccode.net/) and send an email to [standard@lists.publiccode.net](mailto:jekyll-theme-discuss@lists.publiccode.net). +Please help development by reporting problems, suggesting changes and asking questions. +To do this, you can [create a GitHub issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-an-issue). Or, join in the [discussions](https://github.com/standard-for-public-code/standard-for-public-code/discussions). You don't need to change any of our code or documentation to be a contributor! @@ -15,37 +18,56 @@ You don't need to change any of our code or documentation to be a contributor! If you want to add to the documentation or code of one of our projects you should make a pull request. -If you never used GitHub, get up to speed with [Understanding the GitHub flow](https://guides.github.com/introduction/flow/) or follow one of the great free interactive courses in the [GitHub learning lab](https://lab.github.com/) on working with GitHub and working with MarkDown, the syntax this project's documentation is in. +If you never used GitHub, get up to speed with [Understanding the GitHub flow](https://docs.github.com/en/get-started/quickstart/github-flow) or follow one of the great free interactive courses in [GitHub Skills](https://skills.github.com/) on working with GitHub and working with MarkDown, the syntax this project's documentation is in. -This project is [licensed EUPL](LICENSE.md), by contributing you agree to release all your contributions to it under the same license. +This project is [licensed EUPL](LICENSE.md), by contributing you agree to release all your contributions to it under the same license. ### 1. Make your changes -This project uses the [GitFlow branching model and workflow](https://nvie.com/posts/a-successful-git-branching-model/). When you've forked this repository, please make sure to create a feature branch following the GitFlow model. +This project uses the [GitFlow branching model and workflow](https://nvie.com/posts/a-successful-git-branching-model/). +When you've forked this repository, please make sure to create a feature branch following the GitFlow model. + +Add your changes in commits [with a message that explains them](https://thoughtbot.com/blog/5-useful-tips-for-a-better-commit-message). +If more than one type of change is needed, group logically related changes into separate commits. +For example, white-space fixes could be a separate commit from text content changes. +When adding new files, select file formats that are easily viewed in a `diff`, for instance, `.svg` is preferable to a binary image. +Document choices or decisions you make in the commit message, this will enable everyone to be informed of your choices in the future. + +If you are adding code, make sure you've added and updated the relevant documentation and tests before you submit your pull request. +Make sure to write tests that show the behavior of the newly added or changed code. + +#### Style + +The Standard for Public Code aims to [use plain English](criteria/use-plain-english.md) and we have chosen American English for spelling. +Text content should typically follow one line per sentence, with no line-wrap, in order to make `diff` output easier to view. +However, we want to emphasize that it is more important that you make your contribution than worry about spelling and typography. -Add your changes in commits [with a message that explains them](https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message). Document choices or decisions you make in the commit message, this will enable everyone to be informed of your choices in the future. +#### Standards to follow -If you are adding code, make sure you've added and updated the relevant documentation and tests before you submit your pull request. Make sure to write tests that show the behavior of the newly added or changed code. +These are the standards that the Standard for Public Code uses. +Please make sure that your contributions are aligned with them so that they can be merged more easily. + +* [IETF RFC 2119](https://tools.ietf.org/html/rfc2119) - for requirement level keywords +* [Web Content Accessibility Guidelines 2.1](https://www.w3.org/WAI/WCAG22/quickref/?showtechniques=315#reading-level) - for readability ### 2. Pull request -When submitting the pull request, please accompany it with a description of the problem you are trying to solve and the issue numbers that this pull request fixes. +When submitting the pull request, please accompany it with a description of the problem you are trying to solve and the issue number that this pull request fixes. +It is preferred for each pull request to address a single issue where possible. +In some cases a single set of changes may address multiple issues, in which case be sure to list all issue numbers fixed. ### 3. Improve All contributions have to be reviewed by someone. -It could be that your contribution can be merged immediately by a maintainer. However, usually, a new pull request needs some improvements before it can be merged. Other contributors (or helper robots) might have feedback. If this is the case the reviewing maintainer will help you improve your documentation and code. +It could be that your contribution can be merged immediately by a maintainer. +However, usually, a new pull request needs some improvements before it can be merged. +Other contributors (or helper robots) might have feedback. +If this is the case the reviewing maintainer will help you improve your documentation and code. If your documentation and code have passed human review, it is merged. -### 4. Governance -Larger functionality changes or breaking changes will also be reviewed according to our [governance model](governance.md). - -### 5. Celebrate - -Your ideas, documentation and code have become an integral part of this project. You are the open source hero we need! - ---- +### 4. Celebrate -For more information on how to use and contribute to this project, please read the [`README`](README.md). +Your ideas, documentation and code have become an integral part of this project. +You are the open source hero we need!