[DISCUSS] purge the 'component owner' experiment?

[Sean Busbey <bu...@apache.org>]

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.

Re: [DISCUSS] purge the 'component owner' experiment?

[Sean Busbey <bu...@apache.org>]

patch up on https://issues.apache.org/jira/browse/HBASE-20323

On Fri, Mar 30, 2018 at 3:07 PM, Stack <st...@duboce.net> wrote:
> 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 <bu...@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.
>>

Re: [DISCUSS] purge the 'component owner' experiment?

[Stack <st...@duboce.net>]

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 <bu...@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.
>

Re: [DISCUSS] purge the 'component owner' experiment?

[Andrew Purtell <ap...@apache.org>]

It was an interesting experiment but we had more active committers at that
time. Now the would-be owners are more likely to be a bottleneck (due to
limited bandwidth for review) than an aid.


On Wed, Mar 28, 2018 at 7:42 AM, Sean Busbey <bu...@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.
>



-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk