...

Despite the word "Policy" which is suggestive of rules, this document is really a guideline document.  There is a lot of trust between committers; in some cases it may make sense to diverge from these policies.  We try to articulate here when that makes sense.  When in doubt, ask on the dev-list.

Reviews

From an ASF policy perspective, this project follows CTR (Commit-Then-Review) which grants committers permission to commit at will, with the possibility of being retroactively vetoed.  However, in practice code is peer-reviewed before-hand most of the time, and so this project might appear to be the reverse of that.  Strictly speaking, this project does not follow RTC (Review-Then-Commit) which has onerous qualifications we don't wish to adhere to.

...

Don't be shy in asking others for a review.  Earn goodwill and improve the project by reviewing the work of others.

When Reviews Aren't Needed

When changes are sufficiently minor, don't let typical processes get in the way of immediate/timely progress.  You probably shouldn't bother waiting for a review for these circumstances:

...

TODO counter-examples of above that ought to have a review

Tests

There is no real policy on tests, but obviously, we want our code to be tested.  If the proposed changes don't incorporate a test then the issue or GitHub PR (or other review platform) should mention so and why for the benefit of reviewers, unless it's obviously not needed (e.g. already tested via whatever).

Bug fix commits should include at least one test that does not pass without the accompanying fix.

Documentation

TODO All new Features should be accompanied by new documentation (at a minimum, mention on the wiki)

TODO triage below old content

Architectural or "Weighty" Changes to the "Guts" of Solr

Changes to Solr's internals should always be tracked as a patch in the issue tracking system under the RTC model. At least one other person knowledgeable in the code that is changing should review the patch before it is committed.

...

if an architectural or other serious internal change requires changes to existing unit tests, that should be pointed out and the potential ramifications for existing end users should be discussed thoroughly on the Solr developer list.

Non-Backwards Compatible Changes to Functionality or APIs

Changes to Solr's public APIs (either via URL structure, or APIs exposed to Plugin Developers) should always be tracked as a patch in the issue tracking system under the RTC model. Potential ramifications for existing end users should be discussed thoroughly on the Solr user list.

...