[DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates

[Myrle Krantz <my...@apache.org>]

Motivation:

Some podlings want or need feedback on their releases before they are ready
to make official Apache releases.  They want to discuss releases that are
not yet ready for a VOTE, or that they are not sure they are ready for a
vote.  They may wish to make an early release outside of the foundation,
but still test the ASF waters.  They prefer to "fail early, fail often and
fail forward". [1]


Proposal:

Podlings should be able to request feedback by starting a "[DISCUSS]"
thread instead of a "[VOTE]" thread.  Discussion should give podlings
feedback on what they would need to do to bring their release in line with
the requirements for graduation to TLP.  Podlings will be responsible for
capturing feedback that they accept in work items for their project.
Feedback provided in a discussion thread will not block a non-ASF release.

Asking for feedback using this mechanism is not obligatory, but rather a
service that the incubator offers.


Arguments for this proposal:

* It's a very small change which may make it easier to implement than some
of the "throw it all away and start over" proposals circulating, but...
* It doesn't prevent us from making other larger changes.
* It's not a rule.  It's an offering of an additional service + an
incremental reduction in stringency of the incubator.
* It captures some of the value in what we are doing now while increasing
the degrees of freedom provided to podlings.
* It is consistent with our values of transparency, collaboration,
community, pragmatism, meritocracy, and charity.

Best Regards,
Myrle

1.)
https://www.goodreads.com/work/quotes/614412-failing-forward-turning-mistakes-into-stepping-stones-for-success

Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates

[Marvin Humphrey <ma...@rectangular.com>]

+1

I think this proposal could help a lot with how feedback is perceived by
podlings!

On Mon, Feb 25, 2019 at 11:51 PM Myrle Krantz <my...@apache.org> wrote:

> Some podlings want or need feedback on their releases before they are ready
> to make official Apache releases.  They want to discuss releases that are
> not yet ready for a VOTE, or that they are not sure they are ready for a
> vote.

When such a review is actively requested by the podling, it sets up a dynamic
where the recipient can more easily accept and act on the feedback they
receive, without losing face.

Contrast that with the present, where feedback on releases most often arrives
at the time of a release VOTE, where it can be interpreted as punitive.
Naturally, we believe that this feedback is essential and a valuable
contribution to the podling.  So we should set ourselves up to increase the
likelihood that it will be perceived that way!

Now, it may be the case that a podling doesn't avail itself of the opportunity
to request a pre-release review.  But so long as they knew about that the
service was available, even though they might feel resentful they can only
complain so loudly.

I read elsethread that some podlings already pro-actively seek out review,
which speaks well of such podlings and their Mentors.  But I submit while that
these conscientious, well-informed podlings will also benefit from system
better designed to be constructive and positive, they are not the ones most
likely to become disgruntled or even end up in crisis.

The linchpin of this proposal is reliable outreach to those podlings who would
not seek out this service on their own.  If such a podling is not informed,
and then later runs into trouble, we will have missed an valuable opportunity.

Therefore, I'd suggest that an email to the dev list on this subject ought to
be on a mentoring checklist.

> Arguments for this proposal:
>
> * It's a very small change which may make it easier to implement than some
>   of the "throw it all away and start over" proposals circulating, but...
> * It doesn't prevent us from making other larger changes.

+1

> * It's not a rule.  It's an offering of an additional service + an
>   incremental reduction in stringency of the incubator.

+1, and I'd add that it corrects how the Incubator should see itself --
instead of an enforcer, as a provider of services to podlings.

> * It captures some of the value in what we are doing now while increasing
>   the degrees of freedom provided to podlings.
> * It is consistent with our values of transparency, collaboration,
>    community, pragmatism, meritocracy, and charity.

+1, well said!

Marvin Humphrey

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

Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Yes, we should start recommending your approach.

I think the IPMC need to decide as a whole on that first. Perhaps call a vote?

> I am actually for this as normal course and instituting the “pTLP” as the new normal as it is actually makes the PPMC more like a TLP from the start.

And perhaps keep this seperate from above.

One idea did occur to me and that is one solution may not fit all podlings and actually give podlings some choice of what system they want to use when entering the incubator.

I also think it needs to be made very clear that some of the alternative suggestions, while sound appealing (e.g. no IPMC votes mean we can get releases out faster), may in some cases result in:
a) Podlings taking a lot longer to graduate
b) Issues being found where trying to graduate causing disappointment and delays
c) Mentors need to put in more effort especially when to come to steps pre-graduation, at a time when not all of them may be as active
d) The IPMC may need to do more work at graduation time to check that everything is in order.

Now this might only be the case for the small number of codlings that run into trouble, and for the majority it’s fine no matter what system is used.

Also I’ll note a -1 vote on a release shouldn't be a big deal (it’s not a veto), but a -1 vote on a graduations would be a much bigger issue. Hopefully this wouldn’t happen and it should be obvious in the discussion about the graduation that more needs to be done, but podlings are going to be be keen to graduate and may overlook some advice at this point.

> (1) If a podling gets the 3 +1 binding votes from their mentors and/or IPMC members on their dev list then they can release and use a [DISCUSS] thread to solicit improvements for the next release rather than have a “useless” second round of voting on general@

I can point to many many case where the second round voting has been far from useless.

> (3) If “Unofficial” Apache Releases are allowed on the normal podling Apache Distribution Channels then this [DISCUSS] thread can be used until the podling is ready for an “Official” Apache Release. As I understand it this needs approval from Infrastructure.

And probably legal. i.e. Would the currently legal shield still apply and is the current disclaimer adequate? Would it have an impact of the cost of that insurance?

Thanks,
Justin


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

Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates

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

Hi Myrle,

Yes, we should start recommending your approach. I am actually for this as normal course and instituting the “pTLP” as the new normal as it is actually makes the PPMC more like a TLP from the start.

Given our current interpretation of rules that An Official Apache Release requires 3 +1 IPMC Votes:

(1) If a podling gets the 3 +1 binding votes from their mentors and/or IPMC members on their dev list then they can release and use a [DISCUSS] thread to solicit improvements for the next release rather than have a “useless” second round of voting on general@

(2) If a podling is making an non-Apache Release as they are transitioning to Apache they can use this mechanism to solicit reviews about how close they are to being able to produce an Official Apache Release.

(3) If “Unofficial” Apache Releases are allowed on the normal podling Apache Distribution Channels then this [DISCUSS] thread can be used until the podling is ready for an “Official” Apache Release. As I understand it this needs approval from Infrastructure. Allowing this approach brings podlings more quickly into Apache Releases, but has disadvantages like yet another distinction that may be hard to explain.

(4) “pTLP” with some lower number of IPMC votes become the approved podling model for producing “Official” Apache Releases. If this is the model then the IPMC would make the 3 +1 IPMC Vote on a podling's most recent releases a clear graduation requirement.

Regards,
Dave

> On Mar 6, 2019, at 8:15 AM, Myrle Krantz <my...@apache.org> wrote:
> 
> Hey all,
> 
> I've only heard positive feedback on this proposal.  It doesn't solve all
> our problems, but it would provide a path around some of the bureaucracy.
> 
> Would the other mentors be willing to bring this suggestion to their
> podlings?  Especially the "young" ones who still need releases outside of
> the ASF?
> 
> Best Regards,
> Myrle
> 
> On Tue, Feb 26, 2019 at 8:50 AM Myrle Krantz <my...@apache.org> wrote:
> 
>> Motivation:
>> 
>> Some podlings want or need feedback on their releases before they are
>> ready to make official Apache releases.  They want to discuss releases that
>> are not yet ready for a VOTE, or that they are not sure they are ready for
>> a vote.  They may wish to make an early release outside of the foundation,
>> but still test the ASF waters.  They prefer to "fail early, fail often and
>> fail forward". [1]
>> 
>> 
>> Proposal:
>> 
>> Podlings should be able to request feedback by starting a "[DISCUSS]"
>> thread instead of a "[VOTE]" thread.  Discussion should give podlings
>> feedback on what they would need to do to bring their release in line with
>> the requirements for graduation to TLP.  Podlings will be responsible for
>> capturing feedback that they accept in work items for their project.
>> Feedback provided in a discussion thread will not block a non-ASF release.
>> 
>> Asking for feedback using this mechanism is not obligatory, but rather a
>> service that the incubator offers.
>> 
>> 
>> Arguments for this proposal:
>> 
>> * It's a very small change which may make it easier to implement than some
>> of the "throw it all away and start over" proposals circulating, but...
>> * It doesn't prevent us from making other larger changes.
>> * It's not a rule.  It's an offering of an additional service + an
>> incremental reduction in stringency of the incubator.
>> * It captures some of the value in what we are doing now while increasing
>> the degrees of freedom provided to podlings.
>> * It is consistent with our values of transparency, collaboration,
>> community, pragmatism, meritocracy, and charity.
>> 
>> Best Regards,
>> Myrle
>> 
>> 1.)
>> https://www.goodreads.com/work/quotes/614412-failing-forward-turning-mistakes-into-stepping-stones-for-success
>> 


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

Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates

[Myrle Krantz <my...@apache.org>]

Hey all,

I've only heard positive feedback on this proposal.  It doesn't solve all
our problems, but it would provide a path around some of the bureaucracy.

Would the other mentors be willing to bring this suggestion to their
podlings?  Especially the "young" ones who still need releases outside of
the ASF?

Best Regards,
Myrle

On Tue, Feb 26, 2019 at 8:50 AM Myrle Krantz <my...@apache.org> wrote:

> Motivation:
>
> Some podlings want or need feedback on their releases before they are
> ready to make official Apache releases.  They want to discuss releases that
> are not yet ready for a VOTE, or that they are not sure they are ready for
> a vote.  They may wish to make an early release outside of the foundation,
> but still test the ASF waters.  They prefer to "fail early, fail often and
> fail forward". [1]
>
>
> Proposal:
>
> Podlings should be able to request feedback by starting a "[DISCUSS]"
> thread instead of a "[VOTE]" thread.  Discussion should give podlings
> feedback on what they would need to do to bring their release in line with
> the requirements for graduation to TLP.  Podlings will be responsible for
> capturing feedback that they accept in work items for their project.
> Feedback provided in a discussion thread will not block a non-ASF release.
>
> Asking for feedback using this mechanism is not obligatory, but rather a
> service that the incubator offers.
>
>
> Arguments for this proposal:
>
> * It's a very small change which may make it easier to implement than some
> of the "throw it all away and start over" proposals circulating, but...
> * It doesn't prevent us from making other larger changes.
> * It's not a rule.  It's an offering of an additional service + an
> incremental reduction in stringency of the incubator.
> * It captures some of the value in what we are doing now while increasing
> the degrees of freedom provided to podlings.
> * It is consistent with our values of transparency, collaboration,
> community, pragmatism, meritocracy, and charity.
>
> Best Regards,
> Myrle
>
> 1.)
> https://www.goodreads.com/work/quotes/614412-failing-forward-turning-mistakes-into-stepping-stones-for-success
>

Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Allow the VOTE thread to be only on the dev@ list with 0 or 1 mentor vote required. As long as the DISCLAIMER exists then the pooling release is good.
> 
> Once completed the podling sends the vote thread to general@ with [REVIEW] (or [DISCUSS]). This allows the IPMC to review and comment on how close the release is to being a fully proper Apache Release. The podling can more easily take smaller increments while continuing development as they did before Incubation as well as how they will do it once they graduate.
> 
> Graduation requirements don’t change.
> 
> Thoughts?

I think there are some issues with this and not sure how they all can be addressed:
- The level of IPMC reviews of releases is likely to go down. Are mentors going to do something at the same level of effort (vote on releases) if it’s optional (review releases)? Similarly with non IPMC members.
- With reduced attentions It’s more likely that issues go unnoticed in releases (until graduation time).
- Visible progress may be harder for the IPMC to see.
- It's possible that more releases will be needed to be done before they are are in line with ASF releases and some podlings will take longer to graduate.
- If it does take longer to graduate it likely that some podlings will have less mentor attention towards the end.
- Moving "getting it right" just before graduation could cause a couple of issues:
  a) Things are not fixed until the last minute. It’s just human nature if it doesn’t need to be done right away it's often put off. In that case can the IPMC tell that a podling is ready to graduate?
  a) Issues are found by the IPMC when a project has asked to graduate and they may be rejected and worse case go through several cycles of trying to graduate.
  b) Mentors may not be around as much at this time too help.
- it's not known if the current DISCLAIMER is enough to cover us (we can ask legal)
- It's not know if INFRA will allow distribution of artefacts with serious issues in large numbers on ASF infrastructure (we can ask)

If we do do this, rather than change all podlings over to this method, it may be best to do this an experiment (small reversible steps) and see if some podlings would like to try things way and see how it goes. I assume Zipkin may be willing to be one of those. The only issue being the length of the experiment, it will be a few years before we know the outcome.

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

Re: Whimsy general@ subs check (was: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates)

[Lars Francke <la...@gmail.com>]

Greg,

thank you for taking the time to elaborate. I'm afraid I still don't
understand.

I understand that this is how it's currently set up. But these are our
rules, we can change them. There's no law involved here, right?

The way I see it: One problem we're trying to solve is too many people in
the Incubator IPMC, and if there are lots of ASF members in the IPMC just
so they can vote on new podlings let's make a new rule that members are
allowed to vote on it without joining the IPMC. Joining is just an
administrative process the way it is set up now. There's no merit involved
(other than the merit that needs to be proven to become a member in the
first place).

But there's a good chance I still misunderstand.

Cheers,
Lars

On Fri, Mar 1, 2019 at 4:20 PM Greg Stein <gs...@gmail.com> wrote:

> On Fri, Mar 1, 2019 at 9:04 AM Lars Francke <la...@gmail.com>
> wrote:
>
> > On Fri, Mar 1, 2019 at 3:05 PM Greg Stein <gs...@gmail.com> wrote:
> >
> > > On Fri, Mar 1, 2019 at 7:00 AM Lars Francke <la...@gmail.com>
> > > wrote:
> > > >...
> > >
> > > > As far as I know every member can become IPMC member. So if we change
> > the
> > > > rules that every member vote is binding (whether or not they are in
> the
> > > > IPMC) people wouldn't need to join the club.
> > > >
> > >
> > > The legal structure passes through the IPMC. Members are irrelevant in
> > this
> > > scenario.
> > >
> >
> > I'm not sure I understand. But either way I don't believe members are
> > irrelevant. Looking at the Incubator site[1] it says "Foundation members
> > may willingly join the IPMC at any time, [...]" and if they do only to
> vote
> > but not to participate in any other way then that would be one way to
> > reduce membership (by allowing them to vote without being IPMC members)
> >
> > Maybe you can rephrase your comment for me? I may misunderstand.
> >
>
> The legal structure of the Foundation is built upon oversight from the
> Board, to the PMCs, to the communities. The individuals who reside within
> the IPMC are ... individuals.
>
> If Members happen to be individuals that are participating within the IPMC,
> that is wholly orthogonal to everything constructed. Yes, the IPMC gives
> them preferential treatment to *join* the IPMC, but they are peers, just
> like every other person in the community.
>
> The legal structure is built upon a PMC providing (3) +1 votes on a
> release. To be clear: PMC Members. Those with responsibility around the
> community producing the release.
>
> Foundation Members have zero say in any of the technical communities. None.
> They must earn their merit, and join a PMC to get a binding vote. Their
> Membership in the Foundation does not give them any privilege. So, no... a
> Foundation Member should not get a privileged vote within the Incubator
> PMC.
>
> Expand it more broadly: the Board is the representative group of the
> Members. They completely and actively shun any attempt to direct/vote in
> the technical communities. There are two very distinct groups: those in the
> technical communities, and those assisting with the Foundation's
> administrative side. Members are in the latter, and they should not get a
> vote in Incubator/podling releases. They must *join* the technical
> community, via merit, to be afforded that right.
>
> Cheers,
> -g
>

Re: Whimsy general@ subs check (was: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates)

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

On Fri, Mar 1, 2019 at 9:04 AM Lars Francke <la...@gmail.com> wrote:

> On Fri, Mar 1, 2019 at 3:05 PM Greg Stein <gs...@gmail.com> wrote:
>
> > On Fri, Mar 1, 2019 at 7:00 AM Lars Francke <la...@gmail.com>
> > wrote:
> > >...
> >
> > > As far as I know every member can become IPMC member. So if we change
> the
> > > rules that every member vote is binding (whether or not they are in the
> > > IPMC) people wouldn't need to join the club.
> > >
> >
> > The legal structure passes through the IPMC. Members are irrelevant in
> this
> > scenario.
> >
>
> I'm not sure I understand. But either way I don't believe members are
> irrelevant. Looking at the Incubator site[1] it says "Foundation members
> may willingly join the IPMC at any time, [...]" and if they do only to vote
> but not to participate in any other way then that would be one way to
> reduce membership (by allowing them to vote without being IPMC members)
>
> Maybe you can rephrase your comment for me? I may misunderstand.
>

The legal structure of the Foundation is built upon oversight from the
Board, to the PMCs, to the communities. The individuals who reside within
the IPMC are ... individuals.

If Members happen to be individuals that are participating within the IPMC,
that is wholly orthogonal to everything constructed. Yes, the IPMC gives
them preferential treatment to *join* the IPMC, but they are peers, just
like every other person in the community.

