[ZF] Status update for documents

[Jim Fulton]

On Apr 19, 2007, at 1:16 PM, Christian Theune wrote:
...
> sorry this took so long again,

Sorry it took me so long to respond ...

> However, I received a base-line version of the by laws as restructured
> text and replaced the open-office by laws.
> Then I went ahead and checked in my changes regarding the removal  
> of the
> ZMO.

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. :/


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

Jim

--
Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org