[Pydotorg-redesign] The Zope question

[Dylan Reinhardt]

Hi all,

Over on the Marketing Python list, we've had several threads around marketing strategy that have intersected with issues of concern to this group. Several requests have been made to move this discussion over here.

One thread in particular that seems to belong here is the Zope question.

As a strategic issue, there may be significant value in showcasing Zope. I believe there are also strong arguments to make from a usefulness and manageability standpoint.

So here's a post in which I took up the question posted to the other list: why use Zope?

From here, I'll try to keep my web-related advocacy over here where it belongs. :-)

Dylan


---- forwarded message follows ----

Can you give some reasons why Zope (2 or 3) would be a better way to build
python.org than the current ht2html tools?

I expect there are far more than I could think of, but I'm happy to
throw out a few.

The core advantage of Zope is that it facilitates user participation.
Zope (including CMF/Plone) is a very solid platform for building systems
that allow users to contribute and manage content.

Zope makes it possible to create and manage content without touching the
filesystem. Zope provides workflows that ensure that only
moderator/editor-approved content may be published. Once content is
approved, it can transparently make that content available to the
systems used to search the site.

Zope's chief advantage, IMO, is that it opens the door to
user-contributed howtos, white papers, etc. while significantly
*reducing* administrator workload.

In a system (such as our current one), content resides on the
filesystem. Access to the filesystem is not given out willy-nilly, of
course. Thus, the person who is responsible for maintaining the site is
pressed into service as the editor/gatekeeper for content.

In Zope, content editors/moderators don't need access to the filesystem
to perform their responsibilities. The admin is thus freed to focus on
what *admins* do, keeping data backed up, logfiles rotated, etc. As
roles are more narrowly defined, work becomes easier to delegate.

But wait... there's more! Templating is trivially easy. Search
functions actually work. Forums are simple. Structured, link-heavy
subsystems like the FAQ become far easier to keep up to date.

Imagine... to add something to the FAQ, an authorized user might need
only to add an FAQ object through the web. That FAQ object has a small
number of properties such as an index number, a question string, an
answer string and maybe a way of selecting related questions. Once
added (and/or approved) the new question/answer is seamlessly integrated
into the FAQ index and search function.

Roles can be as fine-grained as you wish. If you want to establish
different levels of responsibility for contributing an FAQ vs.
contributing a howto, you can. If you want to give specific people
editorial control, but only over a specific part of the site, that's
easy.

All that, and replication & caching are trivial. A one-line shell
script is all it takes to take a snapshot of a Zope system and cache it
locally. Zope is easily integrated with proxying systems like Apache or
Squid. Content is easily changed and updated, but the end result is
only as dynamic as you choose to make it.

Moreover, Zope is easily maintained. If Zope is installed to use the
DirectoryStorage product, the Zope database is stored as a collection of
files, each of which is basically a pickle of an object in the
database. This storage method is easy to back up incrementally and can
be copied into a CVS.

So... to summarize:
1. User contributions
2. Finer-grained roles
3. Reduction of admin workload
4. Easy replication/caching
5. It's cool as heck

I could go on and on... but hopefully that makes enough of a case to
determine whether it's worth considering in any greater detail.

Dylan

[Dylan Reinhardt]

Ugh... I meant to send this to where it *really* belongs, pydotorg, not
pydotorg-redesign.

Sorry for the bother.

Dylan

Post by Dylan Reinhardt
Hi all,
Over on the Marketing Python list, we've had several threads around marketing strategy that have intersected with issues of concern to this group. Several requests have been made to move this discussion over here.
One thread in particular that seems to belong here is the Zope question.
As a strategic issue, there may be significant value in showcasing Zope. I believe there are also strong arguments to make from a usefulness and manageability standpoint.
So here's a post in which I took up the question posted to the other list: why use Zope?

From here, I'll try to keep my web-related advocacy over here where it belongs. :-)

Dylan
---- forwarded message follows ----

Can you give some reasons why Zope (2 or 3) would be a better way to build
python.org than the current ht2html tools?

