English [en]

GNU Webmastering Guidelines

If you're interested in volunteering as a GNU webmaster, please first complete the GNU webmaster quiz.

By the way, please edit and improve this document!

Working as a www.gnu.org webmaster

All active webmasters have access to the webmasters RT queue, which corresponds to the email address <webmasters@gnu.org>. This is the primary work queue for webmasters. Please check the queue regularly, take a ticket you can handle, handle it, and reply to the message letting the sender know what has happened, and resolve the ticket. See RT guidelines below for many details.

All active webmasters should be part of the www project on Savannah, so changes can be committed. Please join that if you haven't already. Most webmaster tasks are performed by checking out the CVS repository on your local machine, modifying them, and committing the result. Instructions on how to use CVS (you want the “Webpages repository”).

All active webmasters should be on the www-discuss mailing list. If you are not, write to <chief-webmaster@gnu.org>.

Webmasters who are planning to write a significant amount of new material for the site should provide a copyright assignment.

If you find a message to <webmasters@gnu.org> that you don't know how to handle, it's probably best to ignore the message for a while. However, if you noticed that something has been pending for more than a few days, it is good to ask the www-discuss list: “Can someone teach me how to handle messages like this?”

As a general rule, things like this are always okay to do:

Sometimes people 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 nonfree software (see our linking policies). 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 requestor!), and ask someone else to take it from there.

We do not have links to websites 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 nonfree programs.

Sometimes you might be tempted to rearrange the hierarchy, change the CSS formatting, layout, tagging, or other such wide-ranging things. Before doing anything like this, please consult the www-discuss list.

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>.

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 the www-discuss mailing list so that all the webmasters can learn how to handle those issues in the future.

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 <chief-webmaster@gnu.org> as soon as your situation changes.

Using RT

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. This section documents the conventions used by the GNU webmasters.

It is useful to be copied on all RT-related mail: new tickets, other webmasters' answers to tickets, and so on. That way we can all learn from each other. If you can actively help with handling RT tickets, please consider this. A number of people can set up your RT account for this, just mail www-discuss.

RT - quick guide

First and foremost: use your judgment, rather than blindly following procedures. If the action on a particular ticket seems questionable to you for any reason, email www-discuss or use the “Comment” link on the ticket. That said, most tickets fall into one of a few categories, so we try to enumerate the common cases here.

RT - correspondence vs. 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.

RT - 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 RMS whether a certain link on a page was permissible. You can do this by using one of the “Comment” links on the ticket page, and listing the other party (in this case, <rms@gnu.org>) in the CC field. You could also do this by sending a mail with headers like this:

    To: <rms@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 email, however.

Note that this won't work with other RT-handled addresses. So, if you add <campaigns@fsf.org> to the CC field of a comment on a ticket that already exists in webmasters, nothing will come to the campaigns queue. In those situations, create a new ticket in the queue whose attention you want to get, and use the “Refers to” or similar relationship field to connect the two tickets.

RT - ticket status

For tickets which have not had work done on them yet. RT assigns new tickets this status automatically; there is no need to explicitly set it.
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.
For tickets whose problems have been addressed. Do this when you complete the request outlined in the ticket, or determined it's inapplicable, or otherwise dealt with it. Until it is completely addressed, leave it open.
For tickets which are spam (and only spam). This status is set automatically by the “Mark as Spam” option in the web interface, which is the most convenient way to handle spam tickets.
rejected, stalled
Should not be used.

Other considerations regarding tickets' status:

RT - ticket escalation

If you'd like to handle a request but aren't sure how to go about it, or think a request is important and may have been overlooked, leave the ticket open, and email the www-discuss list.

RT - misdirected tickets

Sometimes people send mail to webmasters which is best handled elsewhere. When this happens, you can do one of two things: redirect the ticket within RT, or forward it in regular email.

If there's an RT queue which is appropriate for the ticket, move it there. The ticket's queue can be changed under the “Basics” menu item.

