cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Upayavira">
Subject Re: Discussion of Cocoon TLP Guidelines
Date Mon, 04 Aug 2003 12:03:28 GMT
Minor typo:

<note>&#34;Lazy&#34; means the action item has immediate tactic
          approval, and it is not necessary to tally the vote until a -1
          is posted. Once a -1 reply is posted, the vote must be tallied
          reported before the action item is considered approved. All
          action-item votes are lazy except for a public release

Surely tactic should read tacit:


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
3.  Archaic. Not speaking; silent. 


Regards, Upayavira

On Mon, 4 Aug 2003 13:26:18 +0200, "Christian Haul"
<> 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 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 
> >,

> > 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 
> >

> 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
>     fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

View raw message