subject:"Re\: Reform of Incubator"

On Mon, Aug 3, 2015, at 07:06 PM, Arvind Prabhakar wrote:
 That said, I have personally been in positions where I have seen IPMC
 members ask - and even demand things at times - that I feel are
 unreasonable requests for the podling. The reason I do not challenge
 those is because I feel that their asks are rooted in good intentions, and 
 that
 the IPMC in its current form encourages such involvement and authority.
 At the same time I also worry about the state of the podling and what this
 does to their way of thinking about Apache and the Incubator.

Can you give an example (possibly abstracted to protect the guilty)? 

I'm very aware that I don't have as much experience as other folks
mentoring, and would be grateful if podlings (politely) pushed back if I
am in fact asking for / demanding anything that is not reasonable.

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

On Mon, Aug 3, 2015, at 03:13 PM, Roman Shaposhnik wrote:
 On Mon, Aug 3, 2015 at 3:44 AM, Joe Brockmeier j...@zonker.net wrote:
  On Sun, Aug 2, 2015, at 10:05 PM, Roman Shaposhnik wrote:
  I've been waiting for a bout a week for other to chime in, but
  it seems that nobody has so I'll repeat my question as of
  a week ago: what would be the effective way to change the
  status quo around IPMC an make it more board like?
 
  Perhaps we can start from making the release policy actually
  make sense along the lines that Ross has outlined. I guess
  I can propose a change to the current policies (or to Ross'
  point just get it back from the wayback machine :-)).
 
  But seriously, who else thinks the movement towards empowering
  PPMCs and making IPMC very much like the board makes sense?
 
  I think the thread fizzled because there's not a lot of support for the
  idea. At least, on my end, I'm not in favor.
 
 Yup. I believe this to be an unfortunate (at least from my standpoint)
 but and extremely fair observation.
 
 As far as I'm concerned the issue of RRs of IPMC is in a state of a
 stalemate right now. We clearly have a everything's fine lets just
 add more policy constituency vs. IPMC should be small and more
 board like crowd.

If I had to identify one problem that the IPMC/Incubator suffers from at
the moment it would not be a need for a small and more board like
structure. The biggest problem (and perhaps I view it this way because
I'm suffering from it / am part of the problem) is a lack of time /
attention from mentors. I'm really not sure that the proposal here
solves that in any meaningful way. 
 
 The good news is that we're all united on making sure that the foundation
 is growing by podlings making progress and graduating to TLPs. The
 bad news is that because of the current mentality I don't see the types
 of unfortunate threads that Ignite just went through going away anytime
 soon.

What about the Ignite thread was unfortunate? That it was a bit heated
at times, or just the fact that there was disagreement? 

I fear that there's too much bias towards +1'ing things even when folks
have legitimate concerns. 

 This is that proverbial political overhead that a lot of folks are
 accusing ASF of and cite as a reason of not going into the foundation. Which 
 is
 grossly unfair at the board level, but unfortunately seems to be very
 true at IPMC level today.

A lot of companies seem to view any friction (e.g. actually complying
with policies that put community over code) as political overhead
that makes joining the foundation undesirable.  

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

On Tue, Aug 4, 2015, at 12:23 PM, Ross Gardler wrote:
 It's hard to get the balance right between appropriate oversight and
 unwanted meddling.

No argument there. I'm unconvinced that a restructuring of the
IPMC/PPMC/Mentorship structure as it is today will solve that, though it
might push it around a little. 

I do think negotiating/communicating with mentors is a skill that helps
folks deal with building community and running a project - which is
often new to folks coming to the Incubator. So if there's unwanted
meddling I hope that folks are able to push back a little bit and
resolve that without having to throw out (a potentially) reasonable
structure just to get around it. 

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

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

Re: Reform of Incubator

On 08/04/2015 02:45 PM, Konstantin Boudnik wrote:
 Sorry if it rubs the wrong way. However, we just have seen through the Ignite
 discussion (most recent one) the examples where personal expectations were
 represented as graduation requirements. It is perhaps in good faith - I am not
 questioning the intention. I am saying that when requirements are unclear,
 people interpret them based on their own understanding of unwritten Apache
 ethos. As Brane called it earlier - confusing opinions and policies. You see
 where I am going with this, right?

Perhaps I'm unclear on the proposal - but how would that be mitigated by
this proposal? I understand that it might expose podlings to less of
this when directed towards the full IPMC for graduation, but how would
it prevent this if a mentor confuses personal expectations for
graduation requirements?

Isn't that still a potential issue?

I may misunderstand or have lost track of how that's handled in all the
discussion.

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

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

Re: Reform of Incubator

2015-08-04 Thread Konstantin Boudnik

Sorry if it rubs the wrong way. However, we just have seen through the Ignite
discussion (most recent one) the examples where personal expectations were
represented as graduation requirements. It is perhaps in good faith - I am not
questioning the intention. I am saying that when requirements are unclear,
people interpret them based on their own understanding of unwritten Apache
ethos. As Brane called it earlier - confusing opinions and policies. You see
where I am going with this, right?

Cos

On Tue, Aug 04, 2015 at 08:56AM, Julian Hyde wrote:
 Cos,
 
 There is no bureaucratism outbreak. People are not express[ing]
 their expectations as a law-of-the-land. People are trying, in good
 faith, to make sure that decisions are made consistent with the Apache
 ethos. And before you ask, no, that ethos cannot be written down; it
 has to be interpreted via debate. This is what debate sounds like.
 
 Julian
 
 
 On Mon, Aug 3, 2015 at 9:03 PM, Konstantin Boudnik c...@apache.org wrote:
  On Mon, Aug 03, 2015 at 11:36AM, Roman Shaposhnik wrote:
  On Mon, Aug 3, 2015 at 12:37 AM, Bertrand Delacretaz
  bdelacre...@apache.org wrote:
   On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik ro...@shaposhnik.org 
   wrote:
   ...who else thinks the movement towards empowering
   PPMCs and making IPMC very much like the board makes sense?...
  
   How is that different from the status quo where a podling with active
   mentors can have their releases +1ed by their mentors, requiring
   minimal interaction with the IPMC?
 
  I think it is more of a bias issue. IOW, today it seems that the default 
  bias
  of IPMC is to consider itself a final authority (or a gatekeeper) on 
  podling
  releases. We need to break that bias and make it so that it is truly a 
  safety
  net, rather than a gatekeeper.
 
  IOW, I'd like the release traffic on general@ to ONLY consist of [NOTICE]
  emails, not [VOTE].
 
  We perhaps are observing the well known phenomena called self-selection bias
  [1] And it seems to me that the simplification and better clarification of 
  the
  incubation guidelines might be exactly what's needed to prevent a
  bureaucratism outbreak. As well as the situation when ppl express their
  expectations as a law-of-the-land (even from best intentions).
 
  Cos
 
 
 -
 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: Reform of Incubator

2015-08-04 Thread Konstantin Boudnik

On Tue, Aug 04, 2015 at 02:50PM, Joe Brockmeier wrote:
 On 08/04/2015 02:45 PM, Konstantin Boudnik wrote:
  Sorry if it rubs the wrong way. However, we just have seen through the 
  Ignite
  discussion (most recent one) the examples where personal expectations were
  represented as graduation requirements. It is perhaps in good faith - I am 
  not
  questioning the intention. I am saying that when requirements are unclear,
  people interpret them based on their own understanding of unwritten Apache
  ethos. As Brane called it earlier - confusing opinions and policies. You 
  see
  where I am going with this, right?
 
 Perhaps I'm unclear on the proposal - but how would that be mitigated by
 this proposal? I understand that it might expose podlings to less of
 this when directed towards the full IPMC for graduation, but how would
 it prevent this if a mentor confuses personal expectations for
 graduation requirements?
 
 Isn't that still a potential issue?

You're right, it still might be an issue. My vision was that with a reduced
involvement of the IPMC namely

  - IPMC delegating more day-to-day oversight of the podlings to the mentors
  - release votes just Cc'ed to general@ instead of an explicit IPMC vote. It
doesn't contradict the requirement of the binding votes, but the primarily
would be coming from mentors, I believe
  - more precise graduation guidelines, eg w/o moot 'diversity'-like points

the environment will be less accommodating for such confusions and would cause
lesser number of complex debates. This, in turn, will make the incubation
process more transparent and less counter-intuitive for newcomers. 

Hopefully it clarifies my point a bit better. What do you think?
  Cos

 I may misunderstand or have lost track of how that's handled in all the
 discussion.



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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-08-04 Thread Mattmann, Chris A (3980)

Along these lines, also consider using DRAT:

http://github.com/chrismattmann/drat/

Think of it as RAT at scale with progress logs, Tika-based MIME
file identification. Presentations, videos, and docs are on the
page.

++
Chris Mattmann, Ph.D.
Chief Architect
Instrument Software and Science Data Systems Section (398)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 168-519, Mailstop: 168-527
Email: chris.a.mattm...@nasa.gov
WWW:  http://sunset.usc.edu/~mattmann/
++
Adjunct Associate Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++





-Original Message-
From: Ross Gardler ross.gard...@microsoft.com
Reply-To: general@incubator.apache.org general@incubator.apache.org
Date: Tuesday, August 4, 2015 at 9:12 AM
To: general@incubator.apache.org general@incubator.apache.org
Subject: RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from
the Apache Incubator)

As an immediate start to having a tool to support mentors and TLPs you
might want to consider providing a Rat service. Rat is already very
useful.

Sent from my Windows Phone

From: Daniel Grunomailto:humbed...@apache.org
Sent: ‎8/‎4/‎2015 4:15 AM
To: general@incubator.apache.orgmailto:general@incubator.apache.org
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from
the Apache Incubator)



On 2015-08-04 13:01, Bertrand Delacretaz wrote:
 On Mon, Aug 3, 2015 at 8:33 PM, Roman Shaposhnik ro...@shaposhnik.org
wrote:
 ...Which would be totally fine and gets us back to the point Daniel
and I were
 discussing: a release compliance team (horrible name, I know) as part
of ASF
 IMO it's not a team that's needed, just a clear and modular release
checklist.

 By modular I mean something like our maturity model [1] where each
 item is atomic and numbered so one could say this release doesn't
 comply with RM-42 and everybody knows what it's about.

 And there's no inventing new checklist items unless they are approved
 by the PMC who owns the checklist.

 IMO the Incubator PMC can very much own this checklist, and I
 volunteer to contribute to creating it.

 We do have a starting point at
 http://incubator.apache.org/guides/release.html but the release
 checklist might need more explanations, as footnotes, and its own page
 to keep the noise low.

Hi Bertrand,
If interested, I would very much like to work with you on perhaps
turning this into a sort of 'online compliance check' where podlings
could upload a tarball or some such, and the service would scan it for
compliance, go through the checklist, and report back which elements are
compliant and which are not. I think that this, while not being 100%
accurate, would save a lot of time and aggravation when dealing with the
initial release candidates, and save us a lot of time by automating what
we tend to spend quite a lot of time doing manually.

This won't solve everything, but it would really cut down on the time
that is, in my opinion, wasted on getting a release through the IPMC,
while still retaining the policies and rules we need in order to comply
with our legal requirements.

With regards,
Daniel.

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

Re: Reform of Incubator

2015-08-04 Thread Julian Hyde

Cos,

