Contribution Rules
Below is a list of rules that apply to every contributor of any Corteza repository. With the below points we are able to provide consistent, quality software that is easy to use or contribute to.
- All major modifications must be documented
-
A modification classifies as major when it causes any changes to an actions output or how the action is performed. For example:
-
Changed api response,
-
change in the access control logic,
-
additional settings, environment variables,
-
changed the interface for data export,
-
new features; etc.
-
- All relevant guides must me updated
-
When a modification affects multiple guides, each of them needs to be taken care of. For example, your feature introduces a new application with a special API and a user interface. You should update:
-
Developer guide,
-
administrator guide,
-
end-user guide.
-
- Consistent style of writing
-
Be consistent with other contributors as we wish to have a consistent, easy to read documentation. Refer to [documentation-writing-guidelines] for more insight on this.
- Try to follow the rules
-
In the edge case where it is excusable for you to not follow the above rules (extremely tight schedule, urgent fixes that need to be released asap, …) open up an issue that outlines your changes, provides some references to the PR/commit so someone (preferably yourself) can get to it as soon as possible. No big deal, as long as it gets done before the release.
If you refuse to follow the above guidelines for any reason, you will not be able to contribute to the project. We all hate it when an amazing framework or platform lacks in documentation and we have to reverse engineer every little feature. How good is a product if no one knows how to use or maintain it? Let’s not make our lives harder by not wanting to share our knowledge! |
Stuck? Get in touch with us on https://latest.cortezaproject.org! |