[WF-Infra] Infra Meeting: October

HansHäggström hans.haggstrom at helsinki.fi
Wed Oct 24 03:35:58 PDT 2001

At 11:02 2001-10-23, Michael Miyabara-McCaskey wrote:
>Hello everyone,
>I try not to do speeches, but I think the following needs to be stated.
>"Infrastructure exists to enable others to produce."

Good speech, and it's good to keep this goal in our mind.

With the experience of using the previous websites,
we should try to spot tasks and areas that could be automatized(is that 
even a word? :-)

As Phil said, we should also try to use existing stable products if they 
fit our needs.


>#1 - Belegost (www server) is going away. We were originally notified in May
>2001 and the decommision time is approaching, though not cast in stone. It
>will very likely be by the end of the year which is only about 2 months
>away. For this item, we need as much information as possible to indentify
>any applications, databases, scripts, etc... That are still running on this
>system, and then a new home needs to be found (probably on victor and/or
>moria).  Myself I am aware of "wiki" the current website needing to be
>moved, and something called "Phoenix", but please send any additional
>information on this machine that you know.

Phoenix is one of the game projects (so it's basically part of the content 
migration below,
if I understand correctly).

For my own part, I still have some parts of the Mason site that I haven't 
had time / motivation
to move over yet.  These will be needed in the upcoming Mason development, 
so I have the motivation now.

A big area that needs to be moved over, and which also needs some 
restructuring, is the Media Area.
We currently don't have any active media coordinator, so there's no one who 
has been tending to it.
Perhaps the Media team that is being created for Mason could also take care 
of the Media Area of the site,
as much of the documents and other things in the media section is relevant 
for Mason media too.

>#2 - Web content migration from "wiki" to "Zope".  As I understand it, this
>migration in one form or another has been progressing for nearly a year.
>This is a big time sore spot for a lot of people, mainly due to the amount
>of time.  But more than that, this has caused this group to lose
>credibility.  We are no longer thought of as a group that has the capability
>to accomplish anything.  Now, just in case anyone forgot... I'm not here to
>point fingers... I'm here to help make Worldforge great...  Any and all
>ideas on how to quickly finish this migration and produce a product that is
>at least as functional as the current "wiki" website needs to be discussed
>immediately.  (As a sub-note, the "wiki" site allows WF people to create and
>edit content without needing an admin to "fix Zope", so when I say it needs
>to be at least as functional, I'm not talking about a site were the Infra
>Team needs to provide 24/7 support, we need a stable reliable product).
>#3 - Web Site Navigation.  Though some lump this into the "content
>migration" I do not feel this is the same thing.  We have a specific number
>of types of users that use our site.  And I do not believe the current
>navigation system works for any of them.  I have heard the new website
>called a "morass", a "rat's nest", and other colorful terms.  Mind you this
>is, what is thought about the "new" site, I won't even go into the old one.
>I have seen a number of off the cuff answers to this problem, let's discuss
>them.  But I'd like to take them from the perspective of a profiled type of
>user. Meaning:
>     "New User - Has never been to WF before, and wants to know What we are
>doing, How we are progressing, and Can we tell this person that they have
>many ways to contribute so encourage them to return?".
>     "Returning User - Trying to find out more detail on What's fun to do"
>     "Joined WF - Looking for where to lend help"
>     "ETC..."

A mistake I think that was made with the old site was having two different 
one for newbies and one for developers.  The developer home page was 
located under
the newbie homepage.

Site Structure

So, as I proposed in an earlier email to infra@, we could move the areas 
under developers/
to the top level, and get these top level areas for the website:

- Project
- Games
- Downloads
- Content
- Engineering
- Resources
- Infrastructure

The structure of the areas themselves is relatively clear currently, and is 
less critical anway
than the top level structure.

Here's the most common directory structures that could be used by different 
products / projects on the site:

Area -> Sub-area -> Project -> Project part -> Page
Area -> Sub-area -> Project -> Page
Area -> Project -> Project part -> Page
Area -> Project -> Page
Area -> Page

For example:
Engineering -> Servers -> STAGE -> Developer Documentation -> Stage White 
Paper 01
Engineering -> Clients -> Frost -> Screenshots
Games -> Mason -> Project -> Required Reading
Games -> Werewolf -> Design Document
Project -> Intro

One area where deeper hierarchies are needed is for example the world 
Content -> Worlds -> Dural -> Gazetteer -> Cambria -> Summerset

In addition, the navigation menus were mostly hand edited, so they didn't 
really reflect the
actual structure of the site, making navigation confusing.

The new site design (codenamed Rainbow) that Phil has been working on 
solves this by generating all menus automatically,
based on the contained sub folders.
The navigation neighbourhood in the left navbar could also show siblings, 
uncles, or grandchildret of the
current document.  We'll have to look at the space usage of this, and 
settle on a good compromise.

