Re: wgo revamp timeline (proposal)

[Gergely Nagy <greg gnome hu>]

Hi,


On Thu, 2006-07-06 at 13:47 +0200, Quim Gil wrote:
> After the wgo revamp BoF meeting at Vilanova I'm in charge of pushing a
> list of tasks we agree to do during 2006, and a timeline.
> 
> Here is the draft: http://live.gnome.org/GnomeWeb/DevelopmentTimeline


Constructive criticism of the timelime follows :)

I think this timeline, and the discussion that followed on this list
focuses way too much on the actual CMS system used.

First and foremost, I miss a list of goals to be achieved within this
timeframe. The GnomeWeb wiki page lists some goals, but they seem too
vague or ambitious for now.

There are a lot of implicit issues with this timeline that need to be
made more explicit, like the scope of the revamp. (I guess our goals are
implicit too, but it's hard to grok for a newcomer to the project).

There are no dependencies defined on the development steps.

Not all involved people are visible.


Let's see what we can do about that.

I guess our main goal and scope for this timeline is to revamp the main
www.gnome.org website, while not touching others (e.g.
developer.gnome.org). We have to state our goals, and non-goals, i.e.
what we don't want to do, or what we want to do later. Let's clean up
the GnomeWeb wiki page while we are at it.

We have to define what's wrong with the current implementation and what
we can do about it. Easier navigation, better content, nicer theme,
easier editing of content, I18N, etc. We need a list like that.

We also need to define what's gonna be on the main gnome web site, and
what's not. That's the partitioning part of the timeline. A lot of
things depend on this. We might have to kick some content off the WGO
site, and include something not yet there.

Once we know what content we will provide on the site, we can define the
authoring policies. Responsibles, licensing, translation, URL scheme,
etc.

Only then can we look at what technical means are necessary to fulfill
the above mentioned list of goals. This will give us the specific
requirements for a CMS system.

The design of the site can be investigated parallel to all this. Theme
problems can be identified, mockups can be made. Theme implementation
can start as soon as we decided on the CMS. Actually, it could even
influence the selection of the CMS.

Sandbox systems must be set up for each candidate CMS to test features.

Then, at some point we'll have to decide if the whole endeavor makes
sense at all. Whether the new site will be actually better than the old
version, and whether we can finish within the timeframe. 


I would call this our first milestone.


Then, we have to set up a staging server, where the CMS can be installed
and transitioning can begin. Old, but still relevant content has to be
imported, new content written. Theme must be finalized.

A very thorough testing must be conducted before flipping the switch.
Add as many milestones until final release as necessary.



As the first steps, I suggest to clean up the current GnomeWeb page a
bit. Let's include some pimping for out efforts: state what's going on,
list our top level goals, and describe how people can get involved
(lists, irc). As people take responsibilities, let's list it there as
well. Let it be an entry point for the revamp.

We should also assess the current wgo state ASAP. Map the current
content. Who were writing it? Are they still interested? Describe
current system. Who was running it? How does it work? We'll need this
info to justify why a new system is better.


I realize that this may all be common knowledge to the people already
involved with the wgo efforts. I guess I'm the guinea pig to test new
contributors :)

cheers,
Greg