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

[Ross Gardler]

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 
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%2Fdata=02%7C01%7C%7C14e66a1b43ae48f9db8f08d6a26f939d%7C84df9e7fe9f640afb435%7C1%7C0%7C636874997434876585sdata=qq8L7D0w7Au6yursya5M%2BEVHEDbSMQqVMTYQ1hAEFYk%3Dreserved=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%2FDefaultProjectGuidelinesdata=02%7C01%7C%7C14e66a1b43ae48f9db8f08d6a26f939d%7C84df9e7fe9f640afb435%7C1%7C0%7C636874997434876585sdata=ctQ%2BmlgRbSXVYe5tEQdUhLSZIugzYgVZiPw5nYPna%2FI%3Dreserved=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 :

> 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%2Fghei36data=02%7C01%7C%7C14e66a1b43ae48f9db8f08d6a26f939d%7C84df9e7fe9f640afb435%7C1%7C0%7C636874997434876585sdata=E4BNgsdPokj3UCHZlKdjP60qXF7SZAybTN6gLWUVN9s%3Dreserved=0>
>
> 
> From: Dmitriy Pavlov 
> 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 :
>
> > 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 ope

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

[Myrle Krantz]

On Thu, Mar 7, 2019 at 11:07 AM Bertrand Delacretaz <
bdelacre...@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]

Hi,

On Wed, Mar 6, 2019 at 11:41 PM Ted Dunning  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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Adrian Cole]

> 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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Ted Dunning]

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  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 (was: Re: Whimsy general@ subs check

[Adrian Cole]

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  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 :
>
> > 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-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >

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

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

[Justin Mclean]

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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Justin Mclean]

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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Dave Fisher]

Hi -

Sent from my iPhone

> On Mar 6, 2019, at 1:18 PM, Justin Mclean  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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


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

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

[Dmitriy Pavlov]

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 :

> 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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Responsibilities and Improvements

[Daniel Gruno]

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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Justin Mclean]

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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Dmitriy Pavlov]

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 :

> 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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

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

[Daniel Gruno]

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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Dmitriy Pavlov]

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 :

> 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 
> 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 :
>
> > 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 
> > 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  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-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

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

[Dave Fisher]

> On Mar 6, 2019, at 7:59 AM, sebb  wrote:
> 
> On Wed, 6 Mar 2019 at 15:53, Myrle Krantz  wrote:
>> 
>> On Wed, Mar 6, 2019 at 4:49 PM Daniel Gruno  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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


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

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

[sebb]

On Wed, 6 Mar 2019 at 15:53, Myrle Krantz  wrote:
>
> On Wed, Mar 6, 2019 at 4:49 PM Daniel Gruno  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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Myrle Krantz]

On Wed, Mar 6, 2019 at 4:49 PM Daniel Gruno  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]

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


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 
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  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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org







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

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

[Ross Gardler]

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

> 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 
> 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  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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

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

[Dave Fisher]

 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 
> 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  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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


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

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

[Dmitriy Pavlov]

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 :

> 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 
> 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  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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

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

[Ross Gardler]

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 
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  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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Danny Angus]

+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,  wrote:

> On Sun, Mar 3, 2019 at 10:37 PM Ross Gardler  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]

On Sun, Mar 3, 2019 at 10:37 PM Ross Gardler  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]

On Sun, Mar 3, 2019 at 9:58 PM Craig Russell  wrote:

> Hi Greg,
>
> > On Mar 3, 2019, at 6:15 PM, Greg Stein  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))

[Ross Gardler]

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 
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  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
c...@apache.org <mailto:c...@apache.org> 
https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdb.apache.org%2Fjdodata=02%7C01%7C%7C8f0ef556c879d86908d6a055b63c%7C84df9e7fe9f640afb435%7C1%7C0%7C636872687314777901sdata=B8U4hhYvv4cCT8ccNb2OKWGPJY3e8I1XW9NmsUHyl%2FU%3Dreserved=0
 
<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdb.apache.org%2Fjdodata=02%7C01%7C%7C8f0ef556c879d86908d6a055b63c%7C84df9e7fe9f640afb435%7C1%7C0%7C636872687314787906sdata=bXt1jFmZTWyRJ%2B1tPmxCAXolJRUG8VGLhg9lAk0w4Oo%3Dreserved=0>

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

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

