BTW - Have checked changes in - how do I update the site?
Nicola Ken Barozzi wrote:
My understanding was that there will always be a PMC (or the board) that accepts a candidate on behalf of the ASF. Where there is no Sponsor, the Incubator PMC acts in that role and votes to accept the candidate (thus becoming the Sponsor). The documentation is currently written this way, with the caveat that where the Incubator PMC is the sponsor, one of the exit criteria will be finding an owner on exit. (Owner might be the board for a Pod/Podling that becomes a TLP.)
I agree with Noel, the Sponsor is simply the entity or the person that *advocates* the project to be part of the ASF. But then we come back to the "Sponsoring Entity" thing to say who will accept it.
I am getting a bit lost here :>. When I said "Sponsor" above, I meant in the sense of the "Sponsoring Entity". So, as I understand what has been agreed, there must be some Sponsor (PMC or board) that agrees to the project on behalf of the ASF. Which is all I was trying to say.
Correct. It is me who has not been clear here.
What the above phrase is trying to say is that if we define Sponsor as who advocates the entrance of the project in the ASF, we would need to define Sponsoring Entity again, which defeats the whole purpose of the current redefinition.
In essence, I agree that we should not change the current meaning of Sponsor, that is exactly what you mean.
Or have I missed the point somewhere? (Entirely possible, we have just moved to daylight savings and it's killing me :>).
Yeah, same here :-(
In any case, do we *need* to define the "champion"? I mean, take the case in which a project proposes itself to a PMC, and the PMC votes to have it come in... there is no "champion", and no need for one.
Absolutely not...for the policy. In the policy document it is only mentioned right at the start as there being a requirement for an Apache Member to nominate a project.
Exactly.
That's a carry over from previous documentation - I have tried not to remove requirements that were in the old versions, but am happy to do so on agreemetn from this list.
For the process description though, I *think* it's kind of useful to define. Not because it is directly important from the ASF's perspective, but because it can be incredibly helpful for potential podlings to have someone who helps them understand the "Apache Way", and who helps them through that initial process.
This is the definition of Mentor, if you take out the fact that the project is not in Incubation yet. If we assume that Mentors can change when the project is accepted, it's simply the Mentor, ie the one that guides the project into Apache.
Not something that is important to define formally, but something we might want to encourage potential candidates to do.
Hence, I'd simply remove the definition of "champion" at this point, as it seems irrelevent to the definition of the process from our POV.
This does not mean that there cannot be Apache members that actually champion a project, but it's not strictly necessary for incubation.
[same thing for issue trackers, they can be used but we don't require them]
So, to be absolutely clear on my perspective -
1. The policy document is the normative reference to incubation. It is lean and mean and defines only that which absolutely needs to be defined to satisfy ASF incubation requirements and to ensure the process is repeatable. I would be happy to take Champion out of this.
Ok.
2. The process document is not for us - it is for those who might be thinking about incubation. It is not normative, and it *should* have things like issue trackers and champions. Not because we are mandating them, but because discussing these things might help candidates understand the process a bit better. I believe champions have helped some, so lets keep it in the descriptive document to maybe help others.
This distinction between policy and process is not clear to me at all. From looking at the docs I don't see it, and it's some time that I ask myself why we have different docs. IMO to make things clear there should be only one document that is clearly normative.
Proposal:
We keep a single policy document as our reference and make the process doc into HOWTOs.
- Process HOWTO - Mentor HOWTO - Sponsor HOWTO - Incubating Project HOWTO - etc...
Forrest has a HOWTO DTD, so we can use that.
As for Jason's comment, I agree. If we can get away with special jargon, it's better. We have done it with Shepherd->Mentor, and we may as well do it for /podling/.
Very happy to change it. From my perspective I just picked it up from the earlier documentation :>.
Yup.
This is what we mean: http://www.geobaby.com/forum/showthread.php?threadid=103478
This is what users may find instead: http://dict.die.net/podling/
Hence what about simply "Incubating Project" or "Incubated Project" or "Project being incubated"?
Incubee?
Hmmm...
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
------------------------------------------------------------------------------------------------------------------------------------------ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
