Page History

...

Reviews are usually but not always required. When changes are sufficiently minor (low risk, low consequence, not controversial), don't let such processes get in the way of immediate/timely progress.  It needs to be minor enough that it's not worth mentioning in CHANGES.txt.  You probably shouldn't bother waiting for a review for these circumstances:

• Bug fixes (trivial)
• Extensibility improvements that are trivial (e.g. protected/public) on classes that are already marked with lucene.internal or lucene.experimental (or Solr classes/methods deemed similarly even if not annotated).
• Formatting / indentation
• Typo/grammar corrections
• Documentation and code comments
• Error or log message improvement
• Tests, especially additional tests
• dev-tools/
• Feature/improvement/bug-fix might all be trivial enough sometimes

Yet for any guidelines, there are counter-examples.  Are you intending to auto-indent the entire codebase or do any change affecting many files?  Discuss it first.  Are you doing a intra-page re-organization of documentation?  Try to get a review.  Will your change impact backwards-compatibility?  This requires a review and mention it so it's clear in the JIRA issue.  Adding a new dependency (not just an update)?  Call it out in the JIRA issue; get a review.

...