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 <[email protected]>. 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”).

Notifications for changed pages are sent to the www-commits mailing list. This is a public mailing list, so everyone can subscribe and review the archives.

All active webmasters should be on the www-discuss mailing list. If you are not, write to <[email protected]>.

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 <[email protected]> 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?”

Requests that are OK to do:

• Fix typos, misspellings, broken links, and the like in the www repository (English pages only).
• Take on one of the tasks we need done for this web server. Cleaning up that task list would also be appreciated. Please inform the [email protected] mailing list if you take on a task.
• 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.
• Requests from the Chief GNUisance (Richard Stallman, <[email protected]>) should be followed, though webmasters who see a possible problem in one can raise that issue.
• Some FSF staff routinely send certain kinds of requests to the GNU webmasters. These should in general be followed, though webmasters who see a possible problem in one can raise that issue.
• Unusual, sensitive or problematical requests, and requests that raise policy issues, call for a discussion among the senior webmasters. They should escalate policy issues to the Chief GNUisance when necessary. For requests from FSF staff, the senior webmasters can resolve practical issues with them or escalate if necessary.

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.

Do not commit changes to files related to translations (/licenses/translation.html, /server/standards/README.translations.html, among others) without previous approval by the GNU Translation Managers <[email protected]>.

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 <[email protected]>.

The Chief Webmaster is responsible for making sure that every message sent to webmasters <[email protected]> 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 <[email protected]> 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

To see open tickets, visit rt.gnu.org and log in with your assigned RT username/password. (If you don't have one, email chief-webmaster.) There will be a link to the webmasters queue (among lots of other things) on your RT home page. Once you see the list, clicking on the subject link will open the ticket.

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.

• If the message is spam, click the “Mark as Spam” link in the top row.
• If the message is in a language you don't understand and it's not spam, or you're not sure if it's spam, click “Basics,” then change the Queue field to web-translators.
• Likewise, if the request is about listing a translation of a manual (or other document published or listed on gnu.org), change the Queue field to web-translators.
• If the message is just a thank-you to us, or something else that doesn't require action on our part, click “Resolve.”
• If the message is a simple typo or other buglet on an English page we maintain, go ahead and fix it, using “Reply” to tell the submitter what you did, and then “Resolve” it.
• If the message is a ThankGNU or a ThankCRM, see the Thank GNU procedure.
• If the message is about adding a joke or a song, see the Humor/Music procedure.
• If the message is about adding an image, see the Art Gallery procedure.
• If the message is about a mirror, see mirror procedures and information.
• If the message is about making a link on one of our pages, see the linking policies.
• If the message opened a new ticket, but is actually a follow-up to an existing ticket, use the “Links” feature of RT to combine them. This happens when the original submitter cc'd the message to other recipients, and one of the other recipients sends a reply that includes us—each such reply will (unfortunately) start a new ticket.
• If the message needs to be dealt with by another group, such as web-translators, sysadmin, licensing or audio-video, write a comment in the ticket to say you are moving it and to provide any other information relevant to the receiving queue; then move it to the corresponding queue. The ticket's queue can be changed under the “Basics” menu item. Otherwise forward it (check the specific directions for redirecting tickets).
• If the message is an application to become a GNU webmaster, and if you are a confirmed, active webmaster, then you may want to help the decision process. You can do it by commenting on the answers to the quiz, the applicant's website, or any relevant information available online. Feedback should be provided in the ticket as comments, not replies. This is all that webmasters should do with these tickets.

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

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 <[email protected]> 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 <[email protected]> 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, <[email protected]>) in the CC field. You could also do this by sending a mail with headers like this:

    To: <[email protected]>, <[email protected]>
    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 <[email protected]> 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

new

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.

open

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.

resolved

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.

deleted

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:

• Feel free to mark tickets as resolved liberally. If new correspondence comes in about them, they will automatically be re-opened. If it is just a random request for which there is nothing in particular to do, simply reply as needed and mark it resolved.
• However, if a ticket is important, it is best to keep it open, even when we need more information. That way, we will keep seeing it, and remember to push for the necessary information, rather than forgetting about it.

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 <[email protected]> which is best handled elsewhere. When this happens, you can do one of two things:

1. If there's an RT queue which is appropriate for the ticket, move it there.

