Date: Mon, 26 Jun 2000 23:08:24 +0100 From: Nik Clayton <nik@freebsd.org> To: Jun Kuriyama <kuriyama@FreeBSD.org> Cc: doc@FreeBSD.org, committers@FreeBSD.org Subject: Re: The website Message-ID: <20000626230824.A388@catkin.nothing-going-on.org> In-Reply-To: <7mu2eg4sz7.wl@waterblue.imgsrc.co.jp>; from kuriyama@FreeBSD.org on Mon, Jun 26, 2000 at 07:49:48PM %2B0900 References: <20000625200029.I470@kilt.nothing-going-on.org> <7mu2eg4sz7.wl@waterblue.imgsrc.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 26, 2000 at 07:49:48PM +0900, Jun Kuriyama wrote: > At 26 Jun 2000 09:33:42 GMT, > nik wrote: > > 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. > > I think so. We should reduce unneeded CGI scripts but this check > should be done carefully. I think current CGI set in www.FreeBSD.org > is quite minimal and difficult to replace with static contents. I'd > like to see a list of what part of CGI should be replaced. Yes. My point was that we shouldn't be introducing new CGI scripts wherever practical. > I don't know about the machine load of web building, but it is > difficult to build web stuff more frequently? Japanese web server > re-builds contents once per an hour, and this helps visitors to see > latest news. (like announcements, ftp/cvsup/www site trouble, seminor > informations, etc.) We could certainly go to a more frequent build -- at the moment, the site doesn't change often enough to make it worthwhile. :-( > > * 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. > > I'm not expert on web design, but this should be reviewed widely > before replacing. While I'm not an expert on web design, I did spend three years working as the webmaster for a large UK web design firm. Some of it rubs off :-) > > * 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. > > Yeah, there stuff is good candidate to be written in XML as original > source? :-) Yes. When I did the prototype XML wasn't as widespread as it was. Any implementation of the idea should be XML based. > > * 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. > > I think there ideas are difficult to continue in long term. Many > hackers don't like writing there contents. > > > 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. > > Of course, this is ideal. But should we remove someone's commit privs > who only have time to hack source code, not document? Don't see why not. If a committer can't put together three or four paragraphs about themself, what they're working on in FreeBSD, how they got involved with FreeBSD, and any interesting other bits and pieces, then, given sufficient notice. . . > > * 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. > > Hmmm, it is good idea but it can be done automatically? That's the purpose of this thread. I want to kick-start some prototype implementations. 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?20000626230824.A388>