I expect there are far more than I could think of, but I'm happy to
throw out a few.
The core advantage of Zope is that it facilitates user participation.
Zope (including CMF/Plone) is a very solid platform for building systems
that allow users to contribute and manage content.
Zope makes it possible to create and manage content without touching the
filesystem. Zope provides workflows that ensure that only
moderator/editor-approved content may be published. Once content is
approved, it can transparently make that content available to the
systems used to search the site.
Zope's chief advantage, IMO, is that it opens the door to
user-contributed howtos, white papers, etc. while significantly
*reducing* administrator workload.
In a system (such as our current one), content resides on the
filesystem. Access to the filesystem is not given out willy-nilly, of
course. Thus, the person who is responsible for maintaining the site is
pressed into service as the editor/gatekeeper for content.
In Zope, content editors/moderators don't need access to the filesystem
to perform their responsibilities. The admin is thus freed to focus on
what *admins* do, keeping data backed up, logfiles rotated, etc. As
roles are more narrowly defined, work becomes easier to delegate.
But wait... there's more! Templating is trivially easy. Search
functions actually work. Forums are simple. Structured, link-heavy
subsystems like the FAQ become far easier to keep up to date.
Imagine... to add something to the FAQ, an authorized user might need
only to add an FAQ object through the web. That FAQ object has a small
number of properties such as an index number, a question string, an
answer string and maybe a way of selecting related questions. Once
added (and/or approved) the new question/answer is seamlessly integrated
into the FAQ index and search function.
Roles can be as fine-grained as you wish. If you want to establish
different levels of responsibility for contributing an FAQ vs.
contributing a howto, you can. If you want to give specific people
editorial control, but only over a specific part of the site, that's
easy.
All that, and replication & caching are trivial. A one-line shell
script is all it takes to take a snapshot of a Zope system and cache it
locally. Zope is easily integrated with proxying systems like Apache or
Squid. Content is easily changed and updated, but the end result is
only as dynamic as you choose to make it.
Moreover, Zope is easily maintained. If Zope is installed to use the
DirectoryStorage product, the Zope database is stored as a collection of
files, each of which is basically a pickle of an object in the
database. This storage method is easy to back up incrementally and can
be copied into a CVS.
1. User contributions
2. Finer-grained roles
3. Reduction of admin workload
4. Easy replication/caching
5. It's cool as heck
I could go on and on... but hopefully that makes enough of a case to
determine whether it's worth considering in any greater detail.
Dylan
_______________________________________________
Pydotorg-redesign mailing list
http://mail.python.org/mailman/listinfo/pydotorg-redesign

[Aahz]

Post by Dylan Reinhardt
Ugh... I meant to send this to where it *really* belongs, pydotorg, not
pydotorg-redesign.
Sorry for the bother.

Actually, pydotorg-redesign *is* the right place for this now.

[Tim Parkin]

Post by Aahz

Post by Dylan Reinhardt
Ugh... I meant to send this to where it *really* belongs, pydotorg,

not

Post by Aahz

Post by Dylan Reinhardt
pydotorg-redesign.
Sorry for the bother.

Actually, pydotorg-redesign *is* the right place for this now.

I can see a lot of advantages too. What are the disadvantages though?

Tim Parkin

[Skip Montanaro]

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

Skip

[Brett C.]

Post by Tim Parkin

Post by Aahz

Post by Dylan Reinhardt
Ugh... I meant to send this to where it *really* belongs, pydotorg,

not

Post by Aahz

Post by Dylan Reinhardt
pydotorg-redesign.
Sorry for the bother.

Actually, pydotorg-redesign *is* the right place for this now.

I can see a lot of advantages too. What are the disadvantages though?

This idea was thrown out at PyCon during the pydotorg BOF talk. The
main problem is that not all of the pydotorg maintainers (including me)
know Zope. This would require us to learn how to use the system. Now
considering we are all volunteers that might cost us some maintainers or
at least stall the move-over if this were to happen. Yes, it was
mentioned that the Zope community would probably be willing to help with
the setup and transition, but since this is volunteer there is nothing
holding them to following through (yes, I am being pessimistic).

There is also the issue of the fact that the change-over would have to
happen pretty much all at once. At this moment it is piecemeal which
has been manageable thanks to the fact that one person (mostly AM
Kuchling and Walter Doerwald, I think) can, when they have time, work on
a page or section and move it over to a clean layout and such.

And Zope will have to work through Lynx for Aahz. =)

Personally I am on the fence on this change-over issue.

-Brett

[Aahz]

Post by Brett C.
And Zope will have to work through Lynx for Aahz. =)

I'm not anticipating that this will be a problem.

[Jack Jansen]

On vrijdag, aug 8, 2003, at 23:31 Europe/Amsterdam, Skip Montanaro

Post by Skip Montanaro
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
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.
--
- Jack Jansen <***@oratrix.com>
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma
Goldman -

[Dylan Reinhardt]

Post by Jack Jansen
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).

A substantial goal in its own right... but not a technical requirement.

Post by Jack Jansen
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.

Absolutely true and somewhat circular.

We *can't* do dynamic content management now, therefore we don't. It
follows that a system that *does* offer dynamic content management is
not required... after all, we don't do it now, do we?

I'm not saying we should choose tools and then *find* uses for them...
but neither should we let our goals become unduly constrained by what
we've been able to accomplish in the past.

FWIW,

Dylan

[Aahz]

Post by Jack Jansen
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.

Quite frankly, I'd really love to have a more-complicated permission
system than we currently have because that would make it easier to
offload sections of the web site. That IMO is the primary reason for
switching to Zope or something else, in fact.

But doing it *right* with the resources we have is something I worry
about.

[Dylan Reinhardt]

[Forwarding this discussion to pydotorg-redesign as requested]

(See my response to Aahz's note for some of my problems with Zope.)
Dylan> The core advantage of Zope is that it facilitates user
Dylan> participation. Zope (including CMF/Plone) is a very solid
Dylan> platform for building systems that allow users to contribute and
Dylan> manage content.
I see that as a plus, though more so in situations where you have either a
huge number of contributors,

It's tough to know how many contributors the would have if contributions
were easier to make.

At present, the number of people who contribute to c.l.python are
probably a good estimate of the upper bound. The number who already
contribute content to python.org are a fair lower bound estimate.

or where you have contributors who are likely
to be antagonistic toward one another

*That* I can't speak to... :-)

Editorial oversight - good, no filesystem involvement - I'm not so sure
about.

Just to clarify... all this information *does* get written to the
filesystem. It's just that access to the filesystem is mediated through
Zope. The information is saved to disk, shell access isn't required.

That would be good if we had people beating the doors down to contribute.
We need more domain-specific contributors, not generalists like me.

Again, tough to know what we *might* have if we did more to encourage
contributions. Maybe this is a case of "if you build it, they will
come" or maybe it isn't.

Understood. Roles is one of Zope's strong points. One of Python's mantras
is, "we're all adults here". In the context of the website that means I'm
responsible enough to keep my fingers out of the stuff I don't know about.
Barry doesn't have to constrain my administrative privileges.

Trusting of your team's good judgment is an approach that works well for
a small group of hand-picked admins. It doesn't scale well.

How about the 60+ www.python.org mirrors? Would they have to run Zope to be
a mirror?

Nope.

Zope returns HTML. Mirroring a Zope CMS can be as easy as having a cron
job copy the output of a wget -r into the appropriate htdocs directory.

Bear in mind, that's a *content* system I'm talking about being easy to
cache. Caching content objects is easy because you have (at any given
time) a finite number of objects and a finite number of ways of
rendering each one.

If your system needs to perform logic to render an essentially infinite
number of possible application states, caching is far trickier. I doubt
we need (or want) a full web application running python.org.

Copied into CVS, or can a CVS (or some other source code) repository sit
behind it, automatically checking in updates as I make changes through the
web?

I think you *can* store the live data in CVS, but as I recall, using a
copy was recommended. I believe that was more of a performance issue
than a technical limitation. If this turns out to be important, I'd be
happy to do some research on what the current thinking is.

I'm not suggesting Zope isn't good stuff. I'm not convinced though that it
is the right tool for this particular job.

Of course. No sense putting the solution before the requirements.

On the other hand, looking at what the solution offers may suggest
requirements that are worth embracing.

If we are looking to more
prominently feature Python-based tools in the construction of
www.python.org, then we should consider all options.

Sure.

There are many other
Python-based content management tools out there and most, if not all of them
are newer than Zope.

But are they newer *and* more useful than Zope?

Also, let's not forget that newer is not necessarily more impressive to
certain types of people. *Established* and *stable* may be far stronger
qualities to software evaluators and other fiscal-minded types.

If Zope was a true one-size-fits-all content
management system I doubt these other options would have popped up.

I wonder. Hanging out on c.l.python, I sense a real reluctance to
support Zope. I don't know what the history is there, but something
seems to be muddying the waters besides technical considerations.

Products like Twisted may overlap (some) with Zope, but serve an
obviously different set of needs. It makes sense that both Twisted and
Zope exist. I'm not sure at makes sense that we have so many different
templating systems. :-)

