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:
NOTES ------ * 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
apache.org" 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 [EMAIL PROTECTED] 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.
Others?
* "keep your Shepherd informed" and "Sponsor...in-the-loop" 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.
Cheers,
Berin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