There is no bureaucratism outbreak. People are not express[ing]
their expectations as a law-of-the-land. People are trying, in good
faith, to make sure that decisions are made consistent with the Apache
ethos. And before you ask, no, that ethos cannot be written down; it
has to be interpreted via debate. This is what debate sounds like.

Julian


On Mon, Aug 3, 2015 at 9:03 PM, Konstantin Boudnik c...@apache.org wrote:
 On Mon, Aug 03, 2015 at 11:36AM, Roman Shaposhnik wrote:
 On Mon, Aug 3, 2015 at 12:37 AM, Bertrand Delacretaz
 bdelacre...@apache.org wrote:
  On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik ro...@shaposhnik.org 
  wrote:
  ...who else thinks the movement towards empowering
  PPMCs and making IPMC very much like the board makes sense?...
 
  How is that different from the status quo where a podling with active
  mentors can have their releases +1ed by their mentors, requiring
  minimal interaction with the IPMC?

 I think it is more of a bias issue. IOW, today it seems that the default bias
 of IPMC is to consider itself a final authority (or a gatekeeper) on podling
 releases. We need to break that bias and make it so that it is truly a safety
 net, rather than a gatekeeper.

 IOW, I'd like the release traffic on general@ to ONLY consist of [NOTICE]
 emails, not [VOTE].

 We perhaps are observing the well known phenomena called self-selection bias
 [1] And it seems to me that the simplification and better clarification of the
 incubation guidelines might be exactly what's needed to prevent a
 bureaucratism outbreak. As well as the situation when ppl express their
 expectations as a law-of-the-land (even from best intentions).

 Cos


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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-08-03 Thread Arvind Prabhakar

On Mon, Aug 3, 2015 at 12:37 AM, Bertrand Delacretaz bdelacre...@apache.org
 wrote:

 On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik ro...@shaposhnik.org
 wrote:
  ...who else thinks the movement towards empowering
  PPMCs and making IPMC very much like the board makes sense?...

 How is that different from the status quo where a podling with active
 mentors can have their releases +1ed by their mentors, requiring
 minimal interaction with the IPMC?


In spirit it may not be very different, but in practice it is the polar
opposite. As someone who has worked through the incubation of a few
projects both as an initial committer as well as a mentor, I feel that the
biggest weakness of the current Incubator is it's very strength of being
all inclusive of different interpretations/understandings of the goals of
incubation. With every IPMC member having their own close-to-heart issues
and inclinations, along with their good intentions, I don't think we are
doing very much to help the podlings understand the principals of Apache
Way or learn self-governance that works best for their communities.
Instead, we often end up prescribing things which go beyond the charter of
the Incubator, just to establish a sense of comfort in ensuring we have met
our responsibilities.

Therefore, I too favor the idea of a smaller, well-defined, tactical IPMC
that:
a) establishes a clear objective criteria for growth and graduation
including the necessary processes and policies,
b) oversees the execution of these processes and policies via measurable
means, and,
c) has the final say in the graduation of the podling

...will be a big step in the right direction. This does look more like the
way our board is organized. Arguably, this IPMC could still enlist the help
of member/mentors but will be doing so without granting the decision making
privileges to them.

Regards,
Arvind Prabhakar




 -Bertrand

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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-08-03 Thread Arvind Prabhakar

On Mon, Aug 3, 2015 at 1:59 PM, Andrew Purtell apurt...@apache.org wrote:

 
 
 In fact, in my opinion it leads to the very unfortunate side effect of IPMC
  
 feeling in need to justify why it exists by micromanaging podlings.

 I've been through incubation as a mentor on Phoenix, Nifi, and now getting
 up to speed on Trafodion, I have not seen micromanagement of podlings.
 Could you point out an example? Curious what you mean.


It is worth noting that none of the IPMC members micromanage on purpose, or
are even aware that their actions are being interpreted as acts of
micromanagement. From their perspective, it is their responsibility to
guide the podling, and that is what they are trying to do. It will unfair
to bring those out as examples of micromanagement.

That said, I have personally been in positions where I have seen IPMC
members ask - and even demand things at times - that I feel are
unreasonable requests for the podling. The reason I do not challenge those
is because I feel that their asks are rooted in good intentions, and that
the IPMC in its current form encourages such involvement and authority. At
the same time I also worry about the state of the podling and what this
does to their way of thinking about Apache and the Incubator.

Regards,
Arvind Prabhakar




 On Mon, Aug 3, 2015 at 11:33 AM, Roman Shaposhnik ro...@shaposhnik.org
 wrote:

  On Sun, Aug 2, 2015 at 7:18 PM, John D. Ament johndam...@apache.org
  wrote:
   I wonder how much of the silence is a notion of I don't want to be
   accountable if something goes wrong in this podling.
 
  Right, but that same concern could be applied to every single TLP
  and yet the board seems to do the right thing with that.
 
   Having the IPMC safety net means its at least the IPMC's fault if
  something
   goes wrong.
 
  My point all along has been that this is a false sense of security.
  
  In fact,
  in my opinion it leads to the very unfortunate side effect of IPMC
  feeling in need to justify why it exists by micromanaging podlings.
 
   Personally, I'd be happy if the PPMCs had more self governance.  But I
   think there are also some key people on the IPMC that should be able to
   lend their skills out to the broader PPMCs in case of need.
 
  Which would be totally fine and gets us back to the point Daniel and I
 were
  discussing: a release compliance team (horrible name, I know) as part of
  ASF.
 
  Thanks,
  Roman.
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 


 --
 Best regards,

- Andy

 Problems worthy of attack prove their worth by hitting back. - Piet Hein
 (via Tom White)

Re: Reform of Incubator

2015-08-03 Thread Konstantin Boudnik

On Mon, Aug 03, 2015 at 11:36AM, Roman Shaposhnik wrote:
 On Mon, Aug 3, 2015 at 12:37 AM, Bertrand Delacretaz
 bdelacre...@apache.org wrote:
  On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik ro...@shaposhnik.org 
  wrote:
  ...who else thinks the movement towards empowering
  PPMCs and making IPMC very much like the board makes sense?...
 
  How is that different from the status quo where a podling with active
  mentors can have their releases +1ed by their mentors, requiring
  minimal interaction with the IPMC?
 
 I think it is more of a bias issue. IOW, today it seems that the default bias
 of IPMC is to consider itself a final authority (or a gatekeeper) on podling
 releases. We need to break that bias and make it so that it is truly a safety
 net, rather than a gatekeeper.
 
 IOW, I'd like the release traffic on general@ to ONLY consist of [NOTICE]
 emails, not [VOTE].

We perhaps are observing the well known phenomena called self-selection bias
[1] And it seems to me that the simplification and better clarification of the
incubation guidelines might be exactly what's needed to prevent a
bureaucratism outbreak. As well as the situation when ppl express their
expectations as a law-of-the-land (even from best intentions).

Cos



signature.asc
Description: Digital signature

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-08-03 Thread Joe Brockmeier

On Sun, Aug 2, 2015, at 10:05 PM, Roman Shaposhnik wrote:
 I've been waiting for a bout a week for other to chime in, but
 it seems that nobody has so I'll repeat my question as of
 a week ago: what would be the effective way to change the
 status quo around IPMC an make it more board like?
 
 Perhaps we can start from making the release policy actually
 make sense along the lines that Ross has outlined. I guess
 I can propose a change to the current policies (or to Ross'
 point just get it back from the wayback machine :-)).
 
 But seriously, who else thinks the movement towards empowering
 PPMCs and making IPMC very much like the board makes sense?

I think the thread fizzled because there's not a lot of support for the
idea. At least, on my end, I'm not in favor. 

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-08-03 Thread Daniel Gruno




On 2015-08-03 09:37, Bertrand Delacretaz wrote:

On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:

...who else thinks the movement towards empowering
PPMCs and making IPMC very much like the board makes sense?...

How is that different from the status quo where a podling with active
mentors can have their releases +1ed by their mentors, requiring
minimal interaction with the IPMC?

As you say, releases can - if done right - be done with minimal friction 
from the IPMC, so the issue seems more to be an issue of perception and 
procedure than an issue of policy. There is a clear distinction between 
how the board acts towards TLPs and how the IPMC acts towards podlings, 
and in my opinion there should be: TLPs are _expected to know how to 
act, how to release, how to self-govern_. They have learned this through 
trial and error, many of them in the Incubator, and have built up 
procedures and cultures that enable them to (mostly) govern themselves. 
Podlings are _in training to be like that_, and even with 4, 5, 6 
mentors, it has been shown time and time again (as I believe Marvin also 
mentioned), that there will be issues with the first one or two 
releases, as is only natural when a project is learning how to do 
Apache-style releases, and then the IPMC says hang on, you need to do 
these things differently, fix this, that, and then do this, and then 
the podling slowly adapts to the way we do releases. As we continue to 
let in more and more podlings, it is also safe to assume, that the 
number of 'initial release bugs' will increase, thus this system becomes 
even more important.


To sum up my view: We have a release process that has shown many times 
that it both works and is necessary for podlings, especially on the 
first release. I think this is awesome, and I don't see the need to 
change this specific policy - *but perhaps we could ease the process, as 
I suggested last week, through better tooling and education.*


Allow me to also ask this question: If there is a _visible_ need for 
this existing policy, as has been shown on numerous occasions, how is 
empowering PPMCs by removing the policy going to solve or help the 
issue? I am all for a hands-off approach if it leads to a desired goal 
(wholly or partially), but this specific proposition seems to be 
counter-intuitive to me.


Therefore, I will suggest the same thing I did last week:

- Keep the existing policy
- Make better processes and tooling to aid podlings in their first 
release(s) (see my previous email for details)
- Consider a mentor rotation/swap-in principle to ensure a fresh 
unbiased/non-myopic governance.


Heck, I'd even, to some degree, recommend these steps for TLPs, but eh, 
that's another story :)
If we can create procedures and tools that can do most of the basic 
legal and structural checks in new release candidates, we could cut down 
the time spent arguing about the nitty gritty details, and a lot of the 
unfortunate situations where a podling needs to release fast, but gets 
caught in a legal issue, could be avoided or at the very least be 
resolved a lot faster.


With regards,
Daniel.

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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-08-03 Thread Bertrand Delacretaz

On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 ...who else thinks the movement towards empowering
 PPMCs and making IPMC very much like the board makes sense?...

How is that different from the status quo where a podling with active
mentors can have their releases +1ed by their mentors, requiring
minimal interaction with the IPMC?

-Bertrand

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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-08-03 Thread Roman Shaposhnik

On Sun, Aug 2, 2015 at 7:18 PM, John D. Ament johndam...@apache.org wrote:
 I wonder how much of the silence is a notion of I don't want to be
 accountable if something goes wrong in this podling.

Right, but that same concern could be applied to every single TLP
and yet the board seems to do the right thing with that.

 Having the IPMC safety net means its at least the IPMC's fault if something
 goes wrong.

My point all along has been that this is a false sense of security. In fact,
in my opinion it leads to the very unfortunate side effect of IPMC
feeling in need to justify why it exists by micromanaging podlings.

 Personally, I'd be happy if the PPMCs had more self governance.  But I
 think there are also some key people on the IPMC that should be able to
 lend their skills out to the broader PPMCs in case of need.

Which would be totally fine and gets us back to the point Daniel and I were
discussing: a release compliance team (horrible name, I know) as part of ASF.

