Hello Lennart,
On Monday 03 December 2001 05:06, Lennart Regebro wrote:
> After the discussion here I'm slowly starting to form a picture in my mind
> of how to "solve" the "problems".
>
> First some basic facts of life:
> - Zope corp needs to do what Zope corp thinks it can make money on.
>
> - "We" (that is the Zope community) need to get some features into the base
> of Zope because:
> a. It's not effective that we all solve the same problems
> independantly. b. Some features are hard to do as products.
>
> - It is imperative that there is a single point of control for Zope, ie no
> branching.
>
>
> This means Zope corp needs to control what goes into Zope, but the
> community needs to tell them what should go there, and the community has to
> help to put it in.
> To achieve this, we need better community support systems. That is, we need
> a proper community site, with discussion forums, a merged
> collector/proposal application with proper threaded discussions and applied
> workflow for proposal states.
> The projects that get started also need their protected areas on the site
> with discussion forums and their own CVS trees.
>
> In all, this would support a better inflow of comments from the community,
> it would make it easier for community members to see the responses to their
> input, and it would be easier to start projects with non ZC people involved
> in programming.
Definitely. And definitely there needs to be more technical "infrastructure"
on zope.org to support this way of working. As another result, less people
would find it necessary to move their projects to sourceforge. Just imagine
sourceforge functionality plus wikis, plus fishbowls, plus collector. I like
the fishbowl's standardization of a common workflow, and I would love to see
more integration of all the other parts. I believe this could speed up and
stabilize Zope development drastically. Sometimes I even find _navigating_
through _what's_there_ hard, and I'm afraid to spend time writing something
that someone else may have already written, and which might just be hidden
somewhere in the haystacks...
>
>
> Here are some things that I feel should be introduced into Zope:
> - Workflow support. (Because everybody needs it)
> - Versioning. (Because it's hard to do as a product)
> - Internationalization. (Because it's hard to do as a product)
> - Better user management. (Because everybody needs it)
- Documentation
(Because everybody needs it - at some point of his/her Zope life)
>
> Also, Zope would benefit from the inclusion of several products that
> improve the products included in Zope. Many people have found some objects
> lacking in functionality, and added that functionality and put it up on
> Zope.org. Many of these improved products could easily replace the products
> that come with Zope today, thereby giving a better "wow" factor to Zope
> without much effort.
I think I am not the only one that's afraid of straw fires when it comes to
Zope's "wow factor". The decision, which patch/product/add-on should make it
to the core and which shouldn't, is not easy. This decision has always been
made by ZC, and for the time being I found this fair enough, though it seemed
to me that they have been clobbered over the head with patches so much that
it became just too much work to review every single one in detail (there are
_still_, for months now, so many patches to the tree tag, that enhance its
functionality exactly the way that - imho - the tree tag was meant to work,
and they still haven't made it to the core). It looks as if out of
desperation(convenience?) the burden of proof is being put on the patcher.
What I would really love would be a regular poll for developers so that ZC
can find out what "the community" would like to see move into the core. And
not too abstract (I don't want to vote for "Internationalization", I want to
vote for either "ZBabel" or "Localizer", we're not in parliament here). Pick
20 patches/products, and let the community decide over the priorities. Let ZC
be the final judge, but let the jury pass their decision ("advice") first.
You will always have the problem of this or that patch to apply to a very
specific problem of yours. That's why you wrote it. Okay, this patch is
essential for your site to work properly, but 99% of the other developers
don't need it. If this is the case: tough luck. Pray that they run into the
same problems some day. But for the time being, I don't see this causal
coherence when it comes to "should and if yes then when will this be taken to
the core". So who do I blame? Some people were very quick with their decision
here... (see last threads on this list)
>
> I also feel there are things that could be removed. And now I'm gonna say
> bad things about parts of zope some people probably love, and they will
> hate me for this, but I'll have to live with that. This is my view only. I
> have on occasion been known to be completely wrong. :-)
>
> - Don't do any more work on ZClasses, and eventually drop it. To me they
> do not seem easier to work with than Python, they are messier and not as
> flexible.
Not much has been done on ZClasses in the last months (sorry if this sounds
insulting to someone who has actually worked on them ;-)), so I don't think
that there has been much time "wasted" here. If you don't like ZClasses, if
they don't seem easier to work with than Python: Ignore them. To a lot of
people they are a nice introduction to object-oriented programming under
Zope, and for simple tasks (like subclassing and adding/overriding one
function of a class) they are quite a handy thing to have around the house,
imho. I think that a lot of your concerns will dissolve with the upcoming
Component Architecture.
>
> - I feel that CMF is a failure. It doesn't do what is promised, it's very
> hard to understand and many parts of it are simply designed so badly and
> incorrectly that they are practically useless. Drop CMF. Take the good
> parts and integrate them directly into the Zope base to make Zope a better
> platform form content management applications, and forget about the rest.
The CMF can only be a failure if it fails its goals.
Well, what are the CMF's goals?
Have you seen this interview?
http://www.zopera.org/site/Members/odeckmyn/iv_paul_2001
(recently announced on this list)
Quote:
"Regarding CMF, we expect it to disappear in its current form, ..."
Introduced to us as the "Portal Toolkit", later labeled as "probably evolving
into a commercial product" (couldn't find it in the archives when I tried a
minute ago, but I know I wasn't dreaming when I read it), then renamed to
"Content Management Framework" and the out-of-the-box solution for site
developers that need membership, skinning, an easy content management
interface, and pluggable add-ons, Paul Everitt now calls it "a big prototype
for the new architecture". Although I think that this is not how it all
started, not even how it meant to be less than a year ago, you see that your
concerns are no longer something to worry about. The "good things" will be
taken to the Zope core, the rest will remain interesting only for people who
actually "implement".
Danny
>
>
>
>
>
> _______________________________________________
> Zope-Dev maillist - [EMAIL PROTECTED]
> http://lists.zope.org/mailman/listinfo/zope-dev
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope-announce
> http://lists.zope.org/mailman/listinfo/zope )
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