• Move tickets about a new or existing translation of a gnu.org web page to the web-translators queue. Don't try to edit translated pages, even if you know the language: they are automatically generated from a different format, and maintained by different teams.
• Move bug reports and other items about the Free Software Directory to the directory queue.
• Move bug reports about fsf.org pages (broken links, typos, layout) to the resources queue.
• Move tickets that are about the actual contents of fsf.org pages to the campaigns queue.
• Move tickets that are about FSF memberships to the membership queue.
• For tickets about system problems with www.gnu.org (e.g., system down, a .symlinks file not creating the symbolic link), try to verify the problem and, if it is real, move it to the sysadmin queue.
• Move tickets about mailing lists, Fencepost and the GNU FTP server to the sysadmin queue.
• Requests to remove messages or personal info from mailing list archives (accessible via http://lists.gnu.org) should be acknowledged, and moved to the sysadmin queue.
• For tickets about the Savannah website, version control systems and non-GNU download server, email the original message to <[email protected]>. There is more info about who maintains what service in the Savannah documentation.
• Move tickets about licenses or copyright issues to the licensing queue.
• Move tickets about accounts to the accounts queue.
• For tickets about the GNU libc web pages, point the OP to http://www.gnu.org/software/libc/bugs.html. That is the best way to get the glibc maintainers' attention.
• If the ticket is about the web pages for a specific GNU software package, it is best to send it in private email to the maintainers of that package (they are recorded in the Free Software Directory, or look at the file /gd/gnuorg/maintainers.bypkg on Fencepost), and reply to the OP saying that you did so, resolving the ticket.
• Requests to add a video or audio file to the audio-video website should be forwarded to <[email protected]>.
• Anything else not related to webmastering—including questions about FSF opinions, requests for support, and the like—can be moved to the info queue.

When a misdirected ticket is moved, it's good practice to notify the watchers of both queues: the queue from which the ticket is being moved, and the one to which it is being moved (RT doesn't provide automatic notification). You can notify both queues simultaneously by writing a comment in the ticket using the RT web interface, or by sending mail to <queuename[email protected]> with the original subject line. Just a terse message “Moved ticket 1234 to your queue” suffices.

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

This section only contains information that is specifically aimed at webmasters. For general info, refer to the GNU Website Guidelines.

To create a new page in the main part of gnu.org, please use the boilerplate.  Do not start with an existing page.

Note: Filenames should only contain lowercase letters, digits, ‘.’ and ‘-’ (‘_’ is acceptable, but not recommended).

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 main page is associated with several submenus: /philosophy/essays-and-articles.html, /philosophy/speeches-and-interview.html, and /philosophy/third-party-ideas.html.

The main navigation bar only has entries for the major sections. Every page in the sections that are not listed (e.g., GNU Fun) should therefore link back to their main page to allow people to get more information about the topic at hand.

Navigation within sections has room for improvement. The Education and Malware pages already have breadcrumbs and side menus, but the other ones don't. We should at least add breadcrumbs, and possibly tags, to the Philosophy pages. This is a challenging job. If you are interested in helping with it, please step forward! :-)

Conversion of plain text to XHTML

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 a few things you should take care of while doing the conversion:

• Fix any obvious typos. If in doubt, contact the author.
• Follow the spelling and punctuation guidelines.
• Add the author's name below the <h2> header.

Writing and reviewing items for the Malware section

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

Each item usually belongs to at least 2 pages, which correspond to the type (proprietary-*.html) and origin (malware-*.html) of the malware it describes. New items should also appear in proprietary.html. To make maintenance easier, new malware items are written to a single file (/proprietary/workshop/mal.rec), and addition to the relevant pages is performed by a script (/proprietary/workshop/item-create). Any changes to an existing item are done in mal.rec, and then propagated to the relevant pages with another script: /proprietary/workshop/malgen.

The procedure for adding and modifying malware items is described in the Malware Howto (/proprietary/workshop/README.md).

Pages in the Malware section are under the Creative Commons Attribution 4.0 International License. Please keep this in mind when creating a new page.

Please announce new malware entries on planet.gnu.org. See the information about Posting on Planet GNU.

Adding a page to the Humor or Music section

1. Check whether the proposed joke or song complies with RMS' requirements. If it doesn't, thank the person who proposed it, and politely explain why it can't be published on gnu.org.
2. If it complies, get explicit permission for releasing it under a suitable free license.
3. Create a new page in the /fun/jokes/ or /music/ directory.
4. Add a link to the new page in /fun/humor.html or /music/music.html.

Making a new page visible - Posting on Planet GNU

