incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: Thoughts about formalizing the role of shepherd
Date Mon, 14 Jan 2013 18:18:38 GMT
To begin with, I realize that I am tampering with the structure of the IPMC.

In some ways, the IPMC is just another project. It has members, they
are responsible for supervision of source control and releases. In
other ways, it's very different from the other projects. It's
responsible for bootstrapping projects. So you might look at my
structural proposal as explicitly building extra structure to confront
those challenges.

The problem I'm looking at is indeed the chronic lack of reliable
mentor presence in the projects, as witnessed (maybe) by the signoff
statistics in January.

If the IPMC was working 'as designed', the mentors -- the members of
this PMC -- would be supervising, and reviewing and signing off
reports, and we wouldn't need shepherds. That's my logic.

Starting from there, over a long period of time, we've seen a number of ideas.

There's the shepherds as we have them. And perhaps we should just
stick to this. It helps detect and compensate for mentor weakness, and
it avoids building a radically different structure.

There's 'tear down the incubator' -- decide that the chronic leakage
of mentors means that the whole system we have is not working. I
can't, personally, state an alternative.

Thank you for reminding me of the idea of a champion.

If folks would rather focus on seeing if we can make something of
that, fine with me.



On Mon, Jan 14, 2013 at 9:36 AM, Ross Gardler
<rgardler@opendirective.com> wrote:
> Why would adding another formal role solve the problem that saw the
> creation of shepherds (missing mentors)?
>
> Are you tackling a different problem now?
>
> Unless there is a really solid reason for it I would be concerned about
> crating structure in the incubator that isn't present in the ASF proper.
>
> Should this new role be a better use of the existing champion role,
> complete with the handing over of that title to a PPMC member before
> graduation and a progression to PMC chair upon graduation? We discussed
> this some time ago and agreed it was a good idea but we never really
> carried it through.
>
> Ross
>
> Sent from a mobile device, please excuse mistakes and brevity
> On 13 Jan 2013 08:46, "Benson Margulies" <bimargulies@gmail.com> wrote:
>
>> Right now, a shepherd assignment is a temporary job. It starts as the
>> reports for a cycle begin to come in, and it ends when the shepherd
>> feels that he or she has done what makes sense in terms of reporting
>> to the community and, in some cases, delivering some constructive
>> nudges to the projects.
>>
>> I've been thinking about an alternative, but it may not be popular.
>>
>> In my alternative, the IPMC organizes itself as follows:
>>
>> At the top of the pyramid, tied down to the Aztec altar, is me, the
>> chairman.
>>
>> Next down are the 'vice-chairs', currently known as the shepherds.
>> Each of these people is responsible for a group of projects, dispersed
>> across the reporting cycle. The shepherd, at least, tunes into the
>> reports, but also checks in during the three-month reporting period --
>> particularly if we have identified issues that the project needs to
>> address.
>>
>> Next we have the mentors, who are 'inside' the projects, offering
>> guidance, coaching, and supervision. However, the fact is that we
>> don't have enough volunteers to have multiple, active, tuned-in
>> mentors for all of the projects all of the time.
>>
>> Last, but hardly least, are the freelance members of the committee,
>> who tune in on things like release reviews.
>>
>> If we adopted this plan, we'd add a shepherd slot to the metadata for
>> each project, and I, as chair, would take action if the designated
>> shepherd wasn't available to do a review for a project in a reporting
>> cycle. Either I'd do it myself, or I'd put out a call for assistance.
>>
>> I'm not going to defend this scheme tooth-and-nail. If folks prefer
>> the current approach, I'll focus on fixing the schedule to make it
>> easier to make it work.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message