Last Wednesday at a Solr committers meeting, there was general agreement in attendance to raise the bar for commit permission to require another's consent, which might not have entailed a review of the code. I volunteered to draft a proposal. Other things distracted me but I'm finally thinking of this task now. *This email is NOT the proposal*.
I was about to write something from scratch when I discovered we already have some internal documentation on a commit policy that is both reasonably well written/composed and the actual policy/information is pretty good -- kudos to the mystery author! https://cwiki.apache.org/confluence/display/SOLR/CommitPolicy I'd prefer we have one "Commit Policy" document for Lucene/Solr and only call out Solr specifics when applicable. This is easier to maintain and is in line with the joint-ness of Lucene TLP. So I think it should move to the Lucene cwiki. Granted there is a possibility this kind of content might move into our source control somewhere but that possibility is a subject for another day. I plan to copy this to Lucene, mark as PROPOSAL and then make some large edits. The diff will probably be kinda unrecognizable despite it being in nice shape now. A "Commit Policy" is more broad that a "Code Review Policy"; it could cover a variety of things. For example when to commit without even filing a JIRA issue, which I think is worth mentioning. It should probably also cover Git considerations like merge vs rebase, and multiple commits vs squashing. Maybe we should also cover when to bother adding to CHANGES.txt and "via"? Probably commit message requirements. Snowballing scope :-). Probably not JIRA metadata as it's not part of the commit to be part of a commit policy, but _somewhere_ that's needed. I'm not sure I want to sign up for all that now but at least for the code review subject. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley
