Maintaining web pages is a drag. Every project lead knows it’s been on the task list for ages, with not quite enough priority to get time. It isn’t usually fun, straightforward, or easily delegated. In general, the farther a thing is from where we spend time the less likely it is to get our attention. And we spend our time in the code, on the designs, in bug lists, and in front of the thing itself. That’s the face we see.
But it is quite different from the face everyone else sees.
They see the product. And the impressions or expectations of this product are as important as the actuality of the project that produces it. Things work best when these perceptions are in sync — or at least aren’t out of whack.
So, before someone even has a chance to try your thing of beauty, what face do they see?
Chances are a search engine or link sent them to one of the following:
Projects
The projects index is out of date and incomplete. Which is understandable since it isn’t dynamically generated and no one maintains it. In order to update it, you need special access to push changes to the large (700 MB) and complicated gnomeweb-wml git module. A bad combination of properties.
The site itself is using an old design template that hasn’t been used on other gnome.org sites for many years. There is a strange blank space on the right side where some sidebar probably was supposed to go. Until recently, it even had some broken links too.
The index is a confusing mix of applications that have a user face and components that do not.
The list is incomplete because most recent projects have home pages on the wiki. Some projects have similar home pages on both the projects site and the wiki. Some projects consider the wiki the canonical home page and some consider the projects page canonical. Clearly, having a consistent story would be better.
So that’s just for the index page. The situation for each project site is even worse since they are all expected to have their own site templates. Which means that unless the project maintainer is really on top of things or has a designer on staff, the design falls really out of sync. This is sort of fun as a way to walk through the visual history of GNOME but isn’t a very nice face to present to the world.
Wiki
Old wiki design
Like projects.gnome.org, the site template was out of date and really needed an update. Also like projects.gnome.org, so much of the information on the wiki was out of date or obsolete. And the lack of any kind of structure made that information hard to find.
However, the wiki is much easier to edit and get casual contributions and fixes. It is active and the place where most groups actively contribute and coordinate efforts. The wiki is information rich and deep with historical knowledge. It is here to stay.
Git
The “All Projects” index on git.gnome.org isn’t really intended to be a user facing project listing. It could be better but it isn’t the face we are hoping to show this new user of yours. Fortunately, the site design template is already up to date and seems to be working pretty well.
Future work here may involve doing more with the data we have in each project’s DOAP file.
So which one do we want them to see?
To figure this out we asked the stakeholders. The sysadmin team strongly prefers consolidation on the wiki. We know we have to keep that going. And it doesn’t require editing an esoteric module in git and running site-update jobs in the background. The design and web teams prefer not having to keep two disparate site styles updated and in sync. The project maintainers almost unanimously (except two) preferred editing a wiki to editing a gnomeweb-wml in git. And loved the ability to more easily delegate trivial site maintenance and updates to anyone with a wiki account.
The plan
So the answer was pretty clear. We would:
- Update the wiki theme
- Audit all wiki pages
- Move obsolete wiki pages to Attic
- Establish guidelines for wiki page organization
- Create templates for App & Project pages on the wiki
- Create dynamically generated listings for Apps and Projects on the wiki
- Move and redirect wiki pages to follow new guidelines
- Audit the contents of projects.gnome.org
- Identify new project locations on the wiki, following the new guidelines
- Work with maintainers to migrate content to the wiki
- Provide projects-old.gnome.org as way to get to the old projects site
- Redirect old project pages to new wiki locations
- Redirect the projects site to the Apps listing on the wiki
And where are we with that?
After a couple months of really tedious work I’m happy to say this is pretty much done! With only a few details remaining:
- gnumeric hasn’t been migrated because we need to finish porting the docs over.
- We still have another iteration to do on the design of the wiki.
I’d really like to thanks Andrea Veri for all his work on this. As well as everyone else who has been helping for many weeks now.
Can I help?
Yes, please. Here are some ideas:
- The best thing you can do is to become familiar with the guidelines for the wiki and make sure new pages are put in expected locations. It would be great if we could, as my mom used to say, “keep up, don’t catch up.”
- Help correct relative page links when linking to a sub-page. For example, if you have a page called “Apps/FooBar/Screenshots” a link to it from “Apps/FooBar” should look like “[[/Screenshots|Screenshots]]”.
- Help us find and fix any broken links. We tried our best to prevent it when possible and correct them whenever they were noticed but hey – it isn’t easy.
- Update your App or Project page to follow the application template and project template, respectively.
- Volunteer to do something interesting with DOAP files on git.gnome.org – maybe similar to http://projects.apache.org/references.html
- Help ensure Andrea Veri’s contract is renewed and stays on as the GNOME sysadmin!
And lastly, keep making GNOME great — inside and out.