The legal structure is built upon a PMC providing (3) +1 votes on a
release. To be clear: PMC Members. Those with responsibility around the
community producing the release.

Foundation Members have zero say in any of the technical communities. None.
They must earn their merit, and join a PMC to get a binding vote. Their
Membership in the Foundation does not give them any privilege. So, no... a
Foundation Member should not get a privileged vote within the Incubator PMC.

Expand it more broadly: the Board is the representative group of the
Members. They completely and actively shun any attempt to direct/vote in
the technical communities. There are two very distinct groups: those in the
technical communities, and those assisting with the Foundation's
administrative side. Members are in the latter, and they should not get a
vote in Incubator/podling releases. They must *join* the technical
community, via merit, to be afforded that right.

Cheers,
-g

Re: Whimsy general@ subs check (was: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates)

[Lars Francke <la...@gmail.com>]

On Fri, Mar 1, 2019 at 3:05 PM Greg Stein <gs...@gmail.com> wrote:

> On Fri, Mar 1, 2019 at 7:00 AM Lars Francke <la...@gmail.com>
> wrote:
> >...
>
> > As far as I know every member can become IPMC member. So if we change the
> > rules that every member vote is binding (whether or not they are in the
> > IPMC) people wouldn't need to join the club.
> >
>
> The legal structure passes through the IPMC. Members are irrelevant in this
> scenario.
>

I'm not sure I understand. But either way I don't believe members are
irrelevant. Looking at the Incubator site[1] it says "Foundation members
may willingly join the IPMC at any time, [...]" and if they do only to vote
but not to participate in any other way then that would be one way to
reduce membership (by allowing them to vote without being IPMC members)

Maybe you can rephrase your comment for me? I may misunderstand.


>
> Cheers,
> -g
>

Re: Whimsy general@ subs check (was: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates)

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

On Fri, Mar 1, 2019 at 7:00 AM Lars Francke <la...@gmail.com> wrote:
>...

> As far as I know every member can become IPMC member. So if we change the
> rules that every member vote is binding (whether or not they are in the
> IPMC) people wouldn't need to join the club.
>

The legal structure passes through the IPMC. Members are irrelevant in this
scenario.

Cheers,
-g

Re: Whimsy general@ subs check (was: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates)

[Lars Francke <la...@gmail.com>]

If only some people are like me they joined to support a specific podling
by giving their +1 on a vote. I did the same, then went silent for a year
or so and am only now starting to get interested in the Incubator workings
again.

Maybe if we could change the requirements on binding votes for podling
proposals we wouldn't need as many people in the IPMC?
As far as I know every member can become IPMC member. So if we change the
rules that every member vote is binding (whether or not they are in the
IPMC) people wouldn't need to join the club.

On Fri, Mar 1, 2019 at 1:50 PM Myrle Krantz <my...@apache.org> wrote:

> On Fri, Mar 1, 2019 at 12:33 AM Justin Mclean <ju...@classsoftware.com>
> wrote:
>
> >
> > And most probably do not participate. Would asking for those 100 odd
> > people to be removed come across as friendly?
> >
>
> I'd be +1 on removing them.  a.) While kindness towards our fellow PMC
> members is important, the role of the Incubator is to be friendly to
> incoming projects. b.) It's not unkind to our fellow PMC members.  They are
> welcome to come back when they're ready.
>
> But I also don't think it's going to solve anything.  Those people aren't
> contributing to solutions *or* problems.
>
> Best,
> Myrle
>

Re: Whimsy general@ subs check (was: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates)

[Myrle Krantz <my...@apache.org>]

On Fri, Mar 1, 2019 at 12:33 AM Justin Mclean <ju...@classsoftware.com>
wrote:

>
> And most probably do not participate. Would asking for those 100 odd
> people to be removed come across as friendly?
>

I'd be +1 on removing them.  a.) While kindness towards our fellow PMC
members is important, the role of the Incubator is to be friendly to
incoming projects. b.) It's not unkind to our fellow PMC members.  They are
welcome to come back when they're ready.

But I also don't think it's going to solve anything.  Those people aren't
contributing to solutions *or* problems.

Best,
Myrle

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

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

On Sun, Mar 3, 2019 at 1:42 AM Ted Dunning <te...@gmail.com> wrote:

> Greg,
>
> Would you categorize yourself as one of these drive-by kibitzers?
>

Nope. I don't interact/meddle with podlings, but stick to meta/process
issues within the Incubator.

Somewhat recently, I worked with Fineract and Mynewt as a Mentor, but have
not volunteered for mentoring since their graduations (my
non-work/volunteer time goes to supplement my work time in Infra).

Certainly, I grant you that I may have written a poor email, that
randomized a podling. I've tried to avoid such podling-specific emails, but
may have missed. If something sticks out, then I'd like to hear, so I can
fix going forward.

I've been subscribed to private@ since it was created in October 2002. Ken
Coar was the first subscribed to the list, and I got subscribed about 5
minutes later. My concern is about those who use their IPMC membership for
the drive-bys (the issue that instigated this discussion), yet they aren't
subscribed and *participating* as an IPMC Member for its entire host of
activities and responsibilities for guiding new communities into the ASF.
Maybe that intersection is zero, but I still see no reason to keep people
on the IPMC if they won't subscribe to private@

Cheers,
-g

On Sun, Mar 3, 2019 at 1:42 AM Ted Dunning <te...@gmail.com> wrote:

> Greg,
>
> Would you categorize yourself as one of these drive-by kibitzers?
>
>
>
>
> On Sat, Mar 2, 2019 at 3:55 AM Greg Stein <gs...@gmail.com> wrote:
>
> > On Sat, Mar 2, 2019 at 5:17 AM sebb <se...@gmail.com> wrote:
> >
> > > On Sat, 2 Mar 2019 at 10:49, Greg Stein <gs...@gmail.com> wrote:
> > > >
> > > > On Sat, Mar 2, 2019 at 2:50 AM sebb <se...@gmail.com> wrote:
> > > >
> > > > > On Sat, 2 Mar 2019 at 03:45, Justin Mclean <
> justin@classsoftware.com
> > >
> > > > > wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > > I agree that it's not ideal but it is not a symptom of a big
> > > problem
> > > > > either. We have inactive IPMC members who might become active again
> > > later
> > > > > if a community wants to join the incubator but it's a hassle to
> leave
> > > and
> > > > > then join again.
> > > > > >
> > > > > > Some context, over 300 projects have gone through the incubator,
> 50
> > > are
> > > > > there currently, each requires a champion and 3 mentors at the
> start
> > > (all
> > > > > IPMC members), even with some mentors working on multiple podling
> > it's
> > > not
> > > > > surprising the IPMC is 300 people or so. Nor should it be that a
> > large
> > > > > number of them are inactive as most of the projects they were
> > involved
> > > in
> > > > > have graduated (or retired).
> > > > >
> > > > > +1
> > > > >
> > > > > > But despite this some still think it is an issue so we IMO we
> > should
> > > > > address it, unless they change their minds, and say so here.
> > > > >
> > > > > Personally, I don't think that is a reason to reduce the IPMC
> count.
> > > > > I think it needs to be established WHY it is thought to be an issue
> > > first.
> > > > >
> > > >
> > > > It encourages drive-by bikeshedding. "I'm an IPMC Member from a few
> > years
> > > > back. I see $foo, and OMG need to comment on it."
> > > >
> > > > Did anybody stop and read the concerns recently raised to the Board?
> > Much
> > > > of the focus on that email was about such drive-by commenting.
> > > >
> > > > Thus, reduce the opportunity for drive-by.
> > >
> > > Since the general@ list is public, I don't think reducing the IPMC
> > > will stop comments.
> > >
> >
> > So? It is to reduce the number of people who feel empowered to meddle
> into
> > everything every podling does. You want to fix general@ ??, then go
> ahead.
> > I want to see people who choose not to *participate* in the IPMC [by
> > subscribing to private@] dropped from the roster. The whole world can
> chat
> > on general@. But if you want to be *part* of the IPMC, and want a
> binding
> > vote, and want to really throw-in on Incubator matters, then you damned
> > well better subscribe.
> >
> > The basic structure of 200+ people all having "merit" to jump into a
> > podling's pond is a priori broken. We have *specific* feedback that this
> is
> > true. Not a guess. Not some survey. A "letter" signed by numerous
> > individuals that this is the case. So until the Incubator decides its
> basic
> > structure is Wrong(tm), and stops pushing back against that feedback,
> then
> > what is a simple reversible change to try and disempower the knuckleheads
> > who want to throw in, on the good work done by our podlings? ... Right.
> > Trim the IPMC.
> >
> > -g
> >
>

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

[Ted Dunning <te...@gmail.com>]

Greg,

Would you categorize yourself as one of these drive-by kibitzers?




On Sat, Mar 2, 2019 at 3:55 AM Greg Stein <gs...@gmail.com> wrote:

> On Sat, Mar 2, 2019 at 5:17 AM sebb <se...@gmail.com> wrote:
>
> > On Sat, 2 Mar 2019 at 10:49, Greg Stein <gs...@gmail.com> wrote:
> > >
> > > On Sat, Mar 2, 2019 at 2:50 AM sebb <se...@gmail.com> wrote:
> > >
> > > > On Sat, 2 Mar 2019 at 03:45, Justin Mclean <justin@classsoftware.com
> >
> > > > wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > > I agree that it's not ideal but it is not a symptom of a big
> > problem
> > > > either. We have inactive IPMC members who might become active again
> > later
> > > > if a community wants to join the incubator but it's a hassle to leave
> > and
> > > > then join again.
> > > > >
> > > > > Some context, over 300 projects have gone through the incubator, 50
> > are
> > > > there currently, each requires a champion and 3 mentors at the start
> > (all
> > > > IPMC members), even with some mentors working on multiple podling
> it's
> > not
> > > > surprising the IPMC is 300 people or so. Nor should it be that a
> large
> > > > number of them are inactive as most of the projects they were
> involved
> > in
> > > > have graduated (or retired).
> > > >
> > > > +1
> > > >
> > > > > But despite this some still think it is an issue so we IMO we
> should
> > > > address it, unless they change their minds, and say so here.
> > > >
> > > > Personally, I don't think that is a reason to reduce the IPMC count.
> > > > I think it needs to be established WHY it is thought to be an issue
> > first.
> > > >
> > >
> > > It encourages drive-by bikeshedding. "I'm an IPMC Member from a few
> years
> > > back. I see $foo, and OMG need to comment on it."
> > >
> > > Did anybody stop and read the concerns recently raised to the Board?
> Much
> > > of the focus on that email was about such drive-by commenting.
> > >
> > > Thus, reduce the opportunity for drive-by.
> >
> > Since the general@ list is public, I don't think reducing the IPMC
> > will stop comments.
> >
>
> So? It is to reduce the number of people who feel empowered to meddle into
> everything every podling does. You want to fix general@ ??, then go ahead.
> I want to see people who choose not to *participate* in the IPMC [by
> subscribing to private@] dropped from the roster. The whole world can chat
> on general@. But if you want to be *part* of the IPMC, and want a binding
> vote, and want to really throw-in on Incubator matters, then you damned
> well better subscribe.
>
> The basic structure of 200+ people all having "merit" to jump into a
> podling's pond is a priori broken. We have *specific* feedback that this is
> true. Not a guess. Not some survey. A "letter" signed by numerous
> individuals that this is the case. So until the Incubator decides its basic
> structure is Wrong(tm), and stops pushing back against that feedback, then
> what is a simple reversible change to try and disempower the knuckleheads
> who want to throw in, on the good work done by our podlings? ... Right.
> Trim the IPMC.
>
> -g
>

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

[Craig Russell <ap...@gmail.com>]

I'd like to understand Greg's concerns better.

The complaint that I saw has to do with comments on release candidates, which I believe there is a straightforward solution for (don't be so picky about the first podling releases).

Are there any other instances of IPMC members meddling in podlings' affairs?

Craig


> On Mar 2, 2019, at 3:54 AM, Greg Stein <gs...@gmail.com> wrote:
> 
> On Sat, Mar 2, 2019 at 5:17 AM sebb <sebbaz@gmail.com <ma...@gmail.com>> wrote:
> 
>> On Sat, 2 Mar 2019 at 10:49, Greg Stein <gs...@gmail.com> wrote:
>>> 
>>> On Sat, Mar 2, 2019 at 2:50 AM sebb <se...@gmail.com> wrote:
>>> 
>>>> On Sat, 2 Mar 2019 at 03:45, Justin Mclean <ju...@classsoftware.com>
>>>> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>>> I agree that it's not ideal but it is not a symptom of a big
>> problem
>>>> either. We have inactive IPMC members who might become active again
>> later
>>>> if a community wants to join the incubator but it's a hassle to leave
>> and
>>>> then join again.
>>>>> 
>>>>> Some context, over 300 projects have gone through the incubator, 50
>> are
>>>> there currently, each requires a champion and 3 mentors at the start
>> (all
>>>> IPMC members), even with some mentors working on multiple podling it's
>> not
>>>> surprising the IPMC is 300 people or so. Nor should it be that a large
>>>> number of them are inactive as most of the projects they were involved
>> in
>>>> have graduated (or retired).
>>>> 
>>>> +1
>>>> 
>>>>> But despite this some still think it is an issue so we IMO we should
>>>> address it, unless they change their minds, and say so here.
>>>> 
>>>> Personally, I don't think that is a reason to reduce the IPMC count.
>>>> I think it needs to be established WHY it is thought to be an issue
>> first.
>>>> 
>>> 
>>> It encourages drive-by bikeshedding. "I'm an IPMC Member from a few years
>>> back. I see $foo, and OMG need to comment on it."
>>> 
>>> Did anybody stop and read the concerns recently raised to the Board? Much
>>> of the focus on that email was about such drive-by commenting.
>>> 
>>> Thus, reduce the opportunity for drive-by.
>> 
>> Since the general@ list is public, I don't think reducing the IPMC
>> will stop comments.
>> 
> 
> So? It is to reduce the number of people who feel empowered to meddle into
> everything every podling does. You want to fix general@ ??, then go ahead.
> I want to see people who choose not to *participate* in the IPMC [by
> subscribing to private@] dropped from the roster. The whole world can chat
> on general@. But if you want to be *part* of the IPMC, and want a binding
> vote, and want to really throw-in on Incubator matters, then you damned
> well better subscribe.
> 
> The basic structure of 200+ people all having "merit" to jump into a
> podling's pond is a priori broken. We have *specific* feedback that this is
> true. Not a guess. Not some survey. A "letter" signed by numerous
> individuals that this is the case. So until the Incubator decides its basic
> structure is Wrong(tm), and stops pushing back against that feedback, then
> what is a simple reversible change to try and disempower the knuckleheads
> who want to throw in, on the good work done by our podlings? ... Right.
> Trim the IPMC.
> 
> -g

Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <http://db.apache.org/jdo>

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

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

> On Mar 6, 2019, at 7:59 AM, sebb <se...@gmail.com> wrote:
> 
> On Wed, 6 Mar 2019 at 15:53, Myrle Krantz <my...@apache.org> wrote:
>> 
>> On Wed, Mar 6, 2019 at 4:49 PM Daniel Gruno <hu...@apache.org> wrote:
>> 
>>> Or put differently; why would we care that someone is inactive on the
>>> IPMC? Are we short on bytes on the LDAP server and need to conserve
>>> space? ;). It should make no difference if there are inactive members of
>>> the IPMC or not.
>>> 
>> 
>> Have you tried loading the IPMC roster in whimsy?  ; o)
>> Here, look at what I mean:
>> https://whimsy.apache.org/roster/committee/incubator
> 
> I think the slowness is mainly due to the number of committers (nearly 3000).

Agreed. I think we are bikeshedding on the IPMC membership issue and avoiding the hard problems:

- Not enough Mentors (not enough active IPMC members)
- Overly Bureaucratic Workflows.
- Incubator Guidance is duplicative both internally and compared to the authoritative Foundation documentation

Regards,
Dave

> 
>> (This still isn't my argument though.)
>> 
>> Best,
>> Myrle
> 
> ---------------------------------------------------------------------
> 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: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

[sebb <se...@gmail.com>]

On Wed, 6 Mar 2019 at 15:53, Myrle Krantz <my...@apache.org> wrote:
>
> On Wed, Mar 6, 2019 at 4:49 PM Daniel Gruno <hu...@apache.org> wrote:
>
> > Or put differently; why would we care that someone is inactive on the
> > IPMC? Are we short on bytes on the LDAP server and need to conserve
> > space? ;). It should make no difference if there are inactive members of
> > the IPMC or not.
> >
>
> Have you tried loading the IPMC roster in whimsy?  ; o)
> Here, look at what I mean:
> https://whimsy.apache.org/roster/committee/incubator

I think the slowness is mainly due to the number of committers (nearly 3000).

> (This still isn't my argument though.)
>
> Best,
> Myrle

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

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

[Myrle Krantz <my...@apache.org>]

On Wed, Mar 6, 2019 at 4:49 PM Daniel Gruno <hu...@apache.org> wrote:

> Or put differently; why would we care that someone is inactive on the
> IPMC? Are we short on bytes on the LDAP server and need to conserve
> space? ;). It should make no difference if there are inactive members of
> the IPMC or not.
>