Thanks,
Roman.

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

RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-08-03 Thread Ross Gardler

 This is that proverbial political overhead that a lot of folks are accusing 
ASF of and cite as a reason of not going into the foundation. Which is grossly 
unfair at the board level, but unfortunately seems to be very true at IPMC 
level today.

+1000

-Original Message-
From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman 
Shaposhnik
Sent: Monday, August 3, 2015 12:13 PM
To: general@incubator.apache.org
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the 
Apache Incubator)

On Mon, Aug 3, 2015 at 3:44 AM, Joe Brockmeier j...@zonker.net wrote:
 On Sun, Aug 2, 2015, at 10:05 PM, Roman Shaposhnik wrote:
 I've been waiting for a bout a week for other to chime in, but it 
 seems that nobody has so I'll repeat my question as of a week ago: 
 what would be the effective way to change the status quo around IPMC 
 an make it more board like?

 Perhaps we can start from making the release policy actually make 
 sense along the lines that Ross has outlined. I guess I can propose a 
 change to the current policies (or to Ross'
 point just get it back from the wayback machine :-)).

 But seriously, who else thinks the movement towards empowering PPMCs 
 and making IPMC very much like the board makes sense?

 I think the thread fizzled because there's not a lot of support for 
 the idea. At least, on my end, I'm not in favor.

Yup. I believe this to be an unfortunate (at least from my standpoint) but and 
extremely fair observation.

As far as I'm concerned the issue of RRs of IPMC is in a state of a stalemate 
right now. We clearly have a everything's fine lets just add more policy 
constituency vs. IPMC should be small and more board like crowd.

The good news is that we're all united on making sure that the foundation is 
growing by podlings making progress and graduating to TLPs. The bad news is 
that because of the current mentality I don't see the types of unfortunate 
threads that Ignite just went through going away anytime soon.

This is that proverbial political overhead that a lot of folks are accusing 
ASF of and cite as a reason of not going into the foundation. Which is grossly 
unfair at the board level, but unfortunately seems to be very true at IPMC 
level today.

It is clear to me that the change has very little chance of coming from within 
IPMC.

Thanks,
Roman.

-
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: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-08-03 Thread Roman Shaposhnik

On Mon, Aug 3, 2015 at 3:44 AM, Joe Brockmeier j...@zonker.net wrote:
 On Sun, Aug 2, 2015, at 10:05 PM, Roman Shaposhnik wrote:
 I've been waiting for a bout a week for other to chime in, but
 it seems that nobody has so I'll repeat my question as of
 a week ago: what would be the effective way to change the
 status quo around IPMC an make it more board like?

 Perhaps we can start from making the release policy actually
 make sense along the lines that Ross has outlined. I guess
 I can propose a change to the current policies (or to Ross'
 point just get it back from the wayback machine :-)).

 But seriously, who else thinks the movement towards empowering
 PPMCs and making IPMC very much like the board makes sense?

 I think the thread fizzled because there's not a lot of support for the
 idea. At least, on my end, I'm not in favor.

Yup. I believe this to be an unfortunate (at least from my standpoint)
but and extremely fair observation.

As far as I'm concerned the issue of RRs of IPMC is in a state of a
stalemate right now. We clearly have a everything's fine lets just
add more policy constituency vs. IPMC should be small and more
board like crowd.

The good news is that we're all united on making sure that the foundation
is growing by podlings making progress and graduating to TLPs. The
bad news is that because of the current mentality I don't see the types
of unfortunate threads that Ignite just went through going away anytime
soon.

This is that proverbial political overhead that a lot of folks are accusing
ASF of and cite as a reason of not going into the foundation. Which is
grossly unfair at the board level, but unfortunately seems to be very
true at IPMC level today.

It is clear to me that the change has very little chance of coming from
within IPMC.

Thanks,
Roman.

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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-08-03 Thread Roman Shaposhnik

On Mon, Aug 3, 2015 at 12:37 AM, Bertrand Delacretaz
bdelacre...@apache.org wrote:
 On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 ...who else thinks the movement towards empowering
 PPMCs and making IPMC very much like the board makes sense?...

 How is that different from the status quo where a podling with active
 mentors can have their releases +1ed by their mentors, requiring
 minimal interaction with the IPMC?

I think it is more of a bias issue. IOW, today it seems that the default bias
of IPMC is to consider itself a final authority (or a gatekeeper) on podling
releases. We need to break that bias and make it so that it is truly a safety
net, rather than a gatekeeper.

IOW, I'd like the release traffic on general@ to ONLY consist of [NOTICE]
emails, not [VOTE].

Thanks,
Roman.

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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-08-03 Thread Marvin Humphrey

On Mon, Aug 3, 2015 at 8:48 AM, Arvind Prabhakar arv...@apache.org wrote:
 On Mon, Aug 3, 2015 at 12:37 AM, Bertrand Delacretaz bdelacre...@apache.org
 wrote:

 On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik ro...@shaposhnik.org
 wrote:
  ...who else thinks the movement towards empowering
  PPMCs and making IPMC very much like the board makes sense?...

 How is that different from the status quo where a podling with active
 mentors can have their releases +1ed by their mentors, requiring
 minimal interaction with the IPMC?


 In spirit it may not be very different, but in practice it is the polar
 opposite. As someone who has worked through the incubation of a few
 projects both as an initial committer as well as a mentor, I feel that the
 biggest weakness of the current Incubator is it's very strength of being
 all inclusive of different interpretations/understandings of the goals of
 incubation. With every IPMC member having their own close-to-heart issues
 and inclinations, along with their good intentions, I don't think we are
 doing very much to help the podlings understand the principals of Apache
 Way or learn self-governance that works best for their communities.
 Instead, we often end up prescribing things which go beyond the charter of
 the Incubator, just to establish a sense of comfort in ensuring we have met
 our responsibilities.

It's not the central Incubator folks like our regular release
reviewers and report contributors who invent these extra criteria --
it's individual Mentors out on the podling lists.  Inaccuracy and
overreach on general@incubator is self-correcting, precisely because
this is where everyone comes together.  When inaccuracy and overreach
out on individual podling dev lists, whether that gets corrected
depends on whether the podling is fortunate enough to have a
well-rounded collection of active Mentors.

 Therefore, I too favor the idea of a smaller, well-defined, tactical IPMC
 that:
 a) establishes a clear objective criteria for growth and graduation
 including the necessary processes and policies,

The objective of establishing clear policy documentation is certainly
not going to be made any easier by atomizing the Incubator.  Instead,
Mentors who have strong opinions and strong personalities will
entrench provincial points of view in the podlings they oversee. When
we finally come together, it will be that much more painful to
establish consensus, whether that is to discuss policy on
general@incubator or legal-discuss@apache, or when the Board comes
into conflict with a TLP that received bad advice as a podling.

As someone who has worked hard building consensus for policy
documentation at Apache, and who has seen that hard work pay off when
Incubator threads which would have been contended several years ago
are now settled quickly, I certainly agree that documenting clear
objective criteria is valuable.  But nothing about the present makeup
of the Incubator gets in the way of pursuing that objective -- it's
the opposite.  Its because we resolve our differences in small amounts
here that we do not end up as irreconcilable factions later.

Marvin Humphrey

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

RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-08-03 Thread Dennis E. Hamilton

+1 

-Original Message-
From: Marvin Humphrey [mailto:mar...@rectangular.com] 
Sent: Monday, August 3, 2015 09:37
To: general@incubator.apache.org
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the 
Apache Incubator)

[ ... ]

It's not the central Incubator folks like our regular release
reviewers and report contributors who invent these extra criteria --
it's individual Mentors out on the podling lists.  Inaccuracy and
overreach on general@incubator is self-correcting, precisely because
this is where everyone comes together.  When inaccuracy and overreach
out on individual podling dev lists, whether that gets corrected
depends on whether the podling is fortunate enough to have a
well-rounded collection of active Mentors.

[ ... ]

The objective of establishing clear policy documentation is certainly
not going to be made any easier by atomizing the Incubator.  Instead,
Mentors who have strong opinions and strong personalities will
entrench provincial points of view in the podlings they oversee. When
we finally come together, it will be that much more painful to
establish consensus, whether that is to discuss policy on
general@incubator or legal-discuss@apache, or when the Board comes
into conflict with a TLP that received bad advice as a podling.

As someone who has worked hard building consensus for policy
documentation at Apache, and who has seen that hard work pay off when
Incubator threads which would have been contended several years ago
are now settled quickly, I certainly agree that documenting clear
objective criteria is valuable.  But nothing about the present makeup
of the Incubator gets in the way of pursuing that objective -- it's
the opposite.  Its because we resolve our differences in small amounts
here that we do not end up as irreconcilable factions later.

Marvin Humphrey

-
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: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-08-03 Thread Daniel Gruno




On 2015-08-03 21:13, Roman Shaposhnik wrote:

Yup. I believe this to be an unfortunate (at least from my standpoint)
but and extremely fair observation.

As far as I'm concerned the issue of RRs of IPMC is in a state of a
stalemate right now. We clearly have a everything's fine lets just
add more policy constituency vs. IPMC should be small and more
board like crowd.



I don't think anyone is suggesting we add more policy - at least, I 
haven't heard anyone say that. I'd rather say we're caught between the 
policy is fine, but we may need to streamline the process and the 
policy is hindering development and needs to be trimmed.


I count myself among the 'followers' of the first statement. I think the 
policy itself is sound, but the process of incubation leaves something 
to be desired. In my view, if a release, graduation, vote etc is being 
held up by the IPMC, that is not the fault of the policy, it is the 
fault of tacit knowledge not being shared and used among mentors and 
podlings in an efficient manner. If a release is being held up due to 
missing/incorrect licenses or notices, that is an issue we should solve 
through better education and tooling in the Incubator. If a podling 
wants to graduate, but legitimate concerns (however true or unfounded 
they may be) are raised, that is an issue we should solve - or at least 
make speedier - through better education and tooling/processes.


I see a lot of places where we can definitely improve on processes, make 
them faster and easier, but what I do not see is how the policies are to 
blame. The very fact that these policies cause discussions and delays 
are, in my view, not a nuisance that needs to be abolished, but proof 
that we have procedural and educational flaws. Again, I would be very 
interested in working with people on improving these processes and tools.


I would also ask the people who think we need to trim down our policies 
to be more specific about which policies need to be removed or changed, 
and how it would help the Incubator while still retaining the core 
mission of it; To educate and grow communities wishing to follow the 
Apache Way.


With regards,
Daniel.

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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-08-03 Thread Andrew Purtell



In fact, in my opinion it leads to the very unfortunate side effect of IPMC
 
feeling in need to justify why it exists by micromanaging podlings.

I've been through incubation as a mentor on Phoenix, Nifi, and now getting
up to speed on Trafodion, I have not seen micromanagement of podlings.
Could you point out an example? Curious what you mean.


