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