[ZF] Status update for documents
Christian Theune
ct at gocept.com
Mon Apr 23 12:53:44 EDT 2007
Hi,
Am Montag, den 23.04.2007, 11:53 -0400 schrieb Jim Fulton:
> Thanks. Editorial process note: Please refrain from refilling
> paragraphs. Diff doesn't handle reformatting paragraphs well. (Open
> Office handles tracking text changes much better.) I believe you
> even refilled a paragraph without making other changes. :/
Ok, I generally try to not do that, maybe I didn't notice when I made
that change. Sorry.
> > I have a few questions before I can finalize the draft version:
> >
> > - We wanted to make the ZMO a committee instead.
> > I guess that it's a standing committee.
> >
> > Is it going to be a committee of the board or of the
> > Membership-at-large, though?
>
> I think what you're referring to is my suggestion to have a
> repository-management committee that is responsible for managing
> access control to the software repository. This committee would be a
> standing committee of the board and appointed by the board. It could
> have as few as a single member. :) I suggest keeping this separate
> from the ZMO.
>
> To step back a minute, let me restate my understanding of the goal of
> this initial effort:
>
> Right now, if we transfer copyright to the ZF, we'll lose a lot of
> contributors because many contributors are not contributor members
> and, as written the documents link membership and repository access.
> In addition, we'd lose the ability to grant access to the repository
> to new contributors.
>
> We want to separate repository access from membership. This means we
> need a process for granting access to the repository. I think the
> process should be the following:
>
> - The committer signs (and has their employer sign) and committer
> agreement.
>
> - The committer agreement is presented to the repository-management
> committee who, at their discretion, grants access.
>
> - The repository-management committee can grant or deny repository
> access at their discretion, except that:
>
> o Their decisions can be appealed to the board
>
> o They serve at the pleasure of the board.
>
> Something like the above should be written down.
>
> The repository-management committee can develop additional processes
> as they see fit as long as they are consistent with what's written down.
>
> >
> > - The original ZMO had quite a few responsibilities and
> > properties. I'd like to boil them down.
> >
> > The original list was:
> >
> > - directed and established by the chairman? (rather not, better ...)
> > - leading the zope platform development and
> > - execution, definition and maintenance a development process
> > - produce a roadmap
> > - interact with standards organisations
> > - resolve conflicts, establish working groups
> > - provide development infrastructure
> > - ensure the use of open source rules of engagement
> > - enforce foundation policies and provisions (bylaws, membership
> > agreement, ip policy and other policy documents)
> > - interact with membership at large by providing zope platform
> > plans, status updates and by soliciting requirements and feedback
> > - (conducting academic and research community outreach)
> > (conduct zope platform marketing)
> > - (assure the availability of enablement services, including
> > education and training programs)
> >
> > As the development committee should work on making Zope (and Co)
> > better, I don't think it should do:
> >
> > - do marketing
> > - do enablement services
> > - enforce foundation policies
> >
> > Maybe some of the other points can collapsed a bit to be less
> > verbose?
>
> At this point I'd be for getting rid of the ZMO entirely. We can
> always add something like it later of we decide we want it. IMO, this
> should be community driven. IOW, if the membership decides we need
> more formality in the development process, the membership should
> propose something.
>
> Also, remember that other documents will need to be modified.
>
> Finally I'll issue that this is the most urgent issue with the
> documents that needs to be fixed. There are others, but they are not
> as urgent. For example, we lack a process for inviting new committer
> members. We should address issues like these in follow-on efforts.
Ok, thanks for the explanations. I'll go ahead and:
- Create the repository committee as drafted above
- Drop the unfinished paragraph that transformed the ZMO into a
committee an get rid of that entitity entirely.
Christian
--
gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany
www.gocept.com - ct at gocept.com - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/foundation/attachments/20070423/8c75ff79/attachment.bin
More information about the Foundation
mailing list