[Craig Russell]

Hi Greg,

> On Mar 3, 2019, at 6:15 PM, Greg Stein  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
c...@apache.org  http://db.apache.org/jdo 

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

[Craig Russell]

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  wrote:
> 
> On Sat, Mar 2, 2019 at 5:17 AM sebb  > wrote:
> 
>> On Sat, 2 Mar 2019 at 10:49, Greg Stein  wrote:
>>> 
>>> On Sat, Mar 2, 2019 at 2:50 AM sebb  wrote:
>>> 
 On Sat, 2 Mar 2019 at 03:45, Justin Mclean 
 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
c...@apache.org  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]

On Sun, Mar 3, 2019 at 1:27 PM Thomas Weise  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]

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  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"  wrote:
>
> On Sat, Mar 2, 2019 at 5:17 AM sebb  wrote:
>
> > On Sat, 2 Mar 2019 at 10:49, Greg Stein  wrote:
> > >
> > > On Sat, Mar 2, 2019 at 2:50 AM sebb  wrote:
> > >
> > > > On Sat, 2 Mar 2019 at 03:45, Justin Mclean <
> jus...@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.
> > >
> > > 

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

[Alex Harui]

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"  wrote:

On Sat, Mar 2, 2019 at 5:17 AM sebb  wrote:

> On Sat, 2 Mar 2019 at 10:49, Greg Stein  wrote:
> >
> > On Sat, Mar 2, 2019 at 2:50 AM sebb  wrote:
> >
> > > On Sat, 2 Mar 2019 at 03:45, Justin Mclean 
> > > 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 

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

[Greg Stein]

On Sun, Mar 3, 2019 at 1:42 AM Ted Dunning  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  wrote:

> Greg,
>
> Would you categorize yourself as one of these drive-by kibitzers?
>
>
>
>
> On Sat, Mar 2, 2019 at 3:55 AM Greg Stein  wrote:
>
> > On Sat, Mar 2, 2019 at 5:17 AM sebb  wrote:
> >
> > > On Sat, 2 Mar 2019 at 10:49, Greg Stein  wrote:
> > > >
> > > > On Sat, Mar 2, 2019 at 2:50 AM sebb  wrote:
> > > >
> > > > > On Sat, 2 Mar 2019 at 03:45, Justin Mclean <
> jus...@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]

Greg,

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




On Sat, Mar 2, 2019 at 3:55 AM Greg Stein  wrote:

> On Sat, Mar 2, 2019 at 5:17 AM sebb  wrote:
>
> > On Sat, 2 Mar 2019 at 10:49, Greg Stein  wrote:
> > >
> > > On Sat, Mar 2, 2019 at 2:50 AM sebb  wrote:
> > >
> > > > On Sat, 2 Mar 2019 at 03:45, Justin Mclean  >
> > > > 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]

On Sat, Mar 2, 2019 at 5:17 AM sebb  wrote:

> On Sat, 2 Mar 2019 at 10:49, Greg Stein  wrote:
> >
> > On Sat, Mar 2, 2019 at 2:50 AM sebb  wrote:
> >
> > > On Sat, 2 Mar 2019 at 03:45, Justin Mclean 
> > > 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]

On Sat, 2 Mar 2019 at 10:49, Greg Stein  wrote:
>
> On Sat, Mar 2, 2019 at 2:50 AM sebb  wrote:
>
> > On Sat, 2 Mar 2019 at 03:45, Justin Mclean 
> > 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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Greg Stein]

On Sat, Mar 2, 2019 at 2:50 AM sebb  wrote:

> On Sat, 2 Mar 2019 at 03:45, Justin Mclean 
> 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]

On Sat, 2 Mar 2019 at 03:45, Justin Mclean  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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

[Justin Mclean]

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]

Lots to distill here...

> On Mar 1, 2019, at 2:15 PM, Justin Mclean  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 

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

[Justin Mclean]

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 

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

[Dave Fisher]

Hi -

> On Mar 1, 2019, at 7:23 AM, Kevin A. McGrail  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)