Dylan

[Skip Montanaro]

There are many other Python-based content management tools out there
and most, if not all of them are newer than Zope.

Dylan> But are they newer *and* more useful than Zope?

I should have expanded on my statement. I suspect one reason there are
other tools out there which came after Zope was because there was some itch
Zope didn't scratch for them. That itch may have been something as simple
as missing functionality or something not casually obvious, like not being
about to wrap one's head around all that is Zope. (There's that Zen thing
again.)

If Zope was a true one-size-fits-all content management system I
doubt these other options would have popped up.

Dylan> I wonder. Hanging out on c.l.python, I sense a real reluctance
Dylan> to support Zope. I don't know what the history is there, but
Dylan> something seems to be muddying the waters besides technical
Dylan> considerations.

Dylan> Products like Twisted may overlap (some) with Zope, but serve an
Dylan> obviously different set of needs. It makes sense that both
Dylan> Twisted and Zope exist. I'm not sure at makes sense that we have
Dylan> so many different templating systems. :-)

Ask the authors. I suspect Zope's sheer size is very off putting. Zope is
roughly half the size of Python (comparing Python 2.3 and Zope 2.6.0), and
much of Python's heft is because of its excellent documentation, while the
Zope distribution contains very little standalone documentation. That can
be a very big barrier.

Skip

[Kevin Altis]

From: Jack Jansen
On vrijdag, aug 8, 2003, at 23:31 Europe/Amsterdam, Skip Montanaro

Post by Skip Montanaro
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
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
***@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

[Barry Warsaw]

Post by Kevin Altis
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.

I'll just point out that for some of us <wink>, the current set up is a
HUGE improvement in the workload over what we used to have. Also, the
current setup needs very little babysitting. Except for twiddling a
directory permission here and there, and installing an Apache rewrite
now and again, the system is more or less self-powered. I applaud and
worship the pydotorg and webmaster team for doing such a great job on
the content.

Any CMS is going to require more care and feeding and certainly a lot of
effort to get installed and running (witness new.zope.org). I'm not
advocating against it, but we need to be realistic about how much effort
we can collectively put into this, given that we're all squeezing in
volunteer time.

raise-a-million-bucks-a-year-and-count-me-in-ly y'rs,
-Barry

[Dylan Reinhardt]

Post by Barry Warsaw
I applaud and
worship the pydotorg and webmaster team for doing such a great job on
the content.

No doubt. Cheers!

Post by Barry Warsaw
Any CMS is going to require more care and feeding and certainly a lot of
effort to get installed and running (witness new.zope.org).

The problem with new.zope.org is pretty unique.

Long before Zope *had* CMS tools zope.org had hacked together their
own. The real pain of the NZO migration has been the process of
bringing all that old stuff forward into the modern era.

The process ran longer than they expected and still has a few bugs left
in the collector. It's been embarrassing, frankly. But it's not
indicative of what challenges a new system would face.

Post by Barry Warsaw
I'm not
advocating against it, but we need to be realistic about how much effort
we can collectively put into this, given that we're all squeezing in
volunteer time.

What if I offered to stop pestering the list with hypothetical
situations and organized a few Zope hackers to cook up a prototype?

I'm envisioning a howto/whitepaper system that could *supplement* the
existing python.org, should it be deemed worthy of such a task. I'd be
happy to handle hosting until such time as it is integrated into the
official site offerings.

Any interest?


Dylan

[Skip Montanaro]

(I am just thinking out loud here, not proposing this.)

There's a lot of admitted self-interest on the marketing-python mailing list
in seeing Python "grow". This means people will have more opportunity for
Python jobs. If Zope or a similar content management system replaces the
current system, one possible carrot might be that a corner of the python.org
website could be used by contributors for personal websites. Maybe it's
just nerd cachet, but it seems like it would be an attractive enticement.

