[ZF] Status update for documents

[Christian Theune]

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