incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Lautenbach <>
Subject Re: Another cut at roles and responsibilities
Date Wed, 24 Sep 2003 12:22:45 GMT

Firstly - thanks for all the thoughts.  Great stuff!  (I think.  Grumble 
grumble, more work, mutter mutter :>)

You are more than welcome to update anything in the document you so 
desire.  However that's not a hint - am happy to (and will tomorrow) 
take all this on board and make the changes.

Before I do, some thoughts on your notes, so that people can see what 
I'm going to do.

Cliff Schmidt wrote:

> ------
> *  Starting with the last sentence in the first paragraph of the
> Establishment section, the draft begins to address the people involved
> in the candidate project, but there are large sections of the document
> that are not addressing anyone and just describing the process (probably
> related to the fact that the document has multiple authors).  If this
> document is meant to address people of all roles, I suggest removing
> the instances of "you" and "your".

I see this document as a non-normative "what you need to do" document. 
So I think it is appropriate to address it as a document to a proposer 
(i.e. "you" and "your").  "This is what you are going to go through".

The normative policy document on the other hand would be more formal, 
and use the RFC (can't remember number) that defines policy terms such 
as SHALL, WILL, WOULD etc.  This would not be addressed to a person.

On the web site, the first part of the document would be the 
description, linking off to other documents.  The 
roles-and-resposibilities might be less "you/your" and would be on a 
separate page.

Does that sound fair?

> * How does one, who isn't familiar with Apache, find a Sponsor?  One 
> extreme would be to set up a mailing list like "looking-for-a-sponsor at
>" that would be subscribed by all members/officer who would be
> willing to consider taking such a role.  The other extreme is to leave
> it to the individual to figure it out (if they really care they'll find
> a way).  However, without a list, I think links [1][2] should be included 
> to at least let the proposer discover who is even authorized to be a 
> Sponsor.  Incidentally, I found my sponsor (Steven Noels) when we were
> both speaking at XML Europe 2003, otherwise I didn't know anyone here
> (actually I did, but I didn't know it at the time).

Good thought.  I will add something in.  Those two links are a great 
start, and I might also put something about finding a project that looks 
to be related (e.g. XML and Jakarta for XMLBeans) and subscribing to the 
general@ lists as a lurker for a period of time to see how things work.

> * Either in the Establishment section, or the Sponsor section, it might 
> be worth noting that the Sponsor can help those behind a potential 
> candidate project understand the general "Apache Way" before even 
> proposing the project and possibly wasting everyone's time.  While we
> would rarely want to encourage private conversations, I think private 
> consultation between a neophyte proposer and the Sponsor may be in 
> everyone's best interests.  Of course, this will be less important as
> we have more good docs like this one. ;-)

Yes.  Very good point.  The whole reason for Incubation is the "Apache 
Way", so it's better to ensure people find out what this is early and 
what it might mean.  This is especially useful in a document like this 
that is supposed to be an "informal" guide to prospecitve incubees.

> * If this doc is meant to be read by a new proposer, some of the 
> references to "relevant mailing lists" and "either pmc@ or board@" may
> need to be spelled out a little more somewhere.  Maybe an appendix
> of useful mailing lists?

<GRIN>.  Yes it is a bit cryptic isn't it.

> * In the Sponsor and Candidate sections, it states that the Sponsor 
> presents the Candidate's proposal to the Sponsoring Entity.  Does this 
> mean that someone behind the proposal will not be the one sending 
> out the first public proposal to general@{sponsoring entity} and cc'ing 
> Incubator?  Or does this just mean that the Sponsor will be standing
> by to help moderate the discussion/explain things that the initial 
> proposers cannot?  

No, it was supposed to mean that the Sponsor is there to help (your 
second definition).  I will clean up.

> * Should a proposal template be attached to this document (another 
> appendix)?  XMLBeans used the Jakarta new subproject guidelines [3] 
> as a template, because I'd seen others use it, but I don't think it 
> has been an official practice.  Seems like it could be a helpful thing
> to formalize.

For now, a link to the Jakarta guidelines seems sensible, until we have 
had an opportunity to plagiarise it into an Incubator document :>.

> * In either the Sponsoring Entity section or Shepherd section, I would
> consider explicitly stating that another responsibility/good reason
> for the involvement of the TLP Sponsoring Entity (not the board or 
> Incubator PMC) is to educate the Candidate about practices specific to
> the sponsoring TLP, and about other subprojects that could relate to 
> the Candidate.

Yup.  Will do.

> * Since the doc spells out the roles so clearly, I would replace the
> first instance of "Apache Administration" with "ASF Secretary" and the
> second instance with "ASF Infrastructure team".

Yup.  Will do.

> * "On acceptance of a candidate project, the assigned Shepherd and 
> nominated Sponsor shall be added to the set of committers for the 
> duration of the incubation process."  Does this mean that these two
> are removed from being committers on the project once it escalates?
> Also, the general idea of automatically giving specific people
> committership seems somewhat contrary to a meritocracy.  I actually
> don't think this is a bad idea; it just seems a little messy and 
> somewhat inconsistent.

I remember a similar discussion with Ted and Steve early in the 
Incubation process.  I agree that this is not necessarily the case, but 
I will bow to the superior wisdom of the consensus of this list.


> * "keep your Shepherd informed" and ""  We may 
> want to say this can be greatly aided by conducting business on the 
> -dev list, which can be monitored by these two.  I would think most 
> of what a Shepherd needs to report can be determined by looking at 
> the -dev list.

Will do.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message