Google is particularly shit at pointing people to the correct version. If we choose to have multiple versions still, we should put a giant warning at the stop saying it's not the current version, and perhaps have a version switcher.
Also, while we're modifying the version infrastructure, can we make "unstable" mean the same thing as "latest"? It's weird to have a stable version come out, and have the unstable link still be outdated.
Allan Day wrote:Since the hackfest in Norwich in January it's possible to get specific
> Much of these issues come down to infrastructure, in my opinion. It's
> hard to get into writing docs, the website doesn't show what's new or
> updated, and it is slow to get new material online. Fred's done a
> fantastic job keeping library.gnome.org going, but we probably need
> something else (or at least major improvements).
modules online (almost) directly after the git commits. It is
configured that way for gnome-user-docs and gnome-getting-started-docs
(for help. gnome.org) and for gnome-devel-docs (developer.gnome.org).
A few months ago I posted some plans and questions to the
gnome-doc-devel-list gnome org mailing list, but probably I should
have asked people to subscribe there first :) So here they are:
Support for multiple programming languages & multiple versions:
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)
Covered libraries:
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).
Fred
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list