Webmastering Guidelines

Information on How to be a Webmaster at www.gnu.org

All webmasters should normally have RT access to <webmasters@gnu.org>. When you take care of something sent to this list, please steal the ticket and reply to the message and let the sender know that whatever he or she asked for has been done. Please see the RT guidelines below.

(Note that <webmasters@www.gnu.org> forwards to <webmasters@gnu.org>.)

There are several guides for webmasters, one of the most important ones is the FSF HTML Style Sheet Guidelines.

If you find a message to webmasters@gnu.org that you don't know how to handle, it's probably best that you ignore the message unless you are the assigned owner. However, if you noticed that something has been pending for a long time, It might be useful to ask the www-discuss list: "Can someone teach me how to handle messages like this?"

As a new webmaster for GNU, there is not a whole lot you can do until you see how we want things done. But as a general rule, things like this are always okay to do:

Fix typos, mis-spellings, broken links, and the like
Add Table of Contents to pages
Requests from Richard Stallman <rms@gnu.org>, Peter Brown<peterb@fsf.org>, John Sullivan<johns@gnu.org>, Jonas Oberg <jonas@gnu.org> or anyone else at the FSF Distribution Office
Requests from one of the maintainers of a software package to change something on web pages about that software package, if it does not seem to conflict with any other webmastering policies.
Take on one of the jobs we need done for this web server. (Please inform the www-discuss list or chief webmaster if you take a task.

Sometimes people will send us pages about software that they want us to install. Before doing so, you should make sure that the page doesn't make any references to non-free software and is consistent with our HTML style sheet. If you find discrepancies, please politely point the maintainer to our policies and ask them to make the changes. When making such a request, do so in private email, not on the webmasters list.

People will often send mails asking us to make links to different software packages. Before making such links, it's important to check the page that the link points to and make sure that it does not make any references to non-free software. When in doubt, it is best to post a summary of what you found on the page back to the webmasters list (but not to the requester!), and ask someone else to take it from there.

We do not have links to web sites of the well-known GNU/Linux system distributions, or to the well-known BSD system distributions, because all those sites explicitly describe, and facilitate access to, various non-free programs.

Sometimes you might be tempted to rearrange pages in some drastic way to make certain things stand out more or to format the layout in some other way. Before doing so you should consult the www-discuss list, or the chief webmaster. It's often the case that web pages are constructed one way for a special reason.

All the www.gnu.org web site is managed with CVS. As a webmaster you should first register on Savannah. Then find out which group of people is maintaining the part of www.gnu.org web site you plan to edit using the www.gnu.org to Savannah projects map. Get in touch with one of the project maintainer to get write access to this directory.

If you plan to modify a lot of files everywhere in www.gnu.org on a regular basis, you should join the www project in order to edit the whole tree.

If you update or create any pages under /fun, please read the README file under /fun, before you do so.

Since the <webmasters@gnu.org> address is advertised quite a lot on our web pages it happens quite often that we receive spam to that address. Please mark these tickets as spam and dead.

Handling Press Releases

Occasionally, the webmasters are asked to handle press releases. These are in the /press directory. You should always make both a text and HTML version, and follow the format used for other press releases. (Some do have PDF and Postscript, but webmasters need not worry about that at the moment).

Currently, it is often johns who handles the text version of a press release. He will normally commit the ASCII version, and then tell webmasters to do the "rest" or "DTRT" (do the right thing) with it.

(Although sometimes the file will be emailed to webmasters instead.) You will also be given a date and time when the press release should be up.

For the time being, always check with johns before posting any press releases sent in by other parties, and note that johns will always GPG-sign his messages about press releases.

To handle one of these requests, here is what you should do:

Make an HTML version of the ASCII file, following the format used for other press releases. Be sure to change the META tags for Keywords and Description to reflect the new press release. Also, make any URLs in the press release into actual links.
Make an entry at the top of the list on /press/press.html for the press release.
Add an entry for it on /server/whatsnew.html by updating the /server/whatsnew.txt file (see Adding news).
Make the whatsnew entry a GNUs Flash (add an asterisk to the entry) unless the request to post the release specifically says not to put a note there.
A release date and time "window" will be included in the request to post it. The cvs commit should only be done in that window. If you won't be able to do it then, use the makepatch command (it's in the makepatch package of Debian) to send a patch back to johns, and put URGENT in the subject line.
The final step is submitting it as a story to as many news sites as possible (linuxtoday.com, slashdot.org, and newsforge.com should definitely be done). This can be done later in the same day as when the release goes up, but should also be done the same day.