Have you tried loading the IPMC roster in whimsy?  ; o)
Here, look at what I mean:
https://whimsy.apache.org/roster/committee/incubator

(This still isn't my argument though.)

Best,
Myrle

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

[Daniel Gruno <hu...@apache.org>]

On 3/6/19 4:47 PM, Ross Gardler wrote:
> Merit does not expire. People who are not active today should be able to become active tomorrow without having to jump through approval hoops.
> 
> In projects there is no concept of emeritus PMC. Here in the IPMC the issue is very different. Most people earn merit transitively - become a member, become a mentor, become an IPMC member. It's different.
> 
> Please don't use what is being discussed here as being transitive to a PMC based entirely on directly earned merit.

Or put differently; why would we care that someone is inactive on the 
IPMC? Are we short on bytes on the LDAP server and need to conserve 
space? ;). It should make no difference if there are inactive members of 
the IPMC or not.

> 
> Get Outlook for Android<https://aka.ms/ghei36>
> 
> ________________________________
> From: Dmitriy Pavlov <dp...@apache.org>
> Sent: Tuesday, March 5, 2019 4:46:09 AM
> To: general@incubator.apache.org
> Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))
> 
> I absolutely agree with Greg Stein. I can't find any single reason to keep
> unsubscribed members of IPMC in the roster. These members can be asked to
> subscribe, and if they do, then ok; if don't - it is perfectly ok to remove.
> 
> Similarly, I don't see reasons for having inactive TLP PMC members. I've
> suggested the same change in Apache Ignite, but I don't clearly understand
> why remained members resisting this change.
> 
> 
> пн, 4 мар. 2019 г. в 09:58, Ross Gardler <ro...@gardler.me>:
> 
>> That's right Greg. And since we are filling in gaps for people...
>>
>> I was originally against the pTLP concept (though I supported the
>> experiments) or any of the derivatives that came from it. I think I have
>> changed my position. Largely based on the fact that every single project
>> I've discussed the ASF with in the last 3-5 years has had a very inaccurate
>> perception of how the ASF works. I believe a large part of this is due, in
>> part, to the issues being discussed in this thread.
>>
>> I do not understand how a foundation which prides itself in having very
>> little bureaucratic red tape can be seen as having so much red tape. The
>> projects I talk to just want to build software. It used to be that the ASF
>> focused on running the legal and operational aspects of the foundation
>> projects and developers on projects wrote code. I'm not sure that's true
>> anymore.
>>
>> We need to fix it.
>>
>> I look forward to hearing how the IPMC will seek to strip down the
>> bureaucracy and get back to mentoring the incoming projects on how the ASF
>> is structured so they can get (relatively) quick and clear answers to their
>> questions.
>>
>> Ross
>>
>> ________________________________________
>> From: Greg Stein <gs...@gmail.com>
>> Sent: Sunday, March 3, 2019 10:19 PM
>> To: general@incubator.apache.org
>> Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy
>> general@ subs check (was: .... introduce "[DISCUSS]" threads for podling
>> ... release candidates))
>>
>> On Sun, Mar 3, 2019 at 10:37 PM Ross Gardler <ro...@gardler.me> wrote:
>>
>>> If a podling is a committee in its own right then it can be empowered to
>>> act on behalf of the board and this its releases can be an act of the
>>> foundation.
>>>
>>> ...
>>
>>> Podlings would only become full TLPs once they have demonstrated their
>>> ability to do formal releases.
>>>
>>
>> The above pair of concepts was offered in $priorCycle as "provisional TLPs"
>> (pTLP). I believe the idea ended when Sam pointed out that if a pTLP is
>> trusted, then why not just call it a TLP and trust it to label its releases
>> appropriately? Thus, just create TLPs immediately for a "podling"
>>
>> [ I know Ross knows this; but for $others who may want to look at
>> historical proposals, and compare/contrast to current discussion ... search
>> for "pTLP" ]
>>
>> Cheers,
>> -g
>>
>> ---------------------------------------------------------------------
>> 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: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

[Adrian Cole <ad...@gmail.com>]

Drive by opinion here, since one of the topics is about expiring "merit"

On one hand, you want to encourage participation and people being one
of NNN where NNN are inactive is demotivating
On one hand, you want to immortalize merit, but is an incubator wiki
pile-on indicative of merit?
On one hand, you want to have fairness, like expiring access after
inactivity, but will people get super mad and hate you for a decade if
they are removed?

It is a loaded topic, almost doomed to fail. Personally, I think
"merit doesn't expire" is weak. There are people who willingly damage
projects and plenty of other reasons to consider decisions that seemed
good at first to not be good long term. Which leads into the bike shed
nature of this topic. Many can take a side as it is easy
participation.. we all have stories with contradicting conclusions.

For that reason alone, I think projects themselves should be able to
decide their culture inclusive of their expiry policy for access. I
don't think this topic will result in any convergence of a one road
out.. and I also feel that way with  "merit doesn't expire". That by
itself is suspiciously attributed to the ASF and I would bet any
amount of money not close to a majority agree with that in private
even if they would out loud.

Can we sideline this or move it somewhere else in other words?
-A

On Thu, Mar 7, 2019 at 5:07 AM Dmitriy Pavlov <dp...@apache.org> wrote:
>
> Hi Daniel,
>
> There are two independent questions here.
>
> 1) Removal question and its allowance in general:  this question asked
> during every talk I gave related to ASF. My fellows ask me if someone can
> remove Committer or PMCs. Some folks think it is possible by the vote of
> PMC. They refer to docs I've shared: mnemonic project & incubator guide.
>
> Here I need some general understanding which I can use for
> answering questions.
>
> 2) Inactive members removal: Lack of active PMCs member makes me thinks
> that at some point some removal will be necessary. We can
> continuously grow the roster for a TLP project, but sometimes I feel there
> are ~30 members and only 5-7 active members. So why don't we narrow the
> roster to 7 and invite new members?
>
> It looks reasonable that if you want a binding vote, approve releases,
> propose new committers you need to join community communication channels
> and be there.  My idea is, first of all, ask PMCs if they want to stay or
> leave and, second of all, to always keep committership, because it is based
> on merit.
>
> And here for option 2, I don't have any severe issues to address. If it a
> bad idea, not a problem. In that case, I also would be happy if I
> understand this topic better.
>
> Sincerely,
> Dmitriy Pavlov
>
>
> ср, 6 мар. 2019 г. в 23:12, Daniel Gruno <hu...@apache.org>:
>
> > On 3/6/19 9:08 PM, Dmitriy Pavlov wrote:
> > > Hi Ross,
> > >
> > > Thank you for your reply. Apache Ignite PMCs do not support this idea, so
> > > inactive PMCs will be still there.
> > >
> > > But still, it is not clear for me in general, why following
> > > projects/guidelines contains removal procedure for Committer PMC:
> > > - https://mnemonic.apache.org/develop/bylaws/  after 6 months of
> > inactivity
> > > both PMC and Committer status may be removed.
> > > - Default Incubator guidelines
> > > https://wiki.apache.org/incubator/DefaultProjectGuidelines It contains
> > > procedures of consensus-based removal, - it is ok to remove for
> > Incubator?
> > > is it ok for TLP?
> > >
> > > If both PMC & Committer roles are merit-based, and merit does not expire,
> > > how it even possible to remove TLP committer/PMC (excepting some extreme
> > > cases)?
> > >
> > > This question is not only mine, but it is also often asked and I would
> > like
> > > to know the answer.
> >
> > Turn the question around; *why* are you looking to remove people? What
> > is the problem you are trying to solve here? How will removing someone
> > from the PMC/committer list help address the issues you are facing?
> >
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> >
> > ---------------------------------------------------------------------
> > 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: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Justin, one more question, are Default Guidelines, you've prepared some
> time ago, applicable only for projects under incubation or it is inherited
> 'as is' to TLP?

There were for podlings as they graduation to TLP, so apply to both. They were created, as it’s no longer suggested that project have their own bylaws, with feedback from the IPMC and the board and distilled from existing ASF (not incubator) policy documents. [1]

Thanks,
Justin

1. https://wiki.apache.org/incubator/DefaultProjectGuidelines
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

[Dmitriy Pavlov <dp...@apache.org>]

Hi Justin, Daniel, Thank you for your answer.

Justin, one more question, are Default Guidelines, you've prepared some
time ago, applicable only for projects under incubation or it is inherited
'as is' to TLP?

чт, 7 мар. 2019 г. в 00:18, Justin Mclean <ju...@classsoftware.com>:

> Hi,
>
> > 1) Removal question and its allowance in general:  this question asked
> > during every talk I gave related to ASF. My fellows ask me if someone can
> > remove Committer or PMCs. Some folks think it is possible by the vote of
> > PMC.
>
> The PMC may vote on it but only the board can remove a PMC member, they
> have been reluctant to do so in the past, and I don’t think they would
> remove people for being inactive. The PMC can remove committers but it’s
> extremely rare.
>
> > Here I need some general understanding which I can use for
> > answering questions.
> >
> > 2) Inactive members removal: Lack of active PMCs member makes me thinks
> > that at some point some removal will be necessary.
>
> Merit doesn’t not expire and only the board can remove PMC members, a
> project could ask for removed but only the board can actually remove them.
> In general there's no issue in having inactive member and they may decide
> to become active again.
>
> Some time back there was an attempt to clean up any project which
> mentioner the 6 month inactivity thing, not all of them were caught.
>
> Thanks,
> Justin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

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

Hi -

Sent from my iPhone

> On Mar 6, 2019, at 1:18 PM, Justin Mclean <ju...@classsoftware.com> wrote:
> 
> Hi,
> 
>> 1) Removal question and its allowance in general:  this question asked
>> during every talk I gave related to ASF. My fellows ask me if someone can
>> remove Committer or PMCs. Some folks think it is possible by the vote of
>> PMC.
> 
> The PMC may vote on it but only the board can remove a PMC member, they have been reluctant to do so in the past, and I don’t think they would remove people for being inactive. The PMC can remove committers but it’s extremely rare.

Probably this is in the low single digits (maybe only once) over 20 years and the over 300 projects that have been Apache projects. Several Directors have been known to attempt to heal projects where removal is being forced.

People have voluntarily gone Emeritus and/or Resigned after discussion.

If a project has a “commit war” then it has other issues ... seek help for that case and you will get it.

> 
>> Here I need some general understanding which I can use for
>> answering questions.
>> 
>> 2) Inactive members removal: Lack of active PMCs member makes me thinks
>> that at some point some removal will be necessary. 

Lack of active PMC means other issues including a project that might no longer be viable.

Forcing people out is almost always bad for the community.

> 
> Merit doesn’t not expire and only the board can remove PMC members, a project could ask for removed but only the board can actually remove them. In general there's no issue in having inactive member and they may decide to become active again.

Exactly, I’ve disappeared for a year or so twice in the 11 years since I was voted a PMC member on my first Apache project.

> 
> Some time back there was an attempt to clean up any project which mentioner the 6 month inactivity thing, not all of them were caught.

Project Bylaws are actively discouraged.

Regards,
Dave


> 
> Thanks,
> Justin
> 
> 
> ---------------------------------------------------------------------
> 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: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> 1) Removal question and its allowance in general:  this question asked
> during every talk I gave related to ASF. My fellows ask me if someone can
> remove Committer or PMCs. Some folks think it is possible by the vote of
> PMC.

The PMC may vote on it but only the board can remove a PMC member, they have been reluctant to do so in the past, and I don’t think they would remove people for being inactive. The PMC can remove committers but it’s extremely rare.

> Here I need some general understanding which I can use for
> answering questions.
> 
> 2) Inactive members removal: Lack of active PMCs member makes me thinks
> that at some point some removal will be necessary. 

Merit doesn’t not expire and only the board can remove PMC members, a project could ask for removed but only the board can actually remove them. In general there's no issue in having inactive member and they may decide to become active again.

Some time back there was an attempt to clean up any project which mentioner the 6 month inactivity thing, not all of them were caught.

Thanks,
Justin


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

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

[Adrian Cole <ad...@gmail.com>]

> The standard response to this would be a question in return. Instead of
> "remove inactive members and add new ones" why not just "add new ones".

wires crossed and not IPMC (yet), but I agree with this rationale.
Avoid the loaded topic. focus on the important one.

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

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

[Myrle Krantz <my...@apache.org>]

On Thu, Mar 7, 2019 at 11:07 AM Bertrand Delacretaz <
bdelacretaz@codeconsult.ch> wrote:

> a) Asking PMC members if they want to step down from the PMC if they
> seem to be inactive for a long time
>
> b) Forcibly removing PMC members that the PMC considers inactive
>
> IMO a) is fine if a PMC wants to have a roster that reflects reality,
> but b) is bad in terms of community
>
> And yes in any case removals have to be ratified by the Board as per
> http://www.apache.org/dev/pmc.html#pmc-removal


Minor correction (and perhaps this is what you meant):  In the case of
voluntary resignation, the board does not have to ratify.

Quote from the document you linked:
"Once the PMC member's resignation is received on a mailing list of the
Foundation, the resignation is considered effective (however, the PMC
member has 72 hours to withdraw their resignation). Notifying the board is
not required, but encouraged to ease tracking."

We're not quite the Hotel California. : o)

Greets,
Myrle

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

[Bertrand Delacretaz <bd...@codeconsult.ch>]

Hi,

On Wed, Mar 6, 2019 at 11:41 PM Ted Dunning <te...@gmail.com> wrote:
> ...inactive PMC members are not a problem
> (Apache culture is heavily designed to make this work) and they could be an
> asset in the future. So removing the inactive members is actually a slight
> negative to the project...

I think it's important to differentiate between

a) Asking PMC members if they want to step down from the PMC if they
seem to be inactive for a long time

b) Forcibly removing PMC members that the PMC considers inactive

IMO a) is fine if a PMC wants to have a roster that reflects reality,
but b) is bad in terms of community

And yes in any case removals have to be ratified by the Board as per
http://www.apache.org/dev/pmc.html#pmc-removal

-Bertrand

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

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

[Ted Dunning <te...@gmail.com>]

Dmitriy,

I don't think that you got a real answer to your section question.

The standard response to this would be a question in return. Instead of
"remove inactive members and add new ones" why not just "add new ones".

The point of this question is that inactive PMC members are not a problem
(Apache culture is heavily designed to make this work) and they could be an
asset in the future. So removing the inactive members is actually a slight
negative to the project.

The real key is the "add new ones" part of your suggestion.

On Wed, Mar 6, 2019 at 1:07 PM Dmitriy Pavlov <dp...@apache.org> wrote:

> Hi Daniel,
>
> There are two independent questions here.
>
> ...
>
> 2) Inactive members removal: Lack of active PMCs member makes me thinks
> that at some point some removal will be necessary. We can
> continuously grow the roster for a TLP project, but sometimes I feel there
> are ~30 members and only 5-7 active members. So why don't we narrow the
> roster to 7 and invite new members?
>
> It looks reasonable that if you want a binding vote, approve releases,
> propose new committers you need to join community communication channels
> and be there.  My idea is, first of all, ask PMCs if they want to stay or
> leave and, second of all, to always keep committership, because it is based
> on merit.
>
> And here for option 2, I don't have any severe issues to address. If it a
> bad idea, not a problem. In that case, I also would be happy if I
> understand this topic better.
>
>

Re: [DISCUSS] Responsibilities and Improvements

[Daniel Gruno <hu...@apache.org>]

On 3/6/19 10:07 PM, Dmitriy Pavlov wrote:
> Hi Daniel,
> 
> There are two independent questions here.
> 
> 1) Removal question and its allowance in general:  this question asked
> during every talk I gave related to ASF. My fellows ask me if someone can
> remove Committer or PMCs. Some folks think it is possible by the vote of
> PMC. They refer to docs I've shared: mnemonic project & incubator guide.

I'm not on the board, but if I was, I'd likely ask the same question 
again; what are you trying to solve by removing people? What is gained 
by removing people? I get that people may see a list of people with 30 
our of 40 being inactive as 'noisy', but removing the 30 isn't going to 
make the other 10 more active, nor is having inactive people a blocker 
for adding more to the list. That you have inactive people on the PMC 
is, plainly put, not a problem in itself, nor a blocker, catalyst or 
anything for whatever problems may exist. If the only reason is 
cosmetic, then that's likely not good enough a reason.

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

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

[Justin Mclean <ju...@classsoftware.com>]

Hi,

So I took a look at all the IPMC members not subscribed to the private list and looked at how active they are aver the last year:
- 7 sent one email to the dev list.
- 7 sent a couple of emails to the list
- 4 sent a few more than that (but less than a dozen)
- 83 had no activity

Of their emails some could be considered “drive by” e.g. voting on releases but every single vote (about 20 in total) were +1’s. So while not subscribed to the private list the few IPMC that are active in that group have low levels of involvement and are helpful.

We get far more more activity on the mailing list by non IPMC members (I’ve looked at stats for top 10 people who email the list in the last few months) and some of that is not helpful.

So a possible solution seems to be to moderate the list mailing list so that only IPMC emails get through.