On Mon, Aug 3, 2015 at 11:33 AM, Roman Shaposhnik ro...@shaposhnik.org
wrote:

 On Sun, Aug 2, 2015 at 7:18 PM, John D. Ament johndam...@apache.org
 wrote:
  I wonder how much of the silence is a notion of I don't want to be
  accountable if something goes wrong in this podling.

 Right, but that same concern could be applied to every single TLP
 and yet the board seems to do the right thing with that.

  Having the IPMC safety net means its at least the IPMC's fault if
 something
  goes wrong.

 My point all along has been that this is a false sense of security.
 
 In fact,
 in my opinion it leads to the very unfortunate side effect of IPMC
 feeling in need to justify why it exists by micromanaging podlings.

  Personally, I'd be happy if the PPMCs had more self governance.  But I
  think there are also some key people on the IPMC that should be able to
  lend their skills out to the broader PPMCs in case of need.

 Which would be totally fine and gets us back to the point Daniel and I were
 discussing: a release compliance team (horrible name, I know) as part of
 ASF.

 Thanks,
 Roman.

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




-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-08-03 Thread Branko Čibej

On 03.08.2015 18:36, Marvin Humphrey wrote:
 It's not the central Incubator folks like our regular release
 reviewers and report contributors who invent these extra criteria

Sorry but this has to be said: I see folks on this list inventing policy
(or rather, confusing opinion and policy) all the time. The Ignite
graduation discussion was a good example of that, but by no means unique.

It's this micromanagement self-preservation reflex (thanks, Roman!) that
puts me squarely on the side of a smaller IPMC that would hopefully also
be less of a peanut gallery. No offence meant and especially not to the
people who do put in a stellar performance hereabouts.

-- Brane


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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-08-03 Thread Julian Hyde

In my experience incubating Calcite, the “overhead” was mostly the 
infrastructure and process, not politics. (If you think the incubator is 
political, you haven’t seen politics…) The process is necessary (mostly) to 
ensure clean IP. The infrastructure, less so. So, if we’re talking about how to 
reduce the burden on podlings, those are the areas I would focus on.

Roman’s proposed reform places more responsibility on podling PMCs and, by 
implication, the mentors embedded in those PMCs. I am not sure how well that 
would work in practice given the ongoing problem of absentee mentors. The IPMC 
epitomizes the “it takes a village to raise a child”, in particular with 
village elders stepping in with help/advice from time to time. It would be a 
shame to lose that.

Julian

 
 On Aug 3, 2015, at 12:23 PM, Ross Gardler ross.gard...@microsoft.com wrote:
 
  This is that proverbial political overhead that a lot of folks are 
 accusing ASF of and cite as a reason of not going into the foundation. Which 
 is grossly unfair at the board level, but unfortunately seems to be very true 
 at IPMC level today.
 
 +1000
 
 -Original Message-
 From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman 
 Shaposhnik
 Sent: Monday, August 3, 2015 12:13 PM
 To: general@incubator.apache.org
 Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the 
 Apache Incubator)
 
 On Mon, Aug 3, 2015 at 3:44 AM, Joe Brockmeier j...@zonker.net wrote:
 On Sun, Aug 2, 2015, at 10:05 PM, Roman Shaposhnik wrote:
 I've been waiting for a bout a week for other to chime in, but it 
 seems that nobody has so I'll repeat my question as of a week ago: 
 what would be the effective way to change the status quo around IPMC 
 an make it more board like?
 
 Perhaps we can start from making the release policy actually make 
 sense along the lines that Ross has outlined. I guess I can propose a 
 change to the current policies (or to Ross'
 point just get it back from the wayback machine :-)).
 
 But seriously, who else thinks the movement towards empowering PPMCs 
 and making IPMC very much like the board makes sense?
 
 I think the thread fizzled because there's not a lot of support for 
 the idea. At least, on my end, I'm not in favor.
 
 Yup. I believe this to be an unfortunate (at least from my standpoint) but 
 and extremely fair observation.
 
 As far as I'm concerned the issue of RRs of IPMC is in a state of a 
 stalemate right now. We clearly have a everything's fine lets just add more 
 policy constituency vs. IPMC should be small and more board like crowd.
 
 The good news is that we're all united on making sure that the foundation is 
 growing by podlings making progress and graduating to TLPs. The bad news is 
 that because of the current mentality I don't see the types of unfortunate 
 threads that Ignite just went through going away anytime soon.
 
 This is that proverbial political overhead that a lot of folks are accusing 
 ASF of and cite as a reason of not going into the foundation. Which is 
 grossly unfair at the board level, but unfortunately seems to be very true at 
 IPMC level today.
 
 It is clear to me that the change has very little chance of coming from 
 within IPMC.
 
 Thanks,
 Roman.
 
 -
 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


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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-08-03 Thread Branko Čibej

On 03.08.2015 21:51, Julian Hyde wrote:
 In my experience incubating Calcite, the “overhead” was mostly the 
 infrastructure and process, not politics. (If you think the incubator is 
 political, you haven’t seen politics…) The process is necessary (mostly) to 
 ensure clean IP. The infrastructure, less so. So, if we’re talking about how 
 to reduce the burden on podlings, those are the areas I would focus on.

 Roman’s proposed reform places more responsibility on podling PMCs and, by 
 implication, the mentors embedded in those PMCs.

At the end of the day, it *is* the mentors' responsibility. The IPMC
mostly gets involved after the fact.

 I am not sure how well that would work in practice given the ongoing problem 
 of absentee mentors. The IPMC epitomizes the “it takes a village to raise a 
 child”, in particular with village elders stepping in with help/advice from 
 time to time. It would be a shame to lose that.

There's no need to lose that. But it would be a really good idea to lose
the village spinster who makes the child afraid of the dark and monsters
under the bed ...

-- Brane


 On Aug 3, 2015, at 12:23 PM, Ross Gardler ross.gard...@microsoft.com wrote:

  This is that proverbial political overhead that a lot of folks are 
 accusing ASF of and cite as a reason of not going into the foundation. Which 
 is grossly unfair at the board level, but unfortunately seems to be very 
 true at IPMC level today.

 +1000

 -Original Message-
 From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman 
 Shaposhnik
 Sent: Monday, August 3, 2015 12:13 PM
 To: general@incubator.apache.org
 Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the 
 Apache Incubator)

 On Mon, Aug 3, 2015 at 3:44 AM, Joe Brockmeier j...@zonker.net wrote:
 On Sun, Aug 2, 2015, at 10:05 PM, Roman Shaposhnik wrote:
 I've been waiting for a bout a week for other to chime in, but it 
 seems that nobody has so I'll repeat my question as of a week ago: 
 what would be the effective way to change the status quo around IPMC 
 an make it more board like?

 Perhaps we can start from making the release policy actually make 
 sense along the lines that Ross has outlined. I guess I can propose a 
 change to the current policies (or to Ross'
 point just get it back from the wayback machine :-)).

 But seriously, who else thinks the movement towards empowering PPMCs 
 and making IPMC very much like the board makes sense?
 I think the thread fizzled because there's not a lot of support for 
 the idea. At least, on my end, I'm not in favor.
 Yup. I believe this to be an unfortunate (at least from my standpoint) but 
 and extremely fair observation.

 As far as I'm concerned the issue of RRs of IPMC is in a state of a 
 stalemate right now. We clearly have a everything's fine lets just add more 
 policy constituency vs. IPMC should be small and more board like crowd.

 The good news is that we're all united on making sure that the foundation is 
 growing by podlings making progress and graduating to TLPs. The bad news is 
 that because of the current mentality I don't see the types of unfortunate 
 threads that Ignite just went through going away anytime soon.

 This is that proverbial political overhead that a lot of folks are 
 accusing ASF of and cite as a reason of not going into the foundation. Which 
 is grossly unfair at the board level, but unfortunately seems to be very 
 true at IPMC level today.

 It is clear to me that the change has very little chance of coming from 
 within IPMC.

 Thanks,
 Roman.

 -
 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

 -
 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: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-08-02 Thread Roman Shaposhnik

I've been waiting for a bout a week for other to chime in, but
it seems that nobody has so I'll repeat my question as of
a week ago: what would be the effective way to change the
status quo around IPMC an make it more board like?

Perhaps we can start from making the release policy actually
make sense along the lines that Ross has outlined. I guess
I can propose a change to the current policies (or to Ross'
point just get it back from the wayback machine :-)).

But seriously, who else thinks the movement towards empowering
PPMCs and making IPMC very much like the board makes sense?

Thanks,
Roman.

On Sun, Jul 26, 2015 at 8:56 PM, Ross Gardler
ross.gard...@microsoft.com wrote:
 Well this explains how it got this way, it was poorly worded from the start...

 The first part is about incoming code (the SGA) and nothing has changed there.

 The second part says  SHALL formally request the Incubator PMC approve such 
 a release It does not say [VOTE] and it was never, IMHO, intended to be a 
 separate vote (unless there were insufficient IPMC votes).

 Speaking personally I have always (and I know many other mentors have also, 
 certainly all those that have co-mentored with me) treated a vote on the 
 podling list as binding and a request in the form of a notification (giving 
 time to object if appropriate) when three positive IPMC votes have been cast.

 In 2006 it said Therefore, should a Podling decide it wishes to perform a 
 release, the Podling SHALL hold a vote on the Podling's public -dev list. At 
 least three +1 votes are required (see the Apache Voting Process page), and 
 only the PPMC member votes are binding. If the majority of all votes is 
 positive, then the Podling SHALL send a summary of that vote to the 
 Incubator's general list and formally request the Incubator PMC approve such 
 a release.

 That's still the wording today.

 I've never been challenged on this approach (having mentored many podlings). 
 It was my approach with the most recent release I was a part of, just last 
 week (Ripple). The additional reviews received from the IPMC were useful, 
 spotting a couple of small items, and turned up the one required +1 (only two 
 binding mentor votes).

 Whether this is an accurate recollection of what was discussed way back, or 
 whether this is just a practice I (and others) have fallen into and not been 
 challenged on I urge the IPMC to consider this approach (of course, it does 
 rely on proper oversight from mentors and the IPMC, I'm comfortable with this 
 approach because I never vote +1 without having done due diligence on the 
 release - I trust others do the same).


 Ross

 -Original Message-
 From: David Nalley [mailto:da...@gnsa.us]
 Sent: Sunday, July 26, 2015 6:05 PM
 To: general@incubator.apache.org
 Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the 
 Apache Incubator)

 On Sun, Jul 26, 2015 at 8:41 PM, Ross Gardler ross.gard...@microsoft.com 
 wrote:
 The proposed need to announce release votes on the IPMC list is how things 
 were when the incubator was created. The need for IPMC to control the 
 process is another case of the IPMC over-reaching itself and in so doing 
 causing problems by creating a bottleneck in the process.

 It used to be that it was only required to *notify* the IPMC of a release 
 vote underway. Thereby giving interested IPMC members the opportunity to 
 review artifacts and processes during the normal release cycle. IPMC members 
 were expected to cast their votes on the PPMC list where such things belong.


 I'd love to see links to that - my digging didn't find it. (see below)

 I'm not sure where this idea that the vote actually occurs on the IPMC list 
 came from but it's flat wrong in my opinion (someone may dig through the 
 archives and find a good reason it was changed, but my feeling is that it 
 changed gradually through edits-on-edits-on-edits of the incubation policy).

 The fact is that the PPMC (with IPMC representation from the mentors) should 
 be in charge of their releases, and pretty much everything else. The IPMC 
 role is one of teaching the PPMC how manage itself. Mentors should do this 
 through mentoring and the IPMC should ensure it is done through an 
 appropriate level of oversight (not an inappropriate amount of control).

 Consider this... The board does not bring TLP release votes to board@, why 
 on earth must the IPMC do so?

 I've half a mind to got back the wayback machine and pull the original
 incubator polices and propose them as the new policies (yes, some
 changes have been good, but it seems to me that many have not)


 So I couldn't find anything in 2003, but 2004 has this page[1] which included 
 the text:

 Podlings in Incubation SHALL NOT perform any releases of software without 
 the explicit approval of the Incubator PMC. Such approval SHALL be given only 
 after the Incubator PMC has followed the process detailed in (Reference to 
 Charter), and SHALL NOT occur

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-08-02 Thread John D. Ament