It's nice to notify a queue's watchers when a misdirected ticket is moved; RT doesn't provide automatic notification. You can do this by sending mail to <QUEUENAME-comment@gnu.org> with the original subject line. Just a terse message “Moved ticket 1234 to your queue” suffices.

If there isn't an appropriate RT queue, forward the mail to the appropriate party, and make a comment indicating that you did so (perhaps resolving it, if appropriate). It is usually best not to do this via the RT cc mechanism. Instead, forward the message in normal email.

Editing and creating web pages

Site structure and navigation

The site is divided up into directories by topic—there's a directory for GNU Project information and history (“About GNU” section), a directory for our licenses (“Licenses” section), and so on. Each of these directories has a main page sharing the same name; for example, the /gnu directory has a page, gnu.html, which is the main page for About GNU, and so should provide access to all the material within that section. Note that the Philosophy and Education main pages are associated with several submenus; for Philosophy: /philosophy/essays-and-articles.html, /philosophy/speeches-and-interview.html, and /philosophy/third-party-ideas.html.

The main directories are accessible via navigation bars, and so are the Philosophy and Education submenus, but (for the time being) some other important directories are only accessible via links—e.g., /proprietary can only be reached from the Philosophy main page, and from several articles. Every page in these directories should therefore link back to their main page to allow people to get more information about the topic at hand.

Links should include a full path, if possible. For example, within a specific article in the /proprietary directory, link to /proprietary/proprietary.html, rather than just proprietary.html. This eases maintenance of the site as things get moved around.

Page templating

All new pages in the main part of gnu.org should use a boilerplate that includes additional files by means of Apache SSIs. Please don't start out with an existing page to create a new one; use the original source of the boilerplate instead, and follow the instructions in it.

Page styling

Generic styling for desktops and smartphones is provided by two CSS: /reset.css (from the YUI library, version 2), which normalizes the default rendering of all HTML elements by the various browsers, and /layout.css, which contains gnu.org-specific formatting.

If some special styling is needed for a specific page, it should be added to the page itself in a <style> element, between the SSI directives that include header.html and banner.html. If the style applies to a single element, it should normally be added as an attribute.

Note about grids:  Very few pages currently use them. In the event you'd like to create one that does, good starting points may be found in YUI version 3, and Pure Grids. The components provided by these libraries are licensed under the modified (3-clause) BSD license.

Mobile devices with very limited resources use /mini.css. This stylesheet is just the YUI (version 2) reset and base stylesheets, as these devices typically have minimal need for various fonts and no need for fancy layouts.

Printers use /print.css. Note that the header, navigation bars and footer (except copyright and license) are unprintable.

Historical pages (unmaintained translations for the most part) refer to /gnu.css, which also loads the mobile CSS, as these pages are usually very basic, plain pages with little or no formatting.

Some software manuals use a dedicated CSS, /style.css.


English pages should follow the standard American spelling, hyphenation and punctuation conventions. However, these conventions are not always very specific, especially as regards hyphenation and quotes. For the sake of consistency, gnu.org adds its own rules:

Adding new articles

Occasionally, RMS will mail an article, usually in plain text, to webmasters and ask that they put it on the site. The plain text needs to be converted to XHTML and put into our standard boilerplate. There are some things which you should look out for when doing the conversion:

Writing and reviewing items for /proprietary

If you plan to write or review an item for a page in /proprietary, please refer to our submission guidelines.

Making a new page visible

Web pages for official GNU software

GNU software maintainers usually gain write access to their web repository by registering their project with Savannah. (In the past, they provided webmasters with pages to install on the site, but that is no longer the best procedure.)

