Thoughts about formalizing the role of shepherd

[Benson Margulies <bi...@gmail.com>]

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

Re: Thoughts about formalizing the role of shepherd

[Greg Stein <gs...@gmail.com>]

On Jan 13, 2013 11:46 AM, "Benson Margulies" <bi...@gmail.com> wrote:
>...
> 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.

When I came up with the shepherd process for the Board, I specifically made
the assignments random. This was to prevent a Director from becoming
accustomed/lazy with their assignment, and to ensure that Directors
eventually get detailed insight to *all* projects. It also ensured that
Directors *had* to engage at some level with report reviewing (I felt some
Directors attended meetings without any reviewing; the shepherding helped
to involve them more fully).

Now, I'm not saying the two are the same. They share a name, and some
general concepts, but the Incubator operates very differently. I do think
the Incubator can reuse the idea of "somebody assigned to review in detail"
rather than a normal cursory review.

Anyway, I hope this background helps.

Cheers,
-g

ps. of course, randomization also meant some sucker wasn't saddled with
being the Incubator shepherd for life; it's a hard/lengthy review...

Re: Thoughts about formalizing the role of shepherd

[Dave Fisher <da...@comcast.net>]

On Jan 14, 2013, at 12:33 PM, Christian Grobmeier wrote:

> On Mon, Jan 14, 2013 at 7:18 PM, Benson Margulies <bi...@gmail.com> wrote:
> ...
>> 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.
> 
> With shepherds you might spot problems and bring them to the table.
> But it does not fix the problem of mentors going awol, putting more
> mentor energy into a project. I mean, we have often releases on
> general@ which have trouble to get necessary votes.
> 
> I believe "Shepherds" are good as they are now, but I do not see a
> reason for making them more formal or make up rules for them.

I agree. Benson should assure that Shepherds get a new assignment every time. If I were assigned the same podlings every quarterly report then that would get to be boring.

If a shepherd sees a mentor problem in a podling that they are suddenly interested in then they may choose to volunteer.

> 
>> 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.
> 
> You need people who think of the Incubator as they would think on the
> others project they commit. Committed people.
> If the system is tied to committed people and they are none, we have a problem.
> 
> I have learned that by Jukkas passion and commitment.
> 
> If we would find a way to motivate people to spend some time here, we
> won. The question we need to ask: what is preventing people from
> investing their valuable spare time into the incubator?

On the Incubator report perhaps there could be a section called:

Mentoring issues / turnover:
	- Needs additional mentor(s): Tashi
	- Recent mentoring turnover: Chukwa

I think focus there might help IPMC members consider where to place their commitment.

Regards,
Dave

> 
> Cheers
> Christian
> 
>> 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
>> <rg...@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" <bi...@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
>> 
> 
> 
> 
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
> 
> ---------------------------------------------------------------------
> 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

Re: Thoughts about formalizing the role of shepherd

[Christian Grobmeier <gr...@gmail.com>]

On Mon, Jan 14, 2013 at 7:18 PM, Benson Margulies <bi...@gmail.com> wrote:
...
> 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.

With shepherds you might spot problems and bring them to the table.
But it does not fix the problem of mentors going awol, putting more
mentor energy into a project. I mean, we have often releases on
general@ which have trouble to get necessary votes.

I believe "Shepherds" are good as they are now, but I do not see a
reason for making them more formal or make up rules for them.

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

You need people who think of the Incubator as they would think on the
others project they commit. Committed people.
If the system is tied to committed people and they are none, we have a problem.

I have learned that by Jukkas passion and commitment.

If we would find a way to motivate people to spend some time here, we
won. The question we need to ask: what is preventing people from
investing their valuable spare time into the incubator?

Cheers
Christian

> 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
> <rg...@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" <bi...@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
>



--
http://www.grobmeier.de
https://www.timeandbill.de

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

Re: Thoughts about formalizing the role of shepherd

[Matt Franklin <m....@gmail.com>]

On Mon, Jan 14, 2013 at 1:18 PM, Benson Margulies <bi...@gmail.com> wrote:
> 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.

I disagree that the need for a Shepherd would be obviated by better
mentor engagement.  I think the value of the Shepherds is their
external perspective.  Mentors are by necessity and nature close to
the project.

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

IMO, this has borne only fruit and should be continued.  A radically
different structure will take time to implement & then adjust to.

>
> 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
> <rg...@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" <bi...@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
>

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

Re: Thoughts about formalizing the role of shepherd

[Benson Margulies <bi...@gmail.com>]

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
<rg...@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" <bi...@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

Re: Thoughts about formalizing the role of shepherd

[Ross Gardler <rg...@opendirective.com>]

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" <bi...@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
>
>

Re: Thoughts about formalizing the role of shepherd

[Roman Shaposhnik <rv...@apache.org>]

On Sun, Jan 13, 2013 at 8:46 AM, Benson Margulies <bi...@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.

Let me ask you this: what is this trying to achieve? What is our
definition of success here?

I guess the 'ideal world' of the incubator I'm picturing is the one where
the structure is flat -- everybody's a mentor and there's also an
'Incubator VP' who acts just like a VP of any other project. Theoretically
you could say that there needs to be an 'Incubator PMC' equivalent
and that's what shepherds are -- but I'm not convinced this distinction
is a useful one. Of course, this is coming from a guy who also believes
that most of the time committers == PMC -- so perhaps it is the same
bias talking.

Thanks,
Roman.

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

Re: Thoughts about formalizing the role of shepherd

[Suresh Marru <sm...@apache.org>]

One comment or worry I have is, so far the shepherd comments have been very useful, but we have to be cognizant of the fact that shepherds are very less informed then mentors (by design). So the shepherd comments have to be really constructive. There is a risk of some delicate conversations offending mentors who volunteer lot of energy on the ground -- especially if a shepherd (without too much context) makes a strong recommendation. I am not sure this will be the case, but just a caution. In any case,  please do not take my comments seriously as I am fairly new to both shepherding and mentoring.

+ 0 -- With much much insights, I will refrain any strong opinions on formalizing shepherds and will remain neutral.

Suresh

On Jan 13, 2013, at 11:46 AM, Benson Margulies <bi...@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