[Pydotorg-redesign] The Zope question

[Kevin Altis]

> From: Jack Jansen
>
> On vrijdag, aug 8, 2003, at 23:31 Europe/Amsterdam, Skip Montanaro
> wrote:
>
> >
> >     Tim> I can see a lot of advantages too. What are the disadvantages
> >     Tim> though?
> >
> > Since I'm the person who's posted what I feel to be some Zope
> > disadvantages
> > over on marketing-python, I'll refer you to my two most recent posts:
> >
> >
> > http://pythonology.org/pipermail/marketing-python/2003-August/
> > 004642.html
> >
> > http://pythonology.org/pipermail/marketing-python/2003-August/
> > 004645.html
>
> In addition to those disadvantages, with which I pretty much agree, I
> fail
> to see any *real* advantages to using Zope ("real" here as opposed to
> the
> publicity value/eat your own dogfood thing).
>
> Zope shines when you have lots of active content, we don't. Zope shines
> when
> you have distinct groups of designers, programmers and content people,
> we
> don't. Zope shines when you need to enforce complicated permissions, we
> don't.
>
> Given the group of people on pydotorg ht2html+cvs+rsync strikes me as
> being
> spot-on as the right set of tools for the job. There's definitely of
> room for
> improvement (staging, for instance, or an easier way to get out of the
> rigid ht2html patrix layout), but I see no reason for more than
> evolutionary
> change.

That sums up the issue pretty well, the people and process of today versus
where we might go in the future. Also, you touched on why change is or isn't
needed and the timeframe. python.org is being maintained today in what I
would describe as, not surprisingly, a way that only appeals to sys admin
and programmer types and the process doesn't scale well. I understand why
the current process is what it is, but as part of the redesign process we
said we were going to improve the day to day maintainence and reduce the
workload of the people involved.

At the heart of the Zope issue is that of using a content management system
(CMS) more sophisticated than cvs and a script to apply a template. Some
sort of CMS is almost certainly needed before the day to day content updates
can be handled by new blood that are less command-line oriented and the
system can tolerate a mistyped command or flag. Writers, editorial,
managers, designers, etc. that normally drive day to day site changes can't
really use the current system.

I'll go ahead and say that I think it would be a nice goal to be able to
have python.org content managed by those kinds of folks and not the
programmers who would rather be doing something else with their time. Of
course, many of the same people managing content today will also want to
contribute in the future, so the CMS has to balance their usage requirements
too.

I'm not advocating Zope here, I'm just trying to define what the real needs
are today as well as what they would be in the future to continue to improve
the python.org site. Please add to or correct the answers below. I'm just
gonna braindump some ideas in no particular order.

Q: Should we have a staging server?
A: Probably

Q: Does using Zope or another system for CMS mean that content has to be
served dynamically?
A: I don't think so. The staging server might be the CMS and python.org and
its mirrors would be based on that. That is a pretty common setup.
python.org doesn't have dynamic database driven content (except the wiki),
shopping carts, etc. AFAIK

Q: How much traffic do the mirror sites get?
A: ?

Q: Which parts of the site today are dynamic and are not mirrored?
A: The wiki, search, some CGI scripts, anything else?
It would be worth repeating the different sections that make up the site
like the main docs which are not part of the cvs and ht2html process, IIRC.

Q: Do we need personalized content pages on the main site?
A: Probably not on the main site, but like CVS, the wiki, and any staging
server with a CMS should support user login for editorial workflow...

Q: What are the active portions of the content other than the wiki?
A: This is the day to day work of pydotorg, right? So job postings, events,
submissions for user groups. What else? What messages to
webmaster at python.org result in the site needing changes?

Q: If there was a CMS like Zope/Plone, how would changes to the site be
tracked and could changes be backed out?
A: ?

Q: Could/should the CMS incorporate changes from the command-line, static
page additions, or something outside the normal CMS interface which is
likely browser-based?
A: I would think so if the CMS is done in Python.

Q: Can the wiki page templates be made to follow the new site templates?
A: Hopefully
On a related note, there seems to be some consensus that the wiki is ugly
and helps make finding answers on python.org even harder (separate nav,
separate search, separate layout style). The fact that some content has
migrated out of the normal pydotorg tree and into the wiki to simplify
maintainence might be indicative of the need for a real CMS and more
writer/editorial labor.

Q: Can the current process evolve in stages to a CMS?
A: I think so.

That's more than I intended to spew. Hopefully, this will create some more
talking points.

ka