• When adding a new page, always add a link to the directory's main page. For example, if you've created a new page in the /gnu directory, add a link to it from /gnu/gnu.html. If the page was created in /philosophy or /education, add the link to the relevant submenu (see Site structure and navigation).
• If a new page in /philosophy is especially important, RMS will probably ask webmasters to link it from the Philosophy main page, in addition to the submenu.
• Also add a link to /philosophy/latest-articles.html if what you have added is a recent article, as opposed to one that was published elsewhere long ago.
• A link to the new page will automatically be created in the site map.
• To post news in Planet GNU, log in to the www.gnu.org project on Savannah. Under News > Submit, fill in the form and submit. Notify the project administrators, except RMS, that a news item is waiting for approval. Once approved, the item will make its way to https://planet.gnu.org/

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

The official home page for GNU packages should be on www.gnu.org, specifically in /software/PROGRAMNAME. Sometimes those pages do not exist or they are obsolete. Webmasters are expected to help build or update the pages if the maintainer asks.

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

Before adding or replacing any links, please read our linking criteria.

Fixing dead links

Please check the broken link reports regularly and handle them. Note that webmasters should modify links in the English pages only.

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.

Adding links

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:

• 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 doesn't, say so in your reply to the requestor, outlining in detail what the problem(s) 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.
• If we can link to an older version of XYZ and we can't link to newer versions, we consider the versions separately. We link to the best version we CAN link to if it is better than no version. That is what we do for programs too—and have done for decades.

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 <[email protected]>. 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.