You do have the technical permission to check out any GNU (or non-GNU) web repository from Savannah and commit changes. However, package maintainers are responsible for their own pages, and thus you should not modify a page unless its maintainer asks you to or confirms a particular change. The only exception is for small changes that don't affect meaning, such as fixing (X)HTML validation errors, updating the page to the latest boilerplate, replacing a wrong bug-reporting address in the footer, etc. In any event, you should inform the maintainer of the change.


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 newsfeed 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 nonfree 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 website 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.”

If the page requires nonfree, nontrivial JavaScript and has serious failures with JavaScript disabled, the link shouldn't be made. Similarly, if the page has embedded Flash that plays an important role, so that a person would be missing something important if the videos do not play, the link should not be made.

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 used to provide a good example of a tactful way to do it:

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 contents of other websites, 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 contents 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 nonfree 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.

Links to free GNU/Linux distributions

Suggestions for links to GNU/Linux distributions should be handled like this:

  1. The requestors should be the primary developers of the distro, not just users. If they are users, thank them and ask them to contact the developers in case they want to be listed.
  2. Briefly check that the distro is a feasible candidate: they should have a clear policy of only including free software, and it should be reasonably apparent how to get the sources and what packages are included. If these things are not present, talk to the requestor about it (politely).
  3. If there are no glaring problems, ask the requestors to request an endorsement from the dedicated mailing list <gnu-linux-libre@nongnu.org>. They should include a description of their new distro, a link to their home page, and any other useful info. Our ticket should then be resolved.
  4. FYI: the gnu-linux-libre list will take over from there. In essence, they will review it in detail for meeting our criteria, and if all seems good, pass it on to the FSF licensing person for final approval.

In any event, webmasters should never simply add new distros that are said to be free to our list. FSF licensing and RMS must explicitly approve any additions.

Links to GNU & Free Software User Groups

Requests for links to GNU or Free Software Users Groups can be referred to the LibrePlanet website. Our ticket can then be resolved.

Please check the broken link reports regularly and handle them. 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 or www-discuss 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—please notify them of the problem and what you did to fix it.

We'll sometimes be asked to add links to a page. Most often, the request will come from RMS and you will simply add the link. Otherwise, there are two possibilities:


GNU mirrors

When we get a request to add, change, or remove a mirror of ftp.gnu.org, first ensure the mirror meets our criteria, as described on advice for mirrors; that page explains what we ask mirror volunteers to provide. If in any doubt, comment on the same ticket to ask other webmasters' opinion, or check with the webmasters mailing list and/or <gnu-advisory@gnu.org> before taking any action.

After confirming the mirror meets our criteria for listing, do this:

  1. Edit the file /prep/FTP (in CVS); it's plain text, not HTML.
  2. Run make in the /prep subdirectory.
  3. cvs commit both files FTP and ftp.html. In the commit log message, include the name of the mirror and its location, and the RT number if there is one.
  4. Update the file /gd/gnuorg/web/FTP.contacts on Fencepost, keeping the pattern as explained at the beginning of the file.
  5. See next entry about the status of mirrors.
Checking the status of mirrors

Mirrors are useful as long as they are kept up-to-date. Outdated mirrors can even be harmful, since downloading old versions of software may involve security risks for users. Checking the status of mirrors is therefore an essential part of the process of adding/modifying mirrors.

A mirmon page tracker (maintained by Savannah) shows how up-to-date each mirror is. When a mirror has gotten more than a few days out of date, it is necessary to contact its maintainers and let them know about the problem so that they can fix it. For examples on how to do this, search the RT system for tickets with subjects containing “[Mirror Status]”.

If a mirror needs to be removed, please check to see if it is referenced on /server/mirror.html and remove that entry as well.

The address http(s?)://ftpmirror.gnu.org/PKG (also maintained by Savannah) multiplexes between the mirrors, trying to choose one that is nearby and up to date.

Mirror contact information

When we get a request relating to a mirror, please check the file /gd/gnuorg/web/FTP.contacts on Fencepost and add contact information if it's not there already, or update it, if necessary. We lack information for many older mirrors, or the data we have is not up to date.