I wonder how much of the silence is a notion of I don't want to be
accountable if something goes wrong in this podling.

Having the IPMC safety net means its at least the IPMC's fault if something
goes wrong.

Personally, I'd be happy if the PPMCs had more self governance.  But I
think there are also some key people on the IPMC that should be able to
lend their skills out to the broader PPMCs in case of need.

John

On Sun, Aug 2, 2015 at 10:06 PM Roman Shaposhnik ro...@shaposhnik.org
wrote:

 I've been waiting for a bout a week for other to chime in, but
 it seems that nobody has so I'll repeat my question as of
 a week ago: what would be the effective way to change the
 status quo around IPMC an make it more board like?

 Perhaps we can start from making the release policy actually
 make sense along the lines that Ross has outlined. I guess
 I can propose a change to the current policies (or to Ross'
 point just get it back from the wayback machine :-)).

 But seriously, who else thinks the movement towards empowering
 PPMCs and making IPMC very much like the board makes sense?

 Thanks,
 Roman.

 On Sun, Jul 26, 2015 at 8:56 PM, Ross Gardler
 ross.gard...@microsoft.com wrote:
  Well this explains how it got this way, it was poorly worded from the
 start...
 
  The first part is about incoming code (the SGA) and nothing has changed
 there.
 
  The second part says  SHALL formally request the Incubator PMC approve
 such a release It does not say [VOTE] and it was never, IMHO, intended to
 be a separate vote (unless there were insufficient IPMC votes).
 
  Speaking personally I have always (and I know many other mentors have
 also, certainly all those that have co-mentored with me) treated a vote on
 the podling list as binding and a request in the form of a notification
 (giving time to object if appropriate) when three positive IPMC votes have
 been cast.
 
  In 2006 it said Therefore, should a Podling decide it wishes to perform
 a release, the Podling SHALL hold a vote on the Podling's public -dev list.
 At least three +1 votes are required (see the Apache Voting Process page),
 and only the PPMC member votes are binding. If the majority of all votes is
 positive, then the Podling SHALL send a summary of that vote to the
 Incubator's general list and formally request the Incubator PMC approve
 such a release.
 
  That's still the wording today.
 
  I've never been challenged on this approach (having mentored many
 podlings). It was my approach with the most recent release I was a part of,
 just last week (Ripple). The additional reviews received from the IPMC were
 useful, spotting a couple of small items, and turned up the one required +1
 (only two binding mentor votes).
 
  Whether this is an accurate recollection of what was discussed way back,
 or whether this is just a practice I (and others) have fallen into and not
 been challenged on I urge the IPMC to consider this approach (of course, it
 does rely on proper oversight from mentors and the IPMC, I'm comfortable
 with this approach because I never vote +1 without having done due
 diligence on the release - I trust others do the same).
 
 
  Ross
 
  -Original Message-
  From: David Nalley [mailto:da...@gnsa.us]
  Sent: Sunday, July 26, 2015 6:05 PM
  To: general@incubator.apache.org
  Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from
 the Apache Incubator)
 
  On Sun, Jul 26, 2015 at 8:41 PM, Ross Gardler 
 ross.gard...@microsoft.com wrote:
  The proposed need to announce release votes on the IPMC list is how
 things were when the incubator was created. The need for IPMC to control
 the process is another case of the IPMC over-reaching itself and in so
 doing causing problems by creating a bottleneck in the process.
 
  It used to be that it was only required to *notify* the IPMC of a
 release vote underway. Thereby giving interested IPMC members the
 opportunity to review artifacts and processes during the normal release
 cycle. IPMC members were expected to cast their votes on the PPMC list
 where such things belong.
 
 
  I'd love to see links to that - my digging didn't find it. (see below)
 
  I'm not sure where this idea that the vote actually occurs on the IPMC
 list came from but it's flat wrong in my opinion (someone may dig through
 the archives and find a good reason it was changed, but my feeling is that
 it changed gradually through edits-on-edits-on-edits of the incubation
 policy).
 
  The fact is that the PPMC (with IPMC representation from the mentors)
 should be in charge of their releases, and pretty much everything else. The
 IPMC role is one of teaching the PPMC how manage itself. Mentors should do
 this through mentoring and the IPMC should ensure it is done through an
 appropriate level of oversight (not an inappropriate amount of control).
 
  Consider this... The board does not bring TLP release votes to board@,
 why on earth must the IPMC do so?
 
  I've half a mind to got back

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-08-02 Thread Marvin Humphrey

On Sun, Aug 2, 2015 at 7:05 PM, Roman Shaposhnik ro...@shaposhnik.org wrote:
 what would be the effective way to change the
 status quo around IPMC an make it more board like?

The Board works very hard to provide thorough review of the reports it
receives.  While IPMC review of podling reports is better than it used
to be, there is still room for improvement, particularly in the realm
of cross-cutting feedback.

 Perhaps we can start from making the release policy actually
 make sense along the lines that Ross has outlined. I guess
 I can propose a change to the current policies (or to Ross'
 point just get it back from the wayback machine :-)).

We worked hard to improve the situation around releasing and we
succeeded. The Incubator today produces higher quality releases more
efficiently and with less contention than it ever has before.

To address the specific point about voting, there have been a number
of times when release votes are run simultaneously on the podling dev
list and general@incubator.  It's fine. I tend not to recommend it
simply because most podlings screw up RC release mechanics a lot and
going through several trivial RCs adds noise to general@incubator.

Marvin Humphrey

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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-07-26 Thread Justin Mclean

Hi,

 About 40% of the last 100 threads on general@ is vote release... Cut that
 away is a good start in reforming the Incubator…

IMO Which provides a valuable service in showing poddlings on how to make good 
releases. Do we want to get rid of that?

Thanks,
Justin


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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-07-26 Thread Branko Čibej

On 26.07.2015 10:56, jan i wrote:
 On 26 July 2015 at 10:40, Justin Mclean jus...@classsoftware.com wrote:

 Hi,

 About 40% of the last 100 threads on general@ is vote release... Cut
 that
 away is a good start in reforming the Incubator…
 IMO Which provides a valuable service in showing poddlings on how to make
 good releases. Do we want to get rid of that?

 No that is an important service, on the other hand I also agree that the
 mentors should be guiding/running the podlings not general@

 Maybe we can find some middle ground.
 - Mentors run the podlings, can accept releases etc.
 - Mentors decide when a podlng can graduate (maybe with some form of, needs
 to accepted by all mentors of the project)
 - Any release must be announced (not voted) on general@, so that people
 like you have a chance of controlling it just like today.

 I think this would make incubator a lot more efficient, reduce our inboxes,
 and give us spare time to concentrate on other things.

I like this proposal very much. One of the constant frustrations in the
podlings I'd mentored was the delay between release bits being ready and
the IPMC getting around to vote. It's now a lot better than it was a
couple years ago, when in some instances it took a month or more ...

Concretely: I think it's perfectly OK to review podling releases after
the fact. The incubation disclaimer tells users clearly enough that they
should be extra careful when using releases from incubating projects.

The other frustration is of course evident in the Ignite graduation
discussion.

The only downside of this proposal is that it assumes that every podling
has at least three active (!) mentors. That doesn't always happen; and
currently we expect the podling to chase down inactive mentors or find
new ones. If we adopt Jan's proposal, I'd expect the IPMC to take a more
active role in finding mentors for podlings.

Other than that, big +1.

-- Brane

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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-07-26 Thread Niclas Hedhman

On Sun, Jul 26, 2015 at 7:38 PM, Branko Čibej br...@apache.org wrote:

 The only downside of this proposal is that it assumes that every podling
 has at least three active (!) mentors.

No, I don't necessarily mean that you need 3 mentors either. One active
mentor would be fine with me. Empower the podling to stand on its own feet.
The Incubation disclaimers are plenty warning, otherwise it would be full
releases.

Take a poll among podlings and ask Do you want to be more autonomous from
the IPMC? and see what they say...

Cheers
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-07-26 Thread jan i

On 26 July 2015 at 10:40, Justin Mclean jus...@classsoftware.com wrote:

 Hi,

  About 40% of the last 100 threads on general@ is vote release... Cut
 that
  away is a good start in reforming the Incubator…

 IMO Which provides a valuable service in showing poddlings on how to make
 good releases. Do we want to get rid of that?


No that is an important service, on the other hand I also agree that the
mentors should be guiding/running the podlings not general@

Maybe we can find some middle ground.
- Mentors run the podlings, can accept releases etc.
- Mentors decide when a podlng can graduate (maybe with some form of, needs
to accepted by all mentors of the project)
- Any release must be announced (not voted) on general@, so that people
like you have a chance of controlling it just like today.

I think this would make incubator a lot more efficient, reduce our inboxes,
and give us spare time to concentrate on other things.

rgds
jan i.




 Thanks,
 Justin


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

RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

Note, there must be the binding +1 for a release. This means either three 
active mentors our some assistance from the IPMC. This is fine, some IPMC 
members are very experienced in this regard and are very helpful (as well as 
reasonable, that is understanding when something's a blocker and when it's not).

My biggest concern is not releases (which thread days are much better). My 
concern is people not being involved with a podling until an IPMC engagement is 
needed, then folks come out of the woodwork and start pushing judgments from on 
high. That's not how it works.

The IPMC needs to ensure mentors are doing their job during incubation, not 
after it.  I agree there IPMC should act more like the board in its oversight. 
That means two things:

1) get our of the way unless a problem is identified during the normal 
reporting process
2) ensure mentors are doing their job when reporting to the IPMC

In other words, hands on during reporting. Hands of at ask other times.

Sent from my Windows Phone

From: Niclas Hedhmanmailto:nic...@hedhman.org
Sent: ‎7/‎26/‎2015 8:08 AM
To: general@incubator.apache.orgmailto:general@incubator.apache.org
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the 
Apache Incubator)

On Sun, Jul 26, 2015 at 7:38 PM, Branko Čibej br...@apache.org wrote:

 The only downside of this proposal is that it assumes that every podling
 has at least three active (!) mentors.

No, I don't necessarily mean that you need 3 mentors either. One active
mentor would be fine with me. Empower the podling to stand on its own feet.
The Incubation disclaimers are plenty warning, otherwise it would be full
releases.

Take a poll among podlings and ask Do you want to be more autonomous from
the IPMC? and see what they say...

Cheers
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-07-26 Thread jan i

On Sunday, July 26, 2015, Don Bosco Durai bo...@apache.org wrote:

 My only concern is now the mentor(s) need to check everything before
 approving. In my experience, during the early stages of the releases, lot
 of the license, naming, release location, etc. related issues were
 identified during the approval in the general@ list. Which were very
 helpful to us.

 I agree, but nothing prevents that the mentor ask when in doubt,
