You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Steven Noels <st...@outerthought.org> on 2003/07/29 11:05:39 UTC
Discussion of Cocoon TLP Guidelines
Dear all,
I've just checked in a verbatim copy of the Jakarta Guidelines (located
at http://jakarta.apache.org/site/proposal.html) in the cocoon-site
module, that could serve as a starter to base our own project guidelines
upon. Before we became a TLP (top level project), we were supposed to
follow the XML TLP guidelines (which are currently under debate, a
decent RC can be found at
http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt?rev=1.14&content-type=text/vnd.viewcvs-markup),
but after reading both, I believe the Jakarta guidelines might be a good
foundation to start working from. The guidelines are supposed to
regulate the day-to-day operations of the Cocoon TLP, which of course
includes any existing and possible new subprojects.
So in an attempt to start the debate about the Cocoon TLP guidelines, I
copy/paste/search/replaced through the Jakarta set of guidelines, and
provide this as a starter for further discussions.
Our DRAFT version is located at
http://cvs.apache.org/viewcvs.cgi/cocoon-site/src/documentation/content/xdocs/guidelines.xml?rev=1.1&content-type=text/vnd.viewcvs-markup
Some topics which, IMHO, need further debate are:
- PMC composition and rules for admitting new PMC members (currently,
any committer can self.propose() to become a member of the PMC, and any
committer is allowed on the PMC list - but we need to discuss, maybe
change and at the very least formalize this)
- rules and guidelines for incubating projects, w.r.t. PMC
participation, cohabitation with Incubator guidelines
- basically do a sanity check of the lenghty Jakarta original and see
what might be eradicated from it (less is more)
- check voting guidelines
I would suggest to start the discussion over here
(dev@cocoon.apache.org), we can move to the Wiki if discussing the
document becomes too difficult, and in any case I'd like to use the
formal CVS logs as a change tracking mechanism ASAP - hence putting a
draft in CVS rather than in the Wiki. I will come up with some patches
myself, but not directly in CVS, I'd like to run them through the list.
Please take your time reading through it, it ain't as bad as it looks
like, and it concerns you: developers & contributors of the Cocoon
project(s). And let's try and keep this as lightweight as feasible.
If it comes to (a) vote(s), anybody's opinion is appreciated, so please
speak up. Binding votes about the Cocoon guidelines can be cast by
Cocoon committers only - the original members of the 'founding' PMC that
is. If that would need to be changed, it's the time to implement that,
as well.
Thanks for your attention,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Discussion of Cocoon TLP Guidelines
Posted by Steven Noels <st...@outerthought.org>.
On 30/07/2003 0:13 Michael Wechner wrote:
> Steven Noels wrote:
>
>>
>>
>> If it comes to (a) vote(s), anybody's opinion is appreciated, so
>> please speak up. Binding votes about the Cocoon guidelines can be cast
>> by Cocoon committers only - the original members of the 'founding' PMC
>> that is.
>
>
> I guess that as long as Lenya is under incubation, Lenya committers
> won't be able to vote, right?
>
> Which is fine with personally, but I think it's important to clarify
> what you mean by *original members of the 'founding' PMC*
the situation with xml.apache.org is that all committers can vote for
new subproject proposals (and it needs a majority vote), and that PMC
peeps get to vote on chapter changes IIUC
of course, we are setting everything up as we go along, and it's a bit
of a chicken/egg problem: *we* should decide whether committers of
incubating projects can cast binding votes in this matter, and if I
state that such 'incubating' committers are allowed to vote on such a
decision, well... I think the outcome would be pretty obvious ;-)
<aside type="pmc chair hat off">There's another thing about project
incubation that kinda interests me: what happens upon incubation
failure? To me, there's a difference between the people and the project
involved. The subproject can fail, but committers of failed incubation
projects can still stick around - even though committers are very much
tied to (sub)projects. In this sense, I think any committer, even if
this used to be for a now-failed incubating project, has been deemed
worthy once to carry the Apache feathers, so he/she should be able to
speak up on regulatory matters. Collaterally, since Lenya peeps are
apache.org peeps with a particular interest in Cocoon, I wouldn't mind
if they cast binding votes on the formation of the Cocoon charter.</aside>
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Discussion of Cocoon TLP Guidelines
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Steven Noels wrote:
> On 30/07/2003 0:13 Michael Wechner wrote:
>
>> I guess that as long as Lenya is under incubation, Lenya committers
>> won't be able to vote, right?
>
>
> I don't like a democracy where parts of the population, even if
> temporarily, have no formal way to express themselves. So for Cocoon TLP
> PMC matters, the PMC representative of incubating projects also have a
> binding vote. For subproject votes, only committers to a subproject get
> a binding vote - which means votes for Cocoon matters are off-base for
> Lenya peeps, and vice-versa, but the Cocoon TLP PMC can cast binding
> votes to all subprojects.
>
> How does that sound?
+1
a fair compromise
--
Gregor J. Rothfuss
Wyona Ltd. - Open Source Content Management - Apache Lenya
http://wyona.com http://cocoon.apache.org/lenya
gregor.rothfuss@wyona.com gregor@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Discussion of Cocoon TLP Guidelines
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Steven Noels wrote:
> On 30/07/2003 0:13 Michael Wechner wrote:
>
>> I guess that as long as Lenya is under incubation, Lenya committers
>> won't be able to vote, right?
>
>
> I don't like a democracy where parts of the population, even if
> temporarily, have no formal way to express themselves. So for Cocoon TLP
> PMC matters, the PMC representative of incubating projects also have a
> binding vote. For subproject votes, only committers to a subproject get
> a binding vote - which means votes for Cocoon matters are off-base for
> Lenya peeps, and vice-versa, but the Cocoon TLP PMC can cast binding
> votes to all subprojects.
>
> How does that sound?
+1
a fair compromise
--
Gregor J. Rothfuss
Wyona Ltd. - Open Source Content Management - Apache Lenya
http://wyona.com http://cocoon.apache.org/lenya
gregor.rothfuss@wyona.com gregor@apache.org
Re: Discussion of Cocoon TLP Guidelines
Posted by Steven Noels <st...@outerthought.org>.
On 30/07/2003 0:13 Michael Wechner wrote:
> I guess that as long as Lenya is under incubation, Lenya committers
> won't be able to vote, right?
I don't like a democracy where parts of the population, even if
temporarily, have no formal way to express themselves. So for Cocoon TLP
PMC matters, the PMC representative of incubating projects also have a
binding vote. For subproject votes, only committers to a subproject get
a binding vote - which means votes for Cocoon matters are off-base for
Lenya peeps, and vice-versa, but the Cocoon TLP PMC can cast binding
votes to all subprojects.
How does that sound?
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Discussion of Cocoon TLP Guidelines
Posted by Steven Noels <st...@outerthought.org>.
On 30/07/2003 0:13 Michael Wechner wrote:
> Steven Noels wrote:
>
>>
>>
>> If it comes to (a) vote(s), anybody's opinion is appreciated, so
>> please speak up. Binding votes about the Cocoon guidelines can be cast
>> by Cocoon committers only - the original members of the 'founding' PMC
>> that is.
>
>
> I guess that as long as Lenya is under incubation, Lenya committers
> won't be able to vote, right?
>
> Which is fine with personally, but I think it's important to clarify
> what you mean by *original members of the 'founding' PMC*
the situation with xml.apache.org is that all committers can vote for
new subproject proposals (and it needs a majority vote), and that PMC
peeps get to vote on chapter changes IIUC
of course, we are setting everything up as we go along, and it's a bit
of a chicken/egg problem: *we* should decide whether committers of
incubating projects can cast binding votes in this matter, and if I
state that such 'incubating' committers are allowed to vote on such a
decision, well... I think the outcome would be pretty obvious ;-)
<aside type="pmc chair hat off">There's another thing about project
incubation that kinda interests me: what happens upon incubation
failure? To me, there's a difference between the people and the project
involved. The subproject can fail, but committers of failed incubation
projects can still stick around - even though committers are very much
tied to (sub)projects. In this sense, I think any committer, even if
this used to be for a now-failed incubating project, has been deemed
worthy once to carry the Apache feathers, so he/she should be able to
speak up on regulatory matters. Collaterally, since Lenya peeps are
apache.org peeps with a particular interest in Cocoon, I wouldn't mind
if they cast binding votes on the formation of the Cocoon charter.</aside>
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Discussion of Cocoon TLP Guidelines
Posted by Steven Noels <st...@outerthought.org>.
On 30/07/2003 0:13 Michael Wechner wrote:
> I guess that as long as Lenya is under incubation, Lenya committers
> won't be able to vote, right?
I don't like a democracy where parts of the population, even if
temporarily, have no formal way to express themselves. So for Cocoon TLP
PMC matters, the PMC representative of incubating projects also have a
binding vote. For subproject votes, only committers to a subproject get
a binding vote - which means votes for Cocoon matters are off-base for
Lenya peeps, and vice-versa, but the Cocoon TLP PMC can cast binding
votes to all subprojects.
How does that sound?
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Discussion of Cocoon TLP Guidelines
Posted by Steven Noels <st...@outerthought.org>.
On 30/07/2003 0:13 Michael Wechner wrote:
> Steven Noels wrote:
>
>>
>>
>> If it comes to (a) vote(s), anybody's opinion is appreciated, so
>> please speak up. Binding votes about the Cocoon guidelines can be cast
>> by Cocoon committers only - the original members of the 'founding' PMC
>> that is.
>
>
> I guess that as long as Lenya is under incubation, Lenya committers
> won't be able to vote, right?
>
> Which is fine with personally, but I think it's important to clarify
> what you mean by *original members of the 'founding' PMC*
the situation with xml.apache.org is that all committers can vote for
new subproject proposals (and it needs a majority vote), and that PMC
peeps get to vote on chapter changes IIUC
of course, we are setting everything up as we go along, and it's a bit
of a chicken/egg problem: *we* should decide whether committers of
incubating projects can cast binding votes in this matter, and if I
state that such 'incubating' committers are allowed to vote on such a
decision, well... I think the outcome would be pretty obvious ;-)
<aside type="pmc chair hat off">There's another thing about project
incubation that kinda interests me: what happens upon incubation
failure? To me, there's a difference between the people and the project
involved. The subproject can fail, but committers of failed incubation
projects can still stick around - even though committers are very much
tied to (sub)projects. In this sense, I think any committer, even if
this used to be for a now-failed incubating project, has been deemed
worthy once to carry the Apache feathers, so he/she should be able to
speak up on regulatory matters. Collaterally, since Lenya peeps are
apache.org peeps with a particular interest in Cocoon, I wouldn't mind
if they cast binding votes on the formation of the Cocoon charter.</aside>
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Discussion of Cocoon TLP Guidelines
Posted by Michael Wechner <mi...@wyona.org>.
Steven Noels wrote:
>
>
> If it comes to (a) vote(s), anybody's opinion is appreciated, so
> please speak up. Binding votes about the Cocoon guidelines can be cast
> by Cocoon committers only - the original members of the 'founding' PMC
> that is.
I guess that as long as Lenya is under incubation, Lenya committers
won't be able to vote, right?
Which is fine with personally, but I think it's important to clarify
what you mean by *original members of the 'founding' PMC*
Thanks
Michael
> If that would need to be changed, it's the time to implement that, as
> well.
>
> Thanks for your attention,
>
> </Steven>
Re: Discussion of Cocoon TLP Guidelines
Posted by Michael Wechner <mi...@wyona.org>.
Steven Noels wrote:
>
>
> If it comes to (a) vote(s), anybody's opinion is appreciated, so
> please speak up. Binding votes about the Cocoon guidelines can be cast
> by Cocoon committers only - the original members of the 'founding' PMC
> that is.
I guess that as long as Lenya is under incubation, Lenya committers
won't be able to vote, right?
Which is fine with personally, but I think it's important to clarify
what you mean by *original members of the 'founding' PMC*
Thanks
Michael
> If that would need to be changed, it's the time to implement that, as
> well.
>
> Thanks for your attention,
>
> </Steven>
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Discussion of Cocoon TLP Guidelines
Posted by Steven Noels <st...@outerthought.org>.
On 4/08/2003 13:26 Christian Haul wrote:
> Second, I feel tieing it so close to cvs and in particular wincvs is a
> little bit too strict. I'm quite looking forward to switch to
> subversion at some point :-)
Sure.
>>Some topics which, IMHO, need further debate are:
>>
>> - PMC composition and rules for admitting new PMC members (currently,
>>any committer can self.propose() to become a member of the PMC, and any
>>committer is allowed on the PMC list - but we need to discuss, maybe
>>change and at the very least formalize this)
>
>
> Honestly, I believe that self.propose() is a very good way of doing
> it. We should change this only when we encounter problems with this
> model. Therefore I suggest to change the paragraphs accordingly.
OK.
Thanks,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Discussion of Cocoon TLP Guidelines
Posted by Steven Noels <st...@outerthought.org>.
On 4/08/2003 14:03 Upayavira wrote:
> Minor typo:
>
> <note>"Lazy" means the action item has immediate tactic
> approval, and it is not necessary to tally the vote until a -1
> reply
> is posted. Once a -1 reply is posted, the vote must be tallied
> and
> reported before the action item is considered approved. All
> action-item votes are lazy except for a public release
> vote.</note>
>
> Surely tactic should read tacit:
Sure - will change.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Discussion of Cocoon TLP Guidelines
Posted by Upayavira <uv...@upaya.co.uk>.
Minor typo:
<note>"Lazy" means the action item has immediate tactic
approval, and it is not necessary to tally the vote until a -1
reply
is posted. Once a -1 reply is posted, the vote must be tallied
and
reported before the action item is considered approved. All
action-item votes are lazy except for a public release
vote.</note>
Surely tactic should read tacit:
---From dictionary.com------------------
tac·it
1. Not spoken: indicated tacit approval by smiling and winking.
2a. Implied by or inferred from actions or statements: Management has
given its tacit approval to the plan.
2b. Law. Arising by operation of the law rather than through direct
expression.
3. Archaic. Not speaking; silent.
-----------
Regards, Upayavira
On Mon, 4 Aug 2003 13:26:18 +0200, "Christian Haul"
<ha...@dvs1.informatik.tu-darmstadt.de> said:
> On 29.Jul.2003 -- 11:05 AM, Steven Noels wrote:
> > Dear all,
> >
> > I've just checked in a verbatim copy of the Jakarta Guidelines (located
> > at http://jakarta.apache.org/site/proposal.html) in the cocoon-site
> > module, that could serve as a starter to base our own project guidelines
> > upon. Before we became a TLP (top level project), we were supposed to
> > follow the XML TLP guidelines (which are currently under debate, a
> > decent RC can be found at
> > http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt?rev=1.14&content-type=text/vnd.viewcvs-markup),
> > but after reading both, I believe the Jakarta guidelines might be a good
> > foundation to start working from. The guidelines are supposed to regulate
> > the day-to-day operations of the Cocoon TLP, which of course includes any
> > existing and possible new subprojects.
> >
> > So in an attempt to start the debate about the Cocoon TLP guidelines, I
> > copy/paste/search/replaced through the Jakarta set of guidelines, and
> > provide this as a starter for further discussions.
> >
> > Our DRAFT version is located at
> > http://cvs.apache.org/viewcvs.cgi/cocoon-site/src/documentation/content/xdocs/guidelines.xml?rev=1.1&content-type=text/vnd.viewcvs-markup
>
> Thanks Steven,
> it reads quite good.
>
> Two points in addition to Carsten's: It states that "new features"
> need to be voted before committing. I believe that this is either
> unpractical (and sure not happening ATM) or/and not precise
> enough. Perhaps "major new features" would be better, but then, what's
> "major"? OK, it's only a guideline....
>
> Second, I feel tieing it so close to cvs and in particular wincvs is a
> little bit too strict. I'm quite looking forward to switch to
> subversion at some point :-)
>
> > Some topics which, IMHO, need further debate are:
> >
> > - PMC composition and rules for admitting new PMC members (currently,
> > any committer can self.propose() to become a member of the PMC, and any
> > committer is allowed on the PMC list - but we need to discuss, maybe
> > change and at the very least formalize this)
>
> Honestly, I believe that self.propose() is a very good way of doing
> it. We should change this only when we encounter problems with this
> model. Therefore I suggest to change the paragraphs accordingly.
>
> > - rules and guidelines for incubating projects, w.r.t. PMC
> > participation, cohabitation with Incubator guidelines
> > - basically do a sanity check of the lenghty Jakarta original and see
> > what might be eradicated from it (less is more)
>
> > - check voting guidelines
>
> Look fine.
>
> Chris.
> --
> C h r i s t i a n H a u l
> haul@informatik.tu-darmstadt.de
> fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
>
Re: Discussion of Cocoon TLP Guidelines
Posted by Steven Noels <st...@outerthought.org>.
On 4/08/2003 14:02 Stefano Mazzocchi wrote:
>> Two points in addition to Carsten's: It states that "new features"
>> need to be voted before committing. I believe that this is either
>> unpractical (and sure not happening ATM) or/and not precise
>> enough. Perhaps "major new features" would be better, but then, what's
>> "major"? OK, it's only a guideline....
>
>
> I would say that "anything that changes the contracts" has to be voted.
> New features that are added sideways, don't (say scratchpad or
> scratchpad blocks). But anything that enter the trunk should be voted.
Let's stick to contract or API changes of released versions requiring a
formal vote. New stuff - I honestly don't think so.
> the part that indicates what to do with patches is too much to place
> there. I would remove it.
OK - will look into that.
> the part of new subprojects as well. if somebody asks, we send them to
> incubation right away.
How does other people feel about this? Most commonly, an incubating
project needs a destination PMC, so we would be involved some way anyhow.
Thanks,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Discussion of Cocoon TLP Guidelines
Posted by Steven Noels <st...@outerthought.org>.
On 4/08/2003 14:02 Stefano Mazzocchi wrote:
>>> - rules and guidelines for incubating projects, w.r.t. PMC
>>> participation, cohabitation with Incubator guidelines
>
>
> I would say that we remove that paragraph and avoid dealing with it
> altogether.
> the part of new subprojects as well. if somebody asks, we send them to
> incubation right away.
If the concept and process of incubation is properly defined and offers
more than bouncing off the ball to the incubating PMC, I would be
perfectly happy with that. So far, I think it is reasonable to say that
the Incubator is still FUD with the prospect of becoming something
valuable. Also, I loath to see projects being incubated without a clear
destination PMC in mind. While you are absolutely correct in theory,
practice is teaching us something else, so I'd like to discuss this
before moving either way. Off-loading work to a disfunctional project
isn't a way to get the work done. Closely collaborating with the
Incubator might be better, IMHO.
> well, too much mentioning of vetos, IMHO, but I can live with that.
Exactly - I will try and wordsmith along that way. Vetos are community
killers and a discourse of distrust.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Discussion of Cocoon TLP Guidelines
Posted by Stefano Mazzocchi <st...@apache.org>.
On Monday, Aug 4, 2003, at 13:26 Europe/Rome, Christian Haul wrote:
> On 29.Jul.2003 -- 11:05 AM, Steven Noels wrote:
>> Dear all,
>>
>> I've just checked in a verbatim copy of the Jakarta Guidelines
>> (located
>> at http://jakarta.apache.org/site/proposal.html) in the cocoon-site
>> module, that could serve as a starter to base our own project
>> guidelines
>> upon. Before we became a TLP (top level project), we were supposed to
>> follow the XML TLP guidelines (which are currently under debate, a
>> decent RC can be found at
>> http://cvs.apache.org/viewcvs.cgi/xml-admin/
>> charter.txt?rev=1.14&content-type=text/vnd.viewcvs-markup),
>> but after reading both, I believe the Jakarta guidelines might be a
>> good
>> foundation to start working from. The guidelines are supposed to
>> regulate
>> the day-to-day operations of the Cocoon TLP, which of course includes
>> any
>> existing and possible new subprojects.
>>
>> So in an attempt to start the debate about the Cocoon TLP guidelines,
>> I
>> copy/paste/search/replaced through the Jakarta set of guidelines, and
>> provide this as a starter for further discussions.
>>
>> Our DRAFT version is located at
>> http://cvs.apache.org/viewcvs.cgi/cocoon-site/src/documentation/
>> content/xdocs/guidelines.xml?rev=1.1&content-type=text/vnd.viewcvs-
>> markup
>
> Thanks Steven,
> it reads quite good.
>
> Two points in addition to Carsten's: It states that "new features"
> need to be voted before committing. I believe that this is either
> unpractical (and sure not happening ATM) or/and not precise
> enough. Perhaps "major new features" would be better, but then, what's
> "major"? OK, it's only a guideline....
I would say that "anything that changes the contracts" has to be voted.
New features that are added sideways, don't (say scratchpad or
scratchpad blocks). But anything that enter the trunk should be voted.
> Second, I feel tieing it so close to cvs and in particular wincvs is a
> little bit too strict. I'm quite looking forward to switch to
> subversion at some point :-)
I totally agree. Our guidelines should be technology-agnostic (maybe
referring to another page for this, just like we do for mail lists)
>> Some topics which, IMHO, need further debate are:
>>
>> - PMC composition and rules for admitting new PMC members (currently,
>> any committer can self.propose() to become a member of the PMC, and
>> any
>> committer is allowed on the PMC list - but we need to discuss, maybe
>> change and at the very least formalize this)
>
> Honestly, I believe that self.propose() is a very good way of doing
> it. We should change this only when we encounter problems with this
> model. Therefore I suggest to change the paragraphs accordingly.
+1
>> - rules and guidelines for incubating projects, w.r.t. PMC
>> participation, cohabitation with Incubator guidelines
I would say that we remove that paragraph and avoid dealing with it
altogether.
>> - basically do a sanity check of the lenghty Jakarta original and see
>> what might be eradicated from it (less is more)
the part that indicates what to do with patches is too much to place
there. I would remove it.
the part of new subprojects as well. if somebody asks, we send them to
incubation right away.
>> - check voting guidelines
>
> Look fine.
well, too much mentioning of vetos, IMHO, but I can live with that.
--
Stefano.
Re: Discussion of Cocoon TLP Guidelines
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 29.Jul.2003 -- 11:05 AM, Steven Noels wrote:
> Dear all,
>
> I've just checked in a verbatim copy of the Jakarta Guidelines (located
> at http://jakarta.apache.org/site/proposal.html) in the cocoon-site
> module, that could serve as a starter to base our own project guidelines
> upon. Before we became a TLP (top level project), we were supposed to
> follow the XML TLP guidelines (which are currently under debate, a
> decent RC can be found at
> http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt?rev=1.14&content-type=text/vnd.viewcvs-markup),
> but after reading both, I believe the Jakarta guidelines might be a good
> foundation to start working from. The guidelines are supposed to regulate
> the day-to-day operations of the Cocoon TLP, which of course includes any
> existing and possible new subprojects.
>
> So in an attempt to start the debate about the Cocoon TLP guidelines, I
> copy/paste/search/replaced through the Jakarta set of guidelines, and
> provide this as a starter for further discussions.
>
> Our DRAFT version is located at
> http://cvs.apache.org/viewcvs.cgi/cocoon-site/src/documentation/content/xdocs/guidelines.xml?rev=1.1&content-type=text/vnd.viewcvs-markup
Thanks Steven,
it reads quite good.
Two points in addition to Carsten's: It states that "new features"
need to be voted before committing. I believe that this is either
unpractical (and sure not happening ATM) or/and not precise
enough. Perhaps "major new features" would be better, but then, what's
"major"? OK, it's only a guideline....
Second, I feel tieing it so close to cvs and in particular wincvs is a
little bit too strict. I'm quite looking forward to switch to
subversion at some point :-)
> Some topics which, IMHO, need further debate are:
>
> - PMC composition and rules for admitting new PMC members (currently,
> any committer can self.propose() to become a member of the PMC, and any
> committer is allowed on the PMC list - but we need to discuss, maybe
> change and at the very least formalize this)
Honestly, I believe that self.propose() is a very good way of doing
it. We should change this only when we encounter problems with this
model. Therefore I suggest to change the paragraphs accordingly.
> - rules and guidelines for incubating projects, w.r.t. PMC
> participation, cohabitation with Incubator guidelines
> - basically do a sanity check of the lenghty Jakarta original and see
> what might be eradicated from it (less is more)
> - check voting guidelines
Look fine.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
RE: Discussion of Cocoon TLP Guidelines
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Steven Noels wrote:
>
> On 29/07/2003 11:47 Carsten Ziegeler wrote:
>
> > - the part about the release is not the way we currently do the releases
> > Here we have to decide if we want to stick to our "more lazy" approach
> > of releases or if we want to adopt a more formal but improved way
> > of releasing Cocoon.
>
> I was thinking of down-playing the importance of the process,
> simplifying it into:
>
> * someone meritocraticaly becomes Release Manager, lazy consensus
> applies and people are free to self.propose()
> * that person prepares a release plan with work items
> * once these items are resolved (lazy resolution, consensus votes when
> necessary), that person comes up with a release vote
> * release vote requires majority approval
> * off we go
>
> What do you think? Too little formality?
>
It's ok for me and it reflects more or less the current way of releasing.
Thanks
Carsten
Re: Discussion of Cocoon TLP Guidelines
Posted by Stefano Mazzocchi <st...@apache.org>.
On Monday, Aug 11, 2003, at 14:57 Europe/Rome, Steven Noels wrote:
> On 29/07/2003 11:47 Carsten Ziegeler wrote:
>
>> - the part about the release is not the way we currently do the
>> releases
>> Here we have to decide if we want to stick to our "more lazy"
>> approach
>> of releases or if we want to adopt a more formal but improved way
>> of releasing Cocoon.
>
> I was thinking of down-playing the importance of the process,
> simplifying it into:
>
> * someone meritocraticaly becomes Release Manager, lazy consensus
> applies and people are free to self.propose()
> * that person prepares a release plan with work items
> * once these items are resolved (lazy resolution, consensus votes when
> necessary), that person comes up with a release vote
> * release vote requires majority approval
> * off we go
>
> What do you think? Too little formality?
no, the less formality the better.
Who volunteers gets the job. Visibility and peer pressure will keep
him/her honest.
> --
Stefano.
Re: Discussion of Cocoon TLP Guidelines
Posted by Steven Noels <st...@outerthought.org>.
On 29/07/2003 11:47 Carsten Ziegeler wrote:
> - the part about the release is not the way we currently do the releases
> Here we have to decide if we want to stick to our "more lazy" approach
> of releases or if we want to adopt a more formal but improved way
> of releasing Cocoon.
I was thinking of down-playing the importance of the process,
simplifying it into:
* someone meritocraticaly becomes Release Manager, lazy consensus
applies and people are free to self.propose()
* that person prepares a release plan with work items
* once these items are resolved (lazy resolution, consensus votes when
necessary), that person comes up with a release vote
* release vote requires majority approval
* off we go
What do you think? Too little formality?
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
RE: Discussion of Cocoon TLP Guidelines
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Steven Noels wrote:
> Please take your time reading through it, it ain't as bad as it looks
> like, and it concerns you: developers & contributors of the Cocoon
> project(s). And let's try and keep this as lightweight as feasible.
>
I read most of it and I think it's a very good start. I have two notes:
- we don't have an announcement mailing list.
Ok, we can either drop this paragraph or think about creating such a list.
- the part about the release is not the way we currently do the releases
Here we have to decide if we want to stick to our "more lazy" approach
of releases or if we want to adopt a more formal but improved way
of releasing Cocoon.
Carsten