Webmaster Organization

The following organizational rules are not rigid; they are designed to serve us and assign responsibility so that things don't fall through the cracks. Thus, the policies and escalation procedures need not be followed to the letter, but if you aren't sure what to do, it's best to follow these policies.

The GNU Webmaster Group is led by the Chief Webmaster <chief-webmaster@gnu.org>. You can always find out the identity of the Chief Webmaster by looking at the aliases file on the GNU mail server.

The Chief Webmaster is responsible for making sure that every message sent to webmasters <webmasters@gnu.org> gets handled eventually. The Chief Webmaster isn't responsible for handling every message; just making sure that someone handles them in a timely manner. The Chief Webmaster is also responsible for training new webmasters, and doing her best to correct mishandled webmaster email, when necessary.

If it isn't clear to the webmasters how to handle a particular issue, the message should be sent to <webmaster-escalate@gnu.org>. Replies from <webmaster-escalate@gnu.org> are typically sent back to the whole <webmasters@gnu.org> list (or www-discuss), so that all the webmasters can learn how to handle those issues in the future. It's also useful to cc the whole webmasters list on message to <webmaster-escalate@gnu.org>, so the other webmasters know the message has been escalated and that they should wait for a response.

Mail to <webmaster-escalate@gnu.org> is usually answered in a week or so, at worst. If anyone notices a message sent there has been pending for longer, please do send a message to <webmaster-escalate@gnu.org> checking on the status.

Leaving Webmasters

We realize that people's lives change, and we know that you may not want to be an FSF/GNU webmaster for the rest of your life. We ask that you let us know when you want to move on: please don't simply disappear.

When you sign up to be a webmaster, you commit to a certain number of hours a week of volunteer work. If you need to drop below that level for more than a few weeks, or want to stop being a webmaster entirely, please inform <webmaster-escalate@gnu.org> and <chief-webmaster@gnu.org> as soon as your situation changes.

Using RT

RT Conventions

Mail sent to webmasters is stored in a ticket management system called RT. This system keeps all correspondence about a given issue together, makes sure that no requests are lost, and so on. It works most effectively if people working with each other use roughly the same conventions, and this sections looks to document the conventions used by the GNU webmasters.

Correspondence and Comments

You can attach two kinds of information to a ticket: correspondence and comments.

Correspondence will be sent to the person who sent the initial report. Add correspondence when you want to get more information about the report, give the requestor more information about the work being done, let them know it's finished, and so on.

Comments are only seen by the ticket staff: the owner and people listed as AdminCCs. You can use comments to make internal notes about ticket work. For instance, if you do some work on converting an essay of RMS's to HTML, but didn't get a chance to finish yet, you could add a comment saying that you're partially done, so other webmasters know not to work on it (make sure to leave the ticket marked "open"). You should add something as a comment whenever the original requestor doesn't need to see it. Try to make as much correspondence as you can into comments, however.

Unfortunately, the methods for adding either type of correspondence are very similar, so it's easy to get them confused. Be careful.