especially the
first one, we do not need to force every release to pass general@ for that
( unless
we don't trust the mentors).

rgds
jan i

 Knowing that the mentors are generally busy, it might be good to have an
 extra oversight.

 Take a poll among podlings and ask Do you want to be more autonomous
 from the IPMC? and see what they say...
 We should qualify what autonomous means here.


 Thanks

 Bosco



 On 7/26/15, 8:06 AM, Niclas Hedhman nic...@hedhman.org javascript:;
 wrote:

 On Sun, Jul 26, 2015 at 7:38 PM, Branko Čibej br...@apache.org
 javascript:; wrote:
 
  The only downside of this proposal is that it assumes that every podling
  has at least three active (!) mentors.
 
 No, I don't necessarily mean that you need 3 mentors either. One active
 mentor would be fine with me. Empower the podling to stand on its own
 feet.
 The Incubation disclaimers are plenty warning, otherwise it would be full
 releases.
 
 Take a poll among podlings and ask Do you want to be more autonomous from
 the IPMC? and see what they say...
 
 Cheers
 --
 Niclas Hedhman, Software Developer
 http://zest.apache.org - New Energy for Java



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



-- 
Sent from My iPad, sorry for any misspellings.

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-07-26 Thread Marvin Humphrey

 On Sun, Jul 26, 2015 at 1:20 AM, Niclas Hedhman nic...@hedhman.org wrote:

 About 40% of the last 100 threads on general@ is vote release...
 Cut that away is a good start in reforming the Incubator…

Many of those vote threads are very high quality and valuable.

Successful vote threads are short: a few +1 votes and it's over.  Frequently,
those +1 votes will be accompanied by a description what was reviewed.
Unsuccessful vote threads yield targeted action items and cogent explanations.
Since the end of 2013, when the Incubator community established an improved
consensus about release requirements, fewer RCs get rejected and rancor has
been rare.

On Sun, Jul 26, 2015 at 4:38 AM, Branko Čibej br...@apache.org wrote:

 It's now a lot better than it was a
 couple years ago, when in some instances it took a month or more ...

Yes, we have for the most part solved the problem of RCs twisting in the wind.
Both proposals in this thread will bring that problem back.

Mentor attrition is a fundamental law of the Incubator: because Mentors are
not core contributors, they fall away at increased rate.  It is not possible
to change that fact, only to compensate for it.

The wider IPMC has a certain limited capacity for picking up the slack on
release votes.  Since the end of 2013, we have been using that precious
capacity wisely.

These proposals squander that capacity and put it all back on the Mentors.
Some of those Mentors will be unavailable when they are needed, compounding
the difficulties faced by smaller and more troubled podlings.

 Concretely: I think it's perfectly OK to review podling releases after
 the fact. The incubation disclaimer tells users clearly enough that they
 should be extra careful when using releases from incubating projects.

We routinely see problematic release candidates on general@incubator.  It
would seem that the expertise and temperament for exacting release QC is not
evenly distributed among the Mentor corps -- just like other valuable skills
and talents.

Since 2013, the wider IPMC in collaboration with Mentors has been working
well at cleaning up problematic releases in an expedited manner -- and once a
podling is producing clean releases regularly, it is probably nearing
graduation and will not be affected by the extra 3 days for long.  I don't see
any urgency to change this dynamic.

 The other frustration is of course evident in the Ignite graduation
 discussion.

The outcome of the Ignite graduation discussion was never in doubt.  The wider
IPMC was never going to vote down graduation when there were multiple
attentive Ignite Mentors united in favor -- it was only a matter of time
before people came around.

I think the discussion was more voluminous than it needed to be, but I
attribute that to individual participants sending too many emails in one day.
1-2 per day on a given thread is a good rate.

In the meantime, interested podling observers got to witness a decent debate
on project independence and off-list dev discussion -- which is generally one
of the hardest aspects of Apache-style open development to master.

 The only downside of this proposal is that it assumes that every podling
 has at least three active (!) mentors. That doesn't always happen; and
 currently we expect the podling to chase down inactive mentors or find
 new ones. If we adopt Jan's proposal, I'd expect the IPMC to take a more
 active role in finding mentors for podlings.

Recruiting Mentors for podlings at any stage other than entry has always been
difficult.  It would be deeply unfair to small podlings to establish a policy
which denies this reality.

Marvin Humphrey

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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-07-26 Thread Ted Dunning


I think my own experience as a mentor over recent years is useful here.  I 
thought I understood what was necessary for apache releases when, in fact, I 
understood release requirements for releases like the ones I had previously 
seen. 

The wider by shepherds and by the general votes was a pain because of the added 
delay but it substantially increased the quality of the releases and improved 
the processes the group had.  

With more perspective now, I find that individual mentors often have somewhat 
specialized expertise and my experience was absolutely not unique. 

Marvin and Ross also make good and important points orthogonal to this. 

Sent from my iPhone

On Jul 26, 2015, at 10:08, Marvin Humphrey mar...@rectangular.com wrote:

 On Sun, Jul 26, 2015 at 1:20 AM, Niclas Hedhman nic...@hedhman.org wrote:
 
 About 40% of the last 100 threads on general@ is vote release...
 Cut that away is a good start in reforming the Incubator…
 
 Many of those vote threads are very high quality and valuable.
 
 Successful vote threads are short: a few +1 votes and it's over.  Frequently,
 those +1 votes will be accompanied by a description what was reviewed.
 Unsuccessful vote threads yield targeted action items and cogent explanations.
 Since the end of 2013, when the Incubator community established an improved
 consensus about release requirements, fewer RCs get rejected and rancor has
 been rare.
 
 On Sun, Jul 26, 2015 at 4:38 AM, Branko Čibej br...@apache.org wrote:
 
 It's now a lot better than it was a
 couple years ago, when in some instances it took a month or more ...
 
 Yes, we have for the most part solved the problem of RCs twisting in the wind.
 Both proposals in this thread will bring that problem back.
 
 Mentor attrition is a fundamental law of the Incubator: because Mentors are
 not core contributors, they fall away at increased rate.  It is not possible
 to change that fact, only to compensate for it.
 
 The wider IPMC has a certain limited capacity for picking up the slack on
 release votes.  Since the end of 2013, we have been using that precious
 capacity wisely.
 
 These proposals squander that capacity and put it all back on the Mentors.
 Some of those Mentors will be unavailable when they are needed, compounding
 the difficulties faced by smaller and more troubled podlings.
 
 Concretely: I think it's perfectly OK to review podling releases after
 the fact. The incubation disclaimer tells users clearly enough that they
 should be extra careful when using releases from incubating projects.
 
 We routinely see problematic release candidates on general@incubator.  It
 would seem that the expertise and temperament for exacting release QC is not
 evenly distributed among the Mentor corps -- just like other valuable skills
 and talents.
 
 Since 2013, the wider IPMC in collaboration with Mentors has been working
 well at cleaning up problematic releases in an expedited manner -- and once a
 podling is producing clean releases regularly, it is probably nearing
 graduation and will not be affected by the extra 3 days for long.  I don't see
 any urgency to change this dynamic.
 
 The other frustration is of course evident in the Ignite graduation
 discussion.
 
 The outcome of the Ignite graduation discussion was never in doubt.  The wider
 IPMC was never going to vote down graduation when there were multiple
 attentive Ignite Mentors united in favor -- it was only a matter of time
 before people came around.
 
 I think the discussion was more voluminous than it needed to be, but I
 attribute that to individual participants sending too many emails in one day.
 1-2 per day on a given thread is a good rate.
 
 In the meantime, interested podling observers got to witness a decent debate
 on project independence and off-list dev discussion -- which is generally one
 of the hardest aspects of Apache-style open development to master.
 
 The only downside of this proposal is that it assumes that every podling
 has at least three active (!) mentors. That doesn't always happen; and
 currently we expect the podling to chase down inactive mentors or find
 new ones. If we adopt Jan's proposal, I'd expect the IPMC to take a more
 active role in finding mentors for podlings.
 
 Recruiting Mentors for podlings at any stage other than entry has always been
 difficult.  It would be deeply unfair to small podlings to establish a policy
 which denies this reality.
 
 Marvin Humphrey
 
 -
 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: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-07-26 Thread Don Bosco Durai

My only concern is now the mentor(s) need to check everything before
approving. In my experience, during the early stages of the releases, lot
of the license, naming, release location, etc. related issues were
identified during the approval in the general@ list. Which were very
helpful to us.

Knowing that the mentors are generally busy, it might be good to have an
extra oversight.

Take a poll among podlings and ask Do you want to be more autonomous
from the IPMC? and see what they say...
We should qualify what autonomous means here.


Thanks

Bosco



On 7/26/15, 8:06 AM, Niclas Hedhman nic...@hedhman.org wrote:

On Sun, Jul 26, 2015 at 7:38 PM, Branko Čibej br...@apache.org wrote:

 The only downside of this proposal is that it assumes that every podling
 has at least three active (!) mentors.

No, I don't necessarily mean that you need 3 mentors either. One active
mentor would be fine with me. Empower the podling to stand on its own
feet.
The Incubation disclaimers are plenty warning, otherwise it would be full
releases.

Take a poll among podlings and ask Do you want to be more autonomous from
the IPMC? and see what they say...

Cheers
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java



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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-07-26 Thread toki



On 07/26/2015 04:35 PM, jan i wrote:

 unless we don't trust the mentors

It isn't a case of not trusting the mentors, but rather, the ease with
which something can be accidentally overlooked.

Rephrased. The mentor is too close to the project, to see all of the
errors in the project.

jonathon



signature.asc
Description: OpenPGP digital signature

RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

Wait. I think this is overstating the displeasure.

I don't see anyone saying the feedback is not valuable. I see mentors being 
asked to clearly state their recommendation with reference to the feedback. The 
thread was too long and argumentative to draw any conclusions.

I also see concerns that these issues are raised at the point of discussing 
graduation. That is too late.

This separate thread goes in a significantly different direction and should jot 
be linked to any specific discuss thread.

Sent from my Windows Phone

From: David Nalleymailto:da...@gnsa.us
Sent: ‎7/‎26/‎2015 12:36 PM
To: general@incubator.apache.orgmailto:general@incubator.apache.org
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the 
Apache Incubator)


 Empower the Mentors to run the podlings, teach the newcomers and bring it
 to TLP.


As a mentor of podlings, I dislike the above idea.

Mentors get busy, they miss things, sometimes big things. Sometimes
things that are obvious to an outsider are missed by mentors who don't
catch it. I've certainly been guilty of missing things, and having an
'outside IPMC member' call attention to that has caused me to go find
not just that problem, but other problems with a podling.

Even on smaller issues, Justin and Sebb run circles around me in
validating that releases comply with policy. I've voted affirmatively
on releases that Justin or Sebb has found issues; occasionally glaring
issues. I do not think that just because I am a mentor on $project and
they aren't invalidates concerns they may raise. I may have additional
insight, and be able to explain things.

Similarly, a vote was brought to the IPMC as to whether or not to
recommend graduation. We asked people to inspect the podling and vote,
and for some reason seem displeased when everyone doesn't unanimously
agree with the mentors. I am not sure whether to interpret that as
'non-mentor IPMC votes are discouraged', or whether 'dissenting
opinions are discouraged'. But telling the body responsible (the IPMC)
to leave podlings in its charge alone, particularly when prompted by a
vote called by the podling itself hardly seems appropriate.

--David

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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)




