incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Common naming accross policy/process/roles
Date Mon, 27 Oct 2003 09:28:58 GMT
Berin Lautenbach wrote:

> 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                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------



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


Mime
View raw message