Non-GNU mirrors

When we get a request to add, change, or remove a non-GNU Savannah mirror, email <savannah-hackers-private@gnu.org> with the information. The reason to use -private is to avoid the contact address from becoming public. If the email address of a mirror admin is not involved or there are no other privacy issues, it's better to use <savannah-hackers-public@gnu.org>.

Mirrors of www.gnu.org

We no longer recommend or list mirrors of www.gnu.org.

Other common requests

This section deals with frequent requests that may require non-obvious action, but are not addressed in other parts of the page. Requests that are extremely straightforward—for example, fixing typographical errors, or problems in HTML formatting—are not documented here.


Things to watch out for:

Requests for permission to use an image

When someone requests permission to use an image from the Art section of the site, the first thing to do is to check the page that the image is on. Most of the images have a clear license along with them. If the permissions being requested are reasonable but are incompatible with that license, move the ticket to the licensing queue. Otherwise draw their attention to the license.

If the web page where the image is located does not have a clear license and the request is a clear-cut yes or no, respond to the requestor directly and explain the decision with reference to GNU policy. For more difficult cases, move the ticket to licensing.

When considering a request, err on the side of caution. If the use of an image isn't something we'd link to, for example, then it isn't something we should give permission for. Feel free to discuss any requests on www-discuss before responding to them.

Working with webmaster-related repositories

Basic CVS commands

For further details on CVS, such as reverting to a previous version, or looking at the diff output of a particular change, see the CVS documentation.


A description of scripts and software used on www.gnu.org is available. Please read it before writing any scripts, and also update it as needed.

Since CVS is not able to handle symbolic links directly, a separate mechanism has been implemented to allow webmasters to maintain symbolic links, as follows. (Actual symbolic links are no longer created on www.gnu.org; mod_rewrite rules are used instead. But we'll keep this discussion talking about symlinks since it is easier to understand that way.)

Being a symlink means that relative links from the linked page may break when the symlink jumps to a different directory.

Special files, named .symlinks, when committed to the CVS tree, are interpreted as specifications to build symbolic links. 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.

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

Here is an example of a .symlinks file:

# Make a link named l.html to a target t.html.
# Strictly equivalent to ln -s t.html l.html:
t.html l.html

On each line the first file name must be a relative path name to an existing file. The second file name may not contain any slash; it is the name of the symbolic link to be created in the present directory. For instance, if a page named DIR.html exists in the /DIR directory, and index.html does not exist, /DIR/.symlinks should contain a line like this:

DIR.html index.html

The ln -s analogy accounts for only part of the story. The current method actually takes advantage of the flexibility of URL rewriting. Thus a single HTML entry in the .symlinks file defines links to all possible translations that follow our naming conventions. This makes it impossible to use symlinks to redirect to and from HTML files whose names look like translations, that is, page.LL.html or page.LL-CC.html, where LL and CC are two-letter codes. When you need such redirections, use the htaccess mechanism.

These days, the .symlinks handling happens on www.gnu.org via a cron job that runs twice an hour. Webmasters do not have access to it.

.htaccess and redirections

To browsers, the symbolic links in the previous section are indistinguishable from the actual file. You may want an actual redirection in some cases. You can do this either in the top-level control file .htaccess, or by using something like this as the file to be redirected:

<meta http-equiv="refresh" content="0; url=http://www.gnu.org/target">

System administrators

The system administrators for GNU change from time to time. Please email the sysadmin list <sysadmin@gnu.org> rather than an individual, unless you have a specific reason to do so.

More README pages


 [FSF logo] “The Free Software Foundation (FSF) is a nonprofit with a worldwide mission to promote computer user freedom. We defend the rights of all software users.”

The Free Software Foundation is the principal organizational sponsor of the GNU Operating System. Support GNU and the FSF by buying manuals and gear, joining the FSF as an associate member, or making a donation.