Purge. My assessment is that the OWNER project failed; valiants signed-up with the best of intentions but because of tooling, consistency, attrition, unknowns (pick one), the project faded soon after launch.
Thanks, St.Ack On Wed, Mar 28, 2018 at 7:42 AM, Sean Busbey <bus...@apache.org> wrote: > In late 2012 we tried an experiment where folks volunteered to act as > stewards of particular functional areas. The basic idea was we'd > require scrutiny from more folks if we didn't have anyone available > who had self selected as familiar available at the time of review. > > Described like this in the ref guide currently > > ---- > h3. Patch +1 Policy > > 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. > > Apache HBase is made of components. Components have one or more > OWNERs. See the 'Description' field on the components JIRA page for > who the current owners are by component. > > Patches that fit within the scope of a single Apache 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 vetoes a patch; it cannot be committed > until the justification for the -1 is addressed. > > h3. Component Owner/Lieutenant > > Component owners are listed in the description field on this Apache > HBase JIRA components page. The owners are listed in the 'Description' > field rather than in the 'Component Lead' field because the latter > only allows us list one individual whereas it is encouraged that > components have multiple owners. > > Owners or component lieutenants are volunteers who are (usually, but > not necessarily) expert in their component domain and may have an > agenda on how they think their Apache HBase component should evolve. > > 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. > > ---- > > This was still around enough when I joined the project in ~2014 one of > the things I did was sign up for a few. I would be surprised if anyone > with < 1 year in the project (a) knows about this approach or (b) what > areas (as defined by this effort) specifically to reach out to me > about. I certainly haven't updated the list for which ones I feel most > comfortable talking about now that I've been here a bit. > > Should we drop this effort? Seems counter to several of our community > trends; it adds one more thing to maintain, discourages sense of > shared ownership, requires even more reviewer bandwidth that we don't > have. > > Or should we revitalize it? Would provide a better idea of our > "reviewer coverage" and give easier pointers for e.g. folks looking > for mentorship on learning about particular parts of our HBase. >
