[ZWeb] Zope.org and New zope.org status

[Sidnei da Silva]

On Sun, Jan 12, 2003 at 01:50:14PM -0700, Jeffrey P Shell wrote:
| I have a lot of messages to go through, and I still haven't even eaten 
| yet today (and am actually recovering from a couple of days of birthday 
| drinking and eating), so I'll try to make this quick and hopefully I'm 
| understanding everything that is happening.

Hey! Happy birthday!

| >  - Many people from the community *want* to help, but are often too
| >  busy to coordinate. Its not easy to coordinate work and keep
| >  milestones on sight if you never know when your volunteer will be
| >  available to finish that skin, or fix that bug that is preventing
| >  you to complete your milestone.
| 
| I agree.  This seems to affect the Zope community more than others, 
| maybe it's just that everyone seems to have to work harder (especially 
| in the web development business) to earn their money.  As soon as 
| there's free rent and free food to go along with free software, it will 
| probably be easier to contribute.  But I doubt we'll see markets like 
| that anytime soon. :)

Agreed. As for myself, I think I will stop worrying and make a sign:
"Python Programmer. Work for food and a place to sleep" and sit on a
corner with my iBook. It would be a lot less stressful.

| >  - The new Zope.org will use lots of software besides Zope. Many
| >  people helped (and others could help but havent) by fixing those
| >  pieces of software. Namely, Andy and Kapil, which made the first
| >  stab at CMFBackTalk and Simon, that made the ZWiki upgrade very
| >  smooth, added some features from WikiForNow and improved
| >  CMF-compatibility.
| 
| The one thing that I will beg for for NZO is to cut down on Wiki 
| proliferation.  Wikis are their own moral universes with their own 
| workflow and content organization.  It works for some purposes, but not 
| all.  I would love to see the new fishbowl proposals become single 
| documents with REAL workflow attached instead of ne'er maintained 
| WikiStatusBadges or something like that.  I think that will be a lot 
| easier for those who have to review the proposals to actually review 
| them and pass judgement.  If individual projects want to use a Wiki to 
| collaborate development after a proposal has been accepted, that's 
| fine.  But I think we should cut down on the number of wikis used for 
| other purposes.  Most ZWiki documents really seem to be single-author, 
| many-comments.  I think that the discussions tool for the CMF and "edit 
| this page" functionality that the CMF actions tool provides should cut 
| down on the need for wikis.

Agreed again. Simon has some thoughts about this. Particularly, he
suggested that zope.org should have a single central zope wiki,
instead of a miriad of wikis spread all over the site.

OTOH, this suggestion about using documents instead of wikis reminded
me of an idea I had some time ago. Why dont use workflow with wikis
instead of WikiBadges? It would be the perfect combination. 

| >  - The main problem behind Zope.org is not the software, but how
| >  content is organized. *That* will be the hardest task to be done,
| >  and thats something that will need consensus. Its not a task for a
| >  single person. If a script takes around 8 hours to migrate Zope.org,
| >  I imagine a single person taking from 2-3 years to put Zope.org in
| >  good shape regarding content. So *thats* where we will need
| >  volunteers, and *lots* of them. Divide and conquer!
| 
| I agree.  I think that the content structure should be simplified.  The 
| basic content structure that's on Zope.org isn't necessarily bad, it's 
| the proliferation of content (how-to's, tips, etc) in member folders 
| that needs evaluating; especially out of date documents - do we keep 
| these?  We should ensure that the "modified date" metadata element 
| doesn't change between CZO and NZO.

Your wish was already granted! Im also setting the creation_date to
the modified date and trying to keep the ownership and creator
attributes. I say trying cause the Creator property of CMF is a little
broken (in my opinion) and for some reason, even if I copy the _owner
property it isnt working right.

| So Plone does add some nice features, regardless of what one thinks of 
| the UI (I do think that <http://zope.ch/> is much nicer to look at than 
| most Plone sites (especially in Apple's new Safari browser, which 
| doesn't render Plone's tabs well).  Fortunately, UI is replacable.

Something that we discussed a few days ago. We could make the NZO look
a Plone Skin, that would be mantained along with Plone. I havent asked
limi what does he think about this, but im almost sure he would agreed.

And yes. Auto ID generation would be amazing on NZO.

| Another thing I'd recommend (in case this hasn't already been done) - 
| NZO should stick with released software wherever possible, and avoid 
| running on betas or even release candidates (and Plone is still at RC1 
| status) and should definitely avoid running on CVS checkouts.  Meaning 
| - if Plone is wanted, we should make sure that we test heavily against 
| what's there and try to help them get to a bug-free 1.0 release (RC1 
| has a couple of bugs that are easily fixable (and are fixed in CVS)).

Thats something that will not be easy to avoid. Of course we will
stick with the known-to-be-stable released python and zope
versions. (Well, actually we're running from the Zope-2_6-branch but I
would consider that branch stable). OTOH, its impossible to get a
stable and released CMFBackTalk. The same to CMFPackage, which was
developed only for NZO. ZWiki is working very nicely on the latest
release, but ZPT support isnt 100% there yet, and new fixes are added
every day to the cvs version. We may need to discuss this a little more.

| There also seems to be some decent update/customization tools for 
| Plone.  The other thing that the NZO software should take into 
| consideration is upgradability so that it doesn't get stuck on a 
| heavily modified version of Zope 2.6.1 for years :).  Again, I'm sure 
| this thought has crossed everyone's mind.  Plone and ZopeZen seem to 
| have made some progress in this area offering Tools to aid in executing 
| update / configuration scripts.

Yes, the MigrationTool its working very nicely on the last two
releases. But sometimes its just a matter of testing it before putting
in production. CZO's Data.fs started up very nicely on Zope2.6. (CZO
is running Zope2.3) And everything seemed to work well, except for
some dtml methods that were using variables starting with an
underscore. I dont know if someone did tried to put CZO on Zope2.6
before, but it was a very smooth upgrade. So, if it was so easy, why
no one did it? Sometimes its not just a matter of providing smooth
upgrades, and, specially in this case, we need to ensure that the
human resource will be available when needed.

| *Whew*.  It's now an hour and a half later, and I still haven't eaten.  
| But the zope.org/Documentation page is looking a little bit better!

Nice. Now, something that made me worried when I was thinking about
the results of migration: What will you do with those DTML pages when
NZO lands? Convert them to ZPT or leave them as is? I made the NZO
skin shared between DTML and ZPT, so all you need is a <dtml-var
standard_html_{header,footer}> on your DTML page, but I think it would
be valid to start converting those pages to ZPT instead.

Another thing that I would like you to avoid and fix anytime you can
is the use of hardcoded absolute urls inside the site. For example, on
the old Documentation page all links were absolute, like
http://www.zope.org/Documentation/Books/ZopeBook/current and this is a
problem when testing NZO cause you need to manually edit the url to
ensure all links are working correctly.

work-for-food-and-a-place-to-sleep'ly yours, dc.
-- 
Sidnei da Silva (dreamcatcher) <sidnei@x3ng.com.br>
X3ng Web Technology <http://www.x3ng.com.br>
GNU/Linux user 257852
Debian GNU/Linux 3.0 (Sid) 2.4.18 ppc

Pascal is a language for children wanting to be naughty.
		-- Dr. Kasi Ananthanarayanan