You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Roman Shaposhnik <rv...@apache.org> on 2014/06/01 08:39:06 UTC

Re: Reports needing shepherd attention

On Sat, May 31, 2014 at 10:18 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> Regardless, I guess my real question is this: if a podling feels that they
>> need to achieve a certain milestone in software completeness before
>> they can confidently graduate, are we really in a position to push
>> them out of the incubator somewhat against their will?
>
> I can imagine situations in which you'd graduate a podling that has a
> diverse and self-managing PPMC and advise the PMC to work with Press, or
> Infra, or Brand, or Comdev post-graduation to improve some aspect or
> another.

I can't. If the community doesn't think it is ready the best you can do is
try to persuade them that they are ready, but not graduate by force.

> Back to the instance at hand: the project reported that adding a feature
> is a graduation blocker.  That is unusual.  The likely explanation is
> that they misunderstood what graduation is about.  The situation should
> therefore be checked.
> If the project has a misunderstanding then it
> should be corrected, and if it doesn't then it'd be better if they
> clarified in future reports why they, unusually, consider adding a
> feature to be a graduation blocker.

That's a good point, but see below.

> A podling was asked "Has your community grown" and replied that the
> statistics server was down.  To me, that's not a satisfactory answer,
> for the same reason that (with car drivers) a broken speedometer is not
> a carte blanche to speeding.

I'd agree with you in theory. In practice, the only way for this kind of
checks-n-balances to happen is for mentors to stay super engaged
and take it onto themselves to address these kind of issues during
report review within the community (before the report is every submitted
to the wiki).

Perhaps this email thread will be a reminder to all the mentors out there
to make sure they follow up ASAP.

The next best thing (just as Marvin proposed) would be for the entire
report to be submitted for a short review window (instead of just
shepherding notes). That would also engage the entire IPMC community,
but only as a measure of last resort where we ourselves would
flag this issues to both mentors and the board.

At the end of the day -- just like the board is a hammer, not a scalpel,
IPMC (as a collective) is not a proper tool for the kind of intricate job
you've meant in your replies. Our only hope is to have good mentors.

> Time for reductio ad absurdum.

Never a good move on an email thread ;-)

Thanks,
Roman.

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


Re: Reports needing shepherd attention

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Roman Shaposhnik wrote on Sat, May 31, 2014 at 23:39:06 -0700:
> On Sat, May 31, 2014 at 10:18 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> >> Regardless, I guess my real question is this: if a podling feels that they
> >> need to achieve a certain milestone in software completeness before
> >> they can confidently graduate, are we really in a position to push
> >> them out of the incubator somewhat against their will?
> >
> > I can imagine situations in which you'd graduate a podling that has a
> > diverse and self-managing PPMC and advise the PMC to work with Press, or
> > Infra, or Brand, or Comdev post-graduation to improve some aspect or
> > another.
> 
> I can't. If the community doesn't think it is ready the best you can do is
> try to persuade them that they are ready, but not graduate by force.
> 

We aren't talking about the same thing.

I don't think it would make sense to graduate somebody by force.

I'm just saying that I see scenarios in which a project graduates that
still has some problems, which the PMC-to-be can address by itself
(i.e., doesn't need IPMC's hand-holding with addressing).

> > Back to the instance at hand: the project reported that adding a feature
> > is a graduation blocker.  That is unusual.  The likely explanation is
> > that they misunderstood what graduation is about.  The situation should
> > therefore be checked.
> > If the project has a misunderstanding then it
> > should be corrected, and if it doesn't then it'd be better if they
> > clarified in future reports why they, unusually, consider adding a
> > feature to be a graduation blocker.
> 
> That's a good point, but see below.
> 
> > A podling was asked "Has your community grown" and replied that the
> > statistics server was down.  To me, that's not a satisfactory answer,
> > for the same reason that (with car drivers) a broken speedometer is not
> > a carte blanche to speeding.
> 
> [...] only hope is to have good mentors.

+1

> > Time for reductio ad absurdum.
> 
> Never a good move on an email thread ;-)

Because...?

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