On 2015-07-26 10:56, jan i wrote:

No that is an important service, on the other hand I also agree that the
mentors should be guiding/running the podlings not general@

Maybe we can find some middle ground.
- Mentors run the podlings, can accept releases etc.
- Mentors decide when a podlng can graduate (maybe with some form of, needs
to accepted by all mentors of the project)
- Any release must be announced (not voted) on general@, so that people
like you have a chance of controlling it just like today.

I think this would make incubator a lot more efficient, reduce our inboxes,
and give us spare time to concentrate on other things.

rgds
jan i.
This is somewhat similar to the 2013 alternate release policy we have, 
whereby the first release has to do the initial IPMC clearance vote, but 
subsequent releases only need the mentors' approval. I believe our 
current policy is sound and has proven itself effective, as you can see 
by the many times a new podling's release has been caught by the policy 
watch dogs we have in the IPMC that specialize in reviewing material 
that is to be released.


Optionally, if we aim to 'save space in our inboxes', we could generate 
a new group of people on a specific ML designed for initial release 
verification, and all _first releases_ would go through that list and 
have things checked, while only sending a NOTICE to the general 
incubator list on successfully released software.


I do not, however, think we should just scrap the current rule of having 
the outside judge the initial release, as it has been shown, time after 
time, that it really does help to have this external review.


With regards,
Daniel.

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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)




On 2015-07-27 01:20, Roman Shaposhnik wrote:


I'd like to raise a somewhat orthogonal point. Mainly the fact that our
obsession with doing good work with podlings could, very well, be
obscuring a much more important issues. And given how limited
our resources of eyeballs looking at releases are -- we need to
be practical.

Now, while I couldn't agree more that IP hygiene of releases is one of
the corner  stones of what makes ASF what it is, I have to be realistic in
accepting the fact that once podling is out of the incubation and becomes a TLP
the level of external scrutiny drops by 90% and all bets are off. Some TLPs
do great releases. Some do really poor ones. Sometimes ppl notify the board.

Once again, I can't be happier that there are folks like Justin who spend
an enormous amount of their personal time helping to vet releases of
podlings. I only ask: should his (and guys like him) time be better applied
to helping foundation make sure that our TLPs are doing what they are
supposed to do as well?

I too am very delighted that we have volunteers who are both willing and 
able to help us through these somewhat dry and dusty areas of releasing 
software. I believe our time is better spent if we educate new podlings 
on proper release and IP procedures, so as to prevent these things from 
happening later on when they are released into the apache wilds with the 
273 other projects, and as such, I think it's better to have these 
checks (and the people doing the checks) in the incubator. Having said 
that, I do realize this puts a lot of pressure on very few people, and 
the asynchronicity of going back and forth between podling and incubator 
is not the optimal way. But I believe this is something the incubator 
needs to teach podlings.


What if, for example, we were to come up with a more automated and 
educational system for this, so as to get it faster through the human 
control? We already have Rat that does most of this, so couldn't we make 
a super rat that does a bit more, specifically designed to educate the 
incubating podlings, maybe a web interface where you just throw a 
tarball at it and it'll tell you what needs to be improved.


Sure, it would have a significant cost in people hours at first, but if 
the Incubator is going to be around for another decade or more, it would 
definitely pay off in the end and make initial releases faster.


I'd be happy to collaborate with others on this, if there is an interest 
in giving it a go.


With regards,
Daniel.

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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

David, I think we've been there before a few month ago.
In my view, you're articulating collective (IPMC) vs.
personal (mentors) responsibility.

IIRC, we came to be on different sides of that divide.

I'll repeat again what I said in that discussion: I like
the mentor responsibility model a LOT for the same
reasons I like PMCs responsibility model. We don't
expect all of the ASF membership to constantly
attend to running every project -- we expect PMC to do
that. We expect the board to be effective at striking
the balance of not micromanaging while at the same
time coming down as a ton of bricks when they do
identify an issue worth reacting to. The model works.
I don't see why it can't work for podlings.

I'll specifically abstain from commenting on the Ignite
graduation (few last paragraphs) since I'd like this
thread to be 100% separate from that discussion.

Thanks,
Roman.

On Sun, Jul 26, 2015 at 12:35 PM, David Nalley da...@gnsa.us wrote:

 Empower the Mentors to run the podlings, teach the newcomers and bring it
 to TLP.


 As a mentor of podlings, I dislike the above idea.

 Mentors get busy, they miss things, sometimes big things. Sometimes
 things that are obvious to an outsider are missed by mentors who don't
 catch it. I've certainly been guilty of missing things, and having an
 'outside IPMC member' call attention to that has caused me to go find
 not just that problem, but other problems with a podling.

 Even on smaller issues, Justin and Sebb run circles around me in
 validating that releases comply with policy. I've voted affirmatively
 on releases that Justin or Sebb has found issues; occasionally glaring
 issues. I do not think that just because I am a mentor on $project and
 they aren't invalidates concerns they may raise. I may have additional
 insight, and be able to explain things.

 Similarly, a vote was brought to the IPMC as to whether or not to
 recommend graduation. We asked people to inspect the podling and vote,
 and for some reason seem displeased when everyone doesn't unanimously
 agree with the mentors. I am not sure whether to interpret that as
 'non-mentor IPMC votes are discouraged', or whether 'dissenting
 opinions are discouraged'. But telling the body responsible (the IPMC)
 to leave podlings in its charge alone, particularly when prompted by a
 vote called by the podling itself hardly seems appropriate.

 --David

 -
 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: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-07-26 Thread Konstantin Boudnik

On Sun, Jul 26, 2015 at 01:38PM, Branko Čibej wrote:
 On 26.07.2015 10:56, jan i wrote:
  On 26 July 2015 at 10:40, Justin Mclean jus...@classsoftware.com wrote:
 
  Hi,
 
  About 40% of the last 100 threads on general@ is vote release... Cut
  that
  away is a good start in reforming the Incubator…
  IMO Which provides a valuable service in showing poddlings on how to make
  good releases. Do we want to get rid of that?
 
  No that is an important service, on the other hand I also agree that the
  mentors should be guiding/running the podlings not general@
 
  Maybe we can find some middle ground.
  - Mentors run the podlings, can accept releases etc.
  - Mentors decide when a podlng can graduate (maybe with some form of, needs
  to accepted by all mentors of the project)
  - Any release must be announced (not voted) on general@, so that people
  like you have a chance of controlling it just like today.
 
  I think this would make incubator a lot more efficient, reduce our inboxes,
  and give us spare time to concentrate on other things.
 
 I like this proposal very much. One of the constant frustrations in the
 podlings I'd mentored was the delay between release bits being ready and
 the IPMC getting around to vote. It's now a lot better than it was a
 couple years ago, when in some instances it took a month or more ...
 
 Concretely: I think it's perfectly OK to review podling releases after
 the fact. The incubation disclaimer tells users clearly enough that they
 should be extra careful when using releases from incubating projects.
 
 The other frustration is of course evident in the Ignite graduation
 discussion.
 
 The only downside of this proposal is that it assumes that every podling
 has at least three active (!) mentors. That doesn't always happen; and
 currently we expect the podling to chase down inactive mentors or find
 new ones. If we adopt Jan's proposal, I'd expect the IPMC to take a more
 active role in finding mentors for podlings.
 
 Other than that, big +1.

I like the idea of the post factum release reviews. It doesn't mean that IPMC
at large aren't welcome to jump in and help with the podling release voting.
Perhaps a sane and courteous thing would be to Cc: general@ on the podling
[VOTE] thread? But +1 even as it stands right now.


One of the moot points that has came up a few times recently about the
diversity clause in the graduation guidelines. Namely:

A major criterion for graduation is to have developed an open and diverse
meritocratic community. Time has demonstrated that these kinds of
communities are more robust and productive than more closed ones.

The semantic of diverse isn't clear and is being interpreted in different
ways. I'd like to propose to change the above paragraph to

A major criterion for graduation is to have developed an open and
meritocratic community. Time has demonstrated that these kinds of
communities are more robust and productive than more closed ones.

to avoid possible confusing interpretations in the future.

Regards,
  Cos


signature.asc
Description: Digital signature

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

Since I am relatively new to the Incubator (given that it turns 13 in 
just 2½ month), I will ask a question that may have been answered in the 
earlier years:


Have we given any thought to some sort of mentor rotation policy?

One could argue that what we especially lack right now is the 'outsider' 
view on podlings before it is 'too late', so perhaps changing (or at 
least adding some new) mentors along the way, not just by choice, but by 
design/policy, we could perhaps, just perhaps, catch some potential 
cases of myopia or in the loop issues that seems to, arguably, be the 
cause of some of the concerns raised lately.


I realize that this, with the ASF being an all volunteer org, is not 
something you simply implement in a fortnight, but I think it's worth 
discussing.


With regards,
Daniel.

On 2015-07-26 22:33, Ted Dunning wrote:

I think my own experience as a mentor over recent years is useful here.  I 
thought I understood what was necessary for apache releases when, in fact, I 
understood release requirements for releases like the ones I had previously 
seen.

The wider by shepherds and by the general votes was a pain because of the added 
delay but it substantially increased the quality of the releases and improved 
the processes the group had.

With more perspective now, I find that individual mentors often have somewhat 
specialized expertise and my experience was absolutely not unique.

Marvin and Ross also make good and important points orthogonal to this.





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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

On Sun, Jul 26, 2015 at 1:56 AM, jan i j...@apache.org wrote:
 No that is an important service, on the other hand I also agree that the
 mentors should be guiding/running the podlings not general@

 Maybe we can find some middle ground.
 - Mentors run the podlings, can accept releases etc.
 - Mentors decide when a podlng can graduate (maybe with some form of, needs
 to accepted by all mentors of the project)
 - Any release must be announced (not voted) on general@, so that people
 like you have a chance of controlling it just like today.

 I think this would make incubator a lot more efficient, reduce our inboxes,
 and give us spare time to concentrate on other things.

I really like this idea. Huge +1. How can we, please, make it a reality?
Do we need to draft a new set of by laws/policies for the IPMC or is
there a more gradual approach to putting this into practice?

Thanks,
Roman.

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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

On Sun, Jul 26, 2015 at 9:50 AM, toki toki.kant...@gmail.com wrote:


 On 07/26/2015 04:35 PM, jan i wrote:

 unless we don't trust the mentors

 It isn't a case of not trusting the mentors, but rather, the ease with
 which something can be accidentally overlooked.

 Rephrased. The mentor is too close to the project, to see all of the
 errors in the project.

An how is this different from TLP's PMC?

Thanks,
Roman.

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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

On Sun, Jul 26, 2015 at 3:57 PM, Daniel Gruno humbed...@apache.org wrote:


 On 2015-07-26 10:56, jan i wrote:

 No that is an important service, on the other hand I also agree that the
 mentors should be guiding/running the podlings not general@

 Maybe we can find some middle ground.
 - Mentors run the podlings, can accept releases etc.
 - Mentors decide when a podlng can graduate (maybe with some form of,
 needs
 to accepted by all mentors of the project)
 - Any release must be announced (not voted) on general@, so that people
 like you have a chance of controlling it just like today.

 I think this would make incubator a lot more efficient, reduce our
 inboxes,
 and give us spare time to concentrate on other things.

 rgds
 jan i.

 This is somewhat similar to the 2013 alternate release policy we have,
 whereby the first release has to do the initial IPMC clearance vote, but
 subsequent releases only need the mentors' approval. I believe our current
 policy is sound and has proven itself effective, as you can see by the many
 times a new podling's release has been caught by the policy watch dogs we
 have in the IPMC that specialize in reviewing material that is to be
 released.

 Optionally, if we aim to 'save space in our inboxes', we could generate a
 new group of people on a specific ML designed for initial release
 verification, and all _first releases_ would go through that list and have
 things checked, while only sending a NOTICE to the general incubator list on
 successfully released software.

 I do not, however, think we should just scrap the current rule of having the
 outside judge the initial release, as it has been shown, time after time,
 that it really does help to have this external review.

