Date: Sun, 25 Jun 2000 20:00:29 +0000 From: Nik Clayton <nik@freebsd.org> To: doc@freebsd.org Cc: committers@freebsd.org, dgl@bsdi.com, jim@cdrom.com, papowell@astart.com, wpaul@freebsd.org, ceren@magnesium.net, ryan@ryan.net, murray@bsdi.com Subject: The website Message-ID: <20000625200029.I470@kilt.nothing-going-on.org>
next in thread | raw e-mail | index | archive | help
[ Sent to -committers, so they've got fair warning of a couple of my plans ]
The website needs a lot of work. It's not that the content is bad by any
means, but the organisation and layout makes it difficult to find things,
and you have to dig through several levels before you find anything that's
changed.
Some rough notes based on our Usenix discussions.
* We're constrained in what we can do on the website because of the
requirement to mirror it around the world. While we could co-locate it
somewhere with suitably beefy bandwidth (as other projects do) I'm not
sure this is a good idea. I like the fact that people can contribute
to the project by providing mirrors.
This means that we can't rely on anything that needs a database running
-- IMHO it raises the bar for a mirror to particpate to an unacceptably
high level. It also brings up also sorts of interesting concerns about
how we would go about mirroring information in a database, or finding a
database that supports foreign language text sufficiently well.
This also means that a huge reliance on CGI scripts is also a bad
thing. At the moment mirrors can participate by setting up a fairly
simple webserver that just has to serve static content. The few CGIs
that we do have all refer back to the main site. If we were to force
the mirrors to run the CGI scripts we put a bigger burden on them, both
in terms of the computing power required to run the scripts, and also
because they will probably (quite reasonably) want to audit them before
they run them on their own systems.
This limits the amount of dynamic content we can put on the site.
However, all is not lost. We already rebuild the website twice a day.
This means that twice a day the content on our pages can change, or can
be generated at build-time. It's not quite the same as truly dynamic
content, but it's a fair compromise.
* We should be reusing the orange left hand bar across all the pages.
It's an accepted design standard on many websites, and there's no
reason to be gratuitously different from the crowd unless you're trying
to win design awards.
If you take a look at http://www.demon.net/ you'll see how their left
side navigation bar expands and contracts as you move through the site,
showing you where you are in the site, and useful places you can go
from there.
I like this. It's also not too programmatically difficult to do using
our SGML tools.
* We might want to give each mailing list its own home page. I knocked
up a rough prototype of this a while back, which you can find at
http://people.freebsd.org/~nik/lists/. It needs work (in particular,
it needs integrating in to a complete site plan, rather than the rough
proof of concept it is now) but it's (IMHO) a good way of organising a
lot of our content.
* The front page (and some related pages) have *got* to change more
frequently. At the moment you can come to the FreeBSD home page once a
day, or once a week, and to the uninitiated the project may as well be
dead.
There have been no significant content changes in months.
A redesign of the website has to fix this. Some ideas that were
discussed at Usenix include:
* Providing a place to showcase a "Project of the week" on the front
page (or "Project of the day", or whatever). This would link to one
of the FreeBSD development projects, with a brief description and a
pointer to the project's home page.
* As above, but for a "Committer of the Week". IMHO, each committer
could write up a couple of paragraphs about who they are, how they
got involved in FreeBSD, what they're working on, and so on.
If I had my way, failure to provide this after a reasonable amount of
time (6 weeks say) would be grounds to get the commit bit removed.
The individual chunks of the project don't exist in a vacuum, and
IMHO all committers should be expected to be able to do this, given
reasonable notice.
I realise that might be a bit radical for some. On the other hand,
it does provide an effective way of weeding out the dead wood that's
been discussed. . .
* On each build, generate links to BSD stories on Slashdot, DaemonNews,
BSD Today, the O'Reilly Dev Centre, and others.
Yes, it's the "P" word -- we should be a BSD Portal.
* Provide a projects statistics page. This should contain all sorts of
administrivia, something like:
Number of committers, and growth rate ("At this rate, we will have
300 committers in six months time")
Number of ports, and growth rate (according to Satoshi, we should
have a million ports in ten years time, at the current rate).
Number of mailing list subscribers, and growth rate. Number of
messages to each mailing list in the past 24 hours. Number of
messages sent through hub in total in the past 24 hours. . .
Number of commits to the tree in the past 24 hours, and 7 days.
N
--
Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95.
Telephone line, $24.95 a month. Software, free. USENET transmission,
hundreds if not thousands of dollars. Thinking before posting, priceless.
Somethings in life you can't buy. For everything else, there's MasterCard.
-- Graham Reed, in the Scary Devil Monastery
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000625200029.I470>