Skip

[Dylan Reinhardt]

Post by Kevin Altis
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

You are correct. Using Zope does not inherently impose any requirement
that content be served dynamically.

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

If the chosen CMS were Zope/Plone, changes can be tracked in a number of
ways.

Zope provides its own version control, allowing you to revert to old
versions of objects. There is a trade-off, however, for the longer you
store history, the larger (and faster) your database grows. Version
rollback through Zope can raise dependency issues in certain cases.

A more robust system for revision control is provided when Zope's
database is stored as a collection of files, one per object revision.
When stored this way, Zope's entire data set can be managed with your
favorite revision control tools.

So, in a nutshell, yes. It can be done through-the-web *and* it can be
done correctly. :-)

Post by Kevin Altis
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.

A running Zope process is easily scripted from shell and a non-running
Zope installation can be imported and controlled by a Python script.

Furthermore, it is easy (given the right privileges) to import static
files in as Zope objects.

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

Evolutionary change is both possible and advisable.

As one example, it would be easy enough to create a subdomain that is
managed by Zope and leave everything else as it is. You could use a CMS
to provide a howto/whitepaper library. If that sucks, nothing's lost...
the existing site still works. If the file library takes off, maybe
we'll have other ideas of what we should be doing in a CMS. Or maybe
we'll be happy with what we have. Seems win-win to me.

Dylan

[Aahz]

Post by Dylan Reinhardt
As one example, it would be easy enough to create a subdomain that is
managed by Zope and leave everything else as it is. You could use a
CMS to provide a howto/whitepaper library. If that sucks, nothing's
lost... the existing site still works. If the file library takes off,
maybe we'll have other ideas of what we should be doing in a CMS. Or
maybe we'll be happy with what we have. Seems win-win to me.

This raises another issue that has stalled some work in the past: CNRI
still owns python.org as a domain, restricting our ability to create
subdomains. Until that changes (and the PSF *is* working on this), our
ability to experiment is somewhat limited.

[Michael Hudson]

Post by Dylan Reinhardt
As one example, it would be easy enough to create a subdomain that is
managed by Zope and leave everything else as it is.

... except that AFAIK, the python.org domain is still controlled by
CNRI ...

Cheers,
mwh

[Barry Warsaw]

Post by Michael Hudson

Post by Dylan Reinhardt
As one example, it would be easy enough to create a subdomain that is
managed by Zope and leave everything else as it is.

... except that AFAIK, the python.org domain is still controlled by
CNRI ...

But not for long...
-Barry

[Guido van Rossum]

Post by Michael Hudson
... except that AFAIK, the python.org domain is still controlled by
CNRI ...

Not for much longer. I've got the document signed by CNRI saying they
are transferring the domain to the PSF; all we've got to do is
implement the transfer (for which we have 30 days).

