Calligra/Policies/Review board rules

The review board is used to check patches before they are committed. The reason is that we want to try to find problems with new code before it is committed. This page contains rules for when and how to use it.

Rules for Contributors

The biggest question is when to use the review board and when to commit directly. You should also use the reviewboard if:

• You want to commit in some of the libraries (files under libs/), namely main, flake, kotext, odf.
• you want to change important API's. This should also be preceded by a discussion on the mailinglist.
• You want to commit in code that are used by many applications. Currently that means:
  • plugins/textshape

You should also consider using reviewboard if:

• If you are a new contributor and committing in an application you are not familiar with. This is the call of the maintainer of the application.
• If you are contributing complex code or a big amount of code.
• If you are contributing code that changes the infrastructure, e.g. refactorings.

Rules for Reviewers

Keep in mind that the reason for using the reviewboard is to speed up the development by catching bugs early. An overly tedious and long reviewboard process discourages contributors, espcially new ones. So try to concentrate on the big issues and don't be too picky. It is always possible to fix smaller issues in later commits. Remember that both the contributor and reviewer want the code to go in.

In particular concentrate on:

• architectural problems like bad scalability or issues that make later enhancements difficult.
• code that create unintended problems in other places.

Things that could be pointed out but shouldn't block the commit:

• whitespace issues
• minor coding style issues

General Rules

General Principles

• Mistakes are allowed.
• Keep the tone constructive. If you point out a problem, also try to point to a possible solution. Especially new contributors should get much help. This is important for growing the community.
• Mistakes are allowed!

Procedure

• If nobody comments on a patch for one week the issue should be raised again.
• If nobody comments on the patch for another week, it can be committed. (remember: mistakes are allowed, and the commit can always be reverted)
• A patch can go in if one person presses "Ship it!" or, if there is opposition, there is a majority for it.