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 2015/01/14 17:48:14 UTC
Next steps for various proposals (mentor re-boot, pTLP, etc.)
Hi!
at this point we have had a few lively threads
discussing three somewhat different proposals:
#1 mentor re-boot
#2 pTLP
#3 Ross's strawman http://s.apache.org/8eS
it feels to me that all three need additional work
to be done before we can have any reasonable
consensus around them (let alone voting).
Wearing my chair hat, I would like to suggest that
the next step should be: for each proposal we identify
points that are going to block consensus (AKA would
result in -1 vote if it comes to a vote). I suggest we
do it on the wiki pages themselves (I'll wikify Ross's
proposal tonight). Not editing the wikis but simply
collecting this feedback as the last section in each
proposal. The idea would be to identify all such
points in a week or so.
Sounds good?
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Mon, Jan 19, 2015 at 2:59 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> On Sat, Jan 17, 2015 at 12:16 AM, Ross Gardler (MS OPEN TECH)
> <Ro...@microsoft.com> wrote:
>> http://wiki.apache.org/incubator/IncubatorIssues2013
>
> If someone reviews this it would be nice to add brief comments about
> today's state, maybe right after each item's title (like "early 2014
> status: still a problem")
First of all, this appears to be an immutable page.
That said, looking at the list of issues, I'd say
that every one of them still applies (the caveat
being: to what degree) although the analysis
suggestions could be slightly out of date.
In general, I'd split the issues in two categories:
Operational/Structural issues
Issue 01 - lack of mentor participation
Issue 02 - lack of progress towards graduation
Issue 03 - Too many cooks spoil the IPMC broth
Issue 04 - Horrible signal-to-noise ratio on general@a.o for
podling contributors
Issue 05 - Inadequate reporting
Issue 07 - Vetting releases is a huge pain
Issue 08 - The IPMC is broken
Documentation:
Issue 06 - Podlings status metadata is not reliable
Issue 09 - People do not follow through to improve Incubator documentation
Issue 10 - Steps for Podlings to Acquire Resources Are Disparate
and Poorly Documented
Issue 11 - Clearly and concisely document the "principles and
constraints" for the ASF
Issue 12 - Cold welcome for new projects
In my view, the two categories can be addressed in
parallel. The Documentation agenda seems to be
passionately championed by Marvin and a few other folks.
I'd expect them to make quite a bit of progress there.
Personally, I'd like to focus this thread on the first category.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Sat, Jan 17, 2015 at 12:16 AM, Ross Gardler (MS OPEN TECH)
<Ro...@microsoft.com> wrote:
> http://wiki.apache.org/incubator/IncubatorIssues2013
If someone reviews this it would be nice to add brief comments about
today's state, maybe right after each item's title (like "early 2014
status: still a problem")
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by "Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>.
http://wiki.apache.org/incubator/IncubatorIssues2013
Ross
-----Original Message-----
From: Alan D. Cabrera [mailto:list@toolazydogs.com]
Sent: Friday, January 16, 2015 3:13 PM
To: general@incubator.apache.org
Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
> On Jan 16, 2015, at 3:04 PM, Ross Gardler (MS OPEN TECH) <Ro...@microsoft.com> wrote:
>
> Or we could just do it
>
> We debated plenty. Three proposals came out of it (two if you look at mine as the strawman it was intended to be).
>
> Those proposals are not mutually exclusive.
>
> I say record them in the wiki. Run them for a while. Then compare against the problems document we drew up a couple of years back and see how effective they are.
Where is this problems document?
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 16, 2015, at 3:04 PM, Ross Gardler (MS OPEN TECH) <Ro...@microsoft.com> wrote:
>
> Or we could just do it
>
> We debated plenty. Three proposals came out of it (two if you look at mine as the strawman it was intended to be).
>
> Those proposals are not mutually exclusive.
>
> I say record them in the wiki. Run them for a while. Then compare against the problems document we drew up a couple of years back and see how effective they are.
Where is this problems document?
Regards,
Alan
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Fri, Jan 16, 2015 at 3:04 PM, Ross Gardler (MS OPEN TECH)
<Ro...@microsoft.com> wrote:
> Or we could just do it
>
> We debated plenty. Three proposals came out of it (two if you look at mine as the strawman it was intended to be).
As a matter of fact, while editing yours (sorry, I took the liberty) and leaving
feedback for Alan's I felt like they were pretty close in spirit, with
yours going
all the way to make podlings behave as close to TLPs as possible while
still not overwhelming the board.
> Those proposals are not mutually exclusive.
>
> I say record them in the wiki. Run them for a while. Then compare against the problems
> document we drew up a couple of years back and see how effective they are.
That's the plan.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by "Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>.
Or we could just do it
We debated plenty. Three proposals came out of it (two if you look at mine as the strawman it was intended to be).
Those proposals are not mutually exclusive.
I say record them in the wiki. Run them for a while. Then compare against the problems document we drew up a couple of years back and see how effective they are.
Microsoft Open Technologies, Inc.
A subsidiary of Microsoft Corporation
-----Original Message-----
From: Alan D. Cabrera [mailto:list@toolazydogs.com]
Sent: Friday, January 16, 2015 2:52 PM
To: general@incubator.apache.org
Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
> On Jan 14, 2015, at 8:48 AM, Roman Shaposhnik <rv...@apache.org> wrote:
>
> Hi!
>
> at this point we have had a few lively threads discussing three
> somewhat different proposals:
> #1 mentor re-boot
> #2 pTLP
> #3 Ross's strawman http://s.apache.org/8eS it feels to me that all
> three need additional work to be done before we can have any
> reasonable consensus around them (let alone voting).
>
> Wearing my chair hat, I would like to suggest that the next step
> should be: for each proposal we identify points that are going to
> block consensus (AKA would result in -1 vote if it comes to a vote). I
> suggest we do it on the wiki pages themselves (I'll wikify Ross's
> proposal tonight). Not editing the wikis but simply collecting this
> feedback as the last section in each proposal. The idea would be to
> identify all such points in a week or so.
>
> Sounds good?
Another, or complementary, way this could be done is to work out the pros and cons on a spreadsheet. This would not take the place of a vote, but would provide some useful insight into the opinions that the community has with regards to various aspects of each proposal.
http://s.apache.org/reboot <http://s.apache.org/reboot>
People who wish to contribute their opinions can send an email to adc at apache dot org and I will add them to the list of editors.
There is a Pros tab. Here people can add columns that represent an advantageous aspect that a proposal should cause. It doesn’t have to apply to all, or any, of the existing proposals. There is no limit to the number of advantages aspects added to this tab. Each row in this spreadsheet, this tab specifically, is for each person to indicate using 0-5 how important they feel that particular advantageous aspects are to solving the Incubator’s “woes”.
There is a Cons tab. Here people can add columns that represent an disadvantageous aspect that a proposal could cause. It doesn’t have to apply to all, or any, of the existing proposals. There is no limit to the number of disadvantageous aspects added to this tab. Each row in this spreadsheet, this tab specifically, is for each person to indicate using 0-5 how relevant they feel that particular disadvantageous aspects are to solving the Incubator’s “woes”.
The above two tabs will represent what the community thinks are good things and bad things to do for the Incubator.
Then for each proposal there is a corresponding Pros and Cons tab. These are for people to indicate how strongly they feel that certain advantageous or disadvantageous aspects apply to specific proposals using 0-5.
All of this data bubbles up to the summary tab.
Regards,
Alan
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 14, 2015, at 8:48 AM, Roman Shaposhnik <rv...@apache.org> wrote:
>
> Hi!
>
> at this point we have had a few lively threads
> discussing three somewhat different proposals:
> #1 mentor re-boot
> #2 pTLP
> #3 Ross's strawman http://s.apache.org/8eS
> it feels to me that all three need additional work
> to be done before we can have any reasonable
> consensus around them (let alone voting).
>
> Wearing my chair hat, I would like to suggest that
> the next step should be: for each proposal we identify
> points that are going to block consensus (AKA would
> result in -1 vote if it comes to a vote). I suggest we
> do it on the wiki pages themselves (I'll wikify Ross's
> proposal tonight). Not editing the wikis but simply
> collecting this feedback as the last section in each
> proposal. The idea would be to identify all such
> points in a week or so.
>
> Sounds good?
Another, or complementary, way this could be done is to work out the pros and cons on a spreadsheet. This would not take the place of a vote, but would provide some useful insight into the opinions that the community has with regards to various aspects of each proposal.
http://s.apache.org/reboot <http://s.apache.org/reboot>
People who wish to contribute their opinions can send an email to adc at apache dot org and I will add them to the list of editors.
There is a Pros tab. Here people can add columns that represent an advantageous aspect that a proposal should cause. It doesn’t have to apply to all, or any, of the existing proposals. There is no limit to the number of advantages aspects added to this tab. Each row in this spreadsheet, this tab specifically, is for each person to indicate using 0-5 how important they feel that particular advantageous aspects are to solving the Incubator’s “woes”.
There is a Cons tab. Here people can add columns that represent an disadvantageous aspect that a proposal could cause. It doesn’t have to apply to all, or any, of the existing proposals. There is no limit to the number of disadvantageous aspects added to this tab. Each row in this spreadsheet, this tab specifically, is for each person to indicate using 0-5 how relevant they feel that particular disadvantageous aspects are to solving the Incubator’s “woes”.
The above two tabs will represent what the community thinks are good things and bad things to do for the Incubator.
Then for each proposal there is a corresponding Pros and Cons tab. These are for people to indicate how strongly they feel that certain advantageous or disadvantageous aspects apply to specific proposals using 0-5.
All of this data bubbles up to the summary tab.
Regards,
Alan
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Andrew Purtell <ap...@apache.org>.
I do not dispute anything written below nor do I intend this to be a last
word, just a clarification.
> I
n neither model are people powerless in any meaningful sense.
I approached these proposals by putting myself in the shoes of a newcomer
as best as I'm able (I've been PMC for years and PPMC also). The feeling of
investment in the process I'd have would be different than before under the
second two options (*not* the mentor reboot), as would be the calculus of
bringing a project to Apache. I have not observed the IPMC model to take
ownership away, because the initial contributors bringing their project
here are formed into a PPMC of equals and the usual release votes done by
the IPMC are up-or-down checks on releases, not exercises in differential
power.
On Mon, Jan 19, 2015 at 4:15 PM, Benson Margulies <bi...@gmail.com>
wrote:
> I'm in the odd situation of not particularly wanting to argue in favor
> of the proposal I wrote, yet finding it hard to resist the provocation
> of messages that appear, to me, to misunderstand it. So I'll restrict
> myself to the following, and I won't reply to any further dispute.
> Anyone else is welcome to have a last-er word than me.
>
> The incubator is like no other Apache project. It is not a
> meritocratic, volunteer, community, producing a software product for
> the public good. It is a volunteer, meritocratic, group of people
> solving a problem for the board.
>
> The problem that the incubator sets out to solve is this: "How do you
> bootstrap a community from scratch?"
>
> Because it is a group of people solving a problem for the board,
> there's no special 'merit' in shaping it in the usual ASF PMC growing
> community mold. There may by some problems with that shape related to
> scale, noise, and responsibility. Some people who find those problems
> to be severe want to make changes. Others, not so much. The board is
> always free to solve any problem with any structure that it finds
> effective; there's no 'constitutional' requirement that everything is
> a meritocratic PMC. Witness what happened to ApacheCon.
>
> We have here two competing visions. The current vision says: "Let
> people who have never run an Apache community it start doing it with
> coaching and supervision from 'mentors'." The alternative vision says,
> "Start with a kernel of people who have done it before." Those of you
> who are happy with the current vision? Great! I wrote up the
> alternative vision to try to put some clarity onto a lot of prior
> writing that found fault with the current model and looked for an
> alternative.
>
> I
>
> n neither model are people powerless in any meaningful sense. In the
> current model, people have an interaction with the full IPMC. They can
> get pretty frustrated, but, as Mavin has documented, the frustration
> is more the fault of the lack of documentation than of the behavior of
> the IPMC. In the alternative model, they _start out_ with a group of
> 'strangers' at the center of their community, but those strangers are
> chosen specifically for their ability and experience in building a
> consensus community. And, in any case, they they will rapidly become
> an ever-smaller fraction of the group.
>
> Badly-behaved mentors (and other IPMC members) can overbear in the
> current model, and badly-behaved seed-PMC members could overbear in
> the alternative.
>
> I very much doubt that email discussion will yield any consensus to do
> anything radical. Which might be fine. When the time comes to find
> Roman's successor, an interesting situation may arise in which
> candidates might declare their intention to implement changes. And
> just to be clear, _I_ am not running on the platform of implementing
> what I wrote -- or any other way.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Benson Margulies <bi...@gmail.com>.
I'm in the odd situation of not particularly wanting to argue in favor
of the proposal I wrote, yet finding it hard to resist the provocation
of messages that appear, to me, to misunderstand it. So I'll restrict
myself to the following, and I won't reply to any further dispute.
Anyone else is welcome to have a last-er word than me.
The incubator is like no other Apache project. It is not a
meritocratic, volunteer, community, producing a software product for
the public good. It is a volunteer, meritocratic, group of people
solving a problem for the board.
The problem that the incubator sets out to solve is this: "How do you
bootstrap a community from scratch?"
Because it is a group of people solving a problem for the board,
there's no special 'merit' in shaping it in the usual ASF PMC growing
community mold. There may by some problems with that shape related to
scale, noise, and responsibility. Some people who find those problems
to be severe want to make changes. Others, not so much. The board is
always free to solve any problem with any structure that it finds
effective; there's no 'constitutional' requirement that everything is
a meritocratic PMC. Witness what happened to ApacheCon.
We have here two competing visions. The current vision says: "Let
people who have never run an Apache community it start doing it with
coaching and supervision from 'mentors'." The alternative vision says,
"Start with a kernel of people who have done it before." Those of you
who are happy with the current vision? Great! I wrote up the
alternative vision to try to put some clarity onto a lot of prior
writing that found fault with the current model and looked for an
alternative.
In neither model are people powerless in any meaningful sense. In the
current model, people have an interaction with the full IPMC. They can
get pretty frustrated, but, as Mavin has documented, the frustration
is more the fault of the lack of documentation than of the behavior of
the IPMC. In the alternative model, they _start out_ with a group of
'strangers' at the center of their community, but those strangers are
chosen specifically for their ability and experience in building a
consensus community. And, in any case, they they will rapidly become
an ever-smaller fraction of the group.
Badly-behaved mentors (and other IPMC members) can overbear in the
current model, and badly-behaved seed-PMC members could overbear in
the alternative.
I very much doubt that email discussion will yield any consensus to do
anything radical. Which might be fine. When the time comes to find
Roman's successor, an interesting situation may arise in which
candidates might declare their intention to implement changes. And
just to be clear, _I_ am not running on the platform of implementing
what I wrote -- or any other way.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by "Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>.
As an IPMC member I have objected to this part of the report.
As a Director I have already commented on the report that this practice is inappropriate. I will ask for that section to be struck from the minutes, we'll see if other directors agree.
My comment on the report is:
rg: I've already made the point on the incubator list but I do not
see benefit in highlighting mentors who have not signed-off. It
means very little in isolation (a busy volunteer who didn't have
the time to tick a box on a wiki is not necessarily an absent
mentor from the project community). Given these records are
public I would prefer not to see this data in the minutes.
Ross
-----Original Message-----
From: Andrew Purtell [mailto:apurtell@apache.org]
Sent: Tuesday, January 20, 2015 11:18 AM
To: general@incubator.apache.org
Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
I just experienced being placed on a naughty list in the last incubator report because I was travelling for business and missed checking the box for HTrace. It may not be on any specific proposal. It seems to already be in practice.
On Tue, Jan 20, 2015 at 6:36 AM, Alan D. Cabrera <li...@toolazydogs.com>
wrote:
> Can you add your concerns to the end each of the wiki pages?
>
> I intend to update my proposal to clear up the apprehensions that you
> seem to have. You can then remove/amend your concerns from the wiki proposal.
> I will quickly state that “naughty lists” are not part of the
> mentor-reboot proposal.
>
>
> Thanks!
>
>
> Regards,
> Alan
>
> > On Jan 19, 2015, at 3:55 PM, Andrew Purtell <ap...@apache.org> wrote:
> >
> > I think the cures are all problematic and might be worse than the
> disease.
> >
> >
> > On Mon, Jan 19, 2015 at 1:47 PM, Roman Shaposhnik <rvs@apache.org
> <ma...@apache.org>> wrote:
> >
> >> On Wed, Jan 14, 2015 at 8:48 AM, Roman Shaposhnik <rv...@apache.org>
> wrote:
> >>> Hi!
> >>>
> >>> at this point we have had a few lively threads discussing three
> >>> somewhat different proposals:
> >>> #1 mentor re-boot
> >>> #2 pTLP
> >>> #3 Ross's strawman http://s.apache.org/8eS it feels to me that
> >>> all three need additional work to be done before we can have any
> >>> reasonable consensus around them (let alone voting).
> >>>
> >>> Wearing my chair hat, I would like to suggest that the next step
> >>> should be: for each proposal we identify points that are going to
> >>> block consensus (AKA would result in -1 vote if it comes to a
> >>> vote). I suggest we do it on the wiki pages themselves (I'll
> >>> wikify Ross's proposal tonight). Not editing the wikis but simply
> >>> collecting this feedback as the last section in each proposal. The
> >>> idea would be to identify all such points in a week or so.
> >>>
> >>> Sounds good?
> >>
> >> To follow up. Each of the proposals:
> >> https://wiki.apache.org/incubator/MentorRebootProposal
> >
> >
> > "An active mentor is removed from a podling if that mentor does
> > not review/sign off on a release."
> >
> > The above implies the foundation has a pool of mentors able to
> > consistently meet every reporting requirement in a timely manner,
> > without regard to personal or professional obstacles. I don't see
> > it. For an organization almost entirely made up of volunteers this
> > seems overly optimistic. There is only a small core membership who
> > are capable and willing to do this as evidenced by a skim of history
> > of general@incubator and members@. Perhaps this core group will end
> > up shouldering the incubation load in its entirety. Although sadly
> > this is more or less the current state of affairs, individual
> > podlings do come with new mentors
> not
> > part of the "professional membership" motivated to see at least that
> > specific podling through. It's also risky to expect mentors kicked
> > from a podling to be okay with it and want to try again, especially
> > if listed on some "naughty list" to the board.
> >
> >
> >
> >>
> >> https://wiki.apache.org/incubator/Strawman <
> https://wiki.apache.org/incubator/Strawman>
> >
> >
> > "Only ASF members on the PPMC will have binding votes for the
> releases."
> >
> > This proposal seems better than the others in my estimation, but
> > doesn't allow podlings full investment in their own release
> > management. The
> members
> > on the PPMC who have binding votes will drive the release process
> > out of necessity. Once the podling graduates and the members on the
> > PPMC leave
> to
> > resume other interests or duties, only then for the first time is
> > the project running their own releases. I think it was better to let
> > the podling own their release process but have the IPMC (or
> > equivalent) have
> an
> > up-or-down vote afterward as a check on their activities.
> >
> >
> >
> >>
> >> https://wiki.apache.org/incubator/IncubatorV2 <
> https://wiki.apache.org/incubator/IncubatorV2>
> >>
> >
> > This proposal revokes merit earned by existing IPMC members and
> > reboots incubator supervision as a "sub-board" limited to 15
> > members. How members apply to this board is not specified. It is
> > suggested the current board make recommendations to the board for
> > their replacements, a very unmeritocratic suggestion that is quite
> > surprising. It's not clear at all how the membership can address
> > issues with this "sub-board" as they can with the Board. I think
> > this proposal takes the likely outcome of the
> first
> > proposal, that only a small core group of "professional membership"
> > can manage sufficient activity as mentors to not be kicked from
> > podlings, and codifies it with new structure and bylaws. Maybe in
> > the end this is admitting reality. However, discussion of this
> > proposal also floated the idea that the "sub-board" be later given
> > authority to supervise the
> affairs
> > of established TLPs, which is deeply problematic* and I suspect
> > still hovers in the wings. I would hope not.
> >
> > "All proposals for new ASF projects must include an initial PMC
> > chair and an initial set of PMC members. These people must be
> > acceptable to the board. It is the responsibility of the Incubator
> > Committee to vett these people. All of them must have experience on existing PMCs"
> >
> > This doubles down on the aspect of the Strawman proposal where PPMC
> members
> > are powerless to vote on releases. Here they are powerless to make
> > any
> and
> > all project management decisions about their own software they
> > brought to Apache. It's not mentoring if you make all of the decisions for them.
> >
> > * - Find me any PMC of any TLP that would welcome the
> > self-introduction of newly empowered meddlers who by definition are
> > uninformed of their project particulars.
> >
> >
> >
> >> now has the feedback gathering section at the end.
> >> I am done with my personal feedback. Please provide yours.
> >>
> >> Here's the criteria you can apply when deciding whether to spend
> >> time on this or not: imagine that the proposal the way it is
> >> written were to come to a vote. If at that point you'd be inclined
> >> to vote -1 -- please let us know NOW.
> >>
> >> Using a VOTE thread as a forcing function for folks to provide
> >> feedback would be *really* unfortunate.
> >>
> >> Also, please try to keep 'deal breakers' section as small as
> >> possible (pushing all the non-critical piece of your feedback to
> >> the 'suggestions' section). When in doubt (even if it is -0) --
> >> make it go to suggestions.
> >>
> >> The only items that belong to 'dealbreakers' are the ones that
> >> would *strongly* motivate you to vote -1
> >>
> >> Thanks,
> >> Roman.
> >>
> >> -------------------------------------------------------------------
> >> -- To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet
> > Hein (via Tom White)
>
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
It may already be a “practice" but it is not part of the mentor-reboot proposal.
Regards,
Alan
> On Jan 20, 2015, at 11:17 AM, Andrew Purtell <ap...@apache.org> wrote:
>
> I just experienced being placed on a naughty list in the last incubator
> report because I was travelling for business and missed checking the box
> for HTrace. It may not be on any specific proposal. It seems to already be
> in practice.
>
>
>
> On Tue, Jan 20, 2015 at 6:36 AM, Alan D. Cabrera <li...@toolazydogs.com>
> wrote:
>
>> Can you add your concerns to the end each of the wiki pages?
>>
>> I intend to update my proposal to clear up the apprehensions that you seem
>> to have. You can then remove/amend your concerns from the wiki proposal.
>> I will quickly state that “naughty lists” are not part of the mentor-reboot
>> proposal.
>>
>>
>> Thanks!
>>
>>
>> Regards,
>> Alan
>>
>>> On Jan 19, 2015, at 3:55 PM, Andrew Purtell <ap...@apache.org> wrote:
>>>
>>> I think the cures are all problematic and might be worse than the
>> disease.
>>>
>>>
>>> On Mon, Jan 19, 2015 at 1:47 PM, Roman Shaposhnik <rvs@apache.org
>> <ma...@apache.org>> wrote:
>>>
>>>> On Wed, Jan 14, 2015 at 8:48 AM, Roman Shaposhnik <rv...@apache.org>
>> wrote:
>>>>> Hi!
>>>>>
>>>>> at this point we have had a few lively threads
>>>>> discussing three somewhat different proposals:
>>>>> #1 mentor re-boot
>>>>> #2 pTLP
>>>>> #3 Ross's strawman http://s.apache.org/8eS
>>>>> it feels to me that all three need additional work
>>>>> to be done before we can have any reasonable
>>>>> consensus around them (let alone voting).
>>>>>
>>>>> Wearing my chair hat, I would like to suggest that
>>>>> the next step should be: for each proposal we identify
>>>>> points that are going to block consensus (AKA would
>>>>> result in -1 vote if it comes to a vote). I suggest we
>>>>> do it on the wiki pages themselves (I'll wikify Ross's
>>>>> proposal tonight). Not editing the wikis but simply
>>>>> collecting this feedback as the last section in each
>>>>> proposal. The idea would be to identify all such
>>>>> points in a week or so.
>>>>>
>>>>> Sounds good?
>>>>
>>>> To follow up. Each of the proposals:
>>>> https://wiki.apache.org/incubator/MentorRebootProposal
>>>
>>>
>>> "An active mentor is removed from a podling if that mentor does not
>>> review/sign off on a release."
>>>
>>> The above implies the foundation has a pool of mentors able to
>>> consistently meet every reporting requirement in a timely manner, without
>>> regard to personal or professional obstacles. I don't see it. For an
>>> organization almost entirely made up of volunteers this seems overly
>>> optimistic. There is only a small core membership who are capable and
>>> willing to do this as evidenced by a skim of history of general@incubator
>>> and members@. Perhaps this core group will end up shouldering the
>>> incubation load in its entirety. Although sadly this is more or less the
>>> current state of affairs, individual podlings do come with new mentors
>> not
>>> part of the "professional membership" motivated to see at least that
>>> specific podling through. It's also risky to expect mentors kicked from a
>>> podling to be okay with it and want to try again, especially if listed on
>>> some "naughty list" to the board.
>>>
>>>
>>>
>>>>
>>>> https://wiki.apache.org/incubator/Strawman <
>> https://wiki.apache.org/incubator/Strawman>
>>>
>>>
>>> "Only ASF members on the PPMC will have binding votes for the
>> releases."
>>>
>>> This proposal seems better than the others in my estimation, but doesn't
>>> allow podlings full investment in their own release management. The
>> members
>>> on the PPMC who have binding votes will drive the release process out of
>>> necessity. Once the podling graduates and the members on the PPMC leave
>> to
>>> resume other interests or duties, only then for the first time is the
>>> project running their own releases. I think it was better to let the
>>> podling own their release process but have the IPMC (or equivalent) have
>> an
>>> up-or-down vote afterward as a check on their activities.
>>>
>>>
>>>
>>>>
>>>> https://wiki.apache.org/incubator/IncubatorV2 <
>> https://wiki.apache.org/incubator/IncubatorV2>
>>>>
>>>
>>> This proposal revokes merit earned by existing IPMC members and reboots
>>> incubator supervision as a "sub-board" limited to 15 members. How members
>>> apply to this board is not specified. It is suggested the current board
>>> make recommendations to the board for their replacements, a very
>>> unmeritocratic suggestion that is quite surprising. It's not clear at all
>>> how the membership can address issues with this "sub-board" as they can
>>> with the Board. I think this proposal takes the likely outcome of the
>> first
>>> proposal, that only a small core group of "professional membership" can
>>> manage sufficient activity as mentors to not be kicked from podlings, and
>>> codifies it with new structure and bylaws. Maybe in the end this is
>>> admitting reality. However, discussion of this proposal also floated the
>>> idea that the "sub-board" be later given authority to supervise the
>> affairs
>>> of established TLPs, which is deeply problematic* and I suspect still
>>> hovers in the wings. I would hope not.
>>>
>>> "All proposals for new ASF projects must include an initial PMC chair and
>>> an initial set of PMC members. These people must be acceptable to the
>>> board. It is the responsibility of the Incubator Committee to vett these
>>> people. All of them must have experience on existing PMCs"
>>>
>>> This doubles down on the aspect of the Strawman proposal where PPMC
>> members
>>> are powerless to vote on releases. Here they are powerless to make any
>> and
>>> all project management decisions about their own software they brought to
>>> Apache. It's not mentoring if you make all of the decisions for them.
>>>
>>> * - Find me any PMC of any TLP that would welcome the self-introduction
>>> of newly empowered meddlers who by definition are uninformed of their
>>> project particulars.
>>>
>>>
>>>
>>>> now has the feedback gathering section at the end.
>>>> I am done with my personal feedback. Please provide
>>>> yours.
>>>>
>>>> Here's the criteria you can apply when deciding whether
>>>> to spend time on this or not: imagine that the proposal
>>>> the way it is written were to come to a vote. If at that point
>>>> you'd be inclined to vote -1 -- please let us know NOW.
>>>>
>>>> Using a VOTE thread as a forcing function for folks to
>>>> provide feedback would be *really* unfortunate.
>>>>
>>>> Also, please try to keep 'deal breakers' section as small
>>>> as possible (pushing all the non-critical piece of your
>>>> feedback to the 'suggestions' section). When in doubt
>>>> (even if it is -0) -- make it go to suggestions.
>>>>
>>>> The only items that belong to 'dealbreakers' are the ones
>>>> that would *strongly* motivate you to vote -1
>>>>
>>>> Thanks,
>>>> Roman.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Best regards,
>>>
>>> - Andy
>>>
>>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>>> (via Tom White)
>>
>>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Andrew Purtell <ap...@apache.org>.
I just experienced being placed on a naughty list in the last incubator
report because I was travelling for business and missed checking the box
for HTrace. It may not be on any specific proposal. It seems to already be
in practice.
On Tue, Jan 20, 2015 at 6:36 AM, Alan D. Cabrera <li...@toolazydogs.com>
wrote:
> Can you add your concerns to the end each of the wiki pages?
>
> I intend to update my proposal to clear up the apprehensions that you seem
> to have. You can then remove/amend your concerns from the wiki proposal.
> I will quickly state that “naughty lists” are not part of the mentor-reboot
> proposal.
>
>
> Thanks!
>
>
> Regards,
> Alan
>
> > On Jan 19, 2015, at 3:55 PM, Andrew Purtell <ap...@apache.org> wrote:
> >
> > I think the cures are all problematic and might be worse than the
> disease.
> >
> >
> > On Mon, Jan 19, 2015 at 1:47 PM, Roman Shaposhnik <rvs@apache.org
> <ma...@apache.org>> wrote:
> >
> >> On Wed, Jan 14, 2015 at 8:48 AM, Roman Shaposhnik <rv...@apache.org>
> wrote:
> >>> Hi!
> >>>
> >>> at this point we have had a few lively threads
> >>> discussing three somewhat different proposals:
> >>> #1 mentor re-boot
> >>> #2 pTLP
> >>> #3 Ross's strawman http://s.apache.org/8eS
> >>> it feels to me that all three need additional work
> >>> to be done before we can have any reasonable
> >>> consensus around them (let alone voting).
> >>>
> >>> Wearing my chair hat, I would like to suggest that
> >>> the next step should be: for each proposal we identify
> >>> points that are going to block consensus (AKA would
> >>> result in -1 vote if it comes to a vote). I suggest we
> >>> do it on the wiki pages themselves (I'll wikify Ross's
> >>> proposal tonight). Not editing the wikis but simply
> >>> collecting this feedback as the last section in each
> >>> proposal. The idea would be to identify all such
> >>> points in a week or so.
> >>>
> >>> Sounds good?
> >>
> >> To follow up. Each of the proposals:
> >> https://wiki.apache.org/incubator/MentorRebootProposal
> >
> >
> > "An active mentor is removed from a podling if that mentor does not
> > review/sign off on a release."
> >
> > The above implies the foundation has a pool of mentors able to
> > consistently meet every reporting requirement in a timely manner, without
> > regard to personal or professional obstacles. I don't see it. For an
> > organization almost entirely made up of volunteers this seems overly
> > optimistic. There is only a small core membership who are capable and
> > willing to do this as evidenced by a skim of history of general@incubator
> > and members@. Perhaps this core group will end up shouldering the
> > incubation load in its entirety. Although sadly this is more or less the
> > current state of affairs, individual podlings do come with new mentors
> not
> > part of the "professional membership" motivated to see at least that
> > specific podling through. It's also risky to expect mentors kicked from a
> > podling to be okay with it and want to try again, especially if listed on
> > some "naughty list" to the board.
> >
> >
> >
> >>
> >> https://wiki.apache.org/incubator/Strawman <
> https://wiki.apache.org/incubator/Strawman>
> >
> >
> > "Only ASF members on the PPMC will have binding votes for the
> releases."
> >
> > This proposal seems better than the others in my estimation, but doesn't
> > allow podlings full investment in their own release management. The
> members
> > on the PPMC who have binding votes will drive the release process out of
> > necessity. Once the podling graduates and the members on the PPMC leave
> to
> > resume other interests or duties, only then for the first time is the
> > project running their own releases. I think it was better to let the
> > podling own their release process but have the IPMC (or equivalent) have
> an
> > up-or-down vote afterward as a check on their activities.
> >
> >
> >
> >>
> >> https://wiki.apache.org/incubator/IncubatorV2 <
> https://wiki.apache.org/incubator/IncubatorV2>
> >>
> >
> > This proposal revokes merit earned by existing IPMC members and reboots
> > incubator supervision as a "sub-board" limited to 15 members. How members
> > apply to this board is not specified. It is suggested the current board
> > make recommendations to the board for their replacements, a very
> > unmeritocratic suggestion that is quite surprising. It's not clear at all
> > how the membership can address issues with this "sub-board" as they can
> > with the Board. I think this proposal takes the likely outcome of the
> first
> > proposal, that only a small core group of "professional membership" can
> > manage sufficient activity as mentors to not be kicked from podlings, and
> > codifies it with new structure and bylaws. Maybe in the end this is
> > admitting reality. However, discussion of this proposal also floated the
> > idea that the "sub-board" be later given authority to supervise the
> affairs
> > of established TLPs, which is deeply problematic* and I suspect still
> > hovers in the wings. I would hope not.
> >
> > "All proposals for new ASF projects must include an initial PMC chair and
> > an initial set of PMC members. These people must be acceptable to the
> > board. It is the responsibility of the Incubator Committee to vett these
> > people. All of them must have experience on existing PMCs"
> >
> > This doubles down on the aspect of the Strawman proposal where PPMC
> members
> > are powerless to vote on releases. Here they are powerless to make any
> and
> > all project management decisions about their own software they brought to
> > Apache. It's not mentoring if you make all of the decisions for them.
> >
> > * - Find me any PMC of any TLP that would welcome the self-introduction
> > of newly empowered meddlers who by definition are uninformed of their
> > project particulars.
> >
> >
> >
> >> now has the feedback gathering section at the end.
> >> I am done with my personal feedback. Please provide
> >> yours.
> >>
> >> Here's the criteria you can apply when deciding whether
> >> to spend time on this or not: imagine that the proposal
> >> the way it is written were to come to a vote. If at that point
> >> you'd be inclined to vote -1 -- please let us know NOW.
> >>
> >> Using a VOTE thread as a forcing function for folks to
> >> provide feedback would be *really* unfortunate.
> >>
> >> Also, please try to keep 'deal breakers' section as small
> >> as possible (pushing all the non-critical piece of your
> >> feedback to the 'suggestions' section). When in doubt
> >> (even if it is -0) -- make it go to suggestions.
> >>
> >> The only items that belong to 'dealbreakers' are the ones
> >> that would *strongly* motivate you to vote -1
> >>
> >> Thanks,
> >> Roman.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
>
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Can you add your concerns to the end each of the wiki pages?
I intend to update my proposal to clear up the apprehensions that you seem to have. You can then remove/amend your concerns from the wiki proposal. I will quickly state that “naughty lists” are not part of the mentor-reboot proposal.
Thanks!
Regards,
Alan
> On Jan 19, 2015, at 3:55 PM, Andrew Purtell <ap...@apache.org> wrote:
>
> I think the cures are all problematic and might be worse than the disease.
>
>
> On Mon, Jan 19, 2015 at 1:47 PM, Roman Shaposhnik <rvs@apache.org <ma...@apache.org>> wrote:
>
>> On Wed, Jan 14, 2015 at 8:48 AM, Roman Shaposhnik <rv...@apache.org> wrote:
>>> Hi!
>>>
>>> at this point we have had a few lively threads
>>> discussing three somewhat different proposals:
>>> #1 mentor re-boot
>>> #2 pTLP
>>> #3 Ross's strawman http://s.apache.org/8eS
>>> it feels to me that all three need additional work
>>> to be done before we can have any reasonable
>>> consensus around them (let alone voting).
>>>
>>> Wearing my chair hat, I would like to suggest that
>>> the next step should be: for each proposal we identify
>>> points that are going to block consensus (AKA would
>>> result in -1 vote if it comes to a vote). I suggest we
>>> do it on the wiki pages themselves (I'll wikify Ross's
>>> proposal tonight). Not editing the wikis but simply
>>> collecting this feedback as the last section in each
>>> proposal. The idea would be to identify all such
>>> points in a week or so.
>>>
>>> Sounds good?
>>
>> To follow up. Each of the proposals:
>> https://wiki.apache.org/incubator/MentorRebootProposal
>
>
> "An active mentor is removed from a podling if that mentor does not
> review/sign off on a release."
>
> The above implies the foundation has a pool of mentors able to
> consistently meet every reporting requirement in a timely manner, without
> regard to personal or professional obstacles. I don't see it. For an
> organization almost entirely made up of volunteers this seems overly
> optimistic. There is only a small core membership who are capable and
> willing to do this as evidenced by a skim of history of general@incubator
> and members@. Perhaps this core group will end up shouldering the
> incubation load in its entirety. Although sadly this is more or less the
> current state of affairs, individual podlings do come with new mentors not
> part of the "professional membership" motivated to see at least that
> specific podling through. It's also risky to expect mentors kicked from a
> podling to be okay with it and want to try again, especially if listed on
> some "naughty list" to the board.
>
>
>
>>
>> https://wiki.apache.org/incubator/Strawman <https://wiki.apache.org/incubator/Strawman>
>
>
> "Only ASF members on the PPMC will have binding votes for the releases."
>
> This proposal seems better than the others in my estimation, but doesn't
> allow podlings full investment in their own release management. The members
> on the PPMC who have binding votes will drive the release process out of
> necessity. Once the podling graduates and the members on the PPMC leave to
> resume other interests or duties, only then for the first time is the
> project running their own releases. I think it was better to let the
> podling own their release process but have the IPMC (or equivalent) have an
> up-or-down vote afterward as a check on their activities.
>
>
>
>>
>> https://wiki.apache.org/incubator/IncubatorV2 <https://wiki.apache.org/incubator/IncubatorV2>
>>
>
> This proposal revokes merit earned by existing IPMC members and reboots
> incubator supervision as a "sub-board" limited to 15 members. How members
> apply to this board is not specified. It is suggested the current board
> make recommendations to the board for their replacements, a very
> unmeritocratic suggestion that is quite surprising. It's not clear at all
> how the membership can address issues with this "sub-board" as they can
> with the Board. I think this proposal takes the likely outcome of the first
> proposal, that only a small core group of "professional membership" can
> manage sufficient activity as mentors to not be kicked from podlings, and
> codifies it with new structure and bylaws. Maybe in the end this is
> admitting reality. However, discussion of this proposal also floated the
> idea that the "sub-board" be later given authority to supervise the affairs
> of established TLPs, which is deeply problematic* and I suspect still
> hovers in the wings. I would hope not.
>
> "All proposals for new ASF projects must include an initial PMC chair and
> an initial set of PMC members. These people must be acceptable to the
> board. It is the responsibility of the Incubator Committee to vett these
> people. All of them must have experience on existing PMCs"
>
> This doubles down on the aspect of the Strawman proposal where PPMC members
> are powerless to vote on releases. Here they are powerless to make any and
> all project management decisions about their own software they brought to
> Apache. It's not mentoring if you make all of the decisions for them.
>
> * - Find me any PMC of any TLP that would welcome the self-introduction
> of newly empowered meddlers who by definition are uninformed of their
> project particulars.
>
>
>
>> now has the feedback gathering section at the end.
>> I am done with my personal feedback. Please provide
>> yours.
>>
>> Here's the criteria you can apply when deciding whether
>> to spend time on this or not: imagine that the proposal
>> the way it is written were to come to a vote. If at that point
>> you'd be inclined to vote -1 -- please let us know NOW.
>>
>> Using a VOTE thread as a forcing function for folks to
>> provide feedback would be *really* unfortunate.
>>
>> Also, please try to keep 'deal breakers' section as small
>> as possible (pushing all the non-critical piece of your
>> feedback to the 'suggestions' section). When in doubt
>> (even if it is -0) -- make it go to suggestions.
>>
>> The only items that belong to 'dealbreakers' are the ones
>> that would *strongly* motivate you to vote -1
>>
>> Thanks,
>> Roman.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Chris Douglas <cd...@apache.org>.
Benson, Alan-
Starting a new project is not aggression; it's how we try things that
should fail independently. I have no interest in participating, but if
you believe that we should e.g., have a small, active, junior-varsity
board responsible only for overseeing and guiding new projects: write
a proposal, convince people it's a good idea, and (if accepted) see
how it works in practice.
These interminable discussions are simulacra of work, empty of
practical consequence. Even if consensus were achieved, there is no
measurable benefit. Mentors MUST be DEDICATED (sec 3.1, 3.2, 5.4g) to
the project, EXCEPT when they're not, because WORK (sec 2.3b) and LIFE
(sec 2.3c) may interfere up to three (3) times per (Earth) lunar cycle
and this one time a SQUIRREL took out the power to my neighborhood and
I couldn't sign off on a REPORT. Whatever.
If you're on the IPMC, you (a) orient projects in Apache, so they can
find resources (b) run through a curriculum to give them a sense of
the foundation's expectations (c) let them figure out the rest
themselves. Around the necessity to perform some audit before the
project can release software from the ASF, there has grown a sincere,
but misguided idea that most projects' dysfunction can always be
traced to early, correctable errors. Even if it were true- and it
isn't- it doesn't justify the bureaucracy that keeps getting layered
over this first stage of a journey that's far more difficult and
interesting when lived, rather than documented. If one accepts that
even "mature" projects need (and have) monitoring, the leap to
removing the IPMC altogether is... more of a hop. Prove this wrong; it
would be genuinely instructive.
Nobody suspects either of you of trying to subvert anything. I'd go
further: nobody cares. An effective IPMC member is as relevant as a
receptionist behind an information desk: useful to all, essential for
newcomers, and forgotten by the time you reach the stairs. You have
ideas for tracking people who sit at information desks, or possible
training programs/documentation that would make the building easier to
navigate. If that's your thing: go for it, let us know if you find
anything interesting. But stop meeting where we're trying to work. The
majority of the IPMC is here to help particular projects join the
foundation, and this annual ritual is disruptive to that goal. -C
On Wed, Jan 21, 2015 at 8:53 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>> On Jan 21, 2015, at 3:39 AM, Benson Margulies <bi...@gmail.com> wrote:
>>
>> On Wed, Jan 21, 2015 at 4:03 AM, Bertrand Delacretaz
>> <bd...@apache.org> wrote:
>>> On Tue, Jan 20, 2015 at 9:38 PM, Chris Douglas <cd...@apache.org> wrote:
>>>> On Mon, Jan 19, 2015 at 11:57 PM, Bertrand Delacretaz <
>>>> bdelacretaz@apache.org <javascript:;>> wrote:
>>>>> How is that different from pruning the current IPMC membership by
>>>>> removing inactive members?
>>>>
>>>> Doing *that* would be straightforward. Take the set of mentors on currently
>>>> incubating projects, add the other half dozen who review releases, and set
>>>> everyone else to voluntary emeritus status. Done....
>>>
>>> Agreed - but I don't see how that improves things anyway, I don't see
>>> any problem caused by those inactive members.
>>
>> The near-ad-hominem tone of this thread has extracted a reply in my own defense.
>>
>> It is a misunderstanding, verging on willful, to claim that the V2
>> proposal is primarily intended to remove either inactive or noisy
>> persons from the group. it is a fabrication that there is any idea
>> that some person other than the board might select an initial set of
>> people to further some particular agenda. The idea here of the small
>> group, extracted from something Ross wrote on the Wiki in 2013, is
>> that an incubator committee doesn't need to be big and it doesn't need
>> to grow via merit, if its only job is to accept the board's delegation
>> of a limited set of supervisory tasks. If you make a smaller group, it
>> might still contain vigorous disagreement, but on a scale where they
>> can manageably reach consensus. It would think less of the board if
>> they failed to select people likely to have some significant
>> disagreements.
>
> I resent your and Chris’ characterization of this thread. All that’s been taking place is a frank and civil discussion of opinions as to what the implication of some proposals mean. Your, and Chris’, attempt to characterize them as taking on an ad-hominem tone suggest to me that we are poking at the Achilles heal of the Iv2 proposal and Chris’ impromptu proposal to fork the Incubator.
>
> At the heart of both there is a culling of IPMC members. Sure, the new IPMC may have "Oscar Madison” and “Felix Ungar” tossed into the same bag but that’s a distraction from the real problem that I, and maybe Bertrand, are trying to point out.
>
> At the proposals' core is that there are IPMC members who want to participate but would be left out and in the end the “problems” with the Incubator would not be resolved since, as Chris accurately puts it, we will have distilled dysfunction.
>
> But is it dysfunctional? Only when it tries to be like a school of business and come up with new and improved processes for bringing in new projects instead of focusing on the core problems which don’t go away, tooling and mentor accountability. Otherwise, I think we do a pretty good job. We make mistakes, sure, but mistakes will always be made and I think we’ve made good, focused, incremental pivots to address their causes.
>
>
> Regards,
> Alan
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Benson Margulies <bi...@gmail.com>.
On Wed, Jan 21, 2015 at 11:53 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
>> On Jan 21, 2015, at 3:39 AM, Benson Margulies <bi...@gmail.com> wrote:
>>
>> On Wed, Jan 21, 2015 at 4:03 AM, Bertrand Delacretaz
>> <bd...@apache.org> wrote:
>>> On Tue, Jan 20, 2015 at 9:38 PM, Chris Douglas <cd...@apache.org> wrote:
>>>> On Mon, Jan 19, 2015 at 11:57 PM, Bertrand Delacretaz <
>>>> bdelacretaz@apache.org <javascript:;>> wrote:
>>>>> How is that different from pruning the current IPMC membership by
>>>>> removing inactive members?
>>>>
>>>> Doing *that* would be straightforward. Take the set of mentors on currently
>>>> incubating projects, add the other half dozen who review releases, and set
>>>> everyone else to voluntary emeritus status. Done....
>>>
>>> Agreed - but I don't see how that improves things anyway, I don't see
>>> any problem caused by those inactive members.
>>
>> The near-ad-hominem tone of this thread has extracted a reply in my own defense.
>>
>> It is a misunderstanding, verging on willful, to claim that the V2
>> proposal is primarily intended to remove either inactive or noisy
>> persons from the group. it is a fabrication that there is any idea
>> that some person other than the board might select an initial set of
>> people to further some particular agenda. The idea here of the small
>> group, extracted from something Ross wrote on the Wiki in 2013, is
>> that an incubator committee doesn't need to be big and it doesn't need
>> to grow via merit, if its only job is to accept the board's delegation
>> of a limited set of supervisory tasks. If you make a smaller group, it
>> might still contain vigorous disagreement, but on a scale where they
>> can manageably reach consensus. It would think less of the board if
>> they failed to select people likely to have some significant
>> disagreements.
>
> I resent your and Chris’ characterization of this thread. All that’s been taking place is a frank and civil discussion of opinions as to what the implication of some proposals mean. Your, and Chris’, attempt to characterize them as taking on an ad-hominem tone suggest to me that we are poking at the Achilles heal of the Iv2 proposal and Chris’ impromptu proposal to fork the Incubator.
Since it is the tone of Chris' messages that I am predominantly
objecting to, I am nonplussed. Since the purpose of V2 was to
highlight my perception of the Achilles heel of pTLP, or alternatively
to try to build the rest of the structure it required, I am bemused to
see you looking for a heel of a heel.
Would it help if I deleted the silly thing? No one seems to like it,
and it is failing as a tool to focus discussion on my perceptions of
the missing parts of the pTLP idea. No one seems to express any
affirmative interest. All it seems to do is provoke ventilation. It is
certainly true that you and I have very different views of the
essential character of the some of the issues, but I see no value to
this discussion, the incubator, or the asf in trying any further to
bridge the gap.
I, personally, would be happy to see effort put into Marvin's
documentation project first and foremost, and any discussion about
radical or structural changes to incubation deferred until we see the
impact of that project. I, personally, would be happy to see the Board
establish an 'unincubated' project now and again when there is a
nuclear group of people qualified to run it without IPMC supervision.
I, personally, prefer that the legal structure of a thing like an
incubator match the function, but I accept that I'm apparently unique.
But I have a very hard time typing nothing when there are people
repeatedly accusing me, personally, of conspiratorial intentions. You
and other, feel that the effect of V2 would be to exclude. Fine.
That's a great reason to oppose it. (And also the change to
ApacheCon.) But I perceive trolling, or worse, when people choose to
oppose it by claiming that I drafted it with the intention of taking
control by stuffing a committee with my co-thinkers. That's the plain
sense of what Chris wrote, and I don't like it.
>
> At the heart of both there is a culling of IPMC members. Sure, the new IPMC may have "Oscar Madison” and “Felix Ungar” tossed into the same bag but that’s a distraction from the real problem that I, and maybe Bertrand, are trying to point out.
>
> At the proposals' core is that there are IPMC members who want to participate but would be left out and in the end the “problems” with the Incubator would not be resolved since, as Chris accurately puts it, we will have distilled dysfunction.
>
> But is it dysfunctional? Only when it tries to be like a school of business and come up with new and improved processes for bringing in new projects instead of focusing on the core problems which don’t go away, tooling and mentor accountability. Otherwise, I think we do a pretty good job. We make mistakes, sure, but mistakes will always be made and I think we’ve made good, focused, incremental pivots to address their causes.
>
>
> Regards,
> Alan
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 21, 2015, at 3:39 AM, Benson Margulies <bi...@gmail.com> wrote:
>
> On Wed, Jan 21, 2015 at 4:03 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
>> On Tue, Jan 20, 2015 at 9:38 PM, Chris Douglas <cd...@apache.org> wrote:
>>> On Mon, Jan 19, 2015 at 11:57 PM, Bertrand Delacretaz <
>>> bdelacretaz@apache.org <javascript:;>> wrote:
>>>> How is that different from pruning the current IPMC membership by
>>>> removing inactive members?
>>>
>>> Doing *that* would be straightforward. Take the set of mentors on currently
>>> incubating projects, add the other half dozen who review releases, and set
>>> everyone else to voluntary emeritus status. Done....
>>
>> Agreed - but I don't see how that improves things anyway, I don't see
>> any problem caused by those inactive members.
>
> The near-ad-hominem tone of this thread has extracted a reply in my own defense.
>
> It is a misunderstanding, verging on willful, to claim that the V2
> proposal is primarily intended to remove either inactive or noisy
> persons from the group. it is a fabrication that there is any idea
> that some person other than the board might select an initial set of
> people to further some particular agenda. The idea here of the small
> group, extracted from something Ross wrote on the Wiki in 2013, is
> that an incubator committee doesn't need to be big and it doesn't need
> to grow via merit, if its only job is to accept the board's delegation
> of a limited set of supervisory tasks. If you make a smaller group, it
> might still contain vigorous disagreement, but on a scale where they
> can manageably reach consensus. It would think less of the board if
> they failed to select people likely to have some significant
> disagreements.
I resent your and Chris’ characterization of this thread. All that’s been taking place is a frank and civil discussion of opinions as to what the implication of some proposals mean. Your, and Chris’, attempt to characterize them as taking on an ad-hominem tone suggest to me that we are poking at the Achilles heal of the Iv2 proposal and Chris’ impromptu proposal to fork the Incubator.
At the heart of both there is a culling of IPMC members. Sure, the new IPMC may have "Oscar Madison” and “Felix Ungar” tossed into the same bag but that’s a distraction from the real problem that I, and maybe Bertrand, are trying to point out.
At the proposals' core is that there are IPMC members who want to participate but would be left out and in the end the “problems” with the Incubator would not be resolved since, as Chris accurately puts it, we will have distilled dysfunction.
But is it dysfunctional? Only when it tries to be like a school of business and come up with new and improved processes for bringing in new projects instead of focusing on the core problems which don’t go away, tooling and mentor accountability. Otherwise, I think we do a pretty good job. We make mistakes, sure, but mistakes will always be made and I think we’ve made good, focused, incremental pivots to address their causes.
Regards,
Alan
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Benson Margulies <bi...@gmail.com>.
On Wed, Jan 21, 2015 at 4:03 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> On Tue, Jan 20, 2015 at 9:38 PM, Chris Douglas <cd...@apache.org> wrote:
>> On Mon, Jan 19, 2015 at 11:57 PM, Bertrand Delacretaz <
>> bdelacretaz@apache.org <javascript:;>> wrote:
>>> How is that different from pruning the current IPMC membership by
>>> removing inactive members?
>>
>> Doing *that* would be straightforward. Take the set of mentors on currently
>> incubating projects, add the other half dozen who review releases, and set
>> everyone else to voluntary emeritus status. Done....
>
> Agreed - but I don't see how that improves things anyway, I don't see
> any problem caused by those inactive members.
The near-ad-hominem tone of this thread has extracted a reply in my own defense.
It is a misunderstanding, verging on willful, to claim that the V2
proposal is primarily intended to remove either inactive or noisy
persons from the group. it is a fabrication that there is any idea
that some person other than the board might select an initial set of
people to further some particular agenda. The idea here of the small
group, extracted from something Ross wrote on the Wiki in 2013, is
that an incubator committee doesn't need to be big and it doesn't need
to grow via merit, if its only job is to accept the board's delegation
of a limited set of supervisory tasks. If you make a smaller group, it
might still contain vigorous disagreement, but on a scale where they
can manageably reach consensus. It would think less of the board if
they failed to select people likely to have some significant
disagreements.
>
> -Bertrand
>
> ---------------------------------------------------------------------
> 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: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Jan 20, 2015 at 9:38 PM, Chris Douglas <cd...@apache.org> wrote:
> On Mon, Jan 19, 2015 at 11:57 PM, Bertrand Delacretaz <
> bdelacretaz@apache.org <javascript:;>> wrote:
>> How is that different from pruning the current IPMC membership by
>> removing inactive members?
>
> Doing *that* would be straightforward. Take the set of mentors on currently
> incubating projects, add the other half dozen who review releases, and set
> everyone else to voluntary emeritus status. Done....
Agreed - but I don't see how that improves things anyway, I don't see
any problem caused by those inactive members.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Chris Douglas <cd...@apache.org>.
On Mon, Jan 19, 2015 at 11:57 PM, Bertrand Delacretaz <
bdelacretaz@apache.org <javascript:;>> wrote:
> How is that different from pruning the current IPMC membership by
> removing inactive members?
Doing *that* would be straightforward. Take the set of mentors on currently
incubating projects, add the other half dozen who review releases, and set
everyone else to voluntary emeritus status. Done.
The only thing people are taking from this discussion is offense. Allusions
to problematic people or patterns- presented with too few details to
refute- are coy nonsense. Contact the person(s) directly, raise it on
private@ and fix it, or swallow your indignation and live with it.
If some group thinks they're held back by the current project and they want
to try something radically new, they should JFDI already and stop twisting
in the wind. -C
RE: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by "Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>.
My strawman, which included a board like IPMC, certainly wasn't about shutting out inconvenient IPMC members, that is simply a ridiculous a d insulting suggestion (if it wasn't intended in that way then fine, but it sure sounds like it).
My strawman was partly about consensus, but mostly about having a group if people who take individual responsibility for doing the unpopular stuff when the process is failing (which is not the norm). Today it is rare for the IPMC to do that stuff, partly because it is hard to gain consensus, but mostly because it has no teeth (a phrase I used a great deal in explaining my strawman).
The goal is for that group to prevent the ongoing centralization of the IPMC and put the authority back where it belongs, with active mentors engaged with the project community.
I know some people feel that having a smaller group results in greater centralization, but that depends on who is a part of that group. The *only* goal of my strawman was to give the IPMC accountability and teeth.
Sent from my Windows Phone
________________________________
From: Bertrand Delacretaz<ma...@apache.org>
Sent: 1/20/2015 6:46 AM
To: Incubator General<ma...@incubator.apache.org>
Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
On Tue, Jan 20, 2015 at 3:35 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> ...Isn’t it obvious what the above and IncubatorV2 proposal are about? Consolidating
> like minded individuals into a new IPMC and shutting out the other inconvenient
> members until "they come to their senses”....
I don't buy that conspiracy theory, for me it's just very difficult to
build consensus in the Incubator as the goal is much fuzzier than
producing software.
But maybe I'm too candid ;-)
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Jan 20, 2015 at 4:39 PM, Alan Cabrera <li...@toolazydogs.com> wrote:
> ...Under the above proposals, that necessarily messy, frustrating, exhausting, process
> of garnering consensus on the above thorny issues will not take place as philosophically
> compatible IPM v2 members turn out Apache projects that fit their view....
Ok, I see your point now. Another reason for fixing things that need
to fix instead of blowing up the whole thing just to see if it lands
in a better shape.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Alan Cabrera <li...@toolazydogs.com>.
> On Jan 20, 2015, at 6:46 AM, Bertrand Delacretaz <bd...@apache.org> wrote:
>
>> On Tue, Jan 20, 2015 at 3:35 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>> ...Isn’t it obvious what the above and IncubatorV2 proposal are about? Consolidating
>> like minded individuals into a new IPMC and shutting out the other inconvenient
>> members until "they come to their senses”....
>
> I don't buy that conspiracy theory, for me it's just very difficult to
> build consensus in the Incubator as the goal is much fuzzier than
> producing software.
>
> But maybe I'm too candid ;-)
I am not espousing a conspiracy theory; there is no secret cabal formed after an ApaceCon pub crawl.
I too am being candid. I am merely providing an unvarnished distillation of what the proposals virtually are.
Garnering consensus is difficult here, in part because of the fuzziness you mention, but also because members have such different opinions as to what the Incubator function is and what it means to be an Apache project.
Under the above proposals, that necessarily messy, frustrating, exhausting, process of garnering consensus on the above thorny issues will not take place as philosophically compatible IPM v2 members turn out Apache projects that fit their view.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Jan 20, 2015 at 3:35 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> ...Isn’t it obvious what the above and IncubatorV2 proposal are about? Consolidating
> like minded individuals into a new IPMC and shutting out the other inconvenient
> members until "they come to their senses”....
I don't buy that conspiracy theory, for me it's just very difficult to
build consensus in the Incubator as the goal is much fuzzier than
producing software.
But maybe I'm too candid ;-)
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 19, 2015, at 11:57 PM, Bertrand Delacretaz <bd...@apache.org> wrote:
>
> On Tue, Jan 20, 2015 at 1:37 AM, Chris Douglas <cd...@apache.org> wrote:
>> ...So make a list of the IPMC members
>> you believe should judge the other 90%, and submit a proposal to the
>> board to start a new project. Fork the incubator....
>
> How is that different from pruning the current IPMC membership by
> removing inactive members?
>
> I don't think those inactive folks are a problem, but if people think
> they are it's easy to ask them if they want to stay, and remove those
> who reply no or don't reply.
No one is saying that the problem is inactive IPMC members.
No one.
Isn’t it obvious what the above and IncubatorV2 proposal are about? Consolidating like minded individuals into a new IPMC and shutting out the other inconvenient members until "they come to their senses”.
Frankly, if there are IPMC members that are a real problem then it’s the job of the VP of the Incubator to have a “chat” with them. Are there really so many that it warrants a reboot of the IPMC itself?
Regards,
Alan
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Jan 20, 2015 at 1:37 AM, Chris Douglas <cd...@apache.org> wrote:
> ...So make a list of the IPMC members
> you believe should judge the other 90%, and submit a proposal to the
> board to start a new project. Fork the incubator....
How is that different from pruning the current IPMC membership by
removing inactive members?
I don't think those inactive folks are a problem, but if people think
they are it's easy to ask them if they want to stay, and remove those
who reply no or don't reply.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by "Mattmann, Chris A (3980)" <ch...@jpl.nasa.gov>.
Ditto, kudos to ChrisD
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: Ted Dunning <te...@gmail.com>
Reply-To: "general@incubator.apache.org" <ge...@incubator.apache.org>
Date: Monday, January 19, 2015 at 5:48 PM
To: "general@incubator.apache.org" <ge...@incubator.apache.org>
Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
>On Mon, Jan 19, 2015 at 4:37 PM, Chris Douglas <cd...@apache.org>
>wrote:
>
>> submit a proposal to the
>> board to start a new project. Fork the incubator.
>>
>
>Hmm...
>
>That is the first interesting variation here.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Ted Dunning <te...@gmail.com>.
On Mon, Jan 19, 2015 at 4:37 PM, Chris Douglas <cd...@apache.org> wrote:
> submit a proposal to the
> board to start a new project. Fork the incubator.
>
Hmm...
That is the first interesting variation here.
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Chris Douglas <cd...@apache.org>.
I agree with Andrew. Creating a sub-board of the most vocal members of
the IPMC distills its dysfunction.
But this doesn't require consensus. The proposals focus on identifying
the "true" members of the IPMC; clearly, the authors believe
themselves to be among the elect. So make a list of the IPMC members
you believe should judge the other 90%, and submit a proposal to the
board to start a new project. Fork the incubator.
If the board is interested in your proposal, then you can demonstrate
how successful a small, committed group can be in contrast to the 150+
member IPMC. Concurrently, others may propose TLPs directly to the
board, and this committee will continue as-is.
Surely all of you have better things to do than... this. -C
On Mon, Jan 19, 2015 at 3:55 PM, Andrew Purtell <ap...@apache.org> wrote:
> I think the cures are all problematic and might be worse than the disease.
>
>
> On Mon, Jan 19, 2015 at 1:47 PM, Roman Shaposhnik <rv...@apache.org> wrote:
>
>> On Wed, Jan 14, 2015 at 8:48 AM, Roman Shaposhnik <rv...@apache.org> wrote:
>> > Hi!
>> >
>> > at this point we have had a few lively threads
>> > discussing three somewhat different proposals:
>> > #1 mentor re-boot
>> > #2 pTLP
>> > #3 Ross's strawman http://s.apache.org/8eS
>> > it feels to me that all three need additional work
>> > to be done before we can have any reasonable
>> > consensus around them (let alone voting).
>> >
>> > Wearing my chair hat, I would like to suggest that
>> > the next step should be: for each proposal we identify
>> > points that are going to block consensus (AKA would
>> > result in -1 vote if it comes to a vote). I suggest we
>> > do it on the wiki pages themselves (I'll wikify Ross's
>> > proposal tonight). Not editing the wikis but simply
>> > collecting this feedback as the last section in each
>> > proposal. The idea would be to identify all such
>> > points in a week or so.
>> >
>> > Sounds good?
>>
>> To follow up. Each of the proposals:
>> https://wiki.apache.org/incubator/MentorRebootProposal
>
>
> "An active mentor is removed from a podling if that mentor does not
> review/sign off on a release."
>
> The above implies the foundation has a pool of mentors able to
> consistently meet every reporting requirement in a timely manner, without
> regard to personal or professional obstacles. I don't see it. For an
> organization almost entirely made up of volunteers this seems overly
> optimistic. There is only a small core membership who are capable and
> willing to do this as evidenced by a skim of history of general@incubator
> and members@. Perhaps this core group will end up shouldering the
> incubation load in its entirety. Although sadly this is more or less the
> current state of affairs, individual podlings do come with new mentors not
> part of the "professional membership" motivated to see at least that
> specific podling through. It's also risky to expect mentors kicked from a
> podling to be okay with it and want to try again, especially if listed on
> some "naughty list" to the board.
>
>
>
>>
>> https://wiki.apache.org/incubator/Strawman
>
>
> "Only ASF members on the PPMC will have binding votes for the releases."
>
> This proposal seems better than the others in my estimation, but doesn't
> allow podlings full investment in their own release management. The members
> on the PPMC who have binding votes will drive the release process out of
> necessity. Once the podling graduates and the members on the PPMC leave to
> resume other interests or duties, only then for the first time is the
> project running their own releases. I think it was better to let the
> podling own their release process but have the IPMC (or equivalent) have an
> up-or-down vote afterward as a check on their activities.
>
>
>
>>
>> https://wiki.apache.org/incubator/IncubatorV2
>>
>
> This proposal revokes merit earned by existing IPMC members and reboots
> incubator supervision as a "sub-board" limited to 15 members. How members
> apply to this board is not specified. It is suggested the current board
> make recommendations to the board for their replacements, a very
> unmeritocratic suggestion that is quite surprising. It's not clear at all
> how the membership can address issues with this "sub-board" as they can
> with the Board. I think this proposal takes the likely outcome of the first
> proposal, that only a small core group of "professional membership" can
> manage sufficient activity as mentors to not be kicked from podlings, and
> codifies it with new structure and bylaws. Maybe in the end this is
> admitting reality. However, discussion of this proposal also floated the
> idea that the "sub-board" be later given authority to supervise the affairs
> of established TLPs, which is deeply problematic* and I suspect still
> hovers in the wings. I would hope not.
>
> "All proposals for new ASF projects must include an initial PMC chair and
> an initial set of PMC members. These people must be acceptable to the
> board. It is the responsibility of the Incubator Committee to vett these
> people. All of them must have experience on existing PMCs"
>
> This doubles down on the aspect of the Strawman proposal where PPMC members
> are powerless to vote on releases. Here they are powerless to make any and
> all project management decisions about their own software they brought to
> Apache. It's not mentoring if you make all of the decisions for them.
>
> * - Find me any PMC of any TLP that would welcome the self-introduction
> of newly empowered meddlers who by definition are uninformed of their
> project particulars.
>
>
>
>> now has the feedback gathering section at the end.
>> I am done with my personal feedback. Please provide
>> yours.
>>
>> Here's the criteria you can apply when deciding whether
>> to spend time on this or not: imagine that the proposal
>> the way it is written were to come to a vote. If at that point
>> you'd be inclined to vote -1 -- please let us know NOW.
>>
>> Using a VOTE thread as a forcing function for folks to
>> provide feedback would be *really* unfortunate.
>>
>> Also, please try to keep 'deal breakers' section as small
>> as possible (pushing all the non-critical piece of your
>> feedback to the 'suggestions' section). When in doubt
>> (even if it is -0) -- make it go to suggestions.
>>
>> The only items that belong to 'dealbreakers' are the ones
>> that would *strongly* motivate you to vote -1
>>
>> Thanks,
>> Roman.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Andrew Purtell <ap...@apache.org>.
I think the cures are all problematic and might be worse than the disease.
On Mon, Jan 19, 2015 at 1:47 PM, Roman Shaposhnik <rv...@apache.org> wrote:
> On Wed, Jan 14, 2015 at 8:48 AM, Roman Shaposhnik <rv...@apache.org> wrote:
> > Hi!
> >
> > at this point we have had a few lively threads
> > discussing three somewhat different proposals:
> > #1 mentor re-boot
> > #2 pTLP
> > #3 Ross's strawman http://s.apache.org/8eS
> > it feels to me that all three need additional work
> > to be done before we can have any reasonable
> > consensus around them (let alone voting).
> >
> > Wearing my chair hat, I would like to suggest that
> > the next step should be: for each proposal we identify
> > points that are going to block consensus (AKA would
> > result in -1 vote if it comes to a vote). I suggest we
> > do it on the wiki pages themselves (I'll wikify Ross's
> > proposal tonight). Not editing the wikis but simply
> > collecting this feedback as the last section in each
> > proposal. The idea would be to identify all such
> > points in a week or so.
> >
> > Sounds good?
>
> To follow up. Each of the proposals:
> https://wiki.apache.org/incubator/MentorRebootProposal
"An active mentor is removed from a podling if that mentor does not
review/sign off on a release."
The above implies the foundation has a pool of mentors able to
consistently meet every reporting requirement in a timely manner, without
regard to personal or professional obstacles. I don't see it. For an
organization almost entirely made up of volunteers this seems overly
optimistic. There is only a small core membership who are capable and
willing to do this as evidenced by a skim of history of general@incubator
and members@. Perhaps this core group will end up shouldering the
incubation load in its entirety. Although sadly this is more or less the
current state of affairs, individual podlings do come with new mentors not
part of the "professional membership" motivated to see at least that
specific podling through. It's also risky to expect mentors kicked from a
podling to be okay with it and want to try again, especially if listed on
some "naughty list" to the board.
>
> https://wiki.apache.org/incubator/Strawman
"Only ASF members on the PPMC will have binding votes for the releases."
This proposal seems better than the others in my estimation, but doesn't
allow podlings full investment in their own release management. The members
on the PPMC who have binding votes will drive the release process out of
necessity. Once the podling graduates and the members on the PPMC leave to
resume other interests or duties, only then for the first time is the
project running their own releases. I think it was better to let the
podling own their release process but have the IPMC (or equivalent) have an
up-or-down vote afterward as a check on their activities.
>
> https://wiki.apache.org/incubator/IncubatorV2
>
This proposal revokes merit earned by existing IPMC members and reboots
incubator supervision as a "sub-board" limited to 15 members. How members
apply to this board is not specified. It is suggested the current board
make recommendations to the board for their replacements, a very
unmeritocratic suggestion that is quite surprising. It's not clear at all
how the membership can address issues with this "sub-board" as they can
with the Board. I think this proposal takes the likely outcome of the first
proposal, that only a small core group of "professional membership" can
manage sufficient activity as mentors to not be kicked from podlings, and
codifies it with new structure and bylaws. Maybe in the end this is
admitting reality. However, discussion of this proposal also floated the
idea that the "sub-board" be later given authority to supervise the affairs
of established TLPs, which is deeply problematic* and I suspect still
hovers in the wings. I would hope not.
"All proposals for new ASF projects must include an initial PMC chair and
an initial set of PMC members. These people must be acceptable to the
board. It is the responsibility of the Incubator Committee to vett these
people. All of them must have experience on existing PMCs"
This doubles down on the aspect of the Strawman proposal where PPMC members
are powerless to vote on releases. Here they are powerless to make any and
all project management decisions about their own software they brought to
Apache. It's not mentoring if you make all of the decisions for them.
* - Find me any PMC of any TLP that would welcome the self-introduction
of newly empowered meddlers who by definition are uninformed of their
project particulars.
> now has the feedback gathering section at the end.
> I am done with my personal feedback. Please provide
> yours.
>
> Here's the criteria you can apply when deciding whether
> to spend time on this or not: imagine that the proposal
> the way it is written were to come to a vote. If at that point
> you'd be inclined to vote -1 -- please let us know NOW.
>
> Using a VOTE thread as a forcing function for folks to
> provide feedback would be *really* unfortunate.
>
> Also, please try to keep 'deal breakers' section as small
> as possible (pushing all the non-critical piece of your
> feedback to the 'suggestions' section). When in doubt
> (even if it is -0) -- make it go to suggestions.
>
> The only items that belong to 'dealbreakers' are the ones
> that would *strongly* motivate you to vote -1
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
RE: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by "Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>.
No harm done Marvin :-)
Microsoft Open Technologies, Inc.
A subsidiary of Microsoft Corporation
-----Original Message-----
From: Marvin Humphrey [mailto:marvin@rectangular.com]
Sent: Thursday, January 22, 2015 11:13 AM
To: general@incubator.apache.org
Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
On Thu, Jan 22, 2015 at 10:47 AM, Ross Gardler (MS OPEN TECH) <Ro...@microsoft.com> wrote:
> In the thread "Incubator report sign-off" I posted a mail at Mon 1/5/2015 4:34 PM, it has the following content (edited for brevity here)"
Acknowledged. I apologize for mischaracterizing the effort that Board members such as yourself put in. It was surely not my intent to diminish your efforts, I simply believed the workflow to be more reactive than proactive.
None of this changes any of my commentary on the state of Incubator shepherds, and I hope that the offense given was not so great that it stops conversation cold.
Marvin Humphrey
---------------------------------------------------------------------
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: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Thu, Jan 22, 2015 at 10:47 AM, Ross Gardler (MS OPEN TECH)
<Ro...@microsoft.com> wrote:
> In the thread "Incubator report sign-off" I posted a mail at Mon 1/5/2015 4:34 PM, it has the following content (edited for brevity here)"
Acknowledged. I apologize for mischaracterizing the effort that Board
members such as yourself put in. It was surely not my intent to
diminish your efforts, I simply believed the workflow to be more
reactive than proactive.
None of this changes any of my commentary on the state of Incubator
shepherds, and I hope that the offense given was not so great that it
stops conversation cold.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by "Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>.
In the thread "Incubator report sign-off" I posted a mail at Mon 1/5/2015 4:34 PM, it has the following content (edited for brevity here)"
"Let's think about the work a Director should do when reviewing a report. It’s not reading the report and then ticking a box. It's reading a report, comparing it to previous reports. Taking a quick look at the tone of emails on the dev list. Looking at commit activity. Checking the private list is not too active and more. We have some great tools (thanks Sam) for helping with this process, but it's still time consuming. We also have the concept of Shepherds. Those shepherds are expected to fully review a projects report and status. They will typically spend 10 minutes more than other directors and will be able to answer any questions that come up in the meeting from other directors.
To really review a project properly takes a good 10 mins for non-shepherds and 20-30 minutes for shepherds (at least that is how long *I* spend on each report, I think most, if not all, directors would say the same). This is the case if there is no difficulties. If there are difficulties you can be talking about hours.
As an example of how long it takes to decide whether or not action is taken let me give you two concrete examples. Last night I spent just over four hours reviewing the archives of a TLP to see if a potential problem was actually a problem. I've spent maybe another 2 hours in email threads on the topic. For another project a different director has spent what I would estimate to be at least three hours reviewing and addressing an issue while I've spent maybe an hour tracking those threads to see if I need to help out. That's just in the last week, just the items I'm aware of and it doesn't address other things the directors do on a weekly basis."
Microsoft Open Technologies, Inc.
A subsidiary of Microsoft Corporation
-----Original Message-----
From: Marvin Humphrey [mailto:marvin@rectangular.com]
Sent: Thursday, January 22, 2015 10:39 AM
To: general@incubator.apache.org
Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
On Thu, Jan 22, 2015 at 7:18 AM, Ross Gardler (MS OPEN TECH) <Ro...@microsoft.com> wrote:
> The board do take on such an active task.
As someone who has been subscribed to board@apache for a long time and has attended many monthly Board meetings, this catches me off guard. I will follow Board report commentary with a different eye in the future...
Whatever our expectations are for the Incubator's shepherds, the institution is slowing dying. Past contributors have fallen away and recruitment drives have not yielded sufficient replacements.
And so what? Simply by maintaining "monthly" tags in podlings.xml when podlings don't report or no Mentors sign off, the Report Manager can handle the essential task that the shepherds can no longer be counted on for:
ensuring that we don't lose track of wayward podlings.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Thu, Jan 22, 2015 at 7:18 AM, Ross Gardler (MS OPEN TECH)
<Ro...@microsoft.com> wrote:
> The board do take on such an active task.
As someone who has been subscribed to board@apache for a long time and has
attended many monthly Board meetings, this catches me off guard. I will
follow Board report commentary with a different eye in the future...
Whatever our expectations are for the Incubator's shepherds, the institution
is slowing dying. Past contributors have fallen away and recruitment drives
have not yielded sufficient replacements.
And so what? Simply by maintaining "monthly" tags in podlings.xml when
podlings don't report or no Mentors sign off, the Report Manager can handle
the essential task that the shepherds can no longer be counted on for:
ensuring that we don't lose track of wayward podlings.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by "Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>.
To confirm I was referring to TLPs, personally I don't spend anywhere near as much time on podling reports, as Bertrand indicates that's delegated today.
Sent from my Windows Phone
________________________________
From: Bertrand Delacretaz<ma...@apache.org>
Sent: 1/23/2015 1:22 AM
To: Incubator General<ma...@incubator.apache.org>
Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
On Thu, Jan 22, 2015 at 4:18 PM, Ross Gardler (MS OPEN TECH)
<Ro...@microsoft.com> wrote:
> The board do take on such an active task....
I'm not sure what you mean exactly - IMO board members do pay close
attention to TLP reports (in more or less detail depending on our
perception of the project's health), but we might not look at each
podling report in as much detail.
The board has delegated management of podlings to the Incubator PMC,
so IMO it's fine for board members to just look at the Incubator
summary report, and mostly skim through podling reports, maybe look
more closely at a few that stand out for some reason.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Jan 22, 2015 at 4:18 PM, Ross Gardler (MS OPEN TECH)
<Ro...@microsoft.com> wrote:
> The board do take on such an active task....
I'm not sure what you mean exactly - IMO board members do pay close
attention to TLP reports (in more or less detail depending on our
perception of the project's health), but we might not look at each
podling report in as much detail.
The board has delegated management of podlings to the Incubator PMC,
so IMO it's fine for board members to just look at the Incubator
summary report, and mostly skim through podling reports, maybe look
more closely at a few that stand out for some reason.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by "Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>.
The board do take on such an active task.
Sent from my Windows Phone
________________________________
From: Niclas Hedhman<ma...@hedhman.org>
Sent: 1/21/2015 11:08 PM
To: general@incubator.apache.org<ma...@incubator.apache.org>
Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Ted,
doesn't that then suggest that the Board should do such an active task as
well, since they "thus can spot common problems
easily"? But they don't, possibly due to it doesn't scale. Their man on the
field, the VP, is trusted to have a grip on the situation. Why doesn't IPMC
trust that the mentor(s) has a grip as its man on the field.
Isn't what you describe "another mentor" with a different engagement
level...
Cheers
Niclas
On Thu, Jan 22, 2015 at 11:17 AM, Ted Dunning <te...@gmail.com> wrote:
> On Wed, Jan 21, 2015 at 5:03 PM, Marvin Humphrey <ma...@rectangular.com>
> wrote:
>
> > > Statements like shepherds dilute mentor responsibility are false. A
> > shepherd
> > > provides a mechanism for the IPMC to review the Podling/Mentor
> > relationship.
> > > This is something the IPMC needs to do when voting to graduate a
> > podling. We
> > > should be ALL be doing shepherding work.
> >
> > I can see what Alan's getting at, though. Unless the podling is in
> > trouble,
> > the podling contributors ought to be writing the report. The people who
> > are
> > then best placed to give informed feedback on that report are the
> podling's
> > Mentors. But instead, the people who provide commentary on the state of
> > the
> > podling community tend to be the shepherds, whose understanding is
> > necessarily
> > more superficial. Doesn't that seem strange?
> >
>
> Actually, I don't see it as strange.
>
> More than once while I was actively mentoring a project, a shepherd dropped
> in and noticed something that neither the project nor I had been focussing
> on.
>
> The mentor (me) was very actively involved in helping the community but the
> shepherd distinctly added value.
>
> Shepherds see across many projects and thus can spot common problems
> easily. Mentors focus on a few problems and thus can spot longer-term
> problems. The difference works really well in my experience. At least I
> know that I was able to mentor better with the help.
>
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
RE: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by "Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>.
It doesn't need to be in the public report.
I agree the shepherd model doesn't work here but I still maintain that doesn't mean it can't work.
Accountability, responsibility and reward are what I believe are needed. I've made my suggestions as to how to provide all three
Sent from my Windows Phone
________________________________
From: Marvin Humphrey<ma...@rectangular.com>
Sent: 1/22/2015 11:08 PM
To: general@incubator.apache.org<ma...@incubator.apache.org>
Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
On Thu, Jan 22, 2015 at 4:14 AM, Ted Dunning <te...@gmail.com> wrote:
> If you would like to characterize shepherds as cross-cutting
> mentors-at-large, I wouldn't disagree.
It's costly to produce such cross-cutting commentary. Because the product
ends up in the public report, it's risky to be candid -- recall the
Drill shepherd review that raised objections: <http://s.apache.org/ed>.
Shepherds can diminish the risk either by spending more time gathering
information, raising the cost, or by being more circumspect, diminishing the
review's usefulness. Both choices are suboptimal.
In any case, the Incubator struggles to get consistent shepherd participation.
While the fact that Incubator shepherds are less accountable than Board
members might keep participation under 100% any given month, my guess is that
the main reason the number is under 50% and trending downward is cost/benefit
ratio -- shepherds are making a rational choice to occupy themselves with
tasks they perceive as less arduous and/or more rewarding.
Maybe the time will come to revisit this issue if shepherd participation
flatlines, though that's not a very satisfying outcome...
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Greg Stein <gs...@gmail.com>.
On Fri, Jan 23, 2015 at 9:49 PM, Marvin Humphrey <ma...@rectangular.com>
wrote:
> Hi Greg,
>
> On Fri, Jan 23, 2015 at 1:33 PM, Greg Stein <gs...@gmail.com> wrote:
>
> > There is nothing stopping the IPMC from designating certain Mentors as
> > shepherds for their podlings.
>
> Having volunteers step forward as dedicated shepherds for individual
> podlings would be helpful. On its own, though, it is not sufficient,
> because Incubator shepherds are not as reliable as Board members. What
> happens when the dedicated shepherd goes missing? Podlings will start
> falling through the cracks again.
>
Agreed. I was thinking on a month-to-month basis. "I'll shepherd ACME this
month". (in addition to more general shepherds of "gimme 3 podlings that
haven't been allocated already")
>
> An additional mechanism needs to be in place to ensure that no report goes
> unreviewed. For instance:
>
> 1. The Incubator doesn't file its report until each and every podling
> report has been reviewed by either a shepherd or a freelance IPMC
> member filling in.
>
Ah. I like the term "freelance" (better than my "general" above) ... note
that the IPMC must file a report. It can't wait forever. I think what
you're really looking for is fully-explained in your point below. (ie. not
sure how the above is different than below)
2. Podling reports which have not been reviewed by a shepherd are omitted
> from the aggregate report and the podling is required to report again
> next month.
>
yes, the above would work just fine. "Get the podling report reviewed, or
we strip it from the report to the Board."
Of course, the corollary is that the Board will get a bit cranky if it
keeps receiving empty Incubator reports :-P
> Starting this month, the Incubator has instituted something similar to the
> second option: podling reports where not a single Mentor has signed
> off get rejected and the podling is required to report again next
> month[1]. There was criticism that this mechanism punishes a podling for
> the sins of its Mentors, but the intended result was achieved: every
> podling report got signed off. (Besides, in many cases the podling is at
> fault for filing at the last minute and leaving too small a window for
> Mentor signoff.)
>
*nod* ... It means "get it in on time, and if your Mentors aren't helping,
then find new ones". Unfortunately, we *have* had a case or three in the
past where a podling has been unable to locate new Mentors. There isn't a
good solution for that, under any plan :-(
>
> With signoff required, Mentors assume the essential functionality of
> shepherds, and the value added by the titular "shepherds" is limited to
> cross-cutting feedback. I maintain that there are better ways to provide
> such feedback.
>
Fair enough.
>
> > That activity
> > wasn't happening in the past, so the shepherds were filling in.
>
> Shepherd participation has fallen too low to keep podlings from getting
> lost -- it's now below 50%. What has kept distressed podlings like
> NPanday from falling off the IPMC's radar screen, for the last year and a
> half, has been the Report Manager putting podlings who don't file reports
> into "monthly" reporting. It's not perfect, but it's *way* less work and
> more reliable than shepherds.
>
It's an imperfect system, given volunteers, varying time, and changing
interests. Maybe a call for new shepherds? Maybe a slight change in Mentors
and their signoff? and as you note: maybe another way to create
cross-cutting feedback outside of the Mentor/shepherd roles. (general@ is
already a good mechanism for much of that)
>
> Maybe the Incubator should strike that task from the Report Manager's
> runbook and start losing track of podlings again? Because I feel like we
> designed a better system and nobody noticed.
>
> Marvin Humphrey
>
> [1] This is related but not linked to the list of not-signing-off Mentors
> which the Board has chosen to remove from this month's report. I've
> remained silent about that up till now out of deference to those IPMC
> members who are working hard to address issues of Mentor
> accountability, but I support the Board's decision.
I believe the list of no-sign-off Mentors is very useful, and the Incubator
should have that data. With the right context, it makes sense and is
helpful. It can help identify where a Mentor is slipping and needs
encouragement, replacement, or more Mentors for a podling.
However, the Board minutes do not provide the context. "He was on vacation"
doesn't appear, so it is easy to misconstrue what that list means. And it
is a bit too fine-grained for the Board. Replacing that list with something
like "we had 30 active Mentors, and are reaching out to 4 that appear to
have moved on" would be something the Board would be interested in. That is
about the *health* of the mentoring program, rather than calling out names.
(in fact, we asked a PMC or two to remove individual names from reports
over the past couple months; longer discussion on why)
Cheers,
-g
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Marvin Humphrey <ma...@rectangular.com>.
Hi Greg,
On Fri, Jan 23, 2015 at 1:33 PM, Greg Stein <gs...@gmail.com> wrote:
> There is nothing stopping the IPMC from designating certain Mentors as
> shepherds for their podlings.
Having volunteers step forward as dedicated shepherds for individual
podlings would be helpful. On its own, though, it is not sufficient,
because Incubator shepherds are not as reliable as Board members. What
happens when the dedicated shepherd goes missing? Podlings will start
falling through the cracks again.
An additional mechanism needs to be in place to ensure that no report goes
unreviewed. For instance:
1. The Incubator doesn't file its report until each and every podling
report has been reviewed by either a shepherd or a freelance IPMC
member filling in.
2. Podling reports which have not been reviewed by a shepherd are omitted
from the aggregate report and the podling is required to report again
next month.
Starting this month, the Incubator has instituted something similar to the
second option: podling reports where not a single Mentor has signed
off get rejected and the podling is required to report again next
month[1]. There was criticism that this mechanism punishes a podling for
the sins of its Mentors, but the intended result was achieved: every
podling report got signed off. (Besides, in many cases the podling is at
fault for filing at the last minute and leaving too small a window for
Mentor signoff.)
With signoff required, Mentors assume the essential functionality of
shepherds, and the value added by the titular "shepherds" is limited to
cross-cutting feedback. I maintain that there are better ways to provide
such feedback.
> That activity
> wasn't happening in the past, so the shepherds were filling in.
Shepherd participation has fallen too low to keep podlings from getting
lost -- it's now below 50%. What has kept distressed podlings like
NPanday from falling off the IPMC's radar screen, for the last year and a
half, has been the Report Manager putting podlings who don't file reports
into "monthly" reporting. It's not perfect, but it's *way* less work and
more reliable than shepherds.
Maybe the Incubator should strike that task from the Report Manager's
runbook and start losing track of podlings again? Because I feel like we
designed a better system and nobody noticed.
Marvin Humphrey
[1] This is related but not linked to the list of not-signing-off Mentors
which the Board has chosen to remove from this month's report. I've
remained silent about that up till now out of deference to those IPMC
members who are working hard to address issues of Mentor
accountability, but I support the Board's decision.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Greg Stein <gs...@gmail.com>.
On Fri, Jan 23, 2015 at 12:57 PM, Marvin Humphrey <ma...@rectangular.com>
wrote:
>...
> Time is on the side of those who think shepherd institution should die. It
> would be better if it died quickly, vacating the report review mindspace
> and
> making way for Mentor commentary supplemented by reactive IPMC report
> feedback. Mentors on the ground *are* the Incubator's analogue to Board
> shepherds -- the extra layer is unnecessary and costs too much. It is
> harmful
> that shepherd reviews are "the way it's done".
>
I believe the Incubator shepherds exist to help the IPMC with its duties.
The shepherds delegate/divide the work needed of the IPMC to review the
podling reports, before passing its report up to the Board.
The IPMC is an active entity with responsibilities. It has a job to do, and
the shepherds provide a way to do that. Rather than waving a hand and
saying "the IPMC will review" (and nothing happening cuz everybody thinks
everybody else will do it) ... or requiring the VP to do it every month..
the shepherds provide a way for volunteers to assist with the process.
There is nothing stopping the IPMC from designating certain Mentors as
shepherds for their podlings. Look at the Board: since I am the VP of
Subversion, a shepherd is never assigned to that report. I'm the implied
shepherd. Anything that the Board needs to convey to the PMC, I'm
responsible for that legwork (just like we delegate working with PMCs to
shepherds).
So if a Mentor is active enough, then put your name on the list to be the
shepherd for your podling (and be an IPMC member, of course). That activity
wasn't happening in the past, so the shepherds were filling in. Especially
when a Mentor is temporarily away.
Cheers,
-g
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Fri, Jan 23, 2015 at 4:30 AM, Ted Dunning <te...@gmail.com> wrote:
> On Fri, Jan 23, 2015 at 2:07 AM, Marvin Humphrey <ma...@rectangular.com>
> wrote:
>> On Thu, Jan 22, 2015 at 4:14 AM, Ted Dunning <te...@gmail.com>
>> wrote:
> I really don't have a problem with a report like that going out as long as
> somebody can answer it. I answered it. Dave paid attention. The group
> gained more knowledge about which aspects of a release are important to
> Apache. It was a very good thing, all in all.
But did that communication have to be *in the report*? I guarantee that other
inaccurate shepherd reviews have slipped into the permanent record -- and
that useful feedback has been self-censored by shepherds because that's the
channel they are instructed to use.
Why not just reply to the draft report that gets sent to general@incubator
each month instead?
> My first reaction is that we need to make shepherding have higher rewards.
Higher rewards, eh? I imagine reviewers would value having their feedback
spawn give-and-take -- which would happen in email, but not so much via the
report wiki.
But really, the elephant in the room is cost. Why must proactive community
assessment be a prerequisite to cross-cutting feedback? If the Incubator
didn't insist on that, there would be more and richer critiques. There is
*plenty* of information in podling reports to initiate cross-community
conversations. A reactive workflow suffices.
>> Maybe the time will come to revisit this issue if shepherd participation
>> flatlines, though that's not a very satisfying outcome...
>
> Seems important enough to think about now.
Time is on the side of those who think shepherd institution should die. It
would be better if it died quickly, vacating the report review mindspace and
making way for Mentor commentary supplemented by reactive IPMC report
feedback. Mentors on the ground *are* the Incubator's analogue to Board
shepherds -- the extra layer is unnecessary and costs too much. It is harmful
that shepherd reviews are "the way it's done".
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Ted Dunning <te...@gmail.com>.
On Fri, Jan 23, 2015 at 2:07 AM, Marvin Humphrey <ma...@rectangular.com>
wrote:
> On Thu, Jan 22, 2015 at 4:14 AM, Ted Dunning <te...@gmail.com>
> wrote:
>
> > If you would like to characterize shepherds as cross-cutting
> > mentors-at-large, I wouldn't disagree.
>
> It's costly to produce such cross-cutting commentary. Because the product
> ends up in the public report, it's risky to be candid -- recall the
> Drill shepherd review that raised objections: <http://s.apache.org/ed>.
> Shepherds can diminish the risk either by spending more time gathering
> information, raising the cost, or by being more circumspect, diminishing
> the
> review's usefulness. Both choices are suboptimal.
>
Hmm... you link to my own response there. This shepherd report was
actually one of the things that I found really helpful in mentoring (and
contributing to) on the Drill incubation.
I really don't have a problem with a report like that going out as long as
somebody can answer it. I answered it. Dave paid attention. The group
gained more knowledge about which aspects of a release are important to
Apache. It was a very good thing, all in all.
> In any case, the Incubator struggles to get consistent shepherd
> participation.
> While the fact that Incubator shepherds are less accountable than Board
> members might keep participation under 100% any given month, my guess is
> that
> the main reason the number is under 50% and trending downward is
> cost/benefit
> ratio -- shepherds are making a rational choice to occupy themselves with
> tasks they perceive as less arduous and/or more rewarding.
>
My first reaction is that we need to make shepherding have higher rewards.
Maybe we make a rule that one isn't supposed to mention mentor status
publicly, but can put shepherd work on your resume. :-) / 2
>
> Maybe the time will come to revisit this issue if shepherd participation
> flatlines, though that's not a very satisfying outcome...
>
Seems important enough to think about now.
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Thu, Jan 22, 2015 at 4:14 AM, Ted Dunning <te...@gmail.com> wrote:
> If you would like to characterize shepherds as cross-cutting
> mentors-at-large, I wouldn't disagree.
It's costly to produce such cross-cutting commentary. Because the product
ends up in the public report, it's risky to be candid -- recall the
Drill shepherd review that raised objections: <http://s.apache.org/ed>.
Shepherds can diminish the risk either by spending more time gathering
information, raising the cost, or by being more circumspect, diminishing the
review's usefulness. Both choices are suboptimal.
In any case, the Incubator struggles to get consistent shepherd participation.
While the fact that Incubator shepherds are less accountable than Board
members might keep participation under 100% any given month, my guess is that
the main reason the number is under 50% and trending downward is cost/benefit
ratio -- shepherds are making a rational choice to occupy themselves with
tasks they perceive as less arduous and/or more rewarding.
Maybe the time will come to revisit this issue if shepherd participation
flatlines, though that's not a very satisfying outcome...
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Ted Dunning <te...@gmail.com>.
Niclas,
I merely speak about what I experienced. My experience is that shepherds
provided valuable help to me while I was acting as a mentor. This was (as
I understand it) part of the expectation for shepherds. The board has
never provided me specific help like this in mentoring. I don't think that
it was ever expected that they would.
If you would like to characterize shepherds as cross-cutting
mentors-at-large, I wouldn't disagree. I don't much care about names
unless they confuse people. I really did appreciate the help when I got it.
>From your tone, however, it sounds like you would like for me to disagree
with something you say. I can't figure out what it is that I should
disagree with.
On Thu, Jan 22, 2015 at 2:06 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> Ted,
> doesn't that then suggest that the Board should do such an active task as
> well, since they "thus can spot common problems
> easily"? But they don't, possibly due to it doesn't scale. Their man on the
> field, the VP, is trusted to have a grip on the situation. Why doesn't IPMC
> trust that the mentor(s) has a grip as its man on the field.
>
> Isn't what you describe "another mentor" with a different engagement
> level...
>
> Cheers
> Niclas
>
> On Thu, Jan 22, 2015 at 11:17 AM, Ted Dunning <te...@gmail.com>
> wrote:
>
> > On Wed, Jan 21, 2015 at 5:03 PM, Marvin Humphrey <marvin@rectangular.com
> >
> > wrote:
> >
> > > > Statements like shepherds dilute mentor responsibility are false. A
> > > shepherd
> > > > provides a mechanism for the IPMC to review the Podling/Mentor
> > > relationship.
> > > > This is something the IPMC needs to do when voting to graduate a
> > > podling. We
> > > > should be ALL be doing shepherding work.
> > >
> > > I can see what Alan's getting at, though. Unless the podling is in
> > > trouble,
> > > the podling contributors ought to be writing the report. The people
> who
> > > are
> > > then best placed to give informed feedback on that report are the
> > podling's
> > > Mentors. But instead, the people who provide commentary on the state
> of
> > > the
> > > podling community tend to be the shepherds, whose understanding is
> > > necessarily
> > > more superficial. Doesn't that seem strange?
> > >
> >
> > Actually, I don't see it as strange.
> >
> > More than once while I was actively mentoring a project, a shepherd
> dropped
> > in and noticed something that neither the project nor I had been
> focussing
> > on.
> >
> > The mentor (me) was very actively involved in helping the community but
> the
> > shepherd distinctly added value.
> >
> > Shepherds see across many projects and thus can spot common problems
> > easily. Mentors focus on a few problems and thus can spot longer-term
> > problems. The difference works really well in my experience. At least I
> > know that I was able to mentor better with the help.
> >
>
>
>
> --
> Niclas Hedhman, Software Developer
> http://www.qi4j.org - New Energy for Java
>
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Niclas Hedhman <ni...@hedhman.org>.
Ted,
doesn't that then suggest that the Board should do such an active task as
well, since they "thus can spot common problems
easily"? But they don't, possibly due to it doesn't scale. Their man on the
field, the VP, is trusted to have a grip on the situation. Why doesn't IPMC
trust that the mentor(s) has a grip as its man on the field.
Isn't what you describe "another mentor" with a different engagement
level...
Cheers
Niclas
On Thu, Jan 22, 2015 at 11:17 AM, Ted Dunning <te...@gmail.com> wrote:
> On Wed, Jan 21, 2015 at 5:03 PM, Marvin Humphrey <ma...@rectangular.com>
> wrote:
>
> > > Statements like shepherds dilute mentor responsibility are false. A
> > shepherd
> > > provides a mechanism for the IPMC to review the Podling/Mentor
> > relationship.
> > > This is something the IPMC needs to do when voting to graduate a
> > podling. We
> > > should be ALL be doing shepherding work.
> >
> > I can see what Alan's getting at, though. Unless the podling is in
> > trouble,
> > the podling contributors ought to be writing the report. The people who
> > are
> > then best placed to give informed feedback on that report are the
> podling's
> > Mentors. But instead, the people who provide commentary on the state of
> > the
> > podling community tend to be the shepherds, whose understanding is
> > necessarily
> > more superficial. Doesn't that seem strange?
> >
>
> Actually, I don't see it as strange.
>
> More than once while I was actively mentoring a project, a shepherd dropped
> in and noticed something that neither the project nor I had been focussing
> on.
>
> The mentor (me) was very actively involved in helping the community but the
> shepherd distinctly added value.
>
> Shepherds see across many projects and thus can spot common problems
> easily. Mentors focus on a few problems and thus can spot longer-term
> problems. The difference works really well in my experience. At least I
> know that I was able to mentor better with the help.
>
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Ted Dunning <te...@gmail.com>.
On Wed, Jan 21, 2015 at 5:03 PM, Marvin Humphrey <ma...@rectangular.com>
wrote:
> > Statements like shepherds dilute mentor responsibility are false. A
> shepherd
> > provides a mechanism for the IPMC to review the Podling/Mentor
> relationship.
> > This is something the IPMC needs to do when voting to graduate a
> podling. We
> > should be ALL be doing shepherding work.
>
> I can see what Alan's getting at, though. Unless the podling is in
> trouble,
> the podling contributors ought to be writing the report. The people who
> are
> then best placed to give informed feedback on that report are the podling's
> Mentors. But instead, the people who provide commentary on the state of
> the
> podling community tend to be the shepherds, whose understanding is
> necessarily
> more superficial. Doesn't that seem strange?
>
Actually, I don't see it as strange.
More than once while I was actively mentoring a project, a shepherd dropped
in and noticed something that neither the project nor I had been focussing
on.
The mentor (me) was very actively involved in helping the community but the
shepherd distinctly added value.
Shepherds see across many projects and thus can spot common problems
easily. Mentors focus on a few problems and thus can spot longer-term
problems. The difference works really well in my experience. At least I
know that I was able to mentor better with the help.
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Dave Fisher <da...@comcast.net>.
On Jan 21, 2015, at 2:03 PM, Marvin Humphrey wrote:
> On Mon, Jan 19, 2015 at 2:43 PM, Dave Fisher <da...@comcast.net> wrote:
>> Perhaps there are one or two good ideas in the proposals, but change does
>> not need to be as jarring.
>
> I hope that the Incubator can make the best of those opportunities.
>
>> For example the IPMC ought to confirm with
>> mentors if they are still being a mentor to a particular podling. There can
>> be many reasons why not and we just need to ask. It could be that the
>> podling never achieved a visible development community.
>
> It's possible to automate pinging Mentors who didn't sign off on podling
> reports. A Python script could parse the last Incubator report (plus others
> going back N months if we want richer historical info), then send one email
> per podling to the podling's private list, CC'd to private@incubator. The
> script could be run by the Report Manager or the Chair each month after the
> report is filed.
>
>> Statements like shepherds dilute mentor responsibility are false. A shepherd
>> provides a mechanism for the IPMC to review the Podling/Mentor relationship.
>> This is something the IPMC needs to do when voting to graduate a podling. We
>> should be ALL be doing shepherding work.
>
> I can see what Alan's getting at, though. Unless the podling is in trouble,
> the podling contributors ought to be writing the report. The people who are
> then best placed to give informed feedback on that report are the podling's
> Mentors. But instead, the people who provide commentary on the state of the
> podling community tend to be the shepherds, whose understanding is necessarily
> more superficial. Doesn't that seem strange?
Yes and that may be a call for more informed *action* by the IPMC. Like connecting with the mentors and podling to find out where the community is if anywhere. There may be no there there.
Regards,
Dave
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> 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: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by "Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>.
That is not what *I* do as a shepherd.
Sent from my Windows Phone
________________________________
From: Marvin Humphrey<ma...@rectangular.com>
Sent: 1/21/2015 7:10 PM
To: general@incubator.apache.org<ma...@incubator.apache.org>
Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
On Wed, Jan 21, 2015 at 3:58 PM, Ross Gardler (MS OPEN TECH)
<Ro...@microsoft.com> wrote:
> We should not be focusing on who is/is not ticking a box on a report - it's
> a red herring and therefore a distraction.
>
> We should be focusing on identifying and assisting podlings that are not in
> receipt of adequate and appropriate mentoring.
Well, the idea is to identify such podlings with as little effort and fanfare
as possible.
* If a Mentor signs off on a report, trust that they are engaged.
* If they don't check the box (for any number of reasons), ping them
_privately_ to ask politely whether they're still engaged.
I figure that's both more reliable and less intrusive than shepherding.
But let's consider "retiring the shepherd role" and "automated private
followup after missing signoff" as separate initiatives...
The first person to do shepherding was Jukka. He couldn't handle the load by
himself, so he asked for volunteers[1].
The thing is, the IPMC doesn't seem to have the volunteer capacity to provide
senior-level shepherd reviews for all podlings each month, of the kind that a
Jukka or a Dave Fisher might write up. And it has always bothered me to have
outsiders judging podling communities in the context of a Board report, even
when they're experienced.
What the Board shepherds do is fundamentally different from what the Incubator
shepherds do: Board shepherds trust the report content and follow up after
problems, while Incubator shepherds are expected to dive into the mailing list
archives and assess community health proactively. To do that right is
labor-intensive and basically duplicates work already done by the podling's
Mentors. And what are the benefits?
* Because shepherd participation is below 50%, we can't count on them
to flag problem podlings consistently.
* Providing periodic outsider perspectives might be a good thing, but in the
context of a Board report, the stakes are too high.
* The shepherd gets their mind broadened. This is great, but there are
other ways to achieve that.
Fortunately, the Incubator has developed better mechanisms identify and track
problem podlings. Shepherds were essential while the Incubator was cleaning
house in 2012, but that's no longer the case.
Therefore, I support Alan's suggestion to simplify the Incubator by
streamlining away the shepherd role. The "Shepherd/Mentor notes" section of
the report can be changed to "Mentor/IPMC notes".
Marvin Humphrey
[1] http://markmail.org/message/y3pnb6degtnynmc2
http://s.apache.org/v7g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Wed, Jan 21, 2015 at 3:58 PM, Ross Gardler (MS OPEN TECH)
<Ro...@microsoft.com> wrote:
> We should not be focusing on who is/is not ticking a box on a report - it's
> a red herring and therefore a distraction.
>
> We should be focusing on identifying and assisting podlings that are not in
> receipt of adequate and appropriate mentoring.
Well, the idea is to identify such podlings with as little effort and fanfare
as possible.
* If a Mentor signs off on a report, trust that they are engaged.
* If they don't check the box (for any number of reasons), ping them
_privately_ to ask politely whether they're still engaged.
I figure that's both more reliable and less intrusive than shepherding.
But let's consider "retiring the shepherd role" and "automated private
followup after missing signoff" as separate initiatives...
The first person to do shepherding was Jukka. He couldn't handle the load by
himself, so he asked for volunteers[1].
The thing is, the IPMC doesn't seem to have the volunteer capacity to provide
senior-level shepherd reviews for all podlings each month, of the kind that a
Jukka or a Dave Fisher might write up. And it has always bothered me to have
outsiders judging podling communities in the context of a Board report, even
when they're experienced.
What the Board shepherds do is fundamentally different from what the Incubator
shepherds do: Board shepherds trust the report content and follow up after
problems, while Incubator shepherds are expected to dive into the mailing list
archives and assess community health proactively. To do that right is
labor-intensive and basically duplicates work already done by the podling's
Mentors. And what are the benefits?
* Because shepherd participation is below 50%, we can't count on them
to flag problem podlings consistently.
* Providing periodic outsider perspectives might be a good thing, but in the
context of a Board report, the stakes are too high.
* The shepherd gets their mind broadened. This is great, but there are
other ways to achieve that.
Fortunately, the Incubator has developed better mechanisms identify and track
problem podlings. Shepherds were essential while the Incubator was cleaning
house in 2012, but that's no longer the case.
Therefore, I support Alan's suggestion to simplify the Incubator by
streamlining away the shepherd role. The "Shepherd/Mentor notes" section of
the report can be changed to "Mentor/IPMC notes".
Marvin Humphrey
[1] http://markmail.org/message/y3pnb6degtnynmc2
http://s.apache.org/v7g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by "Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>.
We should not be focusing on who is/is not ticking a box on a report - it's a red herring and therefore a distraction.
We should be focusing on identifying and assisting podlings that are not in receipt of adequate and appropriate mentoring.
There is nothing else of importance.
Microsoft Open Technologies, Inc.
A subsidiary of Microsoft Corporation
-----Original Message-----
From: Marvin Humphrey [mailto:marvin@rectangular.com]
Sent: Wednesday, January 21, 2015 2:04 PM
To: general@incubator.apache.org
Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
On Mon, Jan 19, 2015 at 2:43 PM, Dave Fisher <da...@comcast.net> wrote:
> Perhaps there are one or two good ideas in the proposals, but change
> does not need to be as jarring.
I hope that the Incubator can make the best of those opportunities.
> For example the IPMC ought to confirm with mentors if they are still
> being a mentor to a particular podling. There can be many reasons why
> not and we just need to ask. It could be that the podling never
> achieved a visible development community.
It's possible to automate pinging Mentors who didn't sign off on podling reports. A Python script could parse the last Incubator report (plus others going back N months if we want richer historical info), then send one email per podling to the podling's private list, CC'd to private@incubator. The script could be run by the Report Manager or the Chair each month after the report is filed.
> Statements like shepherds dilute mentor responsibility are false. A
> shepherd provides a mechanism for the IPMC to review the Podling/Mentor relationship.
> This is something the IPMC needs to do when voting to graduate a
> podling. We should be ALL be doing shepherding work.
I can see what Alan's getting at, though. Unless the podling is in trouble, the podling contributors ought to be writing the report. The people who are then best placed to give informed feedback on that report are the podling's Mentors. But instead, the people who provide commentary on the state of the podling community tend to be the shepherds, whose understanding is necessarily more superficial. Doesn't that seem strange?
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Jan 19, 2015 at 2:43 PM, Dave Fisher <da...@comcast.net> wrote:
> Perhaps there are one or two good ideas in the proposals, but change does
> not need to be as jarring.
I hope that the Incubator can make the best of those opportunities.
> For example the IPMC ought to confirm with
> mentors if they are still being a mentor to a particular podling. There can
> be many reasons why not and we just need to ask. It could be that the
> podling never achieved a visible development community.
It's possible to automate pinging Mentors who didn't sign off on podling
reports. A Python script could parse the last Incubator report (plus others
going back N months if we want richer historical info), then send one email
per podling to the podling's private list, CC'd to private@incubator. The
script could be run by the Report Manager or the Chair each month after the
report is filed.
> Statements like shepherds dilute mentor responsibility are false. A shepherd
> provides a mechanism for the IPMC to review the Podling/Mentor relationship.
> This is something the IPMC needs to do when voting to graduate a podling. We
> should be ALL be doing shepherding work.
I can see what Alan's getting at, though. Unless the podling is in trouble,
the podling contributors ought to be writing the report. The people who are
then best placed to give informed feedback on that report are the podling's
Mentors. But instead, the people who provide commentary on the state of the
podling community tend to be the shepherds, whose understanding is necessarily
more superficial. Doesn't that seem strange?
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Jan 19, 2015 at 11:43 PM, Dave Fisher <da...@comcast.net> wrote:
> ...We should stop being abstract with blanket statements and we
> should be looking at specifics...
That was the idea behind https://wiki.apache.org/incubator/IncubatorIssues2013
(I don't think that's immutable BTW, I suppose whoever saw that wasn't
logged in to the wiki)
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Dave Fisher <da...@comcast.net>.
On Jan 19, 2015, at 1:47 PM, Roman Shaposhnik wrote:
> On Wed, Jan 14, 2015 at 8:48 AM, Roman Shaposhnik <rv...@apache.org> wrote:
>> Hi!
>>
>> at this point we have had a few lively threads
>> discussing three somewhat different proposals:
>> #1 mentor re-boot
>> #2 pTLP
>> #3 Ross's strawman http://s.apache.org/8eS
>> it feels to me that all three need additional work
>> to be done before we can have any reasonable
>> consensus around them (let alone voting).
>>
>> Wearing my chair hat, I would like to suggest that
>> the next step should be: for each proposal we identify
>> points that are going to block consensus (AKA would
>> result in -1 vote if it comes to a vote). I suggest we
>> do it on the wiki pages themselves (I'll wikify Ross's
>> proposal tonight). Not editing the wikis but simply
>> collecting this feedback as the last section in each
>> proposal. The idea would be to identify all such
>> points in a week or so.
>>
>> Sounds good?
>
> To follow up. Each of the proposals:
> https://wiki.apache.org/incubator/MentorRebootProposal
> https://wiki.apache.org/incubator/Strawman
> https://wiki.apache.org/incubator/IncubatorV2
>
> now has the feedback gathering section at the end.
> I am done with my personal feedback. Please provide
> yours.
>
> Here's the criteria you can apply when deciding whether
> to spend time on this or not: imagine that the proposal
> the way it is written were to come to a vote. If at that point
> you'd be inclined to vote -1 -- please let us know NOW.
>
> Using a VOTE thread as a forcing function for folks to
> provide feedback would be *really* unfortunate.
>
> Also, please try to keep 'deal breakers' section as small
> as possible (pushing all the non-critical piece of your
> feedback to the 'suggestions' section). When in doubt
> (even if it is -0) -- make it go to suggestions.
>
> The only items that belong to 'dealbreakers' are the ones
> that would *strongly* motivate you to vote -1
I am -1 on all of these and that is unlikely to change. I just don't think that the Incubator is as broken as all the reformers think. I think that the Incubator works for most podlings. I think that these proposals do more harm than good.
This feeling is visceral and I really don't care to articulate it more or to continually debate.
Perhaps there are one or two good ideas in the proposals, but change does not need to be as jarring. For example the IPMC ought to confirm with mentors if they are still being a mentor to a particular podling. There can be many reasons why not and we just need to ask. It could be that the podling never achieved a visible development community.
We should stop being abstract with blanket statements and we should be looking at specifics. When the IPMC looks directly things happen - sometimes the podling is brought to life, sometimes retired and sometime on life support.
Statements like shepherds dilute mentor responsibility are false. A shepherd provides a mechanism for the IPMC to review the Podling/Mentor relationship. This is something the IPMC needs to do when voting to graduate a podling. We should be ALL be doing shepherding work.
Rather than spend the effort on this - review some of the troublesome podlings.
Regards,
Dave
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> 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: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by Roman Shaposhnik <rv...@apache.org>.
On Wed, Jan 14, 2015 at 8:48 AM, Roman Shaposhnik <rv...@apache.org> wrote:
> Hi!
>
> at this point we have had a few lively threads
> discussing three somewhat different proposals:
> #1 mentor re-boot
> #2 pTLP
> #3 Ross's strawman http://s.apache.org/8eS
> it feels to me that all three need additional work
> to be done before we can have any reasonable
> consensus around them (let alone voting).
>
> Wearing my chair hat, I would like to suggest that
> the next step should be: for each proposal we identify
> points that are going to block consensus (AKA would
> result in -1 vote if it comes to a vote). I suggest we
> do it on the wiki pages themselves (I'll wikify Ross's
> proposal tonight). Not editing the wikis but simply
> collecting this feedback as the last section in each
> proposal. The idea would be to identify all such
> points in a week or so.
>
> Sounds good?
To follow up. Each of the proposals:
https://wiki.apache.org/incubator/MentorRebootProposal
https://wiki.apache.org/incubator/Strawman
https://wiki.apache.org/incubator/IncubatorV2
now has the feedback gathering section at the end.
I am done with my personal feedback. Please provide
yours.
Here's the criteria you can apply when deciding whether
to spend time on this or not: imagine that the proposal
the way it is written were to come to a vote. If at that point
you'd be inclined to vote -1 -- please let us know NOW.
Using a VOTE thread as a forcing function for folks to
provide feedback would be *really* unfortunate.
Also, please try to keep 'deal breakers' section as small
as possible (pushing all the non-critical piece of your
feedback to the 'suggestions' section). When in doubt
(even if it is -0) -- make it go to suggestions.
The only items that belong to 'dealbreakers' are the ones
that would *strongly* motivate you to vote -1
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by "Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>.
Please go ahead - apologies for not doing it myself I have access problems on the incubator wiki.
Microsoft Open Technologies, Inc.
A subsidiary of Microsoft Corporation
-----Original Message-----
From: John D. Ament [mailto:johndament@apache.org]
Sent: Wednesday, January 14, 2015 9:22 AM
To: general@incubator.apache.org
Subject: Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Anyone mind then if i put strawman up on the wiki?
On Wed Jan 14 2015 at 12:11:42 PM Alan D. Cabrera <li...@toolazydogs.com>
wrote:
>
> > On Jan 14, 2015, at 8:48 AM, Roman Shaposhnik <rv...@apache.org> wrote:
> >
> > Hi!
> >
> > at this point we have had a few lively threads discussing three
> > somewhat different proposals:
> > #1 mentor re-boot
>
> https://wiki.apache.org/incubator/MentorRebootProposal <
> https://wiki.apache.org/incubator/MentorRebootProposal>
>
> > #2 pTLP
>
> http://wiki.apache.org/incubator/IncubatorV2 <http://wiki.apache.org/
> incubator/IncubatorV2>
>
> > #3 Ross's strawman http://s.apache.org/8eS it feels to me that all
> > three need additional work to be done before we can have any
> > reasonable consensus around them (let alone voting).
> >
> > Wearing my chair hat, I would like to suggest that the next step
> > should be: for each proposal we identify points that are going to
> > block consensus (AKA would result in -1 vote if it comes to a vote).
> > I suggest we do it on the wiki pages themselves (I'll wikify Ross's
> > proposal tonight). Not editing the wikis but simply collecting this
> > feedback as the last section in each proposal. The idea would be to
> > identify all such points in a week or so.
> >
> > Sounds good?
>
> Thanks for picking this up.
>
> Does it make sense to make a matrix to compare them? I’m happy to
> take a crack at it. Could you field offline questions about #2 for me?
>
>
> Regards,
> Alan
>
>
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by "John D. Ament" <jo...@apache.org>.
Anyone mind then if i put strawman up on the wiki?
On Wed Jan 14 2015 at 12:11:42 PM Alan D. Cabrera <li...@toolazydogs.com>
wrote:
>
> > On Jan 14, 2015, at 8:48 AM, Roman Shaposhnik <rv...@apache.org> wrote:
> >
> > Hi!
> >
> > at this point we have had a few lively threads
> > discussing three somewhat different proposals:
> > #1 mentor re-boot
>
> https://wiki.apache.org/incubator/MentorRebootProposal <
> https://wiki.apache.org/incubator/MentorRebootProposal>
>
> > #2 pTLP
>
> http://wiki.apache.org/incubator/IncubatorV2 <http://wiki.apache.org/
> incubator/IncubatorV2>
>
> > #3 Ross's strawman http://s.apache.org/8eS
> > it feels to me that all three need additional work
> > to be done before we can have any reasonable
> > consensus around them (let alone voting).
> >
> > Wearing my chair hat, I would like to suggest that
> > the next step should be: for each proposal we identify
> > points that are going to block consensus (AKA would
> > result in -1 vote if it comes to a vote). I suggest we
> > do it on the wiki pages themselves (I'll wikify Ross's
> > proposal tonight). Not editing the wikis but simply
> > collecting this feedback as the last section in each
> > proposal. The idea would be to identify all such
> > points in a week or so.
> >
> > Sounds good?
>
> Thanks for picking this up.
>
> Does it make sense to make a matrix to compare them? I’m happy to take a
> crack at it. Could you field offline questions about #2 for me?
>
>
> Regards,
> Alan
>
>
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
> On Jan 14, 2015, at 8:48 AM, Roman Shaposhnik <rv...@apache.org> wrote:
>
> Hi!
>
> at this point we have had a few lively threads
> discussing three somewhat different proposals:
> #1 mentor re-boot
https://wiki.apache.org/incubator/MentorRebootProposal <https://wiki.apache.org/incubator/MentorRebootProposal>
> #2 pTLP
http://wiki.apache.org/incubator/IncubatorV2 <http://wiki.apache.org/incubator/IncubatorV2>
> #3 Ross's strawman http://s.apache.org/8eS
> it feels to me that all three need additional work
> to be done before we can have any reasonable
> consensus around them (let alone voting).
>
> Wearing my chair hat, I would like to suggest that
> the next step should be: for each proposal we identify
> points that are going to block consensus (AKA would
> result in -1 vote if it comes to a vote). I suggest we
> do it on the wiki pages themselves (I'll wikify Ross's
> proposal tonight). Not editing the wikis but simply
> collecting this feedback as the last section in each
> proposal. The idea would be to identify all such
> points in a week or so.
>
> Sounds good?
Thanks for picking this up.
Does it make sense to make a matrix to compare them? I’m happy to take a crack at it. Could you field offline questions about #2 for me?
Regards,
Alan
Re: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by "John D. Ament" <jo...@apache.org>.
Roman,
Are all three available on the wiki? Maybe link to them just in case I
missed one..
John
On Wed Jan 14 2015 at 11:48:41 AM Roman Shaposhnik <rv...@apache.org> wrote:
> Hi!
>
> at this point we have had a few lively threads
> discussing three somewhat different proposals:
> #1 mentor re-boot
> #2 pTLP
> #3 Ross's strawman http://s.apache.org/8eS
> it feels to me that all three need additional work
> to be done before we can have any reasonable
> consensus around them (let alone voting).
>
> Wearing my chair hat, I would like to suggest that
> the next step should be: for each proposal we identify
> points that are going to block consensus (AKA would
> result in -1 vote if it comes to a vote). I suggest we
> do it on the wiki pages themselves (I'll wikify Ross's
> proposal tonight). Not editing the wikis but simply
> collecting this feedback as the last section in each
> proposal. The idea would be to identify all such
> points in a week or so.
>
> Sounds good?
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
RE: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Posted by "Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>.
Thank you for volunteering to wikify my proposal - I appreciate it.
Ross
Microsoft Open Technologies, Inc.
A subsidiary of Microsoft Corporation
-----Original Message-----
From: shaposhnik@gmail.com [mailto:shaposhnik@gmail.com] On Behalf Of Roman Shaposhnik
Sent: Wednesday, January 14, 2015 8:48 AM
To: general@incubator.apache.org
Subject: Next steps for various proposals (mentor re-boot, pTLP, etc.)
Hi!
at this point we have had a few lively threads discussing three somewhat different proposals:
#1 mentor re-boot
#2 pTLP
#3 Ross's strawman http://s.apache.org/8eS it feels to me that all three need additional work to be done before we can have any reasonable consensus around them (let alone voting).
Wearing my chair hat, I would like to suggest that the next step should be: for each proposal we identify points that are going to block consensus (AKA would result in -1 vote if it comes to a vote). I suggest we do it on the wiki pages themselves (I'll wikify Ross's proposal tonight). Not editing the wikis but simply collecting this feedback as the last section in each proposal. The idea would be to identify all such points in a week or so.
Sounds good?
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org