Skip to content

Development Rules & Guidelines

Milton Smith edited this page Jun 18, 2018 · 8 revisions

These are not the only rules but some worthwhile to communicate. Following are start of some considerations when contributing to the project.

R10 Documentation requirements for pull requests

Each significant pull request must be preceded with accompanying documentation with a minimum of 3 days prior notice. The reason is that developers introducing significant changes/improvements must allow a period of open and fair community debate around the feature prior to implementation. How can you provide notice, 1) post a new issue, 2) post to the Google DeepViolet Group. Pull requests not accompanied with the documentation link OR have not waited at least 3-days will be rejected.

R20 Nascent pull requests for stylistic changes

Each person has different design and coding styles. Consider the following example,

if(condition) {
  .. do something..
}

OR

if(condition)
{
  .. do something..
}

Any pull requests based purely upon these coding style preferences will be rejected. If you are submitting new code you are allowed to choose a style that works for you. Anyone making changes to your code can adopt their own coding style. However, developers are not allowed to reformat code in other areas just because they don't like the coding styles of others.

R30 Ease of use is key

Deliveries that introduce needless complexity will be rejected.

R40 Only check in a consistent set of changes

Your improvements/changes don't have to fully implement new functionality your including but the changes must not break existing functionality.

R50 Improvements include corresponding unit tests

It's difficult to be entirely comprehensive given the type of project this is but where it's possible to implement practical unit tests please include them in your updates.

R60 Equitable licensing

Any 3rd party code and libraries you introduce is licensed in a compatible way with the Apache v2 license. Message project leader with questions.

R70 Provide attribution

If you include the code of others in accordance with R60, you will acknowledge the original author and if possible include a link to the original version or alternatively provide original author contact information.

R80 Check in code that is cleaner than you checked out

See 'Clean Code' (http://www.cleancoders.com/). Keep in mind R20.

Development Rules & Guidelines adapted in part from those provided for the OWASP ZAP project.