I'd like to raise a somewhat orthogonal point. Mainly the fact that our
obsession with doing good work with podlings could, very well, be
obscuring a much more important issues. And given how limited
our resources of eyeballs looking at releases are -- we need to
be practical.

Now, while I couldn't agree more that IP hygiene of releases is one of
the corner  stones of what makes ASF what it is, I have to be realistic in
accepting the fact that once podling is out of the incubation and becomes a TLP
the level of external scrutiny drops by 90% and all bets are off. Some TLPs
do great releases. Some do really poor ones. Sometimes ppl notify the board.

Once again, I can't be happier that there are folks like Justin who spend
an enormous amount of their personal time helping to vet releases of
podlings. I only ask: should his (and guys like him) time be better applied
to helping foundation make sure that our TLPs are doing what they are
supposed to do as well?

Thanks,
Roman.

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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

2015-07-26 Thread David Nalley

On Sun, Jul 26, 2015 at 8:41 PM, Ross Gardler
ross.gard...@microsoft.com wrote:
The proposed need to announce release votes on the IPMC list is how things
were when the incubator was created. The need for IPMC to control the process
is another case of the IPMC over-reaching itself and in so doing causing
problems by creating a bottleneck in the process.

It used to be that it was only required to *notify* the IPMC of a release
vote underway. Thereby giving interested IPMC members the opportunity to
review artifacts and processes during the normal release cycle. IPMC members
were expected to cast their votes on the PPMC list where such things belong.

I'd love to see links to that - my digging didn't find it. (see below)

I'm not sure where this idea that the vote actually occurs on the IPMC list
came from but it's flat wrong in my opinion (someone may dig through the
archives and find a good reason it was changed, but my feeling is that it
changed gradually through edits-on-edits-on-edits of the incubation policy).

The fact is that the PPMC (with IPMC representation from the mentors) should
be in charge of their releases, and pretty much everything else. The IPMC
role is one of teaching the PPMC how manage itself. Mentors should do this
through mentoring and the IPMC should ensure it is done through an
appropriate level of oversight (not an inappropriate amount of control).

Consider this... The board does not bring TLP release votes to board@, why on
earth must the IPMC do so?

I've half a mind to got back the wayback machine and pull the original
incubator polices and propose them as the new policies (yes, some changes
have been good, but it seems to me that many have not)

So I couldn't find anything in 2003, but 2004 has this page[1] which
included the text:

Podlings in Incubation SHALL NOT perform any releases of software
without the explicit approval of the Incubator PMC. Such approval
SHALL be given only after the Incubator PMC has followed the process
detailed in (Reference to Charter), and SHALL NOT occur until all
source has been legally transferred to the ASF.

and

Therefore, should a Podling decide it wishes to perform a release,
the Podling SHALL formally request the Incubator PMC approve such a
release. The request SHALL have the endorsement of the Mentor.

So it seems that this has been with us for a long while.

[1]
https://web.archive.org/web/20041010183702/http://incubator.apache.org/incubation/Incubation_Policy.html#Releases%0A

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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)




On 2015-07-27 00:04, Ross Gardler wrote:

Wait. I think this is overstating the displeasure.

I don't see anyone saying the feedback is not valuable. I see mentors being 
asked to clearly state their recommendation with reference to the feedback. The 
thread was too long and argumentative to draw any conclusions.

I also see concerns that these issues are raised at the point of discussing 
graduation. That is too late.
At risk of nitpicking on semantics; Discussing graduation should be 
about whether or not a project is ready to graduate, should it not? 
There should not be a moment in a podling's life, past a completed 
graduation vote, where it is too late to voice your concern, 
otherwise, what's the point of having a discussion if it's expected that 
everyone agrees?


As stated elsewhere, unfortunately we have situations where a lot of 
topics that should have been covered at an earlier stage suddenly comes 
up during a graduation discussion, or in the horrible cases, during a 
graduation vote. We should strive to have as few of these moments as 
possible - possibly by redesigning the incubator process a bit to 
address this - , but I don't think we neither should nor can 'outlaw' 
this. This is the 'point of no return' so to speak, and while I would 
really love for this to be a walk in the park every single time (because 
we did our homework in time), there will be cases where both mentors and 
IPMC members have missed things (for various reasons), and until we 
actually come up with a good replacement for please take a good look at 
our podling that actually works and engages people besides the mentors, 
this will remain the point in time where podlings are under the most 
scrutiny.


To sum up: I think the attitude is a bit skewed here. We should not be 
negative about a final big push, we should be glad that it exists - as 
it shows people _can_ take the time to look into what's going on in 
podlings - and look into why this manages to garner extra effort from 
our volunteers and how we can encourage and incentivize them to do this 
at an earlier stage.


Maybe we need a 'half way' discussion/review, maybe we need something 
else. What we have right now does not seem to give the desired result.


I'll get some sleep, have some FOSS dreams (or the usual surreal ones 
with a hedgehog chasing a lion) and see if I can't come up with a more 
specific proposal for tomorrow :)


With regards,
Daniel.



This separate thread goes in a significantly different direction and should jot 
be linked to any specific discuss thread.

Sent from my Windows Phone

From: David Nalleymailto:da...@gnsa.us
Sent: ‎7/‎26/‎2015 12:36 PM
To: general@incubator.apache.orgmailto:general@incubator.apache.org
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the 
Apache Incubator)


Empower the Mentors to run the podlings, teach the newcomers and bring it
to TLP.


As a mentor of podlings, I dislike the above idea.

Mentors get busy, they miss things, sometimes big things. Sometimes
things that are obvious to an outsider are missed by mentors who don't
catch it. I've certainly been guilty of missing things, and having an
'outside IPMC member' call attention to that has caused me to go find
not just that problem, but other problems with a podling.

Even on smaller issues, Justin and Sebb run circles around me in
validating that releases comply with policy. I've voted affirmatively
on releases that Justin or Sebb has found issues; occasionally glaring
issues. I do not think that just because I am a mentor on $project and
they aren't invalidates concerns they may raise. I may have additional
insight, and be able to explain things.

Similarly, a vote was brought to the IPMC as to whether or not to
recommend graduation. We asked people to inspect the podling and vote,
and for some reason seem displeased when everyone doesn't unanimously
agree with the mentors. I am not sure whether to interpret that as
'non-mentor IPMC votes are discouraged', or whether 'dissenting
opinions are discouraged'. But telling the body responsible (the IPMC)
to leave podlings in its charge alone, particularly when prompted by a
vote called by the podling itself hardly seems appropriate.

--David

-
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: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

The proposed need to announce release votes on the IPMC list is how things were 
when the incubator was created. The need for IPMC to control the process is 
another case of the IPMC over-reaching itself and in so doing causing problems 
by creating a bottleneck in the process. 

It used to be that it was only required to *notify* the IPMC of a release vote 
underway. Thereby giving interested IPMC members the opportunity to review 
artifacts and processes during the normal release cycle. IPMC members were 
expected to cast their votes on the PPMC list where such things belong. 

I'm not sure where this idea that the vote actually occurs on the IPMC list 
came from but it's flat wrong in my opinion (someone may dig through the 
archives and find a good reason it was changed, but my feeling is that it 
changed gradually through edits-on-edits-on-edits of the incubation policy). 

The fact is that the PPMC (with IPMC representation from the mentors) should be 
in charge of their releases, and pretty much everything else. The IPMC role is 
one of teaching the PPMC how manage itself. Mentors should do this through 
mentoring and the IPMC should ensure it is done through an appropriate level of 
oversight (not an inappropriate amount of control).

Consider this... The board does not bring TLP release votes to board@, why on 
earth must the IPMC do so?

I've half a mind to got back the wayback machine and pull the original 
incubator polices and propose them as the new policies (yes, some changes 
have been good, but it seems to me that many have not)

Ross

-Original Message-
From: Konstantin Boudnik [mailto:c...@apache.org] 
Sent: Sunday, July 26, 2015 5:15 PM
To: general@incubator.apache.org
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the 
Apache Incubator)

On Sun, Jul 26, 2015 at 01:38PM, Branko Čibej wrote:
 On 26.07.2015 10:56, jan i wrote:
  On 26 July 2015 at 10:40, Justin Mclean jus...@classsoftware.com wrote:
 
  Hi,
 
  About 40% of the last 100 threads on general@ is vote release... 
  Cut
  that
  away is a good start in reforming the Incubator…
  IMO Which provides a valuable service in showing poddlings on how 
  to make good releases. Do we want to get rid of that?
 
  No that is an important service, on the other hand I also agree that 
  the mentors should be guiding/running the podlings not general@
 
  Maybe we can find some middle ground.
  - Mentors run the podlings, can accept releases etc.
  - Mentors decide when a podlng can graduate (maybe with some form 
  of, needs to accepted by all mentors of the project)
  - Any release must be announced (not voted) on general@, so that 
  people like you have a chance of controlling it just like today.
 
  I think this would make incubator a lot more efficient, reduce our 
  inboxes, and give us spare time to concentrate on other things.
 
 I like this proposal very much. One of the constant frustrations in 
 the podlings I'd mentored was the delay between release bits being 
 ready and the IPMC getting around to vote. It's now a lot better than 
 it was a couple years ago, when in some instances it took a month or more ...
 
 Concretely: I think it's perfectly OK to review podling releases after 
 the fact. The incubation disclaimer tells users clearly enough that 
 they should be extra careful when using releases from incubating projects.
 
 The other frustration is of course evident in the Ignite graduation 
 discussion.
 
 The only downside of this proposal is that it assumes that every 
 podling has at least three active (!) mentors. That doesn't always 
 happen; and currently we expect the podling to chase down inactive 
 mentors or find new ones. If we adopt Jan's proposal, I'd expect the 
 IPMC to take a more active role in finding mentors for podlings.
 
 Other than that, big +1.

I like the idea of the post factum release reviews. It doesn't mean that IPMC 
at large aren't welcome to jump in and help with the podling release voting.
Perhaps a sane and courteous thing would be to Cc: general@ on the podling 
[VOTE] thread? But +1 even as it stands right now.


One of the moot points that has came up a few times recently about the 
diversity clause in the graduation guidelines. Namely:

A major criterion for graduation is to have developed an open and diverse
meritocratic community. Time has demonstrated that these kinds of
communities are more robust and productive than more closed ones.

The semantic of diverse isn't clear and is being interpreted in different 
ways. I'd like to propose to change the above paragraph to

A major criterion for graduation is to have developed an open and
meritocratic community. Time has demonstrated that these kinds of
communities are more robust and productive than more closed ones.

to avoid possible confusing interpretations in the future.

Regards,
  Cos

-
To unsubscribe, e

RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)