[Zope-dev] the Zope Framework project

[Martijn Faassen]

Hi Matthew,

Thanks very much for your extensive feedback! Here's some of my feedback.

Matthew Wilkes wrote:
[snip]
>> * if it has a lot of people who contribute to it from our community,
>>   it's likely core.
> 
> -1, it's a zope community package, but not necessarily part of our  
> framework.

What I meant is if lots of people hack on zope.publisher, that means 
zope.publisher seems core. If it's zc.sourcefactory, that might be 
interesting too. It's just one signal though among many; usage by a wide 
range of projects is the most important I'd say.

>> * if it's something we want to encourage more consumer platforms use,
>>   it's likely core.
> 
> -1, as stated above.

In a way the Zope Framework is entirely something we want people to use, 
though. That doesn't mean the Zope Framework should be a platform for 
the promotion of obscure libraries, but if we add code to it then we're 
effectively promoting that code for wider use. Since the code wasn't 
there before, it isn't used yet, after all!

I can imagine though that the most common mechanism for something to 
make it into the core is wide use first, adoption into the core second.

>> Which libraries should be core to start with? Proposed is to take the
>> ``zope.*`` libraries. We can immediately weed out a lot of libraries
>> that aren't considered core, and we can then start the slower
>> processes of adding and removing from that set over time.
> 
> zope.* is a good start, but I think it'd be more useful to look at  
> what packages are actually used by everyone that's considered to be a  
> framework user.

Fully agreed. I just wanted to define a place where we start.

[snip]
>> Any library that is developed for integration with the Zope Framework
>> in the Zope repository can be considered "extra"; "extra" is the set
>> of libraries that is not in the Zope Framework but can work with it.  
>> By
>> having an "extra" designation we can more easily discuss such  
>> libraries.
> 
> What about other dependencies?  Should we have a list of blacklist  
> packages/things that prevent something being called an extra?  What if  
> it only works with 1 user of the framework, or 2, or all but 1, where  
> do we draw the line?

I'm not sure I understand your questions, could you elaborate?

[snip]
> How is the steering group selected?  How long do they serve for?  All  
> these questions need to be answered in a way that everyone considers  
> fair for this to work.

These are all good questions that indeed need to be answered. I didn't 
want to presume answering them right away and establish the idea of a 
steering group first before we go into this. I'll go into my idea for 
this more below.

[snip]
>> In order to
>> determine who is in it we could devise an election procedure by Zope
>> Foundation members.
> 
> -1, I'm not sure the foundation membership is representative of the  
> users.

It could help make said foundation membership more relevant. People need 
a reason to join the foundation and voting for a steering group is as 
good as any. The Zope Foundation in the end is a steward for the Zope 
project as a whole after all.

>  I'd say people put themselves up for election, there is a  
> secret public vote, the foundation review the results and then appoint  
> people.  That way they can overrule the public but are informed by them.

We have a mechanism set up for the Foundation board election that I 
believe we can reuse. You need a way to determine who is allowed to 
vote, though:

* the simplest is to take the Foundation membership. We will allow those 
who care to sign up before, of course.

* harder would be to collect data about checkins over a set period and 
say that those who have done more than n checkins since period X will be 
qualified to vote.

The more I think of it the more I'm in favor of simply using the 
foundation membership roster though. Let it be relevant to people for a 
change!

How long a steering group should serve I'm not sure about. Perhaps start 
out with a relatively short period of half a year, and then once we're 
used to it go for a year-long period? We'll get continuity as it's 
likely there will be partial overlap at least between elections. If a 
steering group works well the elections might also be a formality.

Regards,

Martijn