--Guido van Rossum (home page: http://www.python.org/~guido/)

[Aahz]

Post by Guido van Rossum

Post by Michael Hudson
... except that AFAIK, the python.org domain is still controlled by
CNRI ...

Not for much longer. I've got the document signed by CNRI saying they
are transferring the domain to the PSF; all we've got to do is
implement the transfer (for which we have 30 days).

Woo-hoo! Three cheers!

[Barry Warsaw]

Post by Guido van Rossum

Post by Michael Hudson
... except that AFAIK, the python.org domain is still controlled by
CNRI ...

Not for much longer. I've got the document signed by CNRI saying they
are transferring the domain to the PSF; all we've got to do is
implement the transfer (for which we have 30 days).

Yee haw! I assume there's paperwork to fill out with the registrar and
then we need to set up some nameservers some place. Can XS4ALL do this,
and will we have the ability to make updates ourselves?

-Barry

[Thomas Wouters]

Post by Barry Warsaw
Can XS4ALL do this,

XS4ALL can, yes. It's up to the PSF board (which will be meeting tomorrow.)

Post by Barry Warsaw
and will we have the ability to make updates ourselves?

If XS4ALL hosts it, yes, through our web-interface... although it's
currently only in Dutch :-S Hopefully soon it'll be in English, too :)

[Aahz]

[note followup to pydotorg-redesign]

I'm not on pydotorg-redesign.

You should be, if you want to discuss the future of the web site. Given
that we're currently having a lot of traffic on pydotorg due to current
work, I really don't want to flood the list any further.

Is there an army of people we trust to do content for the website who
don't have the necessary technical-fu to deal with today's system?

That's not the question. The question is whether there are people who
have content who we don't trust to have direct access to creosote.
Simple example: I'd like a submission system for jobs that requires
*them* to format the entries, but doesn't let it get posted until it's
reviewed by a moderator.

[Michael Hudson]

Post by Kevin Altis
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.

I'm not on pydotorg-redesign. Is there an army of people we trust to
do content for the website who don't have the necessary technical-fu
to deal with today's system?

Cheers,
mwh

[Jack Jansen]

I stand corrected, Kevin and Dylan are probably right that my reasoning
is
somewhat circular: the current tools are right for the current crowd
and the
current tasks because they co-evolved.
--
- Jack Jansen <***@oratrix.com>
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma
Goldman -

[A.M. Kuchling]

Post by Dylan Reinhardt
At present, the number of people who contribute to c.l.python are
probably a good estimate of the upper bound. The number who already
contribute content to python.org are a fair lower bound estimate.

In fact the existing FAQ is already open to be edited by anyone through
the FAQwizard script. The result has been a FAQ with uneven quality,
uneven relevance, and many, *many* outdated questions. The nature of
the web interface means it's much harder to revise the FAQ; there's no
way to break up the sections, no way to rearrange questions, no way to
do a search-and-replace over the entire FAQ ...

Despite the FAQ being open to anyone for editing, no one edits it.

I don't believe switching to Zope will magically result in a flood of
command-line fearful people suddenly appearing and offering to maintain
extensive documentation collections.
The Wiki seems to be used mostly for pages of links, not extensive
text; we could implement a little link-tree-editing application and get
much of the same effect as the Wiki.

Stray thought: are there a few people who do a majority of the Wiki
maintenance? If yes, we should invite them to get commit access for
pydotorg. Is there a way to get a full list of people who've edited
pages?

Post by Dylan Reinhardt
I wonder. Hanging out on c.l.python, I sense a real reluctance to
support Zope. I don't know what the history is there, but something
seems to be muddying the waters besides technical considerations.

Every complaint I've seen has been technical; even developers of
competing systems are still friends with the Zope people. I wrote up
http://www.amk.ca/python/writing/why-not-zope.html as an explanation of
why one project I worked on no longer uses Zope.

--amk

[Johannes Gijsbers]

Post by A.M. Kuchling
I don't believe switching to Zope will magically result in a flood of
command-line fearful people suddenly appearing and offering to maintain
extensive documentation collections.
The Wiki seems to be used mostly for pages of links, not extensive
text; we could implement a little link-tree-editing application and get
much of the same effect as the Wiki.

I think it would be easier to solve the problems with the Wiki by integrating
it into the rest of the site. Addressing the separate navigation/layout style
is easy by using CSS and the HTML used for the navigation bar. I don't know
whether Ultraseek could also crawl through the Wiki.

Post by A.M. Kuchling
Stray thought: are there a few people who do a majority of the Wiki
maintenance? If yes, we should invite them to get commit access for
pydotorg.

I could name a few:

Daniel Dittmar (***@dittmar.net) - WebProgramming editor
Mike Rovner - BoostPython editor
Juergen Hermann - general cleaning

and I try to keep the PythonEditors and PythonHosting pages clean.

Johannes Gijsbers

[Aahz]

I'm not suggesting Zope isn't good stuff. I'm not convinced though
that it is the right tool for this particular job. If we are looking
to more prominently feature Python-based tools in the construction of
www.python.org, then we should consider all options. There are many
other Python-based content management tools out there and most, if not
all of them are newer than Zope. If Zope was a true one-size-fits-all
content management system I doubt these other options would have
popped up.

Are there? Non-Zope CMS solutions? I've seen a lot of web frameworks,
but damn few that appear to address CMS in particular. Am I missing
something?

[Dylan Reinhardt]

I tossed around an idea in the bottom of a couple posts that probably
should have gotten its own thread. So here it is.

Would this group be willing to evaluate a demo of a Zope-based CMS that
could *supplement* the current offerings at python.org? If y'all are
willing to look at it, I'd be willing to assemble a small team to do it.

I propose to create a system that could serve as the definitive
repository of howtos, white papers and other user-created content
relating to Python usage (both in general and in specific problem
domains). It could catalog recipes and howtos found on other sites as
well, reducing duplication and ensuring an authoritative collection.
This is well within my level of experience to organize and execute.

Truth be told, I was thinking of doing something like this anyway, but
it'll get done a lot faster if this group shows any interest in
evaluating it. A system like this could have inestimably greater value
as an "official" Python resource than it would as yet another small
community web portal.

If this could be done such that it required no additional inputs from
current maintainers, would you be willing to take a look?

Dylan

[Aahz]

Post by Dylan Reinhardt
Would this group be willing to evaluate a demo of a Zope-based CMS that
could *supplement* the current offerings at python.org? If y'all are
willing to look at it, I'd be willing to assemble a small team to do it.

Why don't you hold that thought until about two or three weeks after the
formal transfer of python.org to the PSF? (I suggest waiting because
there are probably some long-standing DNS changes that have been held
pending the transfer that will get higher priority.)

[Dylan Reinhardt]

Post by Aahz

Post by Dylan Reinhardt
Would this group be willing to evaluate a demo of a Zope-based CMS that
could *supplement* the current offerings at python.org? If y'all are
willing to look at it, I'd be willing to assemble a small team to do it.

Why don't you hold that thought until about two or three weeks after the
formal transfer of python.org to the PSF? (I suggest waiting because
there are probably some long-standing DNS changes that have been held
pending the transfer that will get higher priority.)

I'm happy to hold this thought for a few weeks. Obviously there are a
number of pressing things to attend to.

Good news about the domain transferring. Coordinating DNS with another
organization can be a PITA even under the best of circumstances.

Dylan

[Skip Montanaro]

aahz> Are there? Non-Zope CMS solutions? I've seen a lot of web
aahz> frameworks, but damn few that appear to address CMS in particular.
aahz> Am I missing something?

Nah, probably it was me.

Skip

[Steve Holden]

-----Original Message-----
Reinhardt
Sent: Friday, August 08, 2003 7:31 PM
To: Kevin Altis
Subject: RE: [Pydotorg-redesign] The Zope question

[...]

Evolutionary change is both possible and advisable.
As one example, it would be easy enough to create a subdomain that is
managed by Zope and leave everything else as it is. You
could use a CMS
to provide a howto/whitepaper library. If that sucks,
nothing's lost...
the existing site still works. If the file library takes off, maybe
we'll have other ideas of what we should be doing in a CMS. Or maybe
we'll be happy with what we have. Seems win-win to me.

Now *that's* a good way to introduce these methods. Personally, as a
technical type with a business hat I'm very interested in seeing the
marketing types (e.g. Trevor Toenjes) get to work on some decent
marketing content for Python.

regards
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/pwp/

[Steve Holden]

-----Original Message-----
Sent: Friday, August 08, 2003 8:24 PM
Subject: [Pydotorg-redesign] Experimenting with subdomains

Post by Dylan Reinhardt
As one example, it would be easy enough to create a

subdomain that is

Post by Dylan Reinhardt
managed by Zope and leave everything else as it is. You could use a
CMS to provide a howto/whitepaper library. If that sucks, nothing's
lost... the existing site still works. If the file library

takes off,

Post by Dylan Reinhardt
maybe we'll have other ideas of what we should be doing in

a CMS. Or

Post by Dylan Reinhardt
maybe we'll be happy with what we have. Seems win-win to me.

This raises another issue that has stalled some work in the past: CNRI
still owns python.org as a domain, restricting our ability to create
subdomains. Until that changes (and the PSF *is* working on
this), our
ability to experiment is somewhat limited.

Couldn't we map a subdirectory to either redirect it to another server
or have our server apply to another server for the content?

--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/pwp/

[Aahz]

Post by Steve Holden
Couldn't we map a subdirectory to either redirect it to another server
or have our server apply to another server for the content?

In theory, yes; in practice, I'm not thrilled because of the mirror
issue. For strictly experimental work, I think it'd be fine to use an
HTML refresh.

[Trevor Toenjes]

Post by Aahz
In theory, yes; in practice, I'm not thrilled because of the mirror
issue. For strictly experimental work, I think it'd be fine to use an
HTML refresh.

how is the mirror handled?
is there some type of python/backend-synch, XML,
or are we simply talking about a static HTML copy?

if the latter, then mod_rewrite Apache to redirect directory requests to the
appropriate areas on the file system. Setup the legacy content in one area,
which should continue to be the repository for documentation and be fast.
And setup a CMS(zope) to operate the homepage and spawn new subpages from
there.

Any mirror would be completely unaffected, because it's the generated HTML
it wants. It doesnt care how we generate it.

shoot. you could even setup up subdomains.
www.python.org as the pretty face for python
support.python.org for docs and the community and command line stuff.

You could manage them completely differently if you choose.
and then mirror those, too.

I am not a great sysadmin, but even I could do this.
The benefit is you can now choose the best(or preferred) tool for the job.
And hopefully achieve end objectives of marketing python better while
attracting more content volunteers.

-Trevor

[Aahz]

Post by Trevor Toenjes

Post by Aahz
In theory, yes; in practice, I'm not thrilled because of the mirror
issue. For strictly experimental work, I think it'd be fine to use an
HTML refresh.

how is the mirror handled?
is there some type of python/backend-synch, XML,
or are we simply talking about a static HTML copy?

The latter, using rsync.

Post by Trevor Toenjes
if the latter, then mod_rewrite Apache to redirect directory requests
to the appropriate areas on the file system. Setup the legacy
content in one area, which should continue to be the repository for
documentation and be fast. And setup a CMS(zope) to operate the
homepage and spawn new subpages from there.

I'm not opposed to this, but I'm wary about a mixed setup.

[Trevor Toenjes]

So what is the hold up with the PSF becoming the owner of python.org?

This is a matter of a signed form and waiting a couple days for the domain
records to refelect the changes. I have seen this issue float since I have
been on the list.

Someone needs to knock this out ASAP, before we can move on.

-Trevor

[Aahz]

Post by Trevor Toenjes
So what is the hold up with the PSF becoming the owner of python.org?

It's a political issue. I'm not involved enough to say more.

[Steve Holden]

Trevor:

The problem is that the owner of the domain has to take action to
transfer it and CNRI, as the current owner, appears to be (shall we
say...) busy with other priorities. It's not a purely technical problem.
FWIW, in a recent interview (soon to be published by O'Reilly) Guido
said:

"""
Q: What's the situation with the python.org domain ownership, and do you
anticipate any changes any time soon?

A: As you might know, CNRI still owns that domain, and has let the PSF
use it without much restriction, although they did ask us to keep the
1.6 release on there despite the fact that nobody much uses it.

They have finally approached me, having found the time to address the
question, with a contract to handle the transfer of the domain name,
which is probably the most important thing, a number of trademarks, and
the copyright to the content of the python.org website - the CNRI
position has been that they own that copyright because the web site was
started when we were all at CNRI.
"""

I really think it's best to leave the ex-CNRI Pythonistas to handle
this, since they know the personalities and the issues involved. Looks
like it won't be too much longer.

regards
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/pwp/

-----Original Message-----
Trevor Toenjes
Sent: Saturday, August 09, 2003 12:02 PM
Subject: [Pydotorg-redesign] why the delay with transferring
python.org
So what is the hold up with the PSF becoming the owner of python.org?
This is a matter of a signed form and waiting a couple days
for the domain
records to refelect the changes. I have seen this issue
float since I have
been on the list.
Someone needs to knock this out ASAP, before we can move on.
-Trevor
_______________________________________________
Pydotorg-redesign mailing list
http://mail.python.org/mailman/listinfo/pydotorg-redesign

[Tim Parkin]

Guido Hailed!!

Post by Guido van Rossum

Post by Michael Hudson
... except that AFAIK, the python.org domain is still controlled by
CNRI ...

Not for much longer. I've got the document signed by CNRI saying they
are transferring the domain to the PSF; all we've got to do is
implement the transfer (for which we have 30 days).

And congratulations from both of us at Pollenation... :-)

Tim and Matt