We also discussed about some interesting ideas, such as allowing users to 
edit a separate description of a page
in the page edit form,  that could be used to generate a list of sub pages 
along with descriptions, something that
seems to be a very common type of page in the middle layers of the site 
( see the logs 

>#4 - Web Site Content Management.  Again, this I think has been lumped into
>the "content migration".  But I feel this is it's own topic as well.  Much
>of the content that exists is seriously out of date.  Poorly cross
>referenced.  Has links that do not work.  Etc... Unfortunately, this
>translates to the reader as "these guys don't have it together"... or "these
>guys are dead" (content is so old).  What is needed in this area, is both a
>way to quickly check the site for valid pages, but also this requires buy in
>from each of the other groups to keep the content up to date.  What I would
>like to discuss is what types of tools can help automate the first part
>(valid pages),

We discussed some ideas for making it easy to add related links and version 
history items
to a page in the above IRC discussion.

Basically there would be fields for this on a page edit form, which would 
make it easy to
remember to update those things too.
A Version history entry has the following fields:
- Version
- Date
- Author nick
- Author name
- Changes made to the page/document

http://moria.mit.edu:8080/wf/dev/systems/mason/game/building_houses  for an 
of a version history (it's lacking the full name, though).
That page also has related documents, related discussions, and a glossary, 
three sections
that should be possible to automate to some degree (see link to earlier IRC 

Glossary Database

Here's an example of what a glossary could look like:

Basically, terms that should be included in a glossary would be marked with
<span class=term> someTerm </span>
the first time it occurs in the document.  This style makes it bold italic 
for example,
and also makes it easy to search for.  When the document is saved, all the 
terms in it are added into
the glossary database,  (could be eidetic based, or just use the zope tiny 
tables product), along with the
project/effort/product they are related to (the default could be defined by 
a zope variable for exampe).
The definition for the terms would be entered in a separate glossary 
editor, that could show just
the terms that are used on a specific page, to make editing easier.

Document Status?

Regarding a version & version history for Pages, would it make sense to 
have a Status field too,
with possible values such as DRAFT, REVIEWED, APPROVED, REJECTED, STALLED, 
or something such?

That would tell how valid a document is..  We could also do document 
reviews a bit like the coders
have been doing code reviews over email.  This would not be very useful for 
some types of web pages,
but it seems those types of web pages can be autogenerated a lot (list of 
clients, news page, etc).

The review process could be somewhat automated, the edit page (or some 
other suitable place),
could have a 'send for review' button, which would open an edit field for 
writing a review introduction,
and selecting what mailing lists to use (by default the mailing list 
associated with the current area would be used,
this could be a zope property called primary_mailing_list (a 
secondary_mailing_lists property would hold a list
of all mailing lists that are related to a particular page).
Then the review introduction and the page would be sent to the mailing 
list, perhaps as plaintext + attached html version.
This allows people to insert comments directly at relevant places, and 
makes it generally easier to comment,
generating more comments than posting a URL would do.

The page author would then collect and apply responses, and mark the page 
as reviewed.
Here a possibility to automatically link to replies to the review message 
would be very nice
(based on a review ID in the subject, for example).  That would require a 
mailing list database of some sort,

A page could be approved if three or more other persons approve it (this 
would probably be easiest to handle
manually, through IRC or mailing lists.  We can automate this system as 
needed after having some experience
with it).

The nice thing is that the status is recorded in the history list entry 
where it happened, and can be changed
in subsequent history list entries.  For example, a 1.0.2 version of an 
approved 1.0.0 document could still
be left as APPROVED, but the 1.4 or 2.0 version of it might be changed back 
to DRAFT.  A document could become
DEPRECATED, and then later resurrected again, and so on.

>and then making the assumption that the developers have 1
>thing in common... CVS, how can we make their system into a feeder (push or
>pull) into our website such that people will always be able to quickly see
>"Whats New" in each groups sections.

Hmm.. Do you mean updating pages in the website with CVS?  Or displaying CVS
change messages / statistics?

We should certainly not require CVS for any commonly used website features,
not everyone has CVS installed and set up (only the coders will need it, 
writers, designers, etc. don't necessarily need it for anything else).

Ideas for Sidebar Sections

Displaying CVS statistics somewhere or even in relevant pages would be 
nice, though.
It could be a navbar section, with latest three CVS commit comments, number 
of CVS commits during the last
month or so, and perhaps top five contributors the last month.
It could look at CVS commits to module(s) that are marked as relevant for 
that page, through a related_cvs_directories
zope property, perhaps.
It could get the data from the cvs mailing list from a mailing list database.

Another navbar (should we call it sidebar btw?  It's doing more than just 
navigation..) feature that would be very nice,
is shoving the last five bookmarks that are relevant for the current page.
A bookmark would be relevant if it was made in an irc channel that is 
listed in the related_irc_channels zope property
for that site, or if it contains any of the words listed in a 
bookmark_keywords file / zope property for that page.
Again, we can get IRC bookmark by looking for bookmark posts in the 
general@ mailing list database.

Another email related sidebar could simply show the N (default five or ten) 
latest emails from selected mailing list,
or that contain some keywords specified in a file / zope property.

Note that special sidebar sections will not be included in every page, 
things like email or bookmark sidebar sections
would probably only be included on a project main page.

Also, in some cases the sidebar section could perhaps be displayed in the 
page content area instead.
For example, an area main page could have the latest news and bookmarks in 
the page content area instead of crammed
into the sidebar.

The sidebars that should be shown for a specific page could be configured 
in the edit form for that page.

And finally, sometime in the future a custamizable home page for different 
users could allow the users to specify different
sidebar sections to show in the content area of their 'home page', and 
perhaps also what defaults to use for the rest of the site.

Btw, should we call sidebar sections something more specific, perhaps 
sidebar boxes, or some other name...
In the same style that Slashdot has slashboxes.

Email Database

So, in conclusion it seems like some kind of database of emails in the 
mailing lists would be very useful.
The emails should be colorified / HTMLified like the IRC logs are, and 
possible to link to with an URL.
There should be an interface of some sort for browsing the email archives 
by thread, etc.

The email database should be searchable of course, and there should be some 
way for python scripts / zope tools
to access it.  In particular, there seems to be a need to filter through 
incoming mail to extract review responses,
irc bookmarks, or mails relevant to a certain area/page.

Are there any existing products that we could use or build on for this?

Well, there's some ideas for possible things to automate on the website...
If some of them are unrealistic at the moment, or seem like they would 
the work flow, we can leave them for later / rethink them.

Hans Häggström (aka zzorn)
"Share and Enjoy" - Cirius Cybernetics corp. - THHGTTG

More information about the Infra mailing list