To add correspondence, use one of the "reply" links on the ticket page, or send mail to <webmasters@gnu.org> with

   [gnu.org #1234]

in the subject line, where 1234 is the ticket number.

To add comments, use one of the "comment" links on the ticket page, or send mail to <webmasters-comment@gnu.org> with

   [gnu.org #1234]

in the subject line, where 1234 is the ticket number.

There is no way to make other modifications except through the web interface. However, there are a couple of macro scripts hanging around for modifying email received in Emacs, or in mbox format. Please check with www-discuss for these.

Coordination With Others

You will often need to ask other people for more information about how to handle a ticket. If we don't mind showing them a few internals about how we do things -- in other words, if they're friends of the GNU project -- the best way to do this is to mail them, and make that mail a comment to the ticket as well.

So, say for example that you wanted to ask the chief webmaster whether a certain link on a page was permissible. You can do this by using one of the "comments" links on the ticket page, and listing the other party (in this case, <chief-webmaster@gnu.org>) as a CC:. You could also do this by sending a mail with headers like this:

    To: <chief-webmaster@gnu.org>, <webmasters-comment@gnu.org>
    Subject: [gnu.org #1234] Question about link policy

1234 should be the appropriate ticket number.

The former method is more foolproof: RT will change the outgoing mail so that the only address the other party sees is RT's, and any reply will be guaranteed to go into the ticket (also as comments). The latter is fine if you're primarily doing work by e-mail, however.

Ticket Statuses

There are five ticket statuses: new, open, stalled, resolved, and dead. Each has its own purpose.

new is for tickets which have not had work done on them yet. There usually isn't a need to set a ticket to this status. (If a ticket marked new is over a week old, feel free to "steal" it from its owner.)

open is for tickets which are being worked on. RT will automatically give a ticket this status when comments or correspondence are added; you usually won't need to change a ticket to be open manually.

dead is for tickets which are spam or otherwise bogus. If you use Emacs, or an mbox mailer, there are scripts which makes it easy to mass-file spam tickets as dead, so if you see tickets that are just spam. Make sure to mark them as spam as well. You can also use the web interface's search facility to do this (under "update all").

stalled is for valid tickets which indicate a problem, but which require more information from outside parties (like the original requestor) before we can address them. Give a ticket this status whenever we need information from someone not in the GNU project to fix it. For example, a software maintainer may send mail asking us to put up a new version of a page. If there was a problem with it, you could mail them detailing the problem, asking what the fix should be, and mark the ticket stalled.

resolved is for tickets whose problems have been addressed. Do this when you complete the request outlined in the ticket.

Beyond that, there are a few other considerations when changing tickets' status:

Feel free to mark tickets as stalled or resolved liberally. If new correspondence comes in about them, they will automatically be re-marked as open. If there are no more apparent problems, it's usually better to get it out of the way right away, rather than wait on the off-chcance that more correspondence about it might come in.
If a ticket is particularly urgent, it may be better to leave its status open, rather than marking it as stalled, if we need more information. That way, we will keep seeing it, and remember to push for the necessary information, rather than forgetting about it. (Stalled tickets can be searched, but by default are hidden except on you entry page.)

Escalation

If you'd like to handle a request, but aren't sure how to go about it, leave the ticket open, and set the "discuss-at-meeting" keyword to "yes." You can do this by clicking the "Keyword Selections" link on a ticket's page, highlighting the "yes" option under "discuss-at-meeting," and then saving the changes. You can also email webmaster-escalate, or the www-discuss list.

Misdirected Tickets

Sometimes people send mail to webmasters which should've gone elsewhere. When this happens, you can do one of two things.

If there's an RT queue which is appropriate for the ticket, move it there. The ticket's queue can be changed under a ticket's "The Basics" dialog.

It's nice to notify a queue's watchers when a ticket is moved; RT doesn't provide automatic notification. You can determine who watches a queue by going to "Configuration," choosing "Queues," selecting the desired queue, and choosing "Watchers." Just a brief mail to them saying "I moved ticket 1234 to your queue" will suffice.
If there isn't an appropriate RT queue, forward the mail to the appropriate party, and make a comment indicating that you did so. (You can send the forward itself as a comment to the ticket if you like. See the instructions in "Coordination with others," above, for more information about doing this.)

Webmasters gets a fair amount mail about a number of issues which are only tangentially related to the web site; here's where to redirect all that.

Requests related to the ftp mirror listings should go to the gnu queue
Bug reports and similar items about the Free Software Directory should go to the directory queue (see the the form link from /directory)
Mail about accounts should go to the accounts queue
Tickets about system problems (e.g. a web page is not replicating, or a symlinks file is creating the symbolic link), can be put into the sysadmin queue. If the ticket is about Savannah, send the original mail to savannah-hackers@gnu.org.
Requests to remove messages from mailing list archives (accessible via http://mail.gnu.org should be forwarded to <mailman@mail.gnu.org> - at the time of writing such requests will end up in the sysadmin queue.
Anything else not related to webmastering -- including questions about FSF opinions, requests for support, and the like -- can be moved to the info or gnu queue.

Other Webmastering Procedures and Policies to Consider

There are certain procedures and policies which take hold over the entire site. Almost all requests will have to be considered in light of these standards. Bear these in mind when working on the page.

Inter-site Structure and Navigation

The site is divided up into directories by topic -- there's a directory for GNU project information and history, a directory for our licenses, and so on. Each of these directories has a page sharing the same name; for example, the /philosophy directory has a page, philosophy.html. This page is the main page for this section of the site, and so should provide access to all the material within that directory.

In turn, every other page in the directory should link back to this main page, to allow people to get more information about a given topic.

Links should include a full path, if possible. For example, within a specific article in the philosophy section, link to /philosophy/philosophy.html, rather than just philosophy.html. This eases maintenance of the site as things get moved around. Omitting the host also allows our site to work well on mirrors.

Some pages are dynamic and should include a link with the full hostname; the most notable among these is the Free Software Directory. So, you would link to that with the URL <http://www.gnu.org/directory>. This way, mirrors don't have to have all the bells and whistles to mirror the majority of the site.

Announcements

When significant new content is added, notices should be put up to make people aware of it. Simply add a new entry to /server/whatsnew.html by adding an entry to the /server/whatsnew.txt file (see Adding news)

If you're adding a new page, add a link to the directory's main page. For example, if you've created a new page with more GNU history, /gnu/more-history.html, add a link to it from /gnu/gnu.html. If the page is particularly useful, consider adding a link on /server/sitemap.html as well.

If the page discusses an important issue, consider adding a notice about it to the front page, /home.html.

Adding news

News items are used in 4 ways on the GNU website:

to make the /server/whatsnew.html page
to make the GNU What's New RSS feed
sometimes to make GNUs Flashes on the homepage
all of the above are available in many languages

Changes to news must be made by adding a new entry to the /server/whatsnew.txt file.

The format of the whatsnew.txt file is this:

an optional asterisk, if present this means the item should be a GNUs Flash
the date of the news item
a carriage return
the HTML text of the news item, possibly spanning many lines
a blank line to end the entry

Here is an example showing 4 entrys from the whatsnew.txt file:

* 19 November 2004
<a href="/jobs/fsf-sysadmin.html">FSF is currently seeking a full-time Senior
GNU/Linux Systems Administrator and Programmer</a>

14 September 2004
Added Richard Stallman's new article: 
<a href="/philosophy/fighting-software-patents.html">Fighting Software
 Patents - Singly and Together</a>, with a link from the 
<a href="/philosophy/philosophy.html#LicensingFreeSoftware">Philosophy</a> page.

14 September 2004
Added a new SVG logo to the <a href="/graphics/gnusvgart.html">GNU SVG Art page</a>.

21 August 2004
Added a <a href="/home.ru.html">Russian translation</a> of the main page.

Once the /server/whatsnew.txt file has been updated there is no need to do anything. The news files are remade every hour by a cronjob running on nferrier@fencepost.gnu.org.

The cronjob rebuilds the news according to the Makefile specified in /rss/Makefile. The targets gnunews and gnunews.i18n are used.

The cronjob ensures that the internationalized versions are maintained correctly.

Symbolic Links

Since CVS is not able to handle symbolic links, a simple mechanism has been implemented on the machine hosting the www.gnu.org to allow webmasters to control the symbolic link from the CVS tree.

Special files, named .symlinks, can be committed to the CVS tree that are interpreted as specficiations to build symbolic links. The "symlinks" script can be run immediately after a "cvs update" to fix the symbolic links according to the specifications included in the .symlinks files.

The current directory is searched recursively for .symlinks files. Symbolic links that exist in directory where there is no .symlinks files will be ignored. Only directories containing a .symlinks file are handled.

Each symbolic link specification from the .symlinks file is honored, i.e. the symbolic link is created if it does not exist yet. If a symbolic link is found in the directory and is not listed in the .symlinks file, it is removed.

As a special case, if a page with the directory's name exists, and index.html does not exist, a link will be made from index.html to the main page.

Symbolic links that point outside the web site document root are ignored.

The .symlinks files obey the "ln -s" format, as described below:

Each line starting with a sharp sign ("#") is treated as a comment and ignored.

Lines that do not contain two strings separated by white space are silently ignored.

Here is an example of a .symlinks file:

        #
	# Link foo.html to bar.html.
	# Stricly equivalent to ln -s foo.html bar.html
	#
	foo.html bar.html

On each line the first file name must be a relative path name to an existing file. The file designated by this path must not be outside the document root. The second file name may not contain any slash, it is the name of the symbolic link to be created.

The actual command used to implement this feature is symlinks(1) and the sources can be found in gnudist.gnu.org:/usr/local/src/symlinks-1.1.tar.gz.

Linking Policies

One of the most complex aspects of webmastering is following the linking guidelines; however, it's also a very crucial aspect of the job.

We strive to ensure that all pages we promote -- all pages which are given links on our site -- are friendly to the free software movement. Some pages will obviously not meet such standards; if the site flames the Free Software Foundation, or has no apparent relation to free software and surrounding issues, the link shouldn't be made. Beyond that, however, there are criteria used in determining whether or not it is appropriate to provide a link to a page from ours. They are listed below, in order of descending general importance.

What's the context of the link?

The link's purpose on our site will play a role in determining how strongly it should be judged against the other criteria. Pages hosting GNU projects will be held to the highest standards. Pages about other free software and given high promotion -- for example, included in a GNUs Flash on the main page -- are a close second. Links on the philosophy page may be given more leeway in talking about proprietary software; GNU/Linux user group pages should call the system GNU/Linux almost always but are hardly checked on other criteria. Always keep this in mind when deciding how to weigh each aspect of these policies.

Does the page promote proprietary software?

The big point made by the free software movement is that proprietary software presents an ethical dilemma: you cannot agree to such non-free terms and treat those around you as you would like to be treated. When proprietary software is promoted, people get the impression that it is okay to use it, while we are trying to convince them otherwise. As such, we avoid offering such free advertising, either directly on our site or indirectly through links.

What's tricky about this criteria is the "promotion" point: there's a difference between mentioning proprietary software and making a sales pitch for it. Indeed, the GNU project web site mentions proprietary software throughout, but never gives people the impression that its use does not present ethical problems.

There are two things to keep in mind when determining whether a reference to proprietary software promotes it, or simply mentions it. First, how much information does it offer about the software? Second, how much information is the reader likely to actually gain from this page?

Different pages provide different amounts of information about proprietary software; the more it provides, the more of a problem it poses for us. For example, some pages may link to the primary site for a proprietary software program. Others may describe its functionality in detail. Even the product name given matters; there's a difference between "Windows" and "Microsoft Windows XP Home Edition."

The subject of the reference will also play a role in determining how problematic a reference is. If the software is already very popular, it's unlikely that a basic mention of it will be news to the reader. Some examples of proprietary software which are common enough to be considered "well-known" are major operating systems (Windows, Mac OS, Sun OS, HP-UX) and primary common applications such as Office, Internet Explorer, Photoshop, Acrobat Reader, and Flash.

GNU software project pages feel the full force of this policy. Proprietary software should only be mentioned when the software provides support for it, or to compare it against the features of well-known proprietary software. For example, the following text -- and not much else -- would be acceptable:

w3 is a web browser for GNU Emacs, similar to Internet Explorer. It can run on all platforms GNU Emacs runs on, including GNU/Linux, proprietary Unix systems, and Windows.

Links which appear in other areas, such as the testimonials or philosophy pages, as well as links to user groups may discuss such software in greater detail, but links and other methods of encouragement to "learn more" should still be avoided.

How does the page compare free software to open source?

Almost all pages which have links on our site should, at the very least, treat free software and open source equally. Failure to do so -- whether it be by omitting free software or by implying that open source is superior -- is usually unacceptable. GNU software project pages should have little mention of open source. The GNOME page provides a good example of a way to do it tactfully:-

GNOME is part of the GNU project, and is free software (sometimes referred to as open source software).

Any exceptions to this rule should be apparent from the context. For instance, user groups pages may talk in greater detail about open source; we state on the user groups page, "As with our links page, the FSF is not responsible for the content of other web sites, or how up-to-date their information is."

How does the page treat the GNU project?

Pages which we link to should treat the GNU project well. The primary thing to look out for in this regard is whether the page calls the system GNU/Linux or just "Linux." GNU software project and user group pages should almost never, if ever, fail to do this. Again, exceptions for other pages should be apparent from context.

That said, certain parts of a page should not be considered against these criteria. For example, suppose we were to make a link to a page on a free software news site. Any advertisements or reader comments attached to the article would not be considered when determining whether it met or linking guidelines, since they're understood to be the opinion of their individual authors. Similarly, on user group pages, the content of forums and Wiki pages should not hold weight in these regards.

Finally, some sites are understood to always have exception with most of these guidelines. These sites are usually about issues which are important, but somewhat peripheral, to the free software movement. Several times we have linked to the Electronic Frontier Foundation's site, even though they encourage the use of Flash and talked exclusively about open source software. It's generally understood that since these pages are not primarily about free software, the policies do not hold full force for them.

As a final explanation ( coming from RMS ): Even for making links from www.gnu.org, we do not *require* that people call the system GNU/Linux or use the term "free software" rather than "open source". We do, however, require that they not promote any non-free software.

If all this seems complicated, that's because, unfortunately, it is. Don't worry; a knack for it comes with time and experience. You may mis-evaluate a few pages as you're learning to get a feel for what's acceptable and what isn't; please don't hesitate to get a second opinion from a more experienced webmaster, or someone in charge like the chief webmaster or RMS. New exceptions will always come up; keep an open mind to that possibility and be ready to handle them properly.

Handling Common Requests

There are a number of requests which recur frequently. This section documents guidelines for handling these types of requests.

Those requests which are extremely straightforward -- for example, fixing typographical errors, or problems in HTML formatting -- are not documented here. Only requests which may require non-obvious action are listed.

Fixing Dead Links

If a link has gone bad because a page has moved, try to find its replacement. If you are successful, re-check the page to ensure that it meets our linking criteria, and if so, add it. If you do not find a replacement, remove the link -- if it's central to the page, you may need to make a note explaining that the resource is no longer available. If the page no longer meets our linking criteria, you'll have to make a judgment call, and weigh the value of the link against its problems'; you may want to mail the person who wrote the page with the link to get a second opinion.

If you do remove a link from a page that we don't maintain -- for instance, the page for a piece of software which is kept up-to-date by the maintainer -- it's nice to notify them of the problem and what you did to fix it.

Adding Links

We'll sometimes be asked to add links to the page; most often, this will come from RMS, asking us to add a page to the Other People's Views section of the philosophy page or as part of a GNUs Flash to the front page.

If the person requesting the link is a friend of the GNU project, check the page against our linking criteria, and if it passes, add the link as requested. If it does not meet our linking criteria, send mail back to the requestor, saying so and outlining in detail what the problem(s) with it are.

If the suggestion is coming from someone outside the GNU project, check the page against our linking criteria, and if it passes, forward the suggestion to the appropriate party. If the link would be part of the main GNU site, that would be someone who can speak for the GNU project, such as RMS. If the link would be part of a software page, direct it to the person responsible for the program's site -- if no other contact is given, that would be the maintainers themselves. If you're told that adding the link is acceptable, do so. If the link fails to meet the linking criteria, thank the original requestor for their suggestion and explain that we don't feel the link is most appropriate for our site.

Adding New Articles

Occassionaly, RMS will mail an article, usually in plaintext, to webmasters and ask that they put it on the site. The text needs to be converted to the HTML and put into our standard boilerplate; you can use /boilerplate.html to provide a template for the header and footer, or base your page from another article. There are some things which you should look out for when doing the conversion:

Remember to make sure translation links actually use the page's given name, rather than a boilerplate one
Make sure the article's title is put in both locations, in the <title> tag and in the <h3> text at the top of the page
Put the author of the article in the page's header as well
Provide a link back to the directory's main page

There are also some things you should remember when uploading the page:

Add a link on the directory's main page to the article
Add an entry about the addition to /server/whatsnew.html by adding an entry to the /server/whatsnew.txt file (see Adding news)

Uploading Pages for a Software Project

Software maintainers will provide us with pages about their project to upload to the site. This is the common way pages were maintained earlier in the site's history. Now, maintainers can gain CVS write access to a /software subdirectory by registering their project with Savannah.

If the page is new, or updated infrequently, ask the developer if they plan to register their project on Savannah (http://savannah.gnu.org/), since that will give them direct control over their site. Point out that, if they currently host development elsewhere, they can register as a "web-only" project, which will give them nothing more than write access to the web page.

If they indicate that they will register with Savannah, you can close the ticket; if you would like to upload the content in the interim, you may do that. If they indicate that they do not want to register with Savannah, you may want to escalate the ticket to the chief webmaster for further action. We would like to see all software maintainers using Savannah, and so are reluctant to allow for new special cases.

If the page is old and frequently updated this way, check the content against our linking policies and style guidelines, and upload it if it passes. If it does not, inform the maintainer of what problems we see with it, and ask them if they would be willing to make changes to amend them. Note that we're pretty lenient on HTML style guidelines with software maintainers, so unless they're using JavaScript, excessive frames, browser-specific tags, or something similarly egregious, don't worry about those too much.

Adding Translations

Occassionally, someone will send us a translation of a single page. You can put these in place; all you need to do is upload it and add a link from the main (English) page to it. Be sure to write them back thanking them for the page, and encourage them to get in touch with a translation team if they'd like to help more. Refer them to http://www.gnu.org/server/standards/README.translations.html; a list of translation teams is available there as well.

Deleting Translations

Here and there you might find a translated page which is actually a copy of the original page (i.e., not a translation at all), or translations which seem like they should not exist in their current form for whatever reason. In such a case the best thing to do is to ask the relevant translation team for the reasons they put the page there (please, make sure to CC web-translators@gnu.org on such cases). They might have reasons you are not aware of. In case you do not get within two weeks a satisfactory reason for the page to be left alone, you can handle it as you see fit.

Adding an Event to the Events Page

Sometimes we will be asked to add an event to the events page. If the request is not urgent, redirect such requests to the person who would normally manage the given event. If RMS is to appear at the event, that person is rms-assist@gnu.org; otherwise, it's the speaker themselves.

If the request is urgent, and the request is coming from FSF staff, you can add the event to /events/events.input-html, above the AUTO section. However, if you do so, please take responsibility for the event and remove it when it has passed.

Checking out the Repository

With the shell variable CVS_RSH=ssh, create a directory for your gnu src, and within it type

cvs -d <username>@savannah.gnu.org:/webcvs/www co .

Use "cvs add foofile" to add a file or directory. Use "cvs import" to import an entirely new module (don't use it to just add a directory). Use "cvs update -P" before you commit a file (or "cvs update <foofile>"), and "cvs commit foofile" to actually commit it. Use "cvs log foofile" to look up its log history. For further details on cvs, such as reverting to a previous version, or see diff output of particular changes, see the cvs man file.

Many of the software maintainers do not have their projects under the www/software directory. If a maintainer needs your help with one of their web pages, you can get to it like this:

cvs -d <username>@savannah.gnu.org:/webcvs/fooproject co fooproject

System Administrators

Our system administrators are baughj (Justin Baugh), jag (Joshua Ginsberg), and ward (Ward Vandewege). Please make sure to email the sysadmin list (sysadmin@gnu.org), not them directly, unless you have a specific reason to do so. Since they are extremely busy, they will often ignore email sent directly to them.

Mail Quarantine

About once a week a ticket will be automatically sent to the webmaster's queue to remind them to clean out the mail quarantine. The quarantine is a collection of mails to webmasters@gnu.org that are caught by our spam filter, and should be checked occasionally for false positives.

To do so, use your RT username and password to log in to the quarantine manager (available at http://rt.gnu.org/qmanager/webmasters). The background of the page is color coded from blue (least likely to be spam) to red (most likely to be spam). To read an email, click on it's subject. If you find a false positive then click the "Send to RT" button at the top of the page. When you are satisfied that all of the emails on the index page are spam, you can delete them using the "Delete All Message On This Page" button at the bottom of the index page.

When done you should steal the ticket, comment that you took care of it, and mark it as resolved.

GNU's Not Unix! - Free Software, Free Society

Site Navigation