Clear expectations

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

On Sat, Jan 10, 2015 at 12:41 PM, Jim Jagielski <ji...@jagunet.com> wrote:

> Considering that both detailed answers as well and more "philosophical"
> answers don't satisfy, I am at a loss to what approach to try next.

The Board should endorse a document establishing what Apache expects of
its projects.

This document must be as short as possible -- ideally no more than a
single screenful.  It should link to definitive resources rather than
introduce competing language, and it should only codify existing
requirements, not add new ones.  Modification should require prior
approval by a curating entity.

The resources that this document will need to reference (release, legal
voting, infra, security, etc) have varying levels of maturity.  Separate
efforts to codify satellite resources are important, since those often
have amorphous boundaries themselves -- but that does not block the
establishment of a root document.

Shane Curcuru has submitted a first draft.  It needs significant
refinement, but I believe that it is conceptually sound.

    https://www.apache.org/dev/project-requirements

Development discussions for this document should take place in a public
forum -- probably dev@community.

Eventual Board endorsement of this document as an authoritative resource
is essential.  That's what allows those who consult it to have confidence
that they can know everything Apache requires without having to search
through every last web page and email archive.

Marvin Humphrey

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

Re: Clear expectations

[Roman Shaposhnik <ro...@shaposhnik.org>]

On Sun, Jan 11, 2015 at 7:18 PM, Benson Margulies <bi...@gmail.com> wrote:
> I have an complementary suggestion to Marvin's push for documentation. My
> request is for a much clearer channel of communication to the board. All
> too often, projects wind up communicating with individuals; some board
> members, some not. Those individuals are in an unclear state of headware.
> Board members are always free to express their personal gut reaction, but I
> find that much confusion results from mistaking a gut reaction for an _ex
> cathedra_ statement -- and, in the end, board members don't even own such
> seats. Only the board together can issue a binding ruling. Since we're
> talking IPMC here, perhaps the solution is for the VP to even more actively
> take the role of 'bring your troubles to me, and I'll take them up with the
> board if I can't settle it.'

I've see that as the most frequent culprit: folks who are new to our game
failing to tell apart opinions of the individuals and an opinion of the board.

That's why I was so enthusiastically +1 on Marvin's suggestion of codifying
at least the few commandments that the *board* can agree upon.

Thanks,
Roman.

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

RE: Clear expectations

["Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>]

Well with that clarification I'm a very strong +1 on everything you said :-)

Ross

-----Original Message-----
From: Marvin Humphrey [mailto:marvin@rectangular.com] 
Sent: Tuesday, January 13, 2015 6:49 PM
To: general@incubator.apache.org
Cc: Shane Curcuru
Subject: Re: Clear expectations

On Tue, Jan 13, 2015 at 1:36 PM, Ross Gardler (MS OPEN TECH) <Ro...@microsoft.com> wrote:

> Can you please expand on "I think the answer starts with the very 
> skepticism of top-down governance which has in large part kept us from 
> having clear rules up till now."
>
> I'm not clear on what the "skepticism" is that you refer to as these 
> threads have indicated that there are at least two very different 
> views on whether there is, or is not, top down governance in the ASF.

I meant to tip my hat to those who have spared Apache from adopting cumbersome absolute rules over the years.  By "skeptics", I was thinking of people who, when presented with an elaborate policy proposal, question whether some or all of it is truly required.

It's clear that this undertaking calls for a "governs best which governs least" approach.  We want the simplest rules possible; committing to concrete language is inherently constraining, and we want to minimize that effect.

But just because Apache's requirements are underspecified right now doesn't mean we don't have any.  Establishing where the rules begin and end will allow projects to spend less time researching and arguing over what is required.

Projects may even discover newfound flexibility.  For example, when the Incubator PMC clarified its collective understanding of release policy, it became able to reach consensus on approving many release candidates which would previously have been sent back.

Marvin Humphrey

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

Re: Clear expectations

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

On Tue, Jan 13, 2015 at 1:36 PM, Ross Gardler (MS OPEN TECH)
<Ro...@microsoft.com> wrote:

> Can you please expand on "I think the answer starts with the very skepticism
> of top-down governance which has in large part kept us from having clear
> rules up till now."
>
> I'm not clear on what the "skepticism" is that you refer to as these threads
> have indicated that there are at least two very different views on whether
> there is, or is not, top down governance in the ASF.

I meant to tip my hat to those who have spared Apache from adopting cumbersome
absolute rules over the years.  By "skeptics", I was thinking of people who,
when presented with an elaborate policy proposal, question whether some or all
of it is truly required.

It's clear that this undertaking calls for a "governs best which governs
least" approach.  We want the simplest rules possible; committing to concrete
language is inherently constraining, and we want to minimize that effect.

But just because Apache's requirements are underspecified right now doesn't
mean we don't have any.  Establishing where the rules begin and end will allow
projects to spend less time researching and arguing over what is required.

Projects may even discover newfound flexibility.  For example, when the
Incubator PMC clarified its collective understanding of release policy, it
became able to reach consensus on approving many release candidates which
would previously have been sent back.

Marvin Humphrey

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

RE: Clear expectations

["Ross Gardler (MS OPEN TECH)" <Ro...@microsoft.com>]

Marvin,

Can you please expand on "I think the answer starts with the very skepticism of top-down governance which has in large part kept us from having clear rules up till now."

I'm not clear on what the "skepticism" is that you refer to as these threads have indicated that there are at least two very different views on whether there is, or is not, top down governance in the ASF.

Ross

-----Original Message-----
From: Marvin Humphrey [mailto:marvin@rectangular.com] 
Sent: Tuesday, January 13, 2015 1:27 PM
To: general@incubator.apache.org; Shane Curcuru
Subject: Re: Clear expectations

On Sun, Jan 11, 2015 at 7:18 PM, Benson Margulies <bi...@gmail.com> wrote:
> Does it help anything to look at this, again, as failure modes?

How about this failure mode?

A podling receives thorough instruction on some policy during incubation.
After graduation, that policy gets violated, but most PMC members don't speak up because the rules are messy and poorly documented and they don't have enough confidence in their understanding to pursue the matter.

Is that failure mode even related to the Incubator?  Though you could argue that the passive PMC members did not learn to escalate, the main lesson I take from it is that unclear requirments are a problem for TLPs and the larger organization.

The Incubator is teaching from an inadequate spec.  That's a problem for us in that it wastes the time of Mentors and podlings.  But the spec's inadequacy does not originate with the Incubator.  The Incubator doesn't own that problem.

The question I'd ask is, How can Apache create an awesome spec that's easy to teach, easy to learn, and easy to follow?

I think the answer starts with the very skepticism of top-down governance which has in large part kept us from having clear rules up till now.  That skepticism must be applied aggressively at every step of the way to ensure that we require no more than the bare minimum.

Marvin Humphrey

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

Re: Clear expectations

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

On Sun, Jan 11, 2015 at 7:18 PM, Benson Margulies <bi...@gmail.com> wrote:
> Does it help anything to look at this, again, as failure modes?

How about this failure mode?

A podling receives thorough instruction on some policy during incubation.
After graduation, that policy gets violated, but most PMC members don't speak
up because the rules are messy and poorly documented and they don't have
enough confidence in their understanding to pursue the matter.

Is that failure mode even related to the Incubator?  Though you could argue
that the passive PMC members did not learn to escalate, the main lesson I take
from it is that unclear requirments are a problem for TLPs and the larger
organization.

The Incubator is teaching from an inadequate spec.  That's a problem for us in
that it wastes the time of Mentors and podlings.  But the spec's inadequacy
does not originate with the Incubator.  The Incubator doesn't own that
problem.

The question I'd ask is, How can Apache create an awesome spec that's easy to
teach, easy to learn, and easy to follow?

I think the answer starts with the very skepticism of top-down governance
which has in large part kept us from having clear rules up till now.  That
skepticism must be applied aggressively at every step of the way to ensure
that we require no more than the bare minimum.

Marvin Humphrey

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

Re: Clear expectations

[Benson Margulies <bi...@gmail.com>]

Does it help anything to look at this, again, as failure modes?

One failure mode is a project that emerges from the incubator showing,
well, gross signs that it 'doesn't get it.'

Another failure mode is that a group of people who really do get it, at the
level of the broad principles, get into trouble trying to translate those
principles into very practical matters, due to conflicting sources of
authority and documentation.

Talking about one of these does not invalidate the other as a concern.

I have an complementary suggestion to Marvin's push for documentation. My
request is for a much clearer channel of communication to the board. All
too often, projects wind up communicating with individuals; some board
members, some not. Those individuals are in an unclear state of headware.
Board members are always free to express their personal gut reaction, but I
find that much confusion results from mistaking a gut reaction for an _ex
cathedra_ statement -- and, in the end, board members don't even own such
seats. Only the board together can issue a binding ruling. Since we're
talking IPMC here, perhaps the solution is for the VP to even more actively
take the role of 'bring your troubles to me, and I'll take them up with the
board if I can't settle it.'

Re: Clear expectations

[Roman Shaposhnik <ro...@shaposhnik.org>]

On Sun, Jan 11, 2015 at 4:45 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
> On Sat, Jan 10, 2015 at 12:41 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>
>> Considering that both detailed answers as well and more "philosophical"
>> answers don't satisfy, I am at a loss to what approach to try next.
>
> The Board should endorse a document establishing what Apache expects of
> its projects.
>
> This document must be as short as possible -- ideally no more than a
> single screenful.  It should link to definitive resources rather than
> introduce competing language, and it should only codify existing
> requirements, not add new ones.  Modification should require prior
> approval by a curating entity.
>
> The resources that this document will need to reference (release, legal
> voting, infra, security, etc) have varying levels of maturity.  Separate
> efforts to codify satellite resources are important, since those often
> have amorphous boundaries themselves -- but that does not block the
> establishment of a root document.
>
> Shane Curcuru has submitted a first draft.  It needs significant
> refinement, but I believe that it is conceptually sound.
>
>     https://www.apache.org/dev/project-requirements
>
> Development discussions for this document should take place in a public
> forum -- probably dev@community.
>
> Eventual Board endorsement of this document as an authoritative resource
> is essential.  That's what allows those who consult it to have confidence
> that they can know everything Apache requires without having to search
> through every last web page and email archive.

Huge +1 (especially in the poddlings context)

Thanks,
Roman.

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