Developer experience hackfest - comments about developer.gnome.org
- From: Frederic Peters <fpeters gnome org>
- To: gnome-doc-devel-list gnome org
- Cc: Allan Day <allanpday gmail com>
- Subject: Developer experience hackfest - comments about developer.gnome.org
- Date: Tue, 29 Apr 2014 15:01:48 +0200
Hi all,
The developer experience hackfest starts tomorrow, I won't be able to
attend but I promised to write down some comments on the current
developer.gnome.org and possible directions. Here I am, with notes on
both the technology behind and the structure & navigation, they won't
cover as much as I wanted, too little time :/
It's currently a static website generated with a serie of XSL files,
this had some advantages as most of our sources were XML files (mostly
gtk- doc and docbook at the time). Nowadays it's a bit less true as
the source files are mostly HTML, produced by other tools (mostly
gtk-doc, using the files from the tarballs, instead of generating our
own version, as it's not always possible).
I believe the process should be reviewed to always have HTML files as
source, for Mallard this will mean running yelp-build on the server,
and that has the benefit to make it easier to update to the latest
version. (in the past it was difficult to get new packages installed
on the server, as it was running RHEL5 I believe, and nobody was
available).
This should also make it easier to add or modify "native" pages (like
the index page), as they would be treated like any other HTML files,
instead of being lost in XSL files.
We still need to have some transformation in place, to get some common
navigation elements on all the pages, and to have correct crosslinks.
(I won't mention them again but they are quite an issue to deal with).
There are various tools to turn a collection of HTML files into a web
site, static generators may be hip again (hyde, jekyll) (well, they
were hip three years ago, it may be less true today), but we also got
more experience running django sites (l10n.gnome.org for example).
Thinking out loud, I'd go with a dynamic website, as this would solve
the issue of stale files, and offer better ways to integrate important
things, like search.
On a structure level, there are at least two important questions: what
kind of navigation do we want between programming languages (and
perhaps on a more fundamental level, how do we expose them?), and
between different versions of the libraries. At the time it was
important to have various versions available online, for exemple GTK+
2.6(?) was available because Nokia(?) used that version in their
developments, but today we may want to expose a more unified "this is
the current GNOME API" approach. (and that "bundle" approach would
also benefit devhelp)
This brings the question of the libraries we want on the developer
website, it started as just our core libraries, but requests after
requests, it got its share of other libraries. (but if we decide to
put them away, it's certainly also important to have a place for
them).
Summing it up, I have some ideas on the way I'd rebuild the site
today, in terms of technologies, but the hackfest is the great
opportunity to refine (or redefine) various navigation and structure
requirements.
Fred
[Date Prev][Date Next] [Thread Prev][Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]