Mirrors

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 <[email protected]> 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. (Don't list ftp URLs: this protocol is being phased out.)
2. Run make in the /prep subdirectory.
3. If the answer to the question of whether the site can also be a source for other mirrors is affirmative, then add the rsync URL to those listed in mirror.html under “Mirroring the GNU FTP server” and/or “Mirroring the GNU Alpha release server,” as applicable.
4. cvs commit both files FTP and ftp.html, as well as mirror.html if applicable. In the commit log message, include the name of the mirror and its location, and the RT number if there is one.
5. Update the file /gd/gnuorg/web/FTP.contacts on Fencepost, keeping the pattern as explained at the beginning of the file.
6. 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 long ago each mirror was updated. When Mirmon reports a mirror as out of date or unreachable for a few days, test it yourself to make sure this is the case (Mirmon may have configuration issues, or the mirror may have been updated since the last probe). Then 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].” RT #1817699 has an example of how to test if a mirror can be accessed by rsync.

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/pkgname (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 <[email protected]> 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 <[email protected]>.

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.

ThankGNU/ThankCRM

• Add donors to the appropriate /thankgnus/yyyysupporters.html file under the correct category and cvs commit it. In the commit log message, include all the names and the categories under which they were listed. For example: “Added: contributors John Doe, Jane Doe, Mr. Regular Donor; sustaining contributor Great Doe; patron Generous Company (RT #1234).”
• For a corporation, confirm that they are not a current patron. Occasionally, a patron may accidentally donate via the standard FSF donation form.
• Comment the ticket with something simple like “Done.”
• If for any reason you must use a different name for the entry than the one originally requested, state it clearly in the ticket comment: “Using ‘x’ instead of ‘y’ because ‘z’.”
• If you have any doubts, ask what to do in a comment. For example, you may see that a donor is already on the list, either for the same amount or a different amount. Here's an example of a comment for one of these cases: “John Doe is already listed for the same amount this year. Do you confirm that John Doe should be listed as a new donation in addition to the one that already exists?”
• Finally, move the ticket to the campaigns queue, un-resolved.

Things to watch out for:

• Do not quote the dollar amount in the commit message or anywhere else, just the name, category, and ticket number.
• Do not “Reply” to sysadmin on these messages; they are automatically generated.
• Do not post a ThankGNU for Google Matching Gifts.
• Do not post a ThankGNU for donations which have "Anonymous" listed as a name. Donations listing "Anonymous, in memory of X" or "Anonymous on behalf of X," etc., are fine to include.
• If you need to make a change to an existing entry on the site, be sure to let the FSF campaigns staff know about it by writing to <[email protected]>, so they can make the appropriate changes elsewhere as well if needed.

If you have any questions or if you suspect there may be an issue with a donation (e.g., an improper name), please mention it in a comment and move the ticket to the campaigns queue. The FSF campaigns team may then be able to help you by writing a comment and moving the ticket back to the webmasters queue.

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.

Adding an image to the GNU Gallery

1. When someone offers an image to GNU, first find out from the author which license it is released under, and check that this is a suitable free license. If the new image is a derivative of another one, make sure its license is compatible with at least one of the license(s) the parent image was released under. If in doubt, ask on www-discuss.
2. Check that rendering is adequate at the original size, using the browser's default font size, for at least one of the versions provided by the author. If not, create a new version for display.
3. Try to compress any large PNG files (several hundred kB), for instance with OptiPNG.
4. Install the image file(s) in the /graphics/ directory, but do not install very large ones (2MB or more) unless absolutely necessary; instead, ask the author to upload them to a user-respecting hosting facility, such as Framadrive or Internet Archive.
5. Create a 80x80px thumbnail in the /graphics/icons/ subdirectory; this can be done conveniently with mogrify. To create a thumbnail for arantxa-glitch.jpg, for example, you would run:

   mogrify -resize 80x80 -background white -gravity center \
   -extent 80x80 -format png -path icons arantxa-glitch.jpg \
   && mv icons/arantxa-glitch.png icons/arantxa-glitch.80.png

6. Create a new page in /graphics/, using the boilerplate located at /server/standards/boilerplate_graphics.html. If the image is a derivative work, provide a link (or at least a reference) to the image it is derived from.
7. Choose one or several keywords which will be used to select the new page in the main menu. Currently we have the following keywords (check the selection form to know what each one covers):

   Themes: gnuhead, gnu, tux, rms, emacs, fs, license, drm, surveillance.
Types: ai, ascii, banner, button, icon, cartoon, plastic, logo, poster, svg, wallpaper.

   Feel free to add more as needed, but don't forget to update the selection form if you do.
8. Add entries for the new page in the main menu. The most convenient way to do this is to duplicate one of the entries, and replace the keywords, links, page title and author by those of the new page. This is what the arantxa.html entry looks like:

       <!--#if expr="$THEME = /^(gnuhead|)$/
                  && $TYPE  = /^(banner|logo|)$/" -->
    <tr><td><a href="/graphics/arantxa.html">
        <img src="/graphics/icons/arantxa-glitch.80.png"
              alt="&nbsp;[Glitch]&nbsp;" /></a></td>
        <td>GNU designs<br />
        <small>by Arantxa Serantes</small></td></tr><!--#endif
    -->
   

   Note that the entry starts and ends with SSI directives, and that there is a line break within the endif rather than after it, to avoid numerous blank lines in the HTML that is served to the user.

Updating info in GNU package lists

Sometimes a maintainer of a GNU package requests updating its entries in GNU package lists:

• /graphics/allgnupkgs.html
• /manual/allgnupgks.html
• /server/home-pkgblurbs.html
• /software/allgnupkgs.html
• /software/oldgnupkgs.html

The sources of those files are maintained in /prep/gnumaint/.

1. Download htmlxref.cnf:

    torsocks wget \
      -O htmlxref.cnf \
      https://ftpmirror.gnu.org/texinfo/htmlxref.cnf
   

2. Edit rec/gnupackages.rec, rec/oldpackages.rec, and rec/pkgblurbs.rec.

3. Regenerate the files. You may want to add ./ to your PATH:

    make gnupackages.txt html-update PATH=".:$PATH"
   

4. Make sure the diffs look as expected:

    cvs diff ../../{graphics,manual,software}/allgnupkgs.html \
        ../../software/oldgnupkgs.html \
        ../../server/home-pkgblurbs.html | less
   

5. Return to gnumaint and commit your changes to the source files, then commit the updates to the www repository. If any changes in htmlxref.cnf were needed, send them to the bug-texinfo mailing list.

Planet GNU

Feeds on Planet GNU should generally be following our linking policies.

Making changes to Planet GNU, such as adding or removing feeds, is done by making changes in the appropriate git repository:

• Planet GNU configuration files:

  git clone membername@git.savannah.gnu.org:/srv/git/www/planet-config.git

  https://git.savannah.gnu.org/cgit/www/planet-config.git

• Planet GNU-specific code parts (templates, cron scripts, etc.):

  git clone membername@git.savannah.gnu.org:/srv/git/www/planet-infra.git

  https://git.savannah.gnu.org/cgit/www/planet-infra.git

Changes are not made live immediately but after the cron job is run, which starts at minute 25 of every hour.

More information can be found on Savannah's Using Git page.

Log Messages

It's important to write good commit log messages to help project members and future generations find specific changes in a given file and understand why your changes were made.