Here is the paragraph I will add to the community chapter of our book on what I think we worked out by way of policy over the course of this discussion.
In the below, I dropped the term 'lieutenant' and instead use 'owner'. Owner is from Todds' recounting of how google does it above. Owner, unlike lieutenant, undoes any implication of hierarchy. PATCH +1'ing POLICY[1] The below policy is something we put in place 09/2012. It is a suggested policy rather than a hard requirement. We want to try it first to see if it works before we cast it in stone. HBase is made of components[2]. Components have one or more owners[3]. See the 'Description' field on [1] for who the current owners are by component. Patches that fit within the scope of a single HBase component require, at least, a +1 by one of the component's owners before commit. If owners are absent -- busy or otherwise -- two +1s by non-owners will suffice. Patches that span components need at least two +1s before they can be committed, preferably +1s by owners of components touched by the x-component patch (TODO: This needs tightening up but I think fine for first pass). Any -1 on a patch by anyone vetos a patch; it cannot be committed until the justification for the -1 is addressed. 1. http://search-hadoop.com/m/jtoYcKNU7l1 and 2. https://issues.apache.org/jira/plugins/servlet/project-config/HBASE/components. 3. Link to Component Owners section (follows) COMPONENT OWNERS Component owners are listed in the description field on this page [1]. They are listed in the description field rather than in the 'Component Lead' field because the latter only allows us list one individual whereas components are encouraged to have multiple owners. Owners are volunteers who are (usually, but not necessarily) expert in their component domain and may have an agenda on how they think their HBase component should evolve. Duties: + Owners will try and review patches that land within their component's scope. + If applicable, if an owner has an agenda, they will publish their goals or the design toward which they are driving their component If you would like to be volunteer as a component owner, just write the dev list and we'll sign you up. Owners do not need to be committers. Let me know if you'd add or edit above. Otherwise I'll add it to the refguide in next day or so. St.Ack P.S. I will edit the current list of components and add in those who have volunteered so far on this thread. Thanks.
