[Pydotorg-redesign] Logo question

[Fred L. Drake, Jr.]

Tim Parkin writes:
 > Most of the content will only need simple transformation to become
 > compliant. The remainder can be finalised by hand. It's our intention to
 > parse the content from the website into an form in which the directory
 > structure is irrelevant (unique id's for navigation). Once this is done,

This seems very painful to work with from a maintenance perspective.
How do you expect people to maintain site content?

Do we want to bind up a change to the site's graphical design with a
change in the approach to maintenance?  I can see changing/replacing
the specific tools used, but changing approaches seems out of scope at
this point.

(This is not to say that there shouldn't be a change in approach to
content management, or that I'd be opposed to a change.  I am opposed
to conflating the issues of graphic design with a change in content
management tools.)

 > Any content managed site will have problems with validation unless we
 > can repurpose the content as Structured text (reStructured text?). I

That's a tool issue; we can work around it in many ways.

We could definately start working on support reStructuredText in
HT2HTML, or in some new tool.  I'd love to be able to use
reStructuredText to create and edit content.

 > don't know what people feel about this but IMO it would be very nice and
 > is our preferred solution for content management system where knowledge
 > needs persistence.

Beats editing HTML!

Some documents based on more structured information would need to be
generated from some other representation, but ideally that should feed
rather than bypass whatever general tools are being used (e.g., they
should generate .ht or reStructuredText documnets wherever possible).

...
 > A final question is about talking about the project outside of this
 > mailing list/wiki. Although I can achieve a lot regarding cross browser
 > css, there are a lot of people I know out there whose resources I would
 > like to call on if I hit any large stumbling blocks. I suppose the
 > answer I'm looking for fitsinto either ('Tell as many people as you
 > want', 'please keep it to a minimum number', 'we'd like to restrict it
 > to people who have are involved with Python via mailing lists').I had in
 > mind maybe 3 or 4 people to contact if needs be.

I don't see why there'd be any problems with asking for assistance or
feedback from a handful of people.  I don't know of any reason for
secrecy, though it is easier to get things done when there aren't too
many sources of random feedback and vague new requirements.

I'd expect that we'd want to go from a handful of pages to a larger
portion of the site built using some tool support without involving
too many people, and then bring in more to finesse the design and test
for cross-browser issues.  Once we can present a large portion of the
site using the new design, we should consider presenting a "demo" site
to the community for feedback and testing.

 > Finally, how do people feel about using Zope as the cms (possibly Zope 3
 > if it appears stable soon). Zope seems to offer 80% of what we needed an
 > we can develop the rest . Obviously this would need substantial cacheing
 > (perhaps even serve the site up as html still but use Zope as a static
 > publishing system and admin interface?).

Zope 3 isn't going to be sufficiently stable real soon; there are
still some very fundamental questions being asked among the
developers.

We don't want to use Zope 2, as that will see less new development in
a couple of years, though we expect to maintain it for quite some
time.


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Zope Corporation