- Product owners for each development team coordinate in the product steering group. If you wish to contribute or keep up to date please join the email list and/or Slack channel.
- See signalen.org for how to help with development or propose new features.
-
Do not open up a GitHub issue if the bug is a security vulnerability. Please contact one of the core developers
-
Make sure the bug was not already reported by searching in the already reported issues
-
If you're unable to find an open issue addressing the bug, create a new issue. Be sure to include a clear title and description. Provide as much relevant information and data as possible
-
If you found an open issue addressing the bug you can always contribute by leaving additional information. Make sure your comment is adding new information that has not already have been described in the ticket
-
Please make new feature requests using the feature request template in the product steering repository if your requirement or wish is not listed.
-
Make sure that you have fixed the bug and provide prove this with several tests
-
Open a new GitHub pull request with containing the fix and tests
-
Ensure the PR description clearly describes the problem and solution (Include the relevant issue number if applicable)
-
Bug-fix branches must use the fix prefix and must be branched of the master branch. The branch should include an issue reference number or self explaining name
-
Contributions will not be merged until they have been code reviewed by at least 1 other developer
-
Contributions will not be merged if there are no test proving that the code works as intended
-
Contributions will not be merged if there is no documentation provided
-
You should implement any code review feedback unless you strongly object to it
-
In the event that you object to the code review feedback, you should make your case clearly and calmly. If, after doing so, the feedback is judged to still apply, you must either apply the feedback or withdraw your contribution
Follow the style you see used in the repository. Consistency with the project always outweigh other considerations. It doesn’t matter if you have your own style - just follow along.
The Signals codebase uses the PEP-8 code style in general. In addition to the standards outlined in PEP 8, we have a few guidelines:
- Line-length can exceed 79 characters, to 120, when convenient.
- Line-length can exceed 120 characters, when doing otherwise would be terribly inconvenient.
- Always use single-quoted strings (e.g. 'some string used as an example'), unless a single-quote occurs within the string (e.g. "don't use single quotes for these kind of strings").
Contributors may wish to familiarize themselves with the open standards used within the codebase, including:
Signalen is in incubation codebase stewardship with the Foundation for Public Code.
The codebase stewardship activities by the Foundation for Public Code on this codebase include:
- facilitating the community and its members
- help all contributors contribute in line with the contributing guidelines and the Standard for Public Code
- work with the community to tell their stories, create their brand and market their products
- support the technical and product steering teams