Well actually no I don’t think we should do that :-)  I think this shows that the issue clearly isn’t to do with the IPMC size and removing those 100+ people would actually do more harm than good and we should consider other solutions.

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

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

[Dmitriy Pavlov <dp...@apache.org>]

Hi Daniel,

There are two independent questions here.

1) Removal question and its allowance in general:  this question asked
during every talk I gave related to ASF. My fellows ask me if someone can
remove Committer or PMCs. Some folks think it is possible by the vote of
PMC. They refer to docs I've shared: mnemonic project & incubator guide.

Here I need some general understanding which I can use for
answering questions.

2) Inactive members removal: Lack of active PMCs member makes me thinks
that at some point some removal will be necessary. We can
continuously grow the roster for a TLP project, but sometimes I feel there
are ~30 members and only 5-7 active members. So why don't we narrow the
roster to 7 and invite new members?

It looks reasonable that if you want a binding vote, approve releases,
propose new committers you need to join community communication channels
and be there.  My idea is, first of all, ask PMCs if they want to stay or
leave and, second of all, to always keep committership, because it is based
on merit.

And here for option 2, I don't have any severe issues to address. If it a
bad idea, not a problem. In that case, I also would be happy if I
understand this topic better.

Sincerely,
Dmitriy Pavlov


ср, 6 мар. 2019 г. в 23:12, Daniel Gruno <hu...@apache.org>:

> On 3/6/19 9:08 PM, Dmitriy Pavlov wrote:
> > Hi Ross,
> >
> > Thank you for your reply. Apache Ignite PMCs do not support this idea, so
> > inactive PMCs will be still there.
> >
> > But still, it is not clear for me in general, why following
> > projects/guidelines contains removal procedure for Committer PMC:
> > - https://mnemonic.apache.org/develop/bylaws/  after 6 months of
> inactivity
> > both PMC and Committer status may be removed.
> > - Default Incubator guidelines
> > https://wiki.apache.org/incubator/DefaultProjectGuidelines It contains
> > procedures of consensus-based removal, - it is ok to remove for
> Incubator?
> > is it ok for TLP?
> >
> > If both PMC & Committer roles are merit-based, and merit does not expire,
> > how it even possible to remove TLP committer/PMC (excepting some extreme
> > cases)?
> >
> > This question is not only mine, but it is also often asked and I would
> like
> > to know the answer.
>
> Turn the question around; *why* are you looking to remove people? What
> is the problem you are trying to solve here? How will removing someone
> from the PMC/committer list help address the issues you are facing?
>
> >
> > Sincerely,
> > Dmitriy Pavlov
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

[Daniel Gruno <hu...@apache.org>]

On 3/6/19 9:08 PM, Dmitriy Pavlov wrote:
> Hi Ross,
> 
> Thank you for your reply. Apache Ignite PMCs do not support this idea, so
> inactive PMCs will be still there.
> 
> But still, it is not clear for me in general, why following
> projects/guidelines contains removal procedure for Committer PMC:
> - https://mnemonic.apache.org/develop/bylaws/  after 6 months of inactivity
> both PMC and Committer status may be removed.
> - Default Incubator guidelines
> https://wiki.apache.org/incubator/DefaultProjectGuidelines It contains
> procedures of consensus-based removal, - it is ok to remove for Incubator?
> is it ok for TLP?
> 
> If both PMC & Committer roles are merit-based, and merit does not expire,
> how it even possible to remove TLP committer/PMC (excepting some extreme
> cases)?
> 
> This question is not only mine, but it is also often asked and I would like
> to know the answer.

Turn the question around; *why* are you looking to remove people? What 
is the problem you are trying to solve here? How will removing someone 
from the PMC/committer list help address the issues you are facing?

> 
> Sincerely,
> Dmitriy Pavlov

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

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

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

On Sun, Mar 3, 2019 at 9:58 PM Craig Russell <ap...@gmail.com> wrote:

> Hi Greg,
>
> > On Mar 3, 2019, at 6:15 PM, Greg Stein <gs...@gmail.com> wrote:
> >
> > Acts of the Foundation require specific oversight of the IPMC. To
> establish
> > that "act", we have the (3) +1 vote rule of IPMC members. The IPMC cannot
> > delegate this power further, as each IPMC member is specifically
> empowered
> > by the Board. So PPMC members cannot act for the Foundation since they
> > haven't been empowered by the Board.
> >
> > Again, the above is premised on *needing* that particular empowerment. If
> > podling releases are no longer required to be official, then quite a bit
> > can be changed.
> >
> I believe that this would be a disaster. I choose this word carefully.
>
> In your proposal, would podlings' bad releases use the official Apache
> distribution mechanisms? dist.apache.org, signatures, checksums and the
> mirror systems and KEYS and such?
>

No idea. I believe that a lot of the current issue, bureaucracy, and
drive-by are related making "releases" ASF-compliant.

Yet I seem to recall a time when these releases could have mistakes. These
are podlings, after all. It is expected. It will get fixed next time.

So I think a major problem to solve is "making non-official releases", and
to your point: how to differentiate those from "official releases".

Cheers,
-g

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

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

Hi -

Jumping in here although some points may be repetitive. (This turned into quite a diatribe, apologies.)

TL/DR - I believe we need to revamp our workflows and record keeping to better serve podlings and we need to teardown much of our website content as it is duplicative of the authoritative foundation documentation.

> On Mar 3, 2019, at 10:50 PM, Ross Gardler <ro...@gardler.me> wrote:
> 
> That's right Greg. And since we are filling in gaps for people...
> 
> I was originally against the pTLP concept (though I supported the experiments) or any of the derivatives that came from it. I think I have changed my position. Largely based on the fact that every single project I've discussed the ASF with in the last 3-5 years has had a very inaccurate perception of how the ASF works. I believe a large part of this is due, in part, to the issues being discussed in this thread.

I’ve spent the last day or so reviewing how the Incubator keeps records, does board reporting and build the website. I’ve looked at the top level and content files and directories in the Incubator SVN. This is quite revealing. Lots of good code and several attempts at various tooling at various times. A lot of it is somewhat broken.

Podling’s requirements and the world of open development has moved on to new tools which are not well captured in the Incubator’s procedures. The website build was mostly moved to GIT a few years ago. The overwhelming majority of podlings use GIT and not SVN. The Apache Whimsy project has added extremely easy UI for seeing and doing some of the administrative process for a podling.

Reporting has become a giant and onerous cat-herding exercise. Those of us with experience with cats know that cats don’t take well to herding. How can the IPMC be of better service? Our record keeping and processing SHOULD know a podling’s status. Much of what was the clutch report is broken. This can be fixed.

Bertrand created INCUBATOR-231Cleanup Git-generated Incubator website [1] where we can discuss how to improve the website and finish the conversion.

> I do not understand how a foundation which prides itself in having very little bureaucratic red tape can be seen as having so much red tape. The projects I talk to just want to build software. It used to be that the ASF focused on running the legal and operational aspects of the foundation projects and developers on projects wrote code. I'm not sure that's true anymore.

True. The Incubator is caring about reports and quick legal perfection at the expense of community development. The documentation is overblown. I think that 16 guides on the Incubator site can be reorganized and reduced. These need to redone to clearly focus on which Foundation committees are authorities that will help podlings on their path.

For example why? https://incubator.apache.org/guides/names.html
When this is authoritative: http://www.apache.org/foundation/marks/naming

> 
> We need to fix it.

Yes, for example why do we have "The Incubator PMC MAY consider the termination of a project for violation of these branding guidelines.” on the bottom of https://incubator.apache.org/guides/branding.html. Why is the Incubator website like the line oriented Adventure73 with dungeon rooms where dwarves appeared and often threw an axe at you?

This is completely unfriendly and unnecessary. I’m in the Incubator to help, I’m not here as the Apache Police. If anyone on a TLP has paid attention to how the Board handles issues then you will know that private nudging is used long before any private hammer is thrown.

> 
> I look forward to hearing how the IPMC will seek to strip down the bureaucracy and get back to mentoring the incoming projects on how the ASF is structured so they can get (relatively) quick and clear answers to their questions.

We need to refactor and justify every single incubator guide. There really aren’t too many requirements that are unique to podlings. And these should be easy to find and understand this is all that the Incubator should provide. Any content that the overall foundation has must be used as is and not duplicated often inaccurately. If anyone has a question about trademarks or a license’s classification then if we know it we can answer but the definitive answer should come from the Apache committee and guidance in email answers should refer to that as well. If you are on the IPMC and are also a license / release expert then join the Legal Committee and Infra’s distribution/release policy volunteers.

The IPMC has tooling (maybe broken) to identify podling releases and could publish on general and undertake a review without the podling even having to ask. With the correct tooling the Mentor can be informed and take the best action based on their understanding of the community to rectify the situation.

Let’s do everything we can to make the Incubator a direct guide to the ASF. We’ve never out and out retired a podling. Let’s cut out all the threats and negativity. If we think that official foundation documents need to be updated then do that and don’t write new guidance!

Regards,
Dave

> 
> Ross
> 

[1] https://issues.apache.org/jira/browse/INCUBATOR-231

> ________________________________________
> From: Greg Stein <gs...@gmail.com>
> Sent: Sunday, March 3, 2019 10:1Let's 9 PM
> To: general@incubator.apache.org
> Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))
> 
> On Sun, Mar 3, 2019 at 10:37 PM Ross Gardler <ro...@gardler.me> wrote:
> 
>> If a podling is a committee in its own right then it can be empowered to
>> act on behalf of the board and this its releases can be an act of the
>> foundation.
>> 
>> ...
> 
>> Podlings would only become full TLPs once they have demonstrated their
>> ability to do formal releases.
>> 
> 
> The above pair of concepts was offered in $priorCycle as "provisional TLPs"
> (pTLP). I believe the idea ended when Sam pointed out that if a pTLP is
> trusted, then why not just call it a TLP and trust it to label its releases
> appropriately? Thus, just create TLPs immediately for a "podling"
> 
> [ I know Ross knows this; but for $others who may want to look at
> historical proposals, and compare/contrast to current discussion ... search
> for "pTLP" ]
> 
> Cheers,
> -g
> 
> ---------------------------------------------------------------------
> 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: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

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

Projects are free to set their own bylaws. As long as the community as a whole agree to removal of inactive members then they can do that. Though merit does not and should not expire.

It is my opinion, and the opinion of many others, that keeping busy work to a minimum is important to the health of a community. Removing inactive committers is busy work. If they come back in x months and provide new patches, bringing them back as committers is busy work. If their commit bit remains active but they never commit again is not busy work.

Note, at the foundation level a committer remains recognized (their apache.org account remains active, for example).

Ross

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Dmitriy Pavlov <dp...@apache.org>
Sent: Wednesday, March 6, 2019 12:08:49 PM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

Hi Ross,

Thank you for your reply. Apache Ignite PMCs do not support this idea, so
inactive PMCs will be still there.

But still, it is not clear for me in general, why following
projects/guidelines contains removal procedure for Committer PMC:
- https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmnemonic.apache.org%2Fdevelop%2Fbylaws%2F&amp;data=02%7C01%7C%7C14e66a1b43ae48f9db8f08d6a26f939d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636874997434876585&amp;sdata=qq8L7D0w7Au6yursya5M%2BEVHEDbSMQqVMTYQ1hAEFYk%3D&amp;reserved=0  after 6 months of inactivity
both PMC and Committer status may be removed.
- Default Incubator guidelines
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.apache.org%2Fincubator%2FDefaultProjectGuidelines&amp;data=02%7C01%7C%7C14e66a1b43ae48f9db8f08d6a26f939d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636874997434876585&amp;sdata=ctQ%2BmlgRbSXVYe5tEQdUhLSZIugzYgVZiPw5nYPna%2FI%3D&amp;reserved=0 It contains
procedures of consensus-based removal, - it is ok to remove for Incubator?
is it ok for TLP?

If both PMC & Committer roles are merit-based, and merit does not expire,
how it even possible to remove TLP committer/PMC (excepting some extreme
cases)?

This question is not only mine, but it is also often asked and I would like
to know the answer.

Sincerely,
Dmitriy Pavlov

ср, 6 мар. 2019 г. в 18:47, Ross Gardler <rg...@outlook.com>:

> Merit does not expire. People who are not active today should be able to
> become active tomorrow without having to jump through approval hoops.
>
> In projects there is no concept of emeritus PMC. Here in the IPMC the
> issue is very different. Most people earn merit transitively - become a
> member, become a mentor, become an IPMC member. It's different.
>
> Please don't use what is being discussed here as being transitive to a PMC
> based entirely on directly earned merit.
>
> Get Outlook for Android<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fghei36&amp;data=02%7C01%7C%7C14e66a1b43ae48f9db8f08d6a26f939d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636874997434876585&amp;sdata=E4BNgsdPokj3UCHZlKdjP60qXF7SZAybTN6gLWUVN9s%3D&amp;reserved=0>
>
> ________________________________
> From: Dmitriy Pavlov <dp...@apache.org>
> Sent: Tuesday, March 5, 2019 4:46:09 AM
> To: general@incubator.apache.org
> Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy
> general@ subs check (was: .... introduce "[DISCUSS]" threads for podling
> ... release candidates))
>
> I absolutely agree with Greg Stein. I can't find any single reason to keep
> unsubscribed members of IPMC in the roster. These members can be asked to
> subscribe, and if they do, then ok; if don't - it is perfectly ok to
> remove.
>
> Similarly, I don't see reasons for having inactive TLP PMC members. I've
> suggested the same change in Apache Ignite, but I don't clearly understand
> why remained members resisting this change.
>
>
> пн, 4 мар. 2019 г. в 09:58, Ross Gardler <ro...@gardler.me>:
>
> > That's right Greg. And since we are filling in gaps for people...
> >
> > I was originally against the pTLP concept (though I supported the
> > experiments) or any of the derivatives that came from it. I think I have
> > changed my position. Largely based on the fact that every single project
> > I've discussed the ASF with in the last 3-5 years has had a very
> inaccurate
> > perception of how the ASF works. I believe a large part of this is due,
> in
> > part, to the issues being discussed in this thread.
> >
> > I do not understand how a foundation which prides itself in having very
> > little bureaucratic red tape can be seen as having so much red tape. The
> > projects I talk to just want to build software. It used to be that the
> ASF
> > focused on running the legal and operational aspects of the foundation
> > projects and developers on projects wrote code. I'm not sure that's true
> > anymore.
> >
> > We need to fix it.
> >
> > I look forward to hearing how the IPMC will seek to strip down the
> > bureaucracy and get back to mentoring the incoming projects on how the
> ASF
> > is structured so they can get (relatively) quick and clear answers to
> their
> > questions.
> >
> > Ross
> >
> > ________________________________________
> > From: Greg Stein <gs...@gmail.com>
> > Sent: Sunday, March 3, 2019 10:19 PM
> > To: general@incubator.apache.org
> > Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy
> > general@ subs check (was: .... introduce "[DISCUSS]" threads for podling
> > ... release candidates))
> >
> > On Sun, Mar 3, 2019 at 10:37 PM Ross Gardler <ro...@gardler.me> wrote:
> >
> > > If a podling is a committee in its own right then it can be empowered
> to
> > > act on behalf of the board and this its releases can be an act of the
> > > foundation.
> > >
> > >...
> >
> > > Podlings would only become full TLPs once they have demonstrated their
> > > ability to do formal releases.
> > >
> >
> > The above pair of concepts was offered in $priorCycle as "provisional
> TLPs"
> > (pTLP). I believe the idea ended when Sam pointed out that if a pTLP is
> > trusted, then why not just call it a TLP and trust it to label its
> releases
> > appropriately? Thus, just create TLPs immediately for a "podling"
> >
> > [ I know Ross knows this; but for $others who may want to look at
> > historical proposals, and compare/contrast to current discussion ...
> search
> > for "pTLP" ]
> >
> > Cheers,
> > -g
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

[Dmitriy Pavlov <dp...@apache.org>]

Hi Ross,

Thank you for your reply. Apache Ignite PMCs do not support this idea, so
inactive PMCs will be still there.

But still, it is not clear for me in general, why following
projects/guidelines contains removal procedure for Committer PMC:
- https://mnemonic.apache.org/develop/bylaws/  after 6 months of inactivity
both PMC and Committer status may be removed.
- Default Incubator guidelines
https://wiki.apache.org/incubator/DefaultProjectGuidelines It contains
procedures of consensus-based removal, - it is ok to remove for Incubator?
is it ok for TLP?

If both PMC & Committer roles are merit-based, and merit does not expire,
how it even possible to remove TLP committer/PMC (excepting some extreme
cases)?

This question is not only mine, but it is also often asked and I would like
to know the answer.

Sincerely,
Dmitriy Pavlov

ср, 6 мар. 2019 г. в 18:47, Ross Gardler <rg...@outlook.com>:

> Merit does not expire. People who are not active today should be able to
> become active tomorrow without having to jump through approval hoops.
>
> In projects there is no concept of emeritus PMC. Here in the IPMC the
> issue is very different. Most people earn merit transitively - become a
> member, become a mentor, become an IPMC member. It's different.
>
> Please don't use what is being discussed here as being transitive to a PMC
> based entirely on directly earned merit.
>
> Get Outlook for Android<https://aka.ms/ghei36>
>
> ________________________________
> From: Dmitriy Pavlov <dp...@apache.org>
> Sent: Tuesday, March 5, 2019 4:46:09 AM
> To: general@incubator.apache.org
> Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy
> general@ subs check (was: .... introduce "[DISCUSS]" threads for podling
> ... release candidates))
>
> I absolutely agree with Greg Stein. I can't find any single reason to keep
> unsubscribed members of IPMC in the roster. These members can be asked to
> subscribe, and if they do, then ok; if don't - it is perfectly ok to
> remove.
>
> Similarly, I don't see reasons for having inactive TLP PMC members. I've
> suggested the same change in Apache Ignite, but I don't clearly understand
> why remained members resisting this change.
>
>
> пн, 4 мар. 2019 г. в 09:58, Ross Gardler <ro...@gardler.me>:
>
> > That's right Greg. And since we are filling in gaps for people...
> >
> > I was originally against the pTLP concept (though I supported the
> > experiments) or any of the derivatives that came from it. I think I have
> > changed my position. Largely based on the fact that every single project
> > I've discussed the ASF with in the last 3-5 years has had a very
> inaccurate
> > perception of how the ASF works. I believe a large part of this is due,
> in
> > part, to the issues being discussed in this thread.
> >
> > I do not understand how a foundation which prides itself in having very
> > little bureaucratic red tape can be seen as having so much red tape. The
> > projects I talk to just want to build software. It used to be that the
> ASF
> > focused on running the legal and operational aspects of the foundation
> > projects and developers on projects wrote code. I'm not sure that's true
> > anymore.
> >
> > We need to fix it.
> >
> > I look forward to hearing how the IPMC will seek to strip down the
> > bureaucracy and get back to mentoring the incoming projects on how the
> ASF
> > is structured so they can get (relatively) quick and clear answers to
> their
> > questions.
> >
> > Ross
> >
> > ________________________________________
> > From: Greg Stein <gs...@gmail.com>
> > Sent: Sunday, March 3, 2019 10:19 PM
> > To: general@incubator.apache.org
> > Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy
> > general@ subs check (was: .... introduce "[DISCUSS]" threads for podling
> > ... release candidates))
> >
> > On Sun, Mar 3, 2019 at 10:37 PM Ross Gardler <ro...@gardler.me> wrote:
> >
> > > If a podling is a committee in its own right then it can be empowered
> to
> > > act on behalf of the board and this its releases can be an act of the
> > > foundation.
> > >
> > >...
> >
> > > Podlings would only become full TLPs once they have demonstrated their
> > > ability to do formal releases.
> > >
> >
> > The above pair of concepts was offered in $priorCycle as "provisional
> TLPs"
> > (pTLP). I believe the idea ended when Sam pointed out that if a pTLP is
> > trusted, then why not just call it a TLP and trust it to label its
> releases
> > appropriately? Thus, just create TLPs immediately for a "podling"
> >
> > [ I know Ross knows this; but for $others who may want to look at
> > historical proposals, and compare/contrast to current discussion ...
> search
> > for "pTLP" ]
> >
> > Cheers,
> > -g
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

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

Merit does not expire. People who are not active today should be able to become active tomorrow without having to jump through approval hoops.

In projects there is no concept of emeritus PMC. Here in the IPMC the issue is very different. Most people earn merit transitively - become a member, become a mentor, become an IPMC member. It's different.

Please don't use what is being discussed here as being transitive to a PMC based entirely on directly earned merit.

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Dmitriy Pavlov <dp...@apache.org>
Sent: Tuesday, March 5, 2019 4:46:09 AM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

I absolutely agree with Greg Stein. I can't find any single reason to keep
unsubscribed members of IPMC in the roster. These members can be asked to
subscribe, and if they do, then ok; if don't - it is perfectly ok to remove.

Similarly, I don't see reasons for having inactive TLP PMC members. I've
suggested the same change in Apache Ignite, but I don't clearly understand
why remained members resisting this change.


пн, 4 мар. 2019 г. в 09:58, Ross Gardler <ro...@gardler.me>:

> That's right Greg. And since we are filling in gaps for people...
>
> I was originally against the pTLP concept (though I supported the
> experiments) or any of the derivatives that came from it. I think I have
> changed my position. Largely based on the fact that every single project
> I've discussed the ASF with in the last 3-5 years has had a very inaccurate
> perception of how the ASF works. I believe a large part of this is due, in
> part, to the issues being discussed in this thread.
>
> I do not understand how a foundation which prides itself in having very
> little bureaucratic red tape can be seen as having so much red tape. The
> projects I talk to just want to build software. It used to be that the ASF
> focused on running the legal and operational aspects of the foundation
> projects and developers on projects wrote code. I'm not sure that's true
> anymore.
>
> We need to fix it.
>
> I look forward to hearing how the IPMC will seek to strip down the
> bureaucracy and get back to mentoring the incoming projects on how the ASF
> is structured so they can get (relatively) quick and clear answers to their
> questions.
>
> Ross
>
> ________________________________________
> From: Greg Stein <gs...@gmail.com>
> Sent: Sunday, March 3, 2019 10:19 PM
> To: general@incubator.apache.org
> Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy
> general@ subs check (was: .... introduce "[DISCUSS]" threads for podling
> ... release candidates))
>
> On Sun, Mar 3, 2019 at 10:37 PM Ross Gardler <ro...@gardler.me> wrote:
>
> > If a podling is a committee in its own right then it can be empowered to
> > act on behalf of the board and this its releases can be an act of the
> > foundation.
> >
> >...
>
> > Podlings would only become full TLPs once they have demonstrated their
> > ability to do formal releases.
> >
>
> The above pair of concepts was offered in $priorCycle as "provisional TLPs"
> (pTLP). I believe the idea ended when Sam pointed out that if a pTLP is
> trusted, then why not just call it a TLP and trust it to label its releases
> appropriately? Thus, just create TLPs immediately for a "podling"
>
> [ I know Ross knows this; but for $others who may want to look at
> historical proposals, and compare/contrast to current discussion ... search
> for "pTLP" ]
>
> Cheers,
> -g
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

[Dmitriy Pavlov <dp...@apache.org>]

I absolutely agree with Greg Stein. I can't find any single reason to keep
unsubscribed members of IPMC in the roster. These members can be asked to
subscribe, and if they do, then ok; if don't - it is perfectly ok to remove.

Similarly, I don't see reasons for having inactive TLP PMC members. I've
suggested the same change in Apache Ignite, but I don't clearly understand
why remained members resisting this change.


пн, 4 мар. 2019 г. в 09:58, Ross Gardler <ro...@gardler.me>:

> That's right Greg. And since we are filling in gaps for people...
>
> I was originally against the pTLP concept (though I supported the
> experiments) or any of the derivatives that came from it. I think I have
> changed my position. Largely based on the fact that every single project
> I've discussed the ASF with in the last 3-5 years has had a very inaccurate
> perception of how the ASF works. I believe a large part of this is due, in
> part, to the issues being discussed in this thread.
>
> I do not understand how a foundation which prides itself in having very
> little bureaucratic red tape can be seen as having so much red tape. The
> projects I talk to just want to build software. It used to be that the ASF
> focused on running the legal and operational aspects of the foundation
> projects and developers on projects wrote code. I'm not sure that's true
> anymore.
>
> We need to fix it.
>
> I look forward to hearing how the IPMC will seek to strip down the
> bureaucracy and get back to mentoring the incoming projects on how the ASF
> is structured so they can get (relatively) quick and clear answers to their
> questions.
>
> Ross
>
> ________________________________________
> From: Greg Stein <gs...@gmail.com>
> Sent: Sunday, March 3, 2019 10:19 PM
> To: general@incubator.apache.org
> Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy
> general@ subs check (was: .... introduce "[DISCUSS]" threads for podling
> ... release candidates))
>
> On Sun, Mar 3, 2019 at 10:37 PM Ross Gardler <ro...@gardler.me> wrote:
>
> > If a podling is a committee in its own right then it can be empowered to
> > act on behalf of the board and this its releases can be an act of the
> > foundation.
> >
> >...
>
> > Podlings would only become full TLPs once they have demonstrated their
> > ability to do formal releases.
> >
>
> The above pair of concepts was offered in $priorCycle as "provisional TLPs"
> (pTLP). I believe the idea ended when Sam pointed out that if a pTLP is
> trusted, then why not just call it a TLP and trust it to label its releases
> appropriately? Thus, just create TLPs immediately for a "podling"
>
> [ I know Ross knows this; but for $others who may want to look at
> historical proposals, and compare/contrast to current discussion ... search
> for "pTLP" ]
>
> Cheers,
> -g
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

[Ross Gardler <ro...@gardler.me>]

That's right Greg. And since we are filling in gaps for people...

I was originally against the pTLP concept (though I supported the experiments) or any of the derivatives that came from it. I think I have changed my position. Largely based on the fact that every single project I've discussed the ASF with in the last 3-5 years has had a very inaccurate perception of how the ASF works. I believe a large part of this is due, in part, to the issues being discussed in this thread.

I do not understand how a foundation which prides itself in having very little bureaucratic red tape can be seen as having so much red tape. The projects I talk to just want to build software. It used to be that the ASF focused on running the legal and operational aspects of the foundation projects and developers on projects wrote code. I'm not sure that's true anymore.

We need to fix it.

I look forward to hearing how the IPMC will seek to strip down the bureaucracy and get back to mentoring the incoming projects on how the ASF is structured so they can get (relatively) quick and clear answers to their questions.

Ross

________________________________________
From: Greg Stein <gs...@gmail.com>
Sent: Sunday, March 3, 2019 10:19 PM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

On Sun, Mar 3, 2019 at 10:37 PM Ross Gardler <ro...@gardler.me> wrote:

> If a podling is a committee in its own right then it can be empowered to
> act on behalf of the board and this its releases can be an act of the
> foundation.
>
>...

> Podlings would only become full TLPs once they have demonstrated their
> ability to do formal releases.
>

The above pair of concepts was offered in $priorCycle as "provisional TLPs"
(pTLP). I believe the idea ended when Sam pointed out that if a pTLP is
trusted, then why not just call it a TLP and trust it to label its releases
appropriately? Thus, just create TLPs immediately for a "podling"

[ I know Ross knows this; but for $others who may want to look at
historical proposals, and compare/contrast to current discussion ... search
for "pTLP" ]

Cheers,
-g

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

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

[Danny Angus <da...@gmail.com>]

+1
If we trust mentors to ensure that their podling does the right thing as a
board committee this basically *is* a TLP and we wouldn't need an IPMC, but
if podlings need an IPMC then that must be because we allow for the
podlings to make missteps without bringing down the hammer.

Seems to me that simply explaining and teaching the principles that we are
upholding, the purpose of the roles, and the reasons why we chose this
mechanism to induct external projects would go a long way towards most of
the specific points I have seen raised so far.


D.

On Mon, 4 Mar 2019, 6:19 am Greg Stein, <gs...@gmail.com> wrote:

> On Sun, Mar 3, 2019 at 10:37 PM Ross Gardler <ro...@gardler.me> wrote:
>
> > If a podling is a committee in its own right then it can be empowered to
> > act on behalf of the board and this its releases can be an act of the
> > foundation.
> >
> >...
>
> > Podlings would only become full TLPs once they have demonstrated their
> > ability to do formal releases.
> >
>
> The above pair of concepts was offered in $priorCycle as "provisional TLPs"
> (pTLP). I believe the idea ended when Sam pointed out that if a pTLP is
> trusted, then why not just call it a TLP and trust it to label its releases
> appropriately? Thus, just create TLPs immediately for a "podling"
>
> [ I know Ross knows this; but for $others who may want to look at
> historical proposals, and compare/contrast to current discussion ... search
> for "pTLP" ]
>
> Cheers,
> -g
>

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

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

On Sun, Mar 3, 2019 at 10:37 PM Ross Gardler <ro...@gardler.me> wrote:

> If a podling is a committee in its own right then it can be empowered to
> act on behalf of the board and this its releases can be an act of the
> foundation.
>
>...

> Podlings would only become full TLPs once they have demonstrated their
> ability to do formal releases.
>

The above pair of concepts was offered in $priorCycle as "provisional TLPs"
(pTLP). I believe the idea ended when Sam pointed out that if a pTLP is
trusted, then why not just call it a TLP and trust it to label its releases
appropriately? Thus, just create TLPs immediately for a "podling"

[ I know Ross knows this; but for $others who may want to look at
historical proposals, and compare/contrast to current discussion ... search
for "pTLP" ]

Cheers,
-g

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

[Ross Gardler <ro...@gardler.me>]

If a podling is a committee in its own right then it can be empowered to act on behalf of the board and this its releases can be an act of the foundation.

We already have a good set of practices around marking incubator projects and their releases.

This is dependent upon the project participants being knowledgeable about how to do a legally compliant release. Mentors help with this and we have a legal committee far better versed in answering specific questions that mentors are unable to address.

Podlings would only become full TLPs once they have demonstrated their ability to do formal releases.

Ross

________________________________________
From: Craig Russell <ap...@gmail.com>
Sent: Sunday, March 3, 2019 7:48 PM
To: Incubator
Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

Hi Greg,

> On Mar 3, 2019, at 6:15 PM, Greg Stein <gs...@gmail.com> wrote:
>
> Acts of the Foundation require specific oversight of the IPMC. To establish
> that "act", we have the (3) +1 vote rule of IPMC members. The IPMC cannot
> delegate this power further, as each IPMC member is specifically empowered
> by the Board. So PPMC members cannot act for the Foundation since they
> haven't been empowered by the Board.
>
> Again, the above is premised on *needing* that particular empowerment. If
> podling releases are no longer required to be official, then quite a bit
> can be changed.
>
I believe that this would be a disaster. I choose this word carefully.

In your proposal, would podlings' bad releases use the official Apache distribution mechanisms? dist.apache.org, signatures, checksums and the mirror systems and KEYS and such?

If so, then we need to modify Apache policy since forever, that in order to be An Act Of The Foundation, a board-delegated authority (currently the IPMC) must vote and approve the release.

If not, then we are teaching podlings nothing about official Apache Releases.

Craig

Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org <ma...@apache.org> https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdb.apache.org%2Fjdo&amp;data=02%7C01%7C%7C8f0ef556c8444479d86908d6a055b63c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636872687314777901&amp;sdata=B8U4hhYvv4cCT8ccNb2OKWGPJY3e8I1XW9NmsUHyl%2FU%3D&amp;reserved=0 <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdb.apache.org%2Fjdo&amp;data=02%7C01%7C%7C8f0ef556c8444479d86908d6a055b63c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636872687314787906&amp;sdata=bXt1jFmZTWyRJ%2B1tPmxCAXolJRUG8VGLhg9lAk0w4Oo%3D&amp;reserved=0>

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

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

[Craig Russell <ap...@gmail.com>]

Hi Greg,

> On Mar 3, 2019, at 6:15 PM, Greg Stein <gs...@gmail.com> wrote:
> 
> Acts of the Foundation require specific oversight of the IPMC. To establish
> that "act", we have the (3) +1 vote rule of IPMC members. The IPMC cannot
> delegate this power further, as each IPMC member is specifically empowered
> by the Board. So PPMC members cannot act for the Foundation since they
> haven't been empowered by the Board.
> 
> Again, the above is premised on *needing* that particular empowerment. If
> podling releases are no longer required to be official, then quite a bit
> can be changed.
> 
I believe that this would be a disaster. I choose this word carefully.

In your proposal, would podlings' bad releases use the official Apache distribution mechanisms? dist.apache.org, signatures, checksums and the mirror systems and KEYS and such?

If so, then we need to modify Apache policy since forever, that in order to be An Act Of The Foundation, a board-delegated authority (currently the IPMC) must vote and approve the release.

If not, then we are teaching podlings nothing about official Apache Releases.

Craig

Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <http://db.apache.org/jdo>

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

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

On Sun, Mar 3, 2019 at 1:27 PM Thomas Weise <th...@apache.org> wrote:

> Currently mentors need to be IPMC members. Is that really necessary?
>

Yes and no. :-)

If mentors are going to vote on *official releases* (and we skip the extra
layer of IPMC voting), then (3) mentors must be on the IPMC to make the
vote/release an act of the Foundation.

Now, note the caveats:
* maybe a podling releases some code, but it isn't an "official ASF
release", and (thus) can skip past the Foundation's release
policies/guidelines. mentors would not have to be on the IPMC since we
don't need the chain of responsibility.
* maybe the mentors are not on the IPMC, so when the podling puts together
an official release candidates, then the IPMC votes to make it official.
again, mentors don't have to be on the IPMC.

But if you want a podling to straight up make an official ASF release, and
you want a single vote (rather than the two layers we've been doing), then
the Mentors should probably be on the IPMC.

Alternatively mentors could be given all required powers through the PPMC
> membership


Acts of the Foundation require specific oversight of the IPMC. To establish
that "act", we have the (3) +1 vote rule of IPMC members. The IPMC cannot
delegate this power further, as each IPMC member is specifically empowered
by the Board. So PPMC members cannot act for the Foundation since they
haven't been empowered by the Board.

Again, the above is premised on *needing* that particular empowerment. If
podling releases are no longer required to be official, then quite a bit
can be changed.

>...

> Mentors that are active over a long time and show interest in the overall
> direction of the incubator, could become IPMC candidates. That would be
> similar to how TLPs consider PMC membership.
>

Yup, that's how it operates today, with a special case for ASF Members on
the assumption that the Member already have merit and know what they're
doing. That assumption could be removed, and the IPMC could switch to a
pure-merit model.

Cheers,
-g

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

[Thomas Weise <th...@apache.org>]

Currently mentors need to be IPMC members. Is that really necessary?
Alternatively mentors could be given all required powers through the PPMC
membership and the IPMC could be more focused on long term direction and
improving the incubator as a whole. IPMC already votes on incubator
proposals and nominated mentors. IPMC could take more of an observer role
and only intervene when there is clearly something wrong with a podling
(similar how the board would with a TLP). Podling reports and graduation
proposal provide the opportunity to catch everything that mentors might
have missed.

Mentors that are active over a long time and show interest in the overall
direction of the incubator, could become IPMC candidates. That would be
similar to how TLPs consider PMC membership.

Thomas

On Sun, Mar 3, 2019 at 12:13 AM Alex Harui <ah...@adobe.com.invalid> wrote:

> As a peanut, IMO, it could be that the root problem is that the drive-by
> folks are discussing topics that are too subjective at a critical time (to
> get a release out), not the number of folks who can drive-by.  I'm not even
> in the IPMC, and I can still follow general@ and offer opinions.
>
> Podlings would have their lives improved if there were more folks
> available to help in little increments if the help was consistent.  It
> would be a stronger community if more people could help pound a nail or fix
> a flat tire.  It would take the load off the folks in charge.  More people
> would get more done with less burnout.
>
> In some ways, Roy's suggestion to stop having an IPMC vote as a gate for a
> podling release can help by making it less critical to get someone official
> to rule on something "now".  Just ship it, note it in the bug tracker, and
> get to it when you can find someone to help you or take your time resolving
> it, gathering different opinions and coming up with a solution, even a
> temporary one.  Not all issues need to be addressed before graduation,
> IMO.  Some issues just aren't stop-ship and won't ruin the legal shield or
> put the ASF in legal jeopardy.  Policy issues are not always legal issues.
> In fact, I think most aren't.
>
> Maybe we should try to reduce subjectivity by getting more consensus on
> what issues are really important and which ones aren't.  That might get
> more consistency from the drive-bys.  But some of these issues are
> judgement calls and folks will have different opinions and podlings might
> be better served by being advised to get second opinions.
>
> Reducing the number of volunteers and holding them to a higher standard
> seems anti-volunteer.  It is why I've never asked to join the IPMC.   I can
> pound a nail and fix a flat tire, though.  Finding ways to reduce the size
> of the tasks and requirements on the timing seems like it would attract
> more volunteers and be more helpful.  Instead of having to review an entire
> release in order to cast a binding vote on it, maybe I could spend 5
> minutes to just run RAT on it and if it finds a binary, open a ticket
> asking why.
>
> HTH,
> -Alex
>
> On 3/2/19, 3:55 AM, "Greg Stein" <gs...@gmail.com> wrote:
>
>     On Sat, Mar 2, 2019 at 5:17 AM sebb <se...@gmail.com> wrote:
>
>     > On Sat, 2 Mar 2019 at 10:49, Greg Stein <gs...@gmail.com> wrote:
>     > >
>     > > On Sat, Mar 2, 2019 at 2:50 AM sebb <se...@gmail.com> wrote:
>     > >
>     > > > On Sat, 2 Mar 2019 at 03:45, Justin Mclean <
> justin@classsoftware.com>
>     > > > wrote:
>     > > > >
>     > > > > Hi,
>     > > > >
>     > > > > > I agree that it's not ideal but it is not a symptom of a big
>     > problem
>     > > > either. We have inactive IPMC members who might become active
> again
>     > later
>     > > > if a community wants to join the incubator but it's a hassle to
> leave
>     > and
>     > > > then join again.
>     > > > >
>     > > > > Some context, over 300 projects have gone through the
> incubator, 50
>     > are
>     > > > there currently, each requires a champion and 3 mentors at the
> start
>     > (all
>     > > > IPMC members), even with some mentors working on multiple
> podling it's
>     > not
>     > > > surprising the IPMC is 300 people or so. Nor should it be that a
> large
>     > > > number of them are inactive as most of the projects they were
> involved
>     > in
>     > > > have graduated (or retired).
>     > > >
>     > > > +1
>     > > >
>     > > > > But despite this some still think it is an issue so we IMO we
> should
>     > > > address it, unless they change their minds, and say so here.
>     > > >
>     > > > Personally, I don't think that is a reason to reduce the IPMC
> count.
>     > > > I think it needs to be established WHY it is thought to be an
> issue
>     > first.
>     > > >
>     > >
>     > > It encourages drive-by bikeshedding. "I'm an IPMC Member from a
> few years
>     > > back. I see $foo, and OMG need to comment on it."
>     > >
>     > > Did anybody stop and read the concerns recently raised to the
> Board? Much
>     > > of the focus on that email was about such drive-by commenting.
>     > >
>     > > Thus, reduce the opportunity for drive-by.
>     >
>     > Since the general@ list is public, I don't think reducing the IPMC
>     > will stop comments.
>     >
>
>     So? It is to reduce the number of people who feel empowered to meddle
> into
>     everything every podling does. You want to fix general@ ??, then go
> ahead.
>     I want to see people who choose not to *participate* in the IPMC [by
>     subscribing to private@] dropped from the roster. The whole world can
> chat
>     on general@. But if you want to be *part* of the IPMC, and want a
> binding
>     vote, and want to really throw-in on Incubator matters, then you damned
>     well better subscribe.
>
>     The basic structure of 200+ people all having "merit" to jump into a
>     podling's pond is a priori broken. We have *specific* feedback that
> this is
>     true. Not a guess. Not some survey. A "letter" signed by numerous
>     individuals that this is the case. So until the Incubator decides its
> basic
>     structure is Wrong(tm), and stops pushing back against that feedback,
> then
>     what is a simple reversible change to try and disempower the
> knuckleheads
>     who want to throw in, on the good work done by our podlings? ... Right.
>     Trim the IPMC.
>
>     -g
>
>
>

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

[Alex Harui <ah...@adobe.com.INVALID>]

As a peanut, IMO, it could be that the root problem is that the drive-by folks are discussing topics that are too subjective at a critical time (to get a release out), not the number of folks who can drive-by.  I'm not even in the IPMC, and I can still follow general@ and offer opinions.

Podlings would have their lives improved if there were more folks available to help in little increments if the help was consistent.  It would be a stronger community if more people could help pound a nail or fix a flat tire.  It would take the load off the folks in charge.  More people would get more done with less burnout.

In some ways, Roy's suggestion to stop having an IPMC vote as a gate for a podling release can help by making it less critical to get someone official to rule on something "now".  Just ship it, note it in the bug tracker, and get to it when you can find someone to help you or take your time resolving it, gathering different opinions and coming up with a solution, even a temporary one.  Not all issues need to be addressed before graduation, IMO.  Some issues just aren't stop-ship and won't ruin the legal shield or put the ASF in legal jeopardy.  Policy issues are not always legal issues.  In fact, I think most aren't.

Maybe we should try to reduce subjectivity by getting more consensus on what issues are really important and which ones aren't.  That might get more consistency from the drive-bys.  But some of these issues are judgement calls and folks will have different opinions and podlings might be better served by being advised to get second opinions.

Reducing the number of volunteers and holding them to a higher standard seems anti-volunteer.  It is why I've never asked to join the IPMC.   I can pound a nail and fix a flat tire, though.  Finding ways to reduce the size of the tasks and requirements on the timing seems like it would attract more volunteers and be more helpful.  Instead of having to review an entire release in order to cast a binding vote on it, maybe I could spend 5 minutes to just run RAT on it and if it finds a binary, open a ticket asking why.

HTH,
-Alex

On 3/2/19, 3:55 AM, "Greg Stein" <gs...@gmail.com> wrote:

    On Sat, Mar 2, 2019 at 5:17 AM sebb <se...@gmail.com> wrote:
    
    > On Sat, 2 Mar 2019 at 10:49, Greg Stein <gs...@gmail.com> wrote:
    > >
    > > On Sat, Mar 2, 2019 at 2:50 AM sebb <se...@gmail.com> wrote:
    > >
    > > > On Sat, 2 Mar 2019 at 03:45, Justin Mclean <ju...@classsoftware.com>
    > > > wrote:
    > > > >
    > > > > Hi,
    > > > >
    > > > > > I agree that it's not ideal but it is not a symptom of a big
    > problem
    > > > either. We have inactive IPMC members who might become active again
    > later
    > > > if a community wants to join the incubator but it's a hassle to leave
    > and
    > > > then join again.
    > > > >
    > > > > Some context, over 300 projects have gone through the incubator, 50
    > are
    > > > there currently, each requires a champion and 3 mentors at the start
    > (all
    > > > IPMC members), even with some mentors working on multiple podling it's
    > not
    > > > surprising the IPMC is 300 people or so. Nor should it be that a large
    > > > number of them are inactive as most of the projects they were involved
    > in
    > > > have graduated (or retired).
    > > >
    > > > +1
    > > >
    > > > > But despite this some still think it is an issue so we IMO we should
    > > > address it, unless they change their minds, and say so here.
    > > >
    > > > Personally, I don't think that is a reason to reduce the IPMC count.
    > > > I think it needs to be established WHY it is thought to be an issue
    > first.
    > > >
    > >
    > > It encourages drive-by bikeshedding. "I'm an IPMC Member from a few years
    > > back. I see $foo, and OMG need to comment on it."
    > >
    > > Did anybody stop and read the concerns recently raised to the Board? Much
    > > of the focus on that email was about such drive-by commenting.
    > >
    > > Thus, reduce the opportunity for drive-by.
    >
    > Since the general@ list is public, I don't think reducing the IPMC
    > will stop comments.
    >
    
    So? It is to reduce the number of people who feel empowered to meddle into
    everything every podling does. You want to fix general@ ??, then go ahead.
    I want to see people who choose not to *participate* in the IPMC [by
    subscribing to private@] dropped from the roster. The whole world can chat
    on general@. But if you want to be *part* of the IPMC, and want a binding
    vote, and want to really throw-in on Incubator matters, then you damned
    well better subscribe.
    
    The basic structure of 200+ people all having "merit" to jump into a
    podling's pond is a priori broken. We have *specific* feedback that this is
    true. Not a guess. Not some survey. A "letter" signed by numerous
    individuals that this is the case. So until the Incubator decides its basic
    structure is Wrong(tm), and stops pushing back against that feedback, then
    what is a simple reversible change to try and disempower the knuckleheads
    who want to throw in, on the good work done by our podlings? ... Right.
    Trim the IPMC.
    
    -g
    

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

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

On Sat, Mar 2, 2019 at 5:17 AM sebb <se...@gmail.com> wrote:

> On Sat, 2 Mar 2019 at 10:49, Greg Stein <gs...@gmail.com> wrote:
> >
> > On Sat, Mar 2, 2019 at 2:50 AM sebb <se...@gmail.com> wrote:
> >
> > > On Sat, 2 Mar 2019 at 03:45, Justin Mclean <ju...@classsoftware.com>
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > > I agree that it's not ideal but it is not a symptom of a big
> problem
> > > either. We have inactive IPMC members who might become active again
> later
> > > if a community wants to join the incubator but it's a hassle to leave
> and
> > > then join again.
> > > >
> > > > Some context, over 300 projects have gone through the incubator, 50
> are
> > > there currently, each requires a champion and 3 mentors at the start
> (all
> > > IPMC members), even with some mentors working on multiple podling it's
> not
> > > surprising the IPMC is 300 people or so. Nor should it be that a large
> > > number of them are inactive as most of the projects they were involved
> in
> > > have graduated (or retired).
> > >
> > > +1
> > >
> > > > But despite this some still think it is an issue so we IMO we should
> > > address it, unless they change their minds, and say so here.
> > >
> > > Personally, I don't think that is a reason to reduce the IPMC count.
> > > I think it needs to be established WHY it is thought to be an issue
> first.
> > >
> >
> > It encourages drive-by bikeshedding. "I'm an IPMC Member from a few years
> > back. I see $foo, and OMG need to comment on it."
> >
> > Did anybody stop and read the concerns recently raised to the Board? Much
> > of the focus on that email was about such drive-by commenting.
> >
> > Thus, reduce the opportunity for drive-by.
>
> Since the general@ list is public, I don't think reducing the IPMC
> will stop comments.
>

So? It is to reduce the number of people who feel empowered to meddle into
everything every podling does. You want to fix general@ ??, then go ahead.
I want to see people who choose not to *participate* in the IPMC [by
subscribing to private@] dropped from the roster. The whole world can chat
on general@. But if you want to be *part* of the IPMC, and want a binding
vote, and want to really throw-in on Incubator matters, then you damned
well better subscribe.

The basic structure of 200+ people all having "merit" to jump into a
podling's pond is a priori broken. We have *specific* feedback that this is
true. Not a guess. Not some survey. A "letter" signed by numerous
individuals that this is the case. So until the Incubator decides its basic
structure is Wrong(tm), and stops pushing back against that feedback, then
what is a simple reversible change to try and disempower the knuckleheads
who want to throw in, on the good work done by our podlings? ... Right.
Trim the IPMC.

-g

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

[sebb <se...@gmail.com>]

On Sat, 2 Mar 2019 at 10:49, Greg Stein <gs...@gmail.com> wrote:
>
> On Sat, Mar 2, 2019 at 2:50 AM sebb <se...@gmail.com> wrote:
>
> > On Sat, 2 Mar 2019 at 03:45, Justin Mclean <ju...@classsoftware.com>
> > wrote:
> > >
> > > Hi,
> > >
> > > > I agree that it's not ideal but it is not a symptom of a big problem
> > either. We have inactive IPMC members who might become active again later
> > if a community wants to join the incubator but it's a hassle to leave and
> > then join again.
> > >
> > > Some context, over 300 projects have gone through the incubator, 50 are
> > there currently, each requires a champion and 3 mentors at the start (all
> > IPMC members), even with some mentors working on multiple podling it's not
> > surprising the IPMC is 300 people or so. Nor should it be that a large
> > number of them are inactive as most of the projects they were involved in
> > have graduated (or retired).
> >
> > +1
> >
> > > But despite this some still think it is an issue so we IMO we should
> > address it, unless they change their minds, and say so here.
> >
> > Personally, I don't think that is a reason to reduce the IPMC count.
> > I think it needs to be established WHY it is thought to be an issue first.
> >
>
> It encourages drive-by bikeshedding. "I'm an IPMC Member from a few years
> back. I see $foo, and OMG need to comment on it."
>
> Did anybody stop and read the concerns recently raised to the Board? Much
> of the focus on that email was about such drive-by commenting.
>
> Thus, reduce the opportunity for drive-by.

Since the general@ list is public, I don't think reducing the IPMC
will stop comments.

> Please stop making excuses to keep the status quo. That is pretty much
> everything that I've seen since that email.
>
> -g

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

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

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

On Sat, Mar 2, 2019 at 2:50 AM sebb <se...@gmail.com> wrote:

> On Sat, 2 Mar 2019 at 03:45, Justin Mclean <ju...@classsoftware.com>
> wrote:
> >
> > Hi,
> >
> > > I agree that it's not ideal but it is not a symptom of a big problem
> either. We have inactive IPMC members who might become active again later
> if a community wants to join the incubator but it's a hassle to leave and
> then join again.
> >
> > Some context, over 300 projects have gone through the incubator, 50 are
> there currently, each requires a champion and 3 mentors at the start (all
> IPMC members), even with some mentors working on multiple podling it's not
> surprising the IPMC is 300 people or so. Nor should it be that a large
> number of them are inactive as most of the projects they were involved in
> have graduated (or retired).
>
> +1
>
> > But despite this some still think it is an issue so we IMO we should
> address it, unless they change their minds, and say so here.
>
> Personally, I don't think that is a reason to reduce the IPMC count.
> I think it needs to be established WHY it is thought to be an issue first.
>

It encourages drive-by bikeshedding. "I'm an IPMC Member from a few years
back. I see $foo, and OMG need to comment on it."

Did anybody stop and read the concerns recently raised to the Board? Much
of the focus on that email was about such drive-by commenting.

Thus, reduce the opportunity for drive-by.

Please stop making excuses to keep the status quo. That is pretty much
everything that I've seen since that email.

-g

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

[sebb <se...@gmail.com>]

On Sat, 2 Mar 2019 at 03:45, Justin Mclean <ju...@classsoftware.com> wrote:
>
> Hi,
>
> > I agree that it's not ideal but it is not a symptom of a big problem either. We have inactive IPMC members who might become active again later if a community wants to join the incubator but it's a hassle to leave and then join again.
>
> Some context, over 300 projects have gone through the incubator, 50 are there currently, each requires a champion and 3 mentors at the start (all IPMC members), even with some mentors working on multiple podling it's not surprising the IPMC is 300 people or so. Nor should it be that a large number of them are inactive as most of the projects they were involved in have graduated (or retired).

+1

> But despite this some still think it is an issue so we IMO we should address it, unless they change their minds, and say so here.

Personally, I don't think that is a reason to reduce the IPMC count.
I think it needs to be established WHY it is thought to be an issue first.

> Thanks,
> Justin

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

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> I agree that it's not ideal but it is not a symptom of a big problem either. We have inactive IPMC members who might become active again later if a community wants to join the incubator but it's a hassle to leave and then join again. 

Some context, over 300 projects have gone through the incubator, 50 are there currently, each requires a champion and 3 mentors at the start (all IPMC members), even with some mentors working on multiple podling it's not surprising the IPMC is 300 people or so. Nor should it be that a large number of them are inactive as most of the projects they were involved in have graduated (or retired). But despite this some still think it is an issue so we IMO we should address it, unless they change their minds, and say so here.

Thanks,
Justin

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

[Craig Russell <ap...@gmail.com>]

Lots to distill here...

> On Mar 1, 2019, at 2:15 PM, Justin Mclean <ju...@classsoftware.com> wrote:
> 
> Hi,
> 
> Thanks for taking to time to distill this.
> 
>> Many PMCs contain what could be called inactive PMC members. The concern is if that makes any difference or impedes the active IPMC members. I’m not sure how inactive IPMC members are impacting the functioning of the IPMC.
> 
> I also don’t think it is a concern, but as others have raised it as one, and it’s something that can be easily changed (and undone if needed). Small reversible steps and all that.

I agree that it's not ideal but it is not a symptom of a big problem either. We have inactive IPMC members who might become active again later if a community wants to join the incubator but it's a hassle to leave and then join again. 
> 
>> (1) The purpose of the Incubator is to introduce project communities of individuals to The Apache Way and help them come into alignment with those principles.
> 
> +1
> 
>> Currently, I think that the "Legal Shield” value has been elevated above the Community aspect.Communities are harmed because coming to the ASF can be a sharp, direct change in how they operate and this is a negative disruption. In some podlings the Community aspect of the Apache Way is harder than Legal and in others Legal is harder.
> 
> Do we need to ask the board to spend more on the legal shield? (I don't know what we pay now or how it is worded.) Do these suggested changes required it to be changed? Or do we make need to make podlings aware that they do not have legal protections if's might assume they have?

From my perspective, the legal issues discussed here are overblown. By the time a podling graduates, they have to learn how to make a perfect release. During incubation, they have to make releases, not all of which have to be perfect. That's what we need to keep in mind. The podling releases have a disclaimer that the releases may not be perfect.

So my takeaway is that we should give podlings a bit more leeway on their first (few) releases. Nothing bad will happen by noting what needs to be changed but letting out the release. As long as the podling shows that they can fix bad releases in the next cycle, all's good.

But I don't think we gain anything by trying to bypass the three +1 rule for releases. The IPMC must approve releases according to the rules that every PMC has to adhere to. If the mentors are doing their job, podling releases should have had a good review before coming to the IPMC for approval. And if there are three mentors voting on the dev list, they can decide if a "bad" podling release should block external review/release. Once a podling has three mentor reviews and three mentor +1 votes, the IPMC should step back.

But if a podling can't get their mentors to review and vote, that is the problem we should focus on. But if the larger IPMC needs to review a podling release because mentors have not done, we should give them a bit more leeway and allow e.g. binaries in the release, old copyright notices in code, license files with too much information. As long as the podling understands (in writing) why these are issues.
> 
>> To graduate both must be accomplished.
> 
> +1
> 
>> (2) With this service orientation what are the duties of Mentors? Here is my non exhaustive list.
>> - Boot the Podling Community by making sure that podling community is setup in Apache Infra with Mailing Lists, CLAs, SGAs, LDAP, Code Repositories, Issue Trackers, etc. 
>> - Make sure that decisions are memorialized on the Mailing Lists and how that benefits the community.
>> - Make sure that the PPMC is recognizing contributors and growing the community.
>> - Make sure that the podling’s releases meet ASF Legal, Distribution and Release policies and why that is important.

I'd restate this: Review podling releases and document the deficiencies. Help move toward perfection.

>> - Make sure that the podling understands Branding issues in order to protect their community.
>> - Make sure that the podling understands the ASF committee structure in order to find services.
>> - Do all of the above in a gentle, respectful manner.
>> - Keep track of the above to protect the podling.
>> - Guide the podling in how to report to the IPMC (and later the Board)
>> - Defend the podling if the IPMC or Apache is too demanding.
> 
> Great list I’d also add:
> - Make sure the podling acts in a way that’s free from corporate influence
> - That the podling acts in a respectful manner to people on it list and the wider ASF and is aware of our code of conduct
> - Makes sure they understand consensus and when to (and not to) vote
> - Make sure that releases are repeatable and the knowledge of how to do them captured

i.e. Document the release process in a public place.

> - That they recognises and vote in new committers and PPMC members
> - No BDFY in the making
> - Comply with incubator policy on making press releases while in incubation (see corporate influence)
> - They don’t get avoid the ASF release policy by making release elsewhere and call those ASF releases.
> 
> And there probably a few other things that have slipped my mind.
> 
> For the suggested changed it may be best to separate them out and have seperate discussion and votes on each.
> 
>> (A) On general@ replace [VOTE] on releases with [DISCUSS] or [REVIEW]. The podling would do the release and the review would consist of both Release and Distribution Policy compliance.
>> - 3 or more PPMC votes are still required.
>> - It is an open question about how many IPMC votes we should require. Is it 0, 1, or 3?
> 
> I would say 3, lets not added yet another voting method, podling (and it seems old ASF members) get confused as it is.

I agree. Once they graduate, they will need three binding +1 votes. Why confuse things?
> 
>> (B) Explicitly evaluate Podling Proposals for the following:
>> - if the PPMC has several Apache Members the IPMC should recommend direct to TLP.
>> - explicitly make sure that
>> 	(i) there is at least one mentor who is experienced via successful incubation.
>> 	(ii) that the mentors all have a clear understanding of the Apache Way.
>> 	(iii) that they currently have enough free time to do the necessary work.
>> - confirm what SGAs will be required and assure that these will be signed quickly. (Podlings and Mentors have trouble if it takes the better part of a year for the SGA to happen.)

I think that we need to take a closer look at the github repository migration. In the past, it was easier to bring a code base into the incubator because it was always a copy operation, not a move. So these things were explicitly possible: 

1. There were no questions about the legitimacy of copying a repository from an existing location and starting work in Apache simultaneously with the old project committers working on the old repository.

2. The old project could continue to make releases while the Apache podling was setting up shop.

3. The SGA/ICLA was a gate to exiting the incubator not entering the incubator.

But with the new strategy of moving the github repository, we need to take care that the committers on the old project are ok with losing their rights to commit to the repository pending the podling setup. This is one reason for the lengthy migration. And why I recommend that the podling decide on a repository-by-repository strategy for migration. And explicitly allow continued releases from the old repository while the podling is setting up.

>> - the above may require updates to the proposal template.
> 
> +1
> 
>> (C) Formalize the Shepherd role as follows.
>> - Permanently assign a Shepherd to every podling.
>> - The shepherd tracks mentor engagement.
>> - The shepherd tracks progress of podlings and updates the content/podlings/${podling}.yml file.
>> - The shepherd “sends” report reminders and is a backstop for the Mentors. 
>> - Shepherds are IPMC members whose touch is generally very light like the Board is with TLPs
> 
> Podling already have shepherd they don’t tend to do much (with some exceptions) and we have a shortage of them. How do we recruit more / ensure they do the task they are assigned? Do we require sign off from them on the report for it to be accepted?

I would prefer that we continue on the path we are on with the podlings explicitly noting whether they need more help from their mentors.
> 
>> (D) Recruit Mentors.
>> - The IPMC should send periodic emails to members@
>> - The IPMC should periodically ask ComDev if there is anyone active there to recommend as a Mentor.
> 
> +1 and the IPMC has done several things recent to improve this. Others include:
> - identifying inactive mentors and asking them if they want to cary on
> - asking podlings if their mentors are active on the report
> - meeting people we may not be aware of propose themselves for consideration
> 
>> (E) Change the IPMC structure (this depends on whether we change the podling release VOTE rules)
>> - IPMC members are reduced to those who have successfully mentored a project through to graduation and affirmatively wish to remain on the IPMC.
> 
> I’ve not looked at the number but this may leave many existing podlings with a reduced set of mentors. That may be unfair to mentors (and their podlings) who are active.

I honestly do not see how reducing the size of the IPMC solves anything. From what I've seen, the biggest issue is how to get mentors to be more involved with their podlings. How does reducing address mentor involvement?

Regards, Craig
> 
>> - Other mentors are like committers and are either Apache Members or voted on by the IPMC.
> 
> On TLP only PMC members can approve releases, given the mentors are now committers can their votes binding on release?
> 
> Thanks,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 

Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org <ma...@apache.org> http://db.apache.org/jdo <http://db.apache.org/jdo>

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

[Justin Mclean <ju...@classsoftware.com>]

Hi,

Thanks for taking to time to distill this.

> Many PMCs contain what could be called inactive PMC members. The concern is if that makes any difference or impedes the active IPMC members. I’m not sure how inactive IPMC members are impacting the functioning of the IPMC.

I also don’t think it is a concern, but as others have raised it as one, and it’s something that can be easily changed (and undone if needed). Small reversible steps and all that.

> (1) The purpose of the Incubator is to introduce project communities of individuals to The Apache Way and help them come into alignment with those principles.

+1

> Currently, I think that the "Legal Shield” value has been elevated above the Community aspect.Communities are harmed because coming to the ASF can be a sharp, direct change in how they operate and this is a negative disruption. In some podlings the Community aspect of the Apache Way is harder than Legal and in others Legal is harder.

Do we need to ask the board to spend more on the legal shield? (I don't know what we pay now or how it is worded.) Do these suggested changes required it to be changed? Or do we make need to make podlings aware that they do not have legal protections if's might assume they have?

> To graduate both must be accomplished.

+1

> (2) With this service orientation what are the duties of Mentors? Here is my non exhaustive list.
> - Boot the Podling Community by making sure that podling community is setup in Apache Infra with Mailing Lists, CLAs, SGAs, LDAP, Code Repositories, Issue Trackers, etc. 
> - Make sure that decisions are memorialized on the Mailing Lists and how that benefits the community.
> - Make sure that the PPMC is recognizing contributors and growing the community.
> - Make sure that the podling’s releases meet ASF Legal, Distribution and Release policies and why that is important.
> - Make sure that the podling understands Branding issues in order to protect their community.
> - Make sure that the podling understands the ASF committee structure in order to find services.
> - Do all of the above in a gentle, respectful manner.
> - Keep track of the above to protect the podling.
> - Guide the podling in how to report to the IPMC (and later the Board)
> - Defend the podling if the IPMC or Apache is too demanding.

Great list I’d also add:
- Make sure the podling acts in a way that’s free from corporate influence
- That the podling acts in a respectful manner to people on it list and the wider ASF and is aware of our code of conduct
- Makes sure they understand consensus and when to (and not to) vote
- Make sure that releases are repeatable and the knowledge of how to do them captured
- That they recognises and vote in new committers and PPMC members
- No BDFY in the making
- Comply with incubator policy on making press releases while in incubation (see corporate influence)
- They don’t get avoid the ASF release policy by making release elsewhere and call those ASF releases.

And there probably a few other things that have slipped my mind.

For the suggested changed it may be best to separate them out and have seperate discussion and votes on each.

> (A) On general@ replace [VOTE] on releases with [DISCUSS] or [REVIEW]. The podling would do the release and the review would consist of both Release and Distribution Policy compliance.
> - 3 or more PPMC votes are still required.
> - It is an open question about how many IPMC votes we should require. Is it 0, 1, or 3?

I would say 3, lets not added yet another voting method, podling (and it seems old ASF members) get confused as it is.

> (B) Explicitly evaluate Podling Proposals for the following:
> - if the PPMC has several Apache Members the IPMC should recommend direct to TLP.
> - explicitly make sure that
> 	(i) there is at least one mentor who is experienced via successful incubation.
> 	(ii) that the mentors all have a clear understanding of the Apache Way.
> 	(iii) that they currently have enough free time to do the necessary work.
> - confirm what SGAs will be required and assure that these will be signed quickly. (Podlings and Mentors have trouble if it takes the better part of a year for the SGA to happen.)
> - the above may require updates to the proposal template.

+1

> (C) Formalize the Shepherd role as follows.
> - Permanently assign a Shepherd to every podling.
> - The shepherd tracks mentor engagement.
> - The shepherd tracks progress of podlings and updates the content/podlings/${podling}.yml file.
> - The shepherd “sends” report reminders and is a backstop for the Mentors. 
> - Shepherds are IPMC members whose touch is generally very light like the Board is with TLPs

Podling already have shepherd they don’t tend to do much (with some exceptions) and we have a shortage of them. How do we recruit more / ensure they do the task they are assigned? Do we require sign off from them on the report for it to be accepted?

> (D) Recruit Mentors.
> - The IPMC should send periodic emails to members@
> - The IPMC should periodically ask ComDev if there is anyone active there to recommend as a Mentor.

+1 and the IPMC has done several things recent to improve this. Others include:
- identifying inactive mentors and asking them if they want to cary on
- asking podlings if their mentors are active on the report
- meeting people we may not be aware of propose themselves for consideration

> (E) Change the IPMC structure (this depends on whether we change the podling release VOTE rules)
> - IPMC members are reduced to those who have successfully mentored a project through to graduation and affirmatively wish to remain on the IPMC.

I’ve not looked at the number but this may leave many existing podlings with a reduced set of mentors. That may be unfair to mentors (and their podlings) who are active.

> - Other mentors are like committers and are either Apache Members or voted on by the IPMC.

On TLP only PMC members can approve releases, given the mentors are now committers can their votes binding on release?

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

[DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check (was: .... introduce "[DISCUSS]" threads for podling ... release candidates))

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

Hi -

> On Mar 1, 2019, at 7:23 AM, Kevin A. McGrail <km...@apache.org> wrote:
> 
> On 3/1/2019 5:12 AM, Justin Mclean wrote:
>>> The Board isn't gonna worry about something like that.
>> I wasn’t expecting the board to say anything re that, but the IPMC could of.

Many PMCs contain what could be called inactive PMC members. The concern is if that makes any difference or impedes the active IPMC members. I’m not sure how inactive IPMC members are impacting the functioning of the IPMC.

Members who join just to vote on a Proposal ought to be (a) a proposed Mentor or (b) an initial PPMC member.

> 
> I personally don't know the impact of that statement either.  Sometimes
> opinion in a report and a call to action is helpful.
> 
> What can I do to help fix this issue?

A number of issues were raised in these threads. I don’t think that extra people on the IPMC is the issue with the highest priority. Davor and others raised some points around Mentors and what it means to be one. Myrle had an excellent incremental idea to soften the role of IPMC votes on releases to be advisory reviews. In addition, Jim clearly asks the real question of what value does the Incubator provide podlings? And is it serving its purpose and following The Apache Way.

With those issues in mind:

(1) The purpose of the Incubator is to introduce project communities of individuals to The Apache Way and help them come into alignment with those principles. Currently, I think that the "Legal Shield” value has been elevated above the Community aspect. Communities are harmed because coming to the ASF can be a sharp, direct change in how they operate and this is a negative disruption. In some podlings the Community aspect of the Apache Way is harder than Legal and in others Legal is harder. To graduate both must be accomplished. Some podlings are very successful while still in the Incubator while others atrophy.

(2) With this service orientation what are the duties of Mentors? Here is my non exhaustive list.
- Boot the Podling Community by making sure that podling community is setup in Apache Infra with Mailing Lists, CLAs, SGAs, LDAP, Code Repositories, Issue Trackers, etc. 
- Make sure that decisions are memorialized on the Mailing Lists and how that benefits the community.
- Make sure that the PPMC is recognizing contributors and growing the community.
- Make sure that the podling’s releases meet ASF Legal, Distribution and Release policies and why that is important.
- Make sure that the podling understands Branding issues in order to protect their community.
- Make sure that the podling understands the ASF committee structure in order to find services.
- Do all of the above in a gentle, respectful manner.
- Keep track of the above to protect the podling.
- Guide the podling in how to report to the IPMC (and later the Board)
- Defend the podling if the IPMC or Apache is too demanding.

Yes that is a big list and for each podling can be a large responsibility for a mentor. It’s a high bar and I am sure I don’t always succeed. Between the three or four mentors for a podling experience will tell us that one or two mentors will never engage and the longer it takes to boot the podling community the more who will drop. Some podling’s already have community members who understand The Apache Way and these do very well.

(3) With the above duties what are the responsibilities of the IPMC? Here is my list.
- Evaluate podling proposals and determine if the project is suitable.
- Make sure that podling Mentors are actively helping.
- Recruit more Mentors as needed.
- Tracking the progress of podlings towards graduation. Trust but verify reports.
- Review podling releases to assure that they trend towards alignment with Apache Policies.
- Recommend podling graduation to the Board.
- Retire podlings that are not viable or who wish to move on.
- Report to the Board.

I would like to suggest (repeat) some improvements. Some of these are more a change in emphasis.

(A) On general@ replace [VOTE] on releases with [DISCUSS] or [REVIEW]. The podling would do the release and the review would consist of both Release and Distribution Policy compliance.
- 3 or more PPMC votes are still required.
- It is an open question about how many IPMC votes we should require. Is it 0, 1, or 3?

(B) Explicitly evaluate Podling Proposals for the following:
- if the PPMC has several Apache Members the IPMC should recommend direct to TLP.
- explicitly make sure that
	(i) there is at least one mentor who is experienced via successful incubation.
	(ii) that the mentors all have a clear understanding of the Apache Way.
	(iii) that they currently have enough free time to do the necessary work.
- confirm what SGAs will be required and assure that these will be signed quickly. (Podlings and Mentors have trouble if it takes the better part of a year for the SGA to happen.)
- the above may require updates to the proposal template.

(C) Formalize the Shepherd role as follows.
- Permanently assign a Shepherd to every podling.
- The shepherd tracks mentor engagement.
- The shepherd tracks progress of podlings and updates the content/podlings/${podling}.yml file.
- The shepherd “sends” report reminders and is a backstop for the Mentors. 
- Shepherds are IPMC members whose touch is generally very light like the Board is with TLPs

(D) Recruit Mentors.
- The IPMC should send periodic emails to members@
- The IPMC should periodically ask ComDev if there is anyone active there to recommend as a Mentor.

(E) Change the IPMC structure (this depends on whether we change the podling release VOTE rules)
- IPMC members are reduced to those who have successfully mentored a project through to graduation and affirmatively wish to remain on the IPMC.
- Other mentors are like committers and are either Apache Members or voted on by the IPMC.
- Shepherds are IPMC members.
- Only IPMC votes are binding on accepting proposals.
- The IPMC could vote to recommend that a proposal be direct to TLP.

The hopeful net result here is that the IPMC will have a lighter and more efficient approach to incubating projects.

Please think about this before responding with “spread the flow” criticisms. In response please do not over snip the proposals.

Regards,
Dave

> -- 
> Kevin A. McGrail
> Member, Apache Software Foundation
> Chair Emeritus Apache SpamAssassin Project
> https://www.linkedin.com/in/kmcgrail - 703.798.0171
> 


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

Re: Whimsy general@ subs check (was: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates)

["Kevin A. McGrail" <km...@apache.org>]

On 3/1/2019 5:12 AM, Justin Mclean wrote:
>> The Board isn't gonna worry about something like that.
> I wasn’t expecting the board to say anything re that, but the IPMC could of.

I personally don't know the impact of that statement either.  Sometimes
opinion in a report and a call to action is helpful.

What can I do to help fix this issue?

-- 
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

Re: Whimsy general@ subs check (was: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> The Board isn't gonna worry about something like that.

I wasn’t expecting the board to say anything re that, but the IPMC could of.

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

Re: Whimsy general@ subs check (was: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates)

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

On Fri, Mar 1, 2019 at 3:30 AM Justin Mclean <ju...@classsoftware.com>
wrote:
>...

> When it was mentioned in the board report it got no comments. [1]
>
> "A large number (100+) of IPMC members are not signed up to the private
> mail
> list, each was sent emails asking them to sign up. A couple asked to be
> removed from IPMC but the majority of those contacted have not signed up.
> There's probably not much more that can be done about this."
>

The Board isn't gonna worry about something like that. If you say "this is
causing problems", *then* they'll ask how the community plans to solve it.
.... PMCs are expected to be self-policing until something really goes off
the rails. The above report doesn't suggest such, and you "meh" closer
reinforces that.

Cheers,
-g

Re: Whimsy general@ subs check (was: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> And haven't we *just* been talking about have too many cooks in the
> kitchen? Too much drive-by and bikeshedding?

I would guess that none participate in either lists but I guess we’ll find out.

> ... I see zero problem trimming a hundred people out of the IPMC. The very concept of 200+ PMC
> Members is kind of self-explanatory broken.

OK I’m put to the IPMC and if people agree they should be removed I go ahead and do that. As merit doesn’t expire they can ask to be added back if they want to be involved. 

When it was mentioned in the board report it got no comments. [1]

"A large number (100+) of IPMC members are not signed up to the private mail
list, each was sent emails asking them to sign up. A couple asked to be
removed from IPMC but the majority of those contacted have not signed up.
There's probably not much more that can be done about this."

Thanks,
Justin

1. http://apache.org/foundation/records/minutes/2018/board_minutes_2018_12_19.txt
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: Whimsy general@ subs check (was: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates)

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

On Thu, Feb 28, 2019 at 5:33 PM Justin Mclean <ju...@classsoftware.com>
wrote:

> Hi,
>
> > Ask the Board to remove them. To participate on the IPMC, you should be
> subscribed to private@
>
> At first glance you would be asking to remove yourself btw :-)
>

hahaha... look, rather than glance :-) ... I've been subscribed to
private@incubator since it was created in 2002. Damned youngster!  (just
grep for gstein)


> However I assume some IPMC members use lists.apache.org or perhaps are
> listed under a different email (which is your case I think).
>

Then make them state that explicitly. And also recognize that reading
archives is passive. You're not handling Committee email reactively.

And most probably do not participate. Would asking for those 100 odd people
> to be removed come across as friendly?


So? "I want to be on the IPMC" "Are you going to participate?" "No." "Then
g'bye."

And haven't we *just* been talking about have too many cooks in the
kitchen? Too much drive-by and bikeshedding? ... I see zero problem
trimming a hundred people out of the IPMC. The very concept of 200+ PMC
Members is kind of self-explanatory broken.

Cheers,
-g

Re: Whimsy general@ subs check (was: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> Ask the Board to remove them. To participate on the IPMC, you should be subscribed to private@

At first glance you would be asking to remove yourself btw :-)

However I assume some IPMC members use lists.apache.org or perhaps are listed under a different email (which is your case I think). 

And most probably do not participate. Would asking for those 100 odd people to be removed come across as friendly?

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

Re: Whimsy general@ subs check (was: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates)

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

Ask the Board to remove them. To participate on the IPMC, you should be
subscribed to private@


On Thu, Feb 28, 2019, 15:19 Justin Mclean <ju...@classsoftware.com> wrote:

> Hi,
>
> >> Aren't podlings still required to subscribe to general@incubator?
>
> Hopefully at the very least their mentors are. Perhaps that would be good
> to check as well?
>
> 101 IPMCs members out of 295 are not signed up to the incubator private
> list. Easier this year I tried to improve that my sending each IPMC member
> not subscribed an email asking them to subscribe, a couple decided to step
> down from the IPMC and a couple signed up but it mostly made no difference.
>
> Thanks,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: Whimsy general@ subs check (was: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

>> Aren't podlings still required to subscribe to general@incubator?

Hopefully at the very least their mentors are. Perhaps that would be good to check as well?

101 IPMCs members out of 295 are not signed up to the incubator private list. Easier this year I tried to improve that my sending each IPMC member not subscribed an email asking them to subscribe, a couple decided to step down from the IPMC and a couple signed up but it mostly made no difference.

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

Whimsy general@ subs check (was: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates)

[sebb <se...@gmail.com>]

On Thu, 28 Feb 2019 at 14:54, Myrle Krantz <my...@apache.org> wrote:

> Aren't podlings still required to subscribe to general@incubator?

Whimsy could check if all PPMC members are subscribed to general.
Should it?

If so, please raise an enhancement request via JIRA.

S.

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

Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates

[Myrle Krantz <my...@apache.org>]

Hey Justin,

On Wed, Feb 27, 2019 at 8:33 AM Justin Mclean <ju...@classsoftware.com>
wrote:

> How do we make podling aware they can do this? Obvious people who follow
> this list may know, and we can ask mentors to pass it on to their podling
> lists, on document on the website and perhaps mention it in Dave’s welcome
> package idea. But would that be enough?
>

Important question!

Aren't podlings still required to subscribe to general@incubator?  I don't
know how the rest of the world figures these things out, but I mostly
followed the examples I saw here.  So we need to get a few podlings doing
this to create visibility.  We could do some combination of:

* notify all the dev lists for all the podlings
* notify just those podlings still doing releases outside of the ASF (which
you have helpfully identified)
* ask mentors to suggest it to their podlings when a release is imminent
and the mentor thinks its a good candidate for this approach.
* if a podling approaches you for feedback, ask if you can do so on the
general@incubator list.
* document it (probably the most obligatory and least effective item on the
list. ; o)

I'd also like to read Mick's feedback:
Do you think replacing release voting with release discussing at podling
request as I've suggested would be an improvement?  If so, do you have
ideas for ways to communicate this to podlings?

Best,
Myrle

Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates

[Thomas Weise <th...@apache.org>]

I would consider it a mentor responsibility, just like any other advise on
the way towards graduation. There could be explicit mention in the maturity
assessment / checklist.

--
sent from mobile

On Tue, Feb 26, 2019, 11:33 PM Justin Mclean <ju...@classsoftware.com>
wrote:

> Hi,
>
> > But my proposal to move towards offering early feedback on
> > releases works with or without this change.
>
> +1
>
> How do we make podling aware they can do this? Obvious people who follow
> this list may know, and we can ask mentors to pass it on to their podling
> lists, on document on the website and perhaps mention it in Dave’s welcome
> package idea. But would that be enough?
>
> Thanks,
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates

[Justin Mclean <ju...@classsoftware.com>]

Hi,

> But my proposal to move towards offering early feedback on
> releases works with or without this change. 

+1 

How do we make podling aware they can do this? Obvious people who follow this list may know, and we can ask mentors to pass it on to their podling lists, on document on the website and perhaps mention it in Dave’s welcome package idea. But would that be enough?

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

Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates

[Myrle Krantz <my...@apache.org>]

Dave,

On Tue, Feb 26, 2019 at 10:30 PM Dave Fisher <da...@comcast.net> wrote:

> The IPMC could consider some changes to the Incubator rules. (As proposed
> mostly by Roy on private lists.)
>
> Allow the VOTE thread to be only on the dev@ list with 0 or 1 mentor vote
> required. As long as the DISCLAIMER exists then the pooling release is good.
>

I think the idea is worth discussing (and I'm still deciding how I feel
about it).  But my proposal to move towards offering early feedback on
releases works with or without this change.  For this reason, I suggest you
start a separate thread to discuss this proposal.

Best,
Myrle

(Note: since Roy is making his arguments on a private list, you'll have to
depend on your own words.  If Roy doesn't wish to engage on the public
list, we need to respect that.)

Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates

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

The IPMC could consider some changes to the Incubator rules. (As proposed mostly by Roy on private lists.)

Allow the VOTE thread to be only on the dev@ list with 0 or 1 mentor vote required. As long as the DISCLAIMER exists then the pooling release is good.

Once completed the podling sends the vote thread to general@ with [REVIEW] (or [DISCUSS]). This allows the IPMC to review and comment on how close the release is to being a fully proper Apache Release. The podling can more easily take smaller increments while continuing development as they did before Incubation as well as how they will do it once they graduate.

Graduation requirements don’t change.

Thoughts?

Regards,
Dave

> On Feb 26, 2019, at 12:46 PM, Julian Hyde <jh...@apache.org> wrote:
> 
> This change would be useful.
> 
> As a release manager of a podling, the most disheartening thing is latency. The usual practice is a 72 hour PPMC release vote, followed by a 72 hour IPMC vote, one of which will cross a weekend, so a negative vote on the last day of the IPMC vote adds at least a week to the process. A negative vote (or comment) on day 1 or 2 of the PPMC vote is much less disruptive.
> 
> I encourage reviewers to review a release candidate, and vote, as early as possible in the 72 hour voting period. I also encourage them to review and vote even if there have been -1 votes, because they might find other issues that the previous reviewer(s) missed. Because these practices speed the process along, and even if the first RC fails, get to a good second RC as soon as possible.
> 
> Myrle’s proposal to use a [DISCUSS] thread encourages these practices: people won’t be as tempted to wait for 71 hours before chiming in, and people will tend to continue to review even after they have seen some negative reviews.
> 
> Julian
> 
> 
>> On Feb 25, 2019, at 11:50 PM, Myrle Krantz <my...@apache.org> wrote:
>> 
>> Motivation:
>> 
>> Some podlings want or need feedback on their releases before they are ready
>> to make official Apache releases.  They want to discuss releases that are
>> not yet ready for a VOTE, or that they are not sure they are ready for a
>> vote.  They may wish to make an early release outside of the foundation,
>> but still test the ASF waters.  They prefer to "fail early, fail often and
>> fail forward". [1]
>> 
>> 
>> Proposal:
>> 
>> Podlings should be able to request feedback by starting a "[DISCUSS]"
>> thread instead of a "[VOTE]" thread.  Discussion should give podlings
>> feedback on what they would need to do to bring their release in line with
>> the requirements for graduation to TLP.  Podlings will be responsible for
>> capturing feedback that they accept in work items for their project.
>> Feedback provided in a discussion thread will not block a non-ASF release.
>> 
>> Asking for feedback using this mechanism is not obligatory, but rather a
>> service that the incubator offers.
>> 
>> 
>> Arguments for this proposal:
>> 
>> * It's a very small change which may make it easier to implement than some
>> of the "throw it all away and start over" proposals circulating, but...
>> * It doesn't prevent us from making other larger changes.
>> * It's not a rule.  It's an offering of an additional service + an
>> incremental reduction in stringency of the incubator.
>> * It captures some of the value in what we are doing now while increasing
>> the degrees of freedom provided to podlings.
>> * It is consistent with our values of transparency, collaboration,
>> community, pragmatism, meritocracy, and charity.
>> 
>> Best Regards,
>> Myrle
>> 
>> 1.)
>> https://www.goodreads.com/work/quotes/614412-failing-forward-turning-mistakes-into-stepping-stones-for-success
> 
> 
> ---------------------------------------------------------------------
> 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: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates

[Justin Mclean <ju...@classsoftware.com>]

Hi,

Nice idea. JFYI - This already happens, just not in a formal way, as I often get emails to check podlings releases before they bring them to the IPMC.

> I encourage reviewers to review a release candidate, and vote, as early as possible in the 72 hour voting period. I also encourage them to review and vote even if there have been -1 votes, because they might find other issues that the previous reviewer(s) missed. Because these practices speed the process along, and even if the first RC fails, get to a good second RC as soon as possible.

As we all are volunteers here, and for instance my $dayjob(s) doesn’t involve this, it can be hard to find the time, especially with other things going on. I also tend to hold off voting on podlings I've voted on before and know are good and wait until enough mentors have voted on those. Unless we removed the requirement of an IPMC and replace it with somethings else (and there have been suggested on other lists) I cannot see this part of it improving without more involvement from mentors or the IPMC in voting on releases.

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

Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates

[Julian Hyde <jh...@apache.org>]

This change would be useful.

As a release manager of a podling, the most disheartening thing is latency. The usual practice is a 72 hour PPMC release vote, followed by a 72 hour IPMC vote, one of which will cross a weekend, so a negative vote on the last day of the IPMC vote adds at least a week to the process. A negative vote (or comment) on day 1 or 2 of the PPMC vote is much less disruptive.

I encourage reviewers to review a release candidate, and vote, as early as possible in the 72 hour voting period. I also encourage them to review and vote even if there have been -1 votes, because they might find other issues that the previous reviewer(s) missed. Because these practices speed the process along, and even if the first RC fails, get to a good second RC as soon as possible.

Myrle’s proposal to use a [DISCUSS] thread encourages these practices: people won’t be as tempted to wait for 71 hours before chiming in, and people will tend to continue to review even after they have seen some negative reviews.

Julian


> On Feb 25, 2019, at 11:50 PM, Myrle Krantz <my...@apache.org> wrote:
> 
> Motivation:
> 
> Some podlings want or need feedback on their releases before they are ready
> to make official Apache releases.  They want to discuss releases that are
> not yet ready for a VOTE, or that they are not sure they are ready for a
> vote.  They may wish to make an early release outside of the foundation,
> but still test the ASF waters.  They prefer to "fail early, fail often and
> fail forward". [1]
> 
> 
> Proposal:
> 
> Podlings should be able to request feedback by starting a "[DISCUSS]"
> thread instead of a "[VOTE]" thread.  Discussion should give podlings
> feedback on what they would need to do to bring their release in line with
> the requirements for graduation to TLP.  Podlings will be responsible for
> capturing feedback that they accept in work items for their project.
> Feedback provided in a discussion thread will not block a non-ASF release.
> 
> Asking for feedback using this mechanism is not obligatory, but rather a
> service that the incubator offers.
> 
> 
> Arguments for this proposal:
> 
> * It's a very small change which may make it easier to implement than some
> of the "throw it all away and start over" proposals circulating, but...
> * It doesn't prevent us from making other larger changes.
> * It's not a rule.  It's an offering of an additional service + an
> incremental reduction in stringency of the incubator.
> * It captures some of the value in what we are doing now while increasing
> the degrees of freedom provided to podlings.
> * It is consistent with our values of transparency, collaboration,
> community, pragmatism, meritocracy, and charity.
> 
> Best Regards,
> Myrle
> 
> 1.)
> https://www.goodreads.com/work/quotes/614412-failing-forward-turning-mistakes-into-stepping-stones-for-success


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