[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
www/server/standards README.webmastering.html
|
From: |
Therese Godefroy |
|
Subject: |
www/server/standards README.webmastering.html |
|
Date: |
Fri, 8 Sep 2017 02:27:59 -0400 (EDT) |
CVSROOT: /webcvs/www
Module name: www
Changes by: Therese Godefroy <th_g> 17/09/08 02:27:59
Modified files:
server/standards: README.webmastering.html
Log message:
Update, reorganize, fix some bugs, etc. (discussed with Ineiev):
* Table of contents: list h4 as well as h3; style with class 'summary'.
* RT: update procedures, insist on leaving translations alone.
* Editing and creating web pages: clarify 'structure'; add
'Orthography';
include 'addarticle', 'writeentry', 'announcements' (rename to
'Making the
new pages visible', delete 'Adding news' until news can be pulled
again),
and 'gnupackages' (clarify what webmasters can do to software web
pages).
* Linking: include 'deadlink' and 'addlink'.
* Mirrors: remove Ibiblio, move nongnu and www to the end.
* Common requests: 2 items left: 'ThankGNU' and 'permission to use
image'.
* CVS and symlinks: clarify.
* Minor fixes: links, typos, spelling, quotes, tags, etc.
CVSWeb URLs:
http://web.cvs.savannah.gnu.org/viewcvs/www/server/standards/README.webmastering.html?cvsroot=www&r1=1.194&r2=1.195
Patches:
Index: README.webmastering.html
===================================================================
RCS file: /webcvs/www/www/server/standards/README.webmastering.html,v
retrieving revision 1.194
retrieving revision 1.195
diff -u -b -r1.194 -r1.195
--- README.webmastering.html 9 Aug 2017 13:41:55 -0000 1.194
+++ README.webmastering.html 8 Sep 2017 06:27:58 -0000 1.195
@@ -1,41 +1,91 @@
-<!--#include virtual="/server/html5-header.html" -->
+<!--#include virtual="/server/header.html" -->
<!-- Parent-Version: 1.77 -->
<title>Webmastering Guidelines - GNU Project - Free Software Foundation</title>
+<style type="text/css" media="print,screen"><!--
+.summary { margin-top: 1.3em; }
+dl.compact { margin: 1.3em 0; }
+.compact dt { margin: .5em 0 0 0; }
+dl.compact dd { margin: 0 3%; }
+--></style>
<!--#include virtual="/server/gnun/initial-translations-list.html" -->
<!--#include virtual="/server/banner.html" -->
<h2>GNU Webmastering Guidelines</h2>
-<h3>Information for new webmasters</h3>
-<p>If you're interested in volunteering as a GNU webmaster, please first
+<p class="highlight">
+If you're interested in volunteering as a GNU webmaster, please first
complete the <a
-href="http://www.gnu.org/server/standards/webmaster-quiz.html";>GNU
-webmaster quiz</a>.</p>
+href="/server/standards/webmaster-quiz.html">GNU webmaster quiz</a>.</p>
+<p>By the way, please edit and improve this document!</p>
-<h3>Table of contents</h3>
-
-<p>The rest of this document is long and detailed. Here is a table of
-contents of the top level items:</p>
-
-<a href="#working">Working as a webmaster</a> -
-<a href="#rt">Using RT</a> -
-<a href="#structure">Editing and creating web pages</a> -
-<a href="#announcements">Announcements</a> -
-<a href="#pollinking">Linking policies</a> -
-<a href="#mirrors">Mirrors</a> -
-<a href="#thankgnu">ThankGNU/ThankCRM</a> -
-<a href="#commonreq">Handling common requests</a> -
-<a href="#repo">Working with our repositories</a> -
-<a href="#readme">More README pages</a>.
+<div class="summary">
+<h3 class="no-display">Table of Contents</h3>
+<ul>
+ <li><a href="#working">Working as a webmaster</a>
+ <ul>
+ <li><a href="#organization">Webmaster organization</a></li>
+ <li><a href="#leaving">Leaving webmasters</a></li>
+ </ul></li>
+ <li><a href="#rt">Using RT</a>
+ <ul>
+ <li><a href="#rtguide">RT - quick guide</a></li>
+ <li><a href="#rtreply">RT - correspondence vs. comments</a></li>
+ <li><a href="#rtcoord">RT - coordination with others</a></li>
+ <li><a href="#rtstatus">RT - ticket status</a></li>
+ <li><a href="#rtescalate">RT - ticket escalation</a></li>
+ <li><a href="#rtmisdirected">RT - misdirected tickets</a></li>
+ </ul></li>
+ <li><a href="#webpages">Editing and creating web pages</a>
+ <ul>
+ <li><a href="#structure">Site structure and navigation</a></li>
+ <li><a href="#templating">Page templating</a></li>
+ <li><a href="#styling">Page styling</a></li>
+ <li><a href="#orthography">Orthography</a></li>
+ <li><a href="#addarticle">Adding new articles</a></li>
+ <li><a href="#writeentry">Writing and reviewing items for
<code>/proprietary</code></a></li>
+ <li><a href="#announcements">Making a new page visible</a></li>
+ <li><a href="#gnupackages">Web pages for official GNU software</a></li>
+ </ul></li>
+ <li><a href="#linking">Linking</a>
+ <ul>
+ <li><a href="#pollinking">Linking policies</a></li>
+ <li><a href="#distros">Links to free GNU/Linux distributions</a></li>
+ <li><a href="#usergroups">Links to GNU & Free Software User
Groups</a></li>
+ <li><a href="#deadlink">Fixing dead links</a></li>
+ <li><a href="#addlink">Adding links</a></li>
+ </ul></li>
+ <li><a href="#mirrors">Mirrors</a>
+ <ul>
+ <li><a href="#gnu">GNU mirrors</a></li>
+ <li><a href="#nongnu">Non-GNU mirrors</a></li>
+ <li><a href="#www">Mirrors of www.gnu.org</a></li>
+ </ul></li>
+ <li><a href="#commonreq">Other common requests</a>
+ <ul>
+ <li><a href="#thankgnu">ThankGNU/ThankCRM</a></li>
+ <li><a href="#image">Requests for permission to use an image</a></li>
+ </ul></li>
+ <li><a href="#repo">Working with webmaster-related repositories</a>
+ <ul>
+ <li><a href="#cvs">Basic CVS commands</a></li>
+ <li><a href="#scripts">Scripts</a></li>
+ <li><a href="#symlinks">Symbolic links</a></li>
+ <li><a href="#htaccess">.htaccess and redirections</a></li>
+ <li><a href="#sysadmins">System administrators</a></li>
+ </ul></li>
+ <li><a href="#readme">More README pages</a></li>
+</ul>
+<hr class="no-display" />
+</div>
-<p>By the way, please edit and improve this document!</p>
<h3 id="working">Working as a www.gnu.org webmaster</h3>
+
<p>All active webmasters have access to the <a
-href="http://rt.gnu.org/";>webmasters RT queue</a>, which corresponds to
+href="//rt.gnu.org/">webmasters RT queue</a>, which corresponds to
the email address <a
href="mailto:address@hidden";><address@hidden></a>. This
is the primary work queue for webmasters. Please check the queue
@@ -44,36 +94,32 @@
ticket. See <a href="#rt">RT guidelines</a> below for many details.</p>
<p>All active webmasters should be part of the <a
-href="http://savannah.gnu.org/projects/www/";>www</a> project on
-savannah, so changes can be committed. Please join that if you haven't
+href="//savannah.gnu.org/projects/www/">www</a> 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. <a href="http://savannah.gnu.org/cvs/?group=www";>Instructions
-on how to use CVS</a> (you want the “Webpages
-repository”).</p>
-
-<p>All active webmasters should be on the www-discuss mailing list. You
-should have gotten the subscription and archive information for it when
-you joined. If not, write chief-webmaster. Additional archives are in
-<tt>/com/archive/webmaster*</tt> on fencepost.</p>
+result. <a href="//savannah.gnu.org/cvs/?group=www">Instructions
+on how to use CVS</a> (you want the “Webpages repository”).</p>
+
+<p>All active webmasters should be on the <a
+href="//lists.gnu.org/mailman/listinfo/www-discuss">www-discuss mailing
+list</a>. If you are not, write to <address@hidden>.</p>
<p>Webmasters who are planning to write a significant amount of new
material for the site should provide a copyright assignment.</p>
-<p>If you find a message to address@hidden that you don't know how
+<p>If you find a message to <address@hidden> 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?"</p>
+few days, it is good to ask the www-discuss list: “Can someone teach
+me how to handle messages like this?”</p>
<p>As a general rule, things like this are always okay to do:</p>
<ul>
- <li>Fix typos, misspellings, broken links, and the like (a report of
- broken links is available at
-<a
href="/server/source/linc/linc-report.html">/server/source/linc/linc-report.html</a>
-The reports are separated by language code.)</li>
- <li>Requests from Richard Stallman
+ <li>Fix typos, misspellings, <a href="#deadlink">broken links</a>, and
+ the like in the www repository (English pages only).</li>
+ <li>Requests from Richard Stallman (RMS)
<a href="mailto:address@hidden";><address@hidden></a>,
John Sullivan <a
href="mailto:address@hidden";><address@hidden></a>,
or anyone else at the FSF Distribution Office.</li>
@@ -89,22 +135,23 @@
<p>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 non-free software. When in doubt, it is best to post a
+references to nonfree software (see our <a href="#pollinking">linking
+policies</a>). 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.</p>
-<p>We do not have links to web sites of the <a
+<p>We do not have links to websites of the <a
href="/distros/common-distros.html">well-known</a> 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.</p>
+nonfree programs.</p>
<p>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.</p>
-<h4>Webmaster organization</h4>
+<h4 id="organization">Webmaster organization</h4>
<p>The following organizational rules are not rigid; they are designed to
serve us and assign responsibility so that things don't fall through the
@@ -113,13 +160,11 @@
these policies.</p>
<p>The GNU Webmaster Group is led by the Chief Webmaster <a
-href="mailto:address@hidden";><address@hidden></a>.
-You can always find out the identity of the Chief Webmaster by looking at
-the aliases file on the GNU mail server.</p>
+href="mailto:address@hidden";><address@hidden></a>.</p>
<p>The Chief Webmaster is responsible for making sure that every message sent
-to webmasters <a href="mailto:address@hidden";><address@hidden>
-</a> gets handled
+to webmasters <a
+href="mailto:address@hidden";><address@hidden></a> 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
@@ -131,7 +176,7 @@
future.</p>
-<h4>Leaving webmasters</h4>
+<h4 id="leaving">Leaving webmasters</h4>
<p>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
@@ -148,6 +193,7 @@
<h3 id="rt">Using RT</h3>
+
<p>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
@@ -159,82 +205,83 @@
please consider this. A number of people can set up your RT account for
this, just mail www-discuss.</p>
-<a name="rtguide"></a>
-<h4>RT - quick guide</h4>
+
+<h4 id="rtguide">RT - quick guide</h4>
<p>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’
+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.</p>
<ul>
<li>To see open tickets, visit <a
-href="http://rt.gnu.org/";>rt.gnu.org</a> and log in with your assigned
+href="//rt.gnu.org/">rt.gnu.org</a> and log in with your assigned
RT username/password. (If you don't have one, email www-discuss.)
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.</li>
-<li>If the message is spam, click the ‘Mark as Spam’ link in
+<li>If the message is spam, click the “Mark as Spam” link in
the top row.</li>
<li>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’.</li>
+spam, or you're not sure if it's spam, click “Basics”, then
+change the Queue field to “web-translators”.</li>
<li>If the message is just a thank-you to us, or something else that
-doesn't require action on our part, click ‘Resolve’.</li>
+doesn't require action on our part, click “Resolve”.</li>
-<li>If the message is a simple typo or other buglet on a page we
-maintain, go ahead and fix it, using ‘Reply’ to tell the
-submitter what you did, and then ‘Resolve’ it.</li>
+<li>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.</li>
<li>If the message is a ThankGNU or a ThankCRM see the
<a href="#thankgnu">Thank GNU procedure</a>.</li>
<li>If the message is about making a link on one of our pages, see
-<a href="#pollinking">linking procedures and information</a>.</li>
+the <a href="#pollinking">linking policies</a>.</li>
-<li>If the message is about adding a graphic or a joke, be sure to get
+<li>If the message is about adding an image or a joke, be sure to get
the explicit ok for it to be released under a free
license—GPLv3-or-later and FDLv1.3-or-later is good. Then make a
-new page under <tt>/graphics</tt> resp. <tt>/fun</tt> and add it to the
-index page. rms' requirements for adding items to <tt>/fun</tt> is in
+new page under <code>/graphics</code>, resp. <code>/fun</code>, and add it to
the
+index page. RMS' requirements for adding items to <code>/fun</code> are in
<a href="/fun/README">/fun/README</a>.</li>
<li>If the message is about a mirror, see <a
href="#mirrors">mirror procedures and information</a>.</li>
<li>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
+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.</li>
<li>If the message needs to be dealt with by another group, such as
-sysadmin or licensing, move it to the corresponding queue or otherwise
-forward it. <a href="#rtmisdirected">Specific directions for
-redirecting tickets</a>.</li>
+web-translators, sysadmin, licensing or audio-video, move it to the
+corresponding queue or otherwise forward it. <a
+href="#rtmisdirected">Specific directions for redirecting tickets</a>.</li>
</ul>
-<h4>RT - correspondence vs. comments</h4>
+
+<h4 id="rtreply">RT - correspondence vs. comments</h4>
<p>You can attach two kinds of information to a ticket: correspondence and
comments.</p>
-<p>Correspondence will be sent to the person who sent the initial report. Add
+<p><em>Correspondence</em> 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.</p>
-<p>Comments are only seen by the ticket staff: the owner and people listed
+<p><em>Comments</em> 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").
+(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.</p>
@@ -242,7 +289,7 @@
<p>Unfortunately, the methods for adding either type of correspondence are
very similar, so it's easy to get them confused. Be careful.</p>
-<p>To add correspondence, use one of the "reply" links on the ticket page, or
+<p>To add correspondence, use one of the “Reply” links on the
ticket page, or
send mail to <address@hidden> with</p>
<pre>
@@ -251,7 +298,7 @@
<p>in the subject line, where 1234 is the ticket number.</p>
-<p>To add comments, use one of the "comment" links on the ticket page, or send
+<p>To add comments, use one of the “Comment” links on the ticket
page, or send
mail to <address@hidden> with</p>
<pre>
@@ -265,7 +312,8 @@
hanging around for modifying email received in Emacs, or in mbox
format. Please check with www-discuss for these.</p>
-<h4>RT - coordination with others</h4>
+
+<h4 id="rtcoord">RT - coordination with others</h4>
<p>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
@@ -273,13 +321,13 @@
project—the best way to do this is to mail them, and make that
mail a comment to the ticket as well.</p>
-<p>So, say for example that you wanted to ask rms whether
+<p>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 "comments" links on the ticket page, and listing the other
-party (in this case, <address@hidden>) as a CC:. You
+one of the “Comment” links on the ticket page, and listing the
other
+party (in this case, <address@hidden>) in the CC field. You
could also do this by sending a mail with headers like this:</p>
-<pre>
+<pre class="emph-box">
To: <address@hidden>, <address@hidden>
Subject: [gnu.org #1234] Question about link policy
</pre>
@@ -289,43 +337,46 @@
<p>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.</p>
+you're primarily doing work by email, however.</p>
-<p>Note that this won't work with other RT-handled addresses. So, if
+<p><em>Note that this won't work with other RT-handled addresses.</em> So, if
you add <address@hidden> 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 using the “Refers
+<em>campaigns</em> 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.</p>
-<h4>RT - ticket status</h4>
-<p>Here are the possible ticket statuses in RT:</p>
+<h4 id="rtstatus">RT - ticket status</h4>
-<ul>
-<li><tt>new</tt> is for tickets which have not had work done on them yet.
+<dl class="compact">
+<dt>new</dt>
+<dd>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.</li>
+explicitly set it.</dd>
-<li><tt>open</tt> is for tickets which are being worked on. RT will
+<dt>open</dt>
+<dd>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.</li>
+manually.</dd>
-<li><tt>resolved</tt> is for tickets whose problems have been addressed.
+<dt>resolved</dt>
+<dd>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.</li>
+completely addressed, leave it open.</dd>
-<li><tt>deleted</tt> is for tickets which are spam (and only spam).
-This status is set automatically by the ‘Mark as Spam’
+<dt>deleted</dt>
+<dd>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.</li>
-
-<li><tt>rejected</tt> and <tt>stalled</tt> should not be used.</li>
+spam tickets.</dd>
-</ul>
+<dt>rejected, stalled</dt>
+<dd>Should not be used.</dd>
+</dl>
<p>Other considerations regarding tickets' status:</p>
@@ -342,86 +393,95 @@
</ul>
-<h4>RT - ticket escalation</h4>
+<h4 id="rtescalate">RT - ticket escalation</h4>
<p>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.</p>
-<a name="rtmisdirected"></a>
-<h4>RT - misdirected tickets</h4>
+<h4 id="rtmisdirected">RT - misdirected tickets</h4>
<p>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.</p>
<p>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’
+there. The ticket's queue can be changed under the “Basics”
menu item.</p>
<ul>
-<li>Move tickets with opinions or inquiries about free software or GNU
- philosophy, help using specific programs, or other such non-web
- site-specific questions, to the info queue.</li>
+<li>Move tickets about a new or existing translation of a gnu.org web page
+ to the <em>web-translators</em> queue. <em>Don't try to edit translated
+ pages</em>, even if you know the language: they are automatically
+ generated from a different format, and maintained by different teams.</li>
<li>Move bug reports and other items about the Free Software Directory
- to the directory queue.</li>
+ to the <em>directory</em> queue.</li>
<li>Move bug reports about fsf.org pages (broken links, typos, layout)
- to the resources queue.</li>
+ to the <em>resources</em> queue.</li>
-<li>Move tickets that are about the actual content of fsf.org pages to
- the campaigns queue.</li>
+<li>Move tickets that are about the actual contents of fsf.org pages to
+ the <em>campaigns</em> queue.</li>
-<li>Move tickets that are about FSF memberships to the memberships
+<li>Move tickets that are about FSF memberships to the <em>membership</em>
queue.</li>
<li>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.</li>
+ down, a <a href="#symlinks">.symlinks file</a> not creating the symbolic
+ link), try to verify the problem and, if it is real, move it to the
+ <em>sysadmin</em> queue.</li>
+
+<li>Move tickets about mailing lists, Fencepost and the GNU FTP server
+ to the <em>sysadmin</em> queue.</li>
+
+<li>For tickets about the Savannah website, version control systems and
+ non-GNU download server, email the original message to
+ <address@hidden>. There is more info about
+ who maintains what service in the <a
+ href="//savannah.gnu.org/maintenance/NotSavannahAdmins/">
+ Savannah documentation</a>.</li>
-<li>Move tickets about a new or existing translation of a gnu.org web page
- to web-translators. Exception: for happy-birthday-to-gnu subtitles
- and other FSF campaigns pages on gnu.org, handle them
- ourselves.</li>
-
-<li>For tickets about Savannah, email the original message to
- address@hidden</li>
-
-<li>Move tickets about licensing to the licensing queue.</li>
+<li>Move tickets about licensing to the <em>licensing</em> queue.</li>
-<li>Move tickets about accounts to the accounts queue.</li>
+<li>Move tickets about accounts to the <em>accounts</em> queue.</li>
-<li>Move tickets about the */allgnupkgs.html pages to the maintainers
- queue.</li>
+<li>Forward tickets about the <code>/*/allgnupkgs.html</code> pages to
+ <address@hidden>.</li>
<li>Requests to remove messages from mailing list archives (accessible via
- <a href="http://mail.gnu.org";>http://mail.gnu.org</a> should be forwarded
- to <address@hidden>.</li>
+ <a href="//lists.gnu.org">http://lists.gnu.org</a>) should only be
+ honored if there are very compelling reasons, in which case they
+ should be forwarded to <address@hidden>. The initial reply
+ should be that mailing lists are archived by many independent sites,
+ and removing the message from one of them would only attract attention
+ to it.</li>
<li>Anything else not related to webmastering—including questions
about FSF opinions, requests for support, and the like—can be
- moved to the info queue.</li>
+ moved to the <em>info</em> queue.</li>
<li>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.</li>
+ <code>http://www.gnu.org/software/libc/bugs.html</code>. That is
+ the best way to get the glibc maintainers' attention.</li>
<li>If the ticket is about the web pages for a <a
href="#gnupackages">specific GNU software package</a>, 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
- <tt>/gd/gnuorg/maintainers.bypkg</tt> on fencepost), and reply to
+ <code>/gd/gnuorg/maintainers.bypkg</code> on Fencepost), and reply to
the OP saying that you did so, resolving the ticket.</li>
+<li>Requests to add a video or audio file to the audio-video website should
+ be forwarded to <a
+ href="mailto:address@hidden";><address@hidden></a>.</li>
</ul>
<p>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 address@hidden with the original subject
-line. Just a terse message "Moved ticket 1234 to your queue"
+sending mail to <address@hidden> with the original subject
+line. Just a terse message “Moved ticket 1234 to your queue”
suffices.</p>
<p>If there isn't an appropriate RT queue, forward the mail to the
@@ -431,111 +491,171 @@
email.</p>
-<h3 id="structure">Editing and creating web pages</h3>
+<h3 id="webpages">Editing and creating web pages</h3>
+
-<h4>Site structure and navigation</h4>
+<h4 id="structure">Site structure and navigation</h4>
<p>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, which is the main page for this section of the
-site, and so should provide access to all the material within that
-directory.</p>
-
-<p>The main directories (/gnu, /philosophy, etc.) are accessible via
-navigation bars, but some other important directories (e.g. /proprietary)
-are not (yet?). Every page in these directories should link back to the
-main page, to allow people to get more information about the topic at
-hand.</p>
+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 <code>/gnu</code> directory has a page,
+<code>gnu.html</code>, 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: <code>/philosophy/essays-and-articles.html</code>,
+<code>/philosophy/speeches-and-interview.html</code>,
+and <code>/philosophy/third-party-ideas.html</code>.</p>
+
+<p>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.,
+<code>/proprietary</code> 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.</p>
<p>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.</p>
-
-<p>Some pages are dynamic and should include a link with the full
-hostname; a notable example is the Free Software Directory. So, we link
-to that with the URL <tt><http://www.gnu.org/directory></tt>.</p>
+a specific article in the <code>/proprietary</code> directory, link to
+<code>/proprietary/proprietary.html</code>, rather than just
+<code>proprietary.html</code>. This eases maintenance of the site as
+things get moved around.</p>
+
-<h4>Page templating</h4>
+<h4 id="templating">Page templating</h4>
<p>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 <a
-href="http://web.cvs.savannah.gnu.org/viewvc/*checkout*/www/server/standards/boilerplate.html?root=www&content-type=text%2Fplain";>
-original source</a> of the boilerplate instead.</p>
+href="//web.cvs.savannah.gnu.org/viewvc/*checkout*/www/server/standards/boilerplate.html?root=www&content-type=text%2Fplain">
+original source</a> of the boilerplate instead, and follow the instructions
+in it.</p>
-<h4>Page styling</h4>
+
+<h4 id="styling">Page styling</h4>
<p>Generic styling for desktops and smartphones is provided by two CSS:
-<tt><a
-href="http://web.archive.org/web/20070321054317/http://developer.yahoo.com/yui/reset/";>
-/reset.css</a></tt>, and <tt>/layout.css</tt>, which contains
-gnu.org-specific formatting.</p>
+<code>/reset.css</code> (from the <a
+href="//web.archive.org/web/20070930230754/http://developer.yahoo.com:80/yui/";>
+YUI library, version 2</a>), which normalizes the default rendering of all
+HTML elements by the various browsers, and <code>/layout.css</code>, which
+contains gnu.org-specific formatting.</p>
<p>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 be normally be added as an attribute.</p>
+that include <code>header.html</code> and <code>banner.html</code>. If the
+style applies to a single element, it should normally be added as an
attribute.</p>
<p><em>Note about grids:</em> Very few pages currently use them. In the
event you'd like to create one that does, good starting points may be
found in <a
-href="https://yuilibrary.com/yui/docs/cssgrids/";>YUI version 3</a>, and <a
-href="https://purecss.io/grids/";>Pure Grids</a>. The components provided by
+href="//yuilibrary.com/yui/docs/cssgrids/">YUI version 3</a>, and <a
+href="//purecss.io/grids/">Pure Grids</a>. The components provided by
these libraries are licensed under the modified (3-clause) BSD license.</p>
-<p>Mobile devices with very limited resources use <tt>/mini.css</tt>.
-This stylesheet is just the YUI reset and base stylesheets, as these
+<p>Mobile devices with very limited resources use <code>/mini.css</code>.
+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.</p>
-<p>Printers use <tt>/print.css</tt>. Note that the header, navigation
+<p>Printers use <code>/print.css</code>. Note that the header, navigation
bars and footer (except copyright and license) are unprintable.</p>
<p>Historical pages (unmaintained translations for the most part) refer
-to <tt>/gnu.css</tt> which also loads the mobile CSS, as these pages are
+to <code>/gnu.css</code>, which also loads the mobile CSS, as these pages are
usually very basic, plain pages with little or no formatting.</p>
-<p>Some software manuals use a dedicated CSS, <tt>/style.css</tt>.</p>
+<p>Some software manuals use a dedicated CSS, <code>/style.css</code>.</p>
-<h3 id="announcements">Announcements: directory links, sitemap, home page</h3>
+<h4 id="orthography">Orthography</h4>
-<p>When significant new material is added, notices should be put up to
-make people aware of it:</p>
+<p>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:</p>
<ul>
-<li><a href="#polnews">Add a News entry</a> (next
-section).</li>
+<li>In ordinary text, HTML entities “&ldquo;...&rdquo;”
+and “&lsquo;...&rsquo;” are preferred over straight
+quotes ("..." and '...').</li>
+
+<li>“Nonfree” is preferred over “non-free”;
+likewise, “noncommercial” over “non-commercial.”</li>
+</ul>
-<li>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 <tt>/gnu</tt>
-directory, add a link to it from <tt>/gnu/gnu.html</tt>.</li>
-<li>If a new page is sufficiently important, add a link on the home
-page, <tt>/home.html</tt>.</li>
+<h4 id="addarticle">Adding new articles</h4>
+
+<p>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 <a href="#templating">put into our standard
+boilerplate</a>. There are some things which you should look out for when
+doing the conversion:</p>
+<ul>
+<li>When they exist, preserve double spaces after sentence breaks.</li>
+<li>Replace any straight quotes with HTML entities (in ordinary text only,
+of course).</li>
+<li>Replace any instances of “non-free” with
+“nonfree.”</li>
+<li>Add the author's name below the <h2> header.</li>
</ul>
-<h4 id="polnews">Adding news: whatsnew</h4>
-<p>News items are posted by adding a new "News" entry to the
-<a href="http://savannah.gnu.org/projects/www";>www project on
-Savannah</a>.</p>
-
-<p>Once that is done there is no need to do anything more. The News
-item will eventually appear on <a href="http://planet.gnu.org";>
-http://planet.gnu.org</a>. A cron job
-will trigger <a href="/server/source/source.html">planetrss.pl</a>
-to pull new items from the RSS feed and add them to
-<a href="/planetfeeds.html">/planetfeeds.html</a>
-where they are then included in home.html via an SSI Include
-directive. Email www-discuss if something seems to be wrong.</p>
+<h4 id="writeentry">Writing and reviewing items for /proprietary</h4>
+
+<p>
+If you plan to write or review an item for a page in <a
+href="/proprietary">/proprietary</a>, please refer to our <a
+href="/server/standards/proprietary-guidelines.html">submission guidelines</a>.
+</p>
+
+
+<h4 id="announcements">Making a new page visible</h4>
+
+<ul>
+<li>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 <code>/gnu</code>
+directory, add a link to it from <code>/gnu/gnu.html</code>. If the page
+was created in <code>/philosophy</code> or <code>/education</code>, add the
+link to the relevant submenu (see <a href="#structure">Site structure and
+navigation</a>).</li>
+
+<li>If a new page in <code>/philosophy</code> is especially important, RMS
+will probably ask webmasters to link it from the Philosophy main page, in
+addition to the submenu.</li>
+
+<li>Also add a link to <code>/philosophy/latest-articles.html</code> if
+what you have added is a recent article, as opposed to one that was
+published elsewhere long ago.</li>
+
+<li>A link to the new page will automatically be created in the site map.</li>
+</ul>
+
+
+<h4 id="gnupackages">Web pages for official GNU software</h4>
+
+<p>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.)</p>
+
+<p>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.</p>
+
+
+<h3 id="linking">Linking</h3>
-<h3 id="pollinking">Linking policies</h3>
+<h4 id="pollinking">Linking policies</h4>
<p>One of the most complex aspects of webmastering is following the linking
guidelines; however, it's also a very crucial aspect of the job.</p>
@@ -549,36 +669,36 @@
provide a link to a page from ours. They are listed below, in order of
descending general importance.</p>
-<ul>
-<li>What's the context of the link?</li>
-</ul>
+<dl>
+<dt>What's the context of the link?</dt>
+<dd>
<p>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.
+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.</p>
+</dd>
-<ul>
-<li>Does the page promote proprietary software?</li>
-</ul>
+<dt>Does the page promote proprietary software?</dt>
+<dd>
<p>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
+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.</p>
-<p>What's tricky about this criteria is the "promotion" point: there's
+<p>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
+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.</p>
@@ -593,8 +713,8 @@
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."</p>
+there's a difference between “Windows” and
+“Microsoft Windows XP Home Edition.”</p>
<p>If the page requires <a href="/philosophy/javascript-trap.html">nonfree,
nontrivial JavaScript</a> and has serious failures with
@@ -607,7 +727,7 @@
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
+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.</p>
@@ -618,42 +738,42 @@
well-known proprietary software. For example, the following
text—and not much else—would be acceptable:</p>
-<p>w3 is a web browser for GNU Emacs, similar to Internet Explorer.
+<blockquote><p>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.</p>
+proprietary Unix systems, and Windows.</p></blockquote>
<p>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.</p>
+encouragement to “learn more” should still be avoided.</p>
+</dd>
-<ul>
-<li>How does the page compare free software to open source?</li>
-</ul>
+<dt>How does the page compare free software to open source?</dt>
+<dd>
<p>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:-</p>
+page provides a good example of a way to do it tactfully:</p>
-<p>GNOME is part of the GNU project, and is free software (sometimes
-referred to as open source software).</p>
+<blockquote><p>GNOME is part of the GNU Project, and is free software
(sometimes
+referred to as open source software).</p></blockquote>
<p>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."</p>
+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.”</p>
+</dd>
-<ul>
-<li>How does the page treat the GNU project?</li>
-</ul>
+<dt>How does the page treat the GNU Project?</dt>
-<p>Pages which we link to should treat the GNU project well. The
+<dd>
+<p>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
+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.</p>
@@ -662,7 +782,7 @@
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
+authors. Similarly, on user group pages, the contents of forums and Wiki
pages should not hold weight in these regards.</p>
<p>Finally, some sites are understood to always have exception with most of
@@ -675,22 +795,23 @@
them.</p>
<p>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.</p>
+Even for making links from www.gnu.org, we do not <em>require</em> 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.</p>
<p>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
+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.</p>
+</dd>
+</dl>
-<a id="distros"></a>
-<h4>Links to free GNU/Linux distributions</h4>
+<h4 id="distros">Links to free GNU/Linux distributions</h4>
<p>Suggestions for links to <a href="/distros/distros.html">GNU/Linux
distributions</a> should be handled like this:</p>
@@ -708,7 +829,7 @@
it (politely).</li>
<li>If there are no glaring problems, ask the requestors to request an
-endorsement from the (nongnu.org) gnu-linux-libre mailing list. They
+endorsement from the dedicated mailing list <address@hidden>. 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.</li>
@@ -718,9 +839,9 @@
good, pass it on to the FSF licensing person for final approval.</li>
</ol>
-<p>In any event, webmasters should <i>never</i> simply add new distros
+<p>In any event, webmasters should <em>never</em> simply add new distros
that are said to be free to <a href="/distros/free-distros.html">our
-list</a>. FSF licensing and rms must explicitly approve any
+list</a>. FSF licensing and RMS must explicitly approve any
additions.</p>
@@ -730,97 +851,149 @@
to the LibrePlanet website. Our ticket can then be resolved.</p>
+<h4 id="deadlink">Fixing dead links</h4>
+
+<p>Please check the <a href="/server/source/linc/linc-report.html">broken
+link reports</a> 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.</p>
+
+<p>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.</p>
+
+
+<h4 id="addlink">Adding links</h4>
+
+<p>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:</p>
+
+<ul>
+<li>If the person requesting the link is a friend of the GNU Project,
+check the page against our <a href="#pollinking">linking criteria</a>,
+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.</li>
+
+<li>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.</li>
+</ul>
+
+
<h3 id="mirrors">Mirrors</h3>
-<h4>GNU mirrors</h4>
+
+<h4 id="gnu">GNU mirrors</h4>
<p>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
<a href="/server/mirror.html">advice for mirrors</a>; that page explains
-what we ask mirror volunteers to provide. If in <i>any</i> doubt, comment
+what we ask mirror volunteers to provide. If in <em>any</em> doubt, comment
on the same ticket to ask other webmasters' opinion, or check with the
-webmasters mailing list and/or address@hidden before taking any
+webmasters mailing list and/or <address@hidden> before taking any
action.</p>
<p>After confirming the mirror meets our criteria for listing, do this:</p>
<ol>
- <li>Edit the file /prep/FTP (in CVS); it's plain text, not HTML.</li>
- <li>Run <code>make</code> in the <tt>prep/</tt> subdirectory.</li>
- <li>cvs commit both files FTP and ftp.html. In the commit log message,
+ <li>Edit the file <code>/prep/FTP</code> (in CVS); it's plain text, not
HTML.</li>
+ <li>Run <code>make</code> in the <code>/prep</code> subdirectory.</li>
+ <li><code>cvs commit</code> both files <code>FTP</code> and
+ <code>ftp.html</code>. In the commit log message,
include the name of the mirror and its location, and the RT number if
there is one.</li>
- <li>Update the file <tt>/gd/gnuorg/web/FTP.contacts</tt> on Fencepost,
+ <li>Update the file <code>/gd/gnuorg/web/FTP.contacts</code> on Fencepost,
keeping the pattern as explained at the beginning of the file.</li>
<li>See next entry about the status of mirrors.</li>
</ol>
-<h5>Checking the Status of Mirrors</h5>
+<h5>Checking the status of mirrors</h5>
<p>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.</p>
-<p>A <a href="http://download.savannah.gnu.org/mirmon/allgnu/";>mirmon page</a>
-tracker (maintained by savannah) shows how up-to-date each mirror is. When
+<p>A <a href="//download.savannah.gnu.org/mirmon/allgnu/">mirmon page</a>
+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]”.</p>
<p>If a mirror needs to be removed, please check to see if it is referenced
-on <tt>/server/mirror.html</tt> and remove that entry as well.</p>
+on <code>/server/mirror.html</code> and remove that entry as well.</p>
-<p>The address <tt>http://ftpmirror.gnu.org/PKG</tt> (also maintained by
-savannah) multiplexes between the mirrors, trying to choose one that is
+<p>The address <code>http(s?)://ftpmirror.gnu.org/PKG</code> (also maintained
by
+Savannah) multiplexes between the mirrors, trying to choose one that is
nearby and up to date.</p>
-<h4>nongnu mirrors</h4>
+<h5>Mirror contact information</h5>
+
+<p>When we get a request relating to a mirror, please check the file
+<code>/gd/gnuorg/web/FTP.contacts</code> 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.</p>
+
-<p>When we get a request to add, change, or remove a nongnu savannah mirror,
-email address@hidden with the information. The reason to
+<h4 id="nongnu">Non-GNU mirrors</h4>
+
+<p>When we get a request to add, change, or remove a non-GNU Savannah mirror,
+email <address@hidden> 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 address@hidden</p>
+privacy issues, it's better to use <address@hidden>.</p>
+
-<h4>www mirrors</h4>
+<h4 id="www">Mirrors of www.gnu.org</h4>
<p>We no longer recommend or list mirrors of www.gnu.org.</p>
-<p><b>Mirror contact information</b></p>
-<p>When we get a request relating to a mirror, please check the file
-<tt>/gd/gnuorg/web/FTP.contacts</tt> 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.</p>
+<h3 id="commonreq">Other common requests</h3>
+
-<p><b>Ibiblio URL changes</b></p>
+<p>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.</p>
-<p>If we are told or determine that there is a change in the rsync URL or
-the <a href="/server/mirror.html">advertised source mirror</a> URLs for
-ibiblio, all mirror maintainers should be informed. This requires
-hand-assembling a list of addresses from the <tt>FTP.contacts</tt> file
-based on the current mirror list.</p>
-<h3 id="thankgnu">ThankGNU/ThankCRM</h3>
+<h4 id="thankgnu">ThankGNU/ThankCRM</h4>
<ul>
<li>For a corporation, confirm that they are not a <a
- href="https://fsf.org/patrons";>current patron</a>. Occasionally, a
+ href="//fsf.org/patrons">current patron</a>. Occasionally, a
patron may accidentally donate via the standard FSF donation form.</li>
<li>For an individual, add it to the
- appropriate <tt>/thankgnus/YYYYsupporters.html</tt> file in the
- correct place with a commit message such as "Add John Doe to YYYY >=
- 500$ ThankGNU list (RT #1234)" and comment the ticket with something
- simple like "Done".</li>
+ appropriate <code>/thankgnus/YYYYsupporters.html</code> file in the
+ correct place, with a commit message such as “Add John Doe to
+ sustaining contributors (RT #1234),” and comment the ticket with
+ something simple like “Done.”</li>
<li>Mention in a RT comment whether you added an entry or not. The
script sending out the messages has bugs. The occasional case of a
person donating the same amount twice is handled by FSF staff.</li>
- <li>Finally, move the ticket into the 'campaigns' queue.</li>
+ <li>Finally, move the ticket to the <em>campaigns</em> queue.</li>
</ul>
<p>Things to watch out for:</p>
@@ -829,259 +1002,126 @@
<li>Do not quote the dollar amount in the commit message or
anywhere else, just the name, ticket number and category.</li>
- <li>Do not ‘Reply’ to sysadmin on these messages; they
+ <li>Do not “Reply” to sysadmin on these messages; they
are automatically generated.</li>
<li>Do not post a ThankGNU for Google Matching Gifts.</li>
</ul>
-<h3 id="commonreq">Handling common requests</h3>
-
-<p>There are a number of requests which recur frequently. This section
-documents guidelines for handling these types of requests.</p>
+<h4 id="image">Requests for permission to use an image</h4>
-<p>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.</p>
-
-<h4 id="deadlink">Fixing dead links</h4>
-<p>Please check the <a href="/server/source/linc/linc-report.html">broken
-link report</a> 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.</p>
+<p>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 <em>licensing</em>
+queue. Otherwise draw their attention to the license.</p>
-<p>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.</p>
+<p>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 <em>licensing</em>.</p>
-<h4 id="addlink">Adding links</h4>
+<p>When considering a request, err on the side of caution. If the use of
+an image isn't <a href="#pollinking">something we'd link to</a>, 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.</p>
-<p>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.</p>
-
-<p>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.</p>
-<p>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.</p>
+<h3 id="repo">Working with webmaster-related repositories</h3>
-<h4 id="addarticle">Adding new articles</h4>
-<p>Occasionally, RMS will mail an article, usually in plain text, 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:</p>
+<h4 id="cvs">Basic CVS commands</h4>
<ul>
-<li>When they exist, preserve double spaces after sentence breaks.</li>
-<li>Ensure that the article's title is put in both the
- <title> tag and in the <h2> text at the top of the page.</li>
-<li>Put the author of the article in the page's header as well.</li>
-<li>Provide a link back to the directory's main page. If it is a
- speech or an interview, briefly state the topic.</li>
-<li>New pages (and existing pages) should have a timestamp at the bottom.
- See the <a href="boilerplate.html">boilerplate</a> file for the precise
- location and format.</li>
-</ul>
-
-<h4 id="writeentry">Writing and reviewing items for /proprietary</h4>
-
-<p>
-If you plan to write or review an item for a page in <a
href="/proprietary">/proprietary</a>,
-please refer to <a href="/server/standards/proprietary-guidelines.html">these
-guidelines</a>.
-</p>
+<li>
+Before the initial checkout, set the environment variable
+<code>CVS_RSH=ssh</code>.
+</li>
-<p><a href="#announcements">Announce the page on the site.</a></p>
+<li>
+<p>Check out the main www repository:</p>
-<a id="gnupackages"></a>
-<h4>Web pages for official GNU software</h4>
+<pre class="emph-box">
+cvs -d <username>@cvs.savannah.gnu.org:/web/www co www
+</pre>
-<p>GNU software maintainers usually gain CVS write access to their
-/software subdirectory by registering their project with Savannah. (In
-the past, they provided webmasters with pages for us to install
-on the site, but that is no longer the best procedure.)</p>
+<p>You will get a working directory, <code>www</code>, with the same
+structure as our main website.</p>
+</li>
-<p>In general, package maintainers are responsible for their own
-content, and thus webmasters should not make changes to package-specific
-web pages unless we're asked to. We do have the technical permission to
-check out any GNU (or non-GNU) web repository from savannah and commit
-changes, if a maintainer asks us to, or confirms a particular
-change.</p>
-
-<h4>Translations: Adding and deleting</h4>
-
-<p>Adding: Occasionally, someone will send us a translation of a single
-page. Move these tickets to the web-translators queue.</p>
-
-<p>Deleting: 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 address@hidden on such cases). They
-might have reasons you are not aware of. In case you do not get
-<b>within two weeks</b> a satisfactory reason for the page to be left
-alone, you can handle it as you see fit.</p>
-
-<h4>Requests for permission to use an image</h4>
-
-<p>When someone emails requesting permission to use an image from the
-Art section of the site, the first thing to do is to check the web page
-that the image is on. Most of the images have a clear license on the
-page with them. If the permission being requested are reasonable but are
-incompatible with that license, forward the ticket to the licensing
-queue. Otherwise draw their attention to the license.</p>
+<li>
+<p>Check out the web repository of the fooproject:</p>
-<p>If the web page with the image on 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 forward to licensing.</p>
+<pre class="emph-box">
+cvs -d <username>@cvs.savannah.gnu.org:/web/fooproject co fooproject
+</pre>
-<p>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 with www-discuss before responding to them.</p>
+<p>You will get a working directory, <code>fooproject</code> with the same
+structure as the <code>www/software/fooproject</code> subdirectory. Note,
+however, that the fooproject and www repositories are independent. The
+working directories can be anywhere in your filesystem.</p>
+
+<p><em>Please read <a href="#gnupackages">Web pages for official GNU
+software</a> before committing anything to the web repository of a
+software project.</em></p>
+</li>
-<h4 id="pressreleases">Handling press releases</h4>
+<li>
+<p>Add a file or directory:</p>
-<p>Occasionally, the webmasters are asked to handle press releases. These
-are in the <a href="/press">/press</a> 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).</p>
-
-<p>Currently, it is often <a href="mailto:address@hidden";>johns</a> who
-handles the text version of a press release. He will normally commit
-the <acronym title="American Standard Code for Information
-Interchange">ASCII</acronym> version, and then tell webmasters to do the
-"rest" or "DTRT" (do the right thing) with it.
-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.</p>
-
-<p>At present, 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.</p>
+<pre class="emph-box">
+cvs add foo
+</pre>
+</li>
-<p>To handle one of these requests, here is what you should do:</p>
+<li>
+<p>Update before you edit a file:</p>
-<ul>
-<li>Make an HTML version of the ASCII file, following the
- format used for other press releases. Be sure to change the
- <code>META</code> tags for <code>Keywords</code> and
- <code>Description</code> to reflect the new press release. Also, make
- any URLs in the press release into actual links.
+<pre class="emph-box">
+cvs update -P foo
+</pre>
</li>
-<li>Make an entry at the top of the list on <a
- href="/press/press.html">/press/press.html</a> for the press
- release.</li>
-
-<li><a href="#polnews">Add an entry to the whatsnew page.</a></li>
-
-<li>Make the whatsnew entry a GNUs Flash (add an asterisk to the
- entry) unless the request to post the release specifically
- says <em>not</em> to put a note there.</li>
-
-<li> A release date and time "window" will be included in the request to
- post it. The <code>cvs commit</code> should <strong>only be
- done</strong> in that window. If you won't be able to do it then,
- use the <code>makepatch</code> command (it's in the makepatch
- package of Debian) to send a patch back to johns, and put URGENT in
- the subject line.</li>
-
-<li>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.</li>
-</ul>
-
+<li>
+<p>Check the changes you are going to commit:</p>
-<h3 id="repo">Working with webmaster-related repositories</h3>
+<pre class="emph-box">
+cvs diff foo
+</pre>
+</li>
-<ul>
<li>
-<p><i>Main www repository:</i>To make an initial checkout, set the
-environment variable CVS_RSH=ssh, and run</p>
+<p>Perform the commit:</p>
-<pre>
-cvs -d <username>@cvs.savannah.gnu.org:/web/www co www
+<pre class="emph-box">
+cvs commit foo
</pre>
-<p>You should end up with a directory <tt>www</tt> with the CVS checkout
-of our web site.</p>
-
-<p>CVS cheatsheet: use <tt>cvs add foo</tt> to add a file or directory.
-Use <tt>cvs update -P foo</tt> before you commit a file,
-and <tt>cvs commit foo</tt> to perform the commit. Changes
-(except to <a href="#symlinks">.symlinks files</a>) should be instantly
-visible on www.gnu.org. For further details on cvs, such as reverting
-to a previous version, or see diff output of particular changes, see the
-<a href="http://cvs.nongnu.org/";>CVS documentation</a>.</p>
+<p>This will open a text editor where you should enter a log message. The
+commit will occur upon saving the message.</p>
<p>Without being excessively verbose, log messages should describe
-as clearly as possible the nature of the commit including any related
+as clearly as possible the nature of the commit, including any related
ticket numbers from RT to allow future historians to understand why your
changes were made.</p>
<p>Whenever possible, changes to multiple files that share the same log
message should be bundled in one commit. Do not bundle multiple unrelated
changes in one commit.</p>
-</li>
-
-<li>
-<p><i>audio-video repository:</i> Use <tt>audio-video</tt> instead of
-<tt>www</tt> and you will get the repository corresponding to <a
-href="http://audio-video.gnu.org";>audio-video.gnu.org</a>. Discuss
-any changes to audio-video with address@hidden</p>
-
-<p>The task of adding material to this repository is currently being handled by
-the <a href="https://savannah.gnu.org/projects/audio-video/";>GNU and FSF
-audio and video group in Savannah</a>, so when we get a request to add a
-video or audio file, we should either submit a new task there or forward
-the request to their mailing list at
-<a href="mailto:address@hidden";><address@hidden></a>.</p>
-</li>
-
-<li>
-<p><i>Other packages:</i> Many software packages have their own projects
-on Savannah and hence their own web repository corresponding to their
-www/software/fooproject directory. If the maintainer needs your help
-with one of their web pages, you can get to it like this:</p>
-
-<pre>
-cvs -d <username>@cvs.savannah.gnu.org:/web/fooproject co fooproject
-</pre>
-<p>Do not edit the web pages for software projects unless the maintainer
-says ok. At the very least, inform them if you make a change.</p>
+<p>The changes (except to <a href="#symlinks">.symlinks files</a>) should
+be visible on www.gnu.org within minutes.</p>
</li>
</ul>
+<p>For further details on CVS, such as reverting to a previous version, or
+looking at the <code>diff</code> output of a particular change, see the <a
+href="//www.gnu.org/software/trans-coord/manual/cvs/">
+CVS documentation</a>.</p>
+
<h4 id="scripts">Scripts</h4>
@@ -1095,84 +1135,87 @@
<p>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
-<tt>www.gnu.org</tt>; mod_rewrite rules are used instead. But we'll
+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.)</p>
<p>Being a symlink means that relative links from the linked page
may break when the symlink jumps to a different directory.</p>
-<p>Special files, named .symlinks, can be committed to the CVS tree that
-are interpreted as specifications to build symbolic links. On commit,
-the current directory is searched recursively for .symlinks files. Only
-directories containing a .symlinks file are handled.</p>
-
-<p>Each symbolic link specification from the .symlinks file is honored,
+<p>Special files, named <code>.symlinks</code>, 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.</p>
-<p>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.</p>
-
-<p>The .symlinks files obey the "ln -s" format, as described below:</p>
-
-<p>Lines starting with a sharp sign ("#") are ignored.</p>
+<p>The .symlinks files obey the <code>ln -s</code> format, as described
below:</p>
-<p>Lines that do not contain two strings separated by white space are silently
-ignored.</p>
+<ul>
+<li>Lines starting with a sharp sign (“#”) are ignored.</li>
-<p>Symbolic links that point outside the web site document root are
-ignored.</p>
+<li>Lines that do not contain two strings separated by white space are silently
+ignored.</li>
+</ul>
<p>Here is an example of a .symlinks file:</p>
-<pre>
+<pre class="emph-box">
# Make a link named l.html to a target t.html.
# Strictly equivalent to ln -s t.html l.html:
t.html l.html
</pre>
<p>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 in the present directory.</p>
+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 <code>DIR.html</code> exists in the
+<code>/DIR</code> directory, and <code>index.html</code> does not exist,
+<code>/DIR/.symlinks</code> should contain a line like this:</p>
-<p>As a special case, if a file name ends in “.html”, single
-line defines links to all possible translations that follow our <a
+<pre class="emph-box">
+DIR.html index.html
+</pre>
+
+<p>The <code>ln -s</code> 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 <a
href="/server/fsf-html-style-sheet.html#NamingTranslations">naming
-conventions</a>. As a side effect, this makes it impossible to use
+conventions</a>. This makes it impossible to use
symlinks to redirect to and from HTML files whose names look like
translations, that is, <code>page.<var>LL</var>.html</code> or
<code>page.<var>LL-CC</var>.html</code>, where LL and CC are two-letter
codes. When you need such redirections, use the <a
href="#htaccess">htaccess mechanism</a>.</p>
-<p>These days, the .symlinks handling happens on <tt>www.gnu.org</tt>
+<p>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.</p>
+
<h4 id="htaccess">.htaccess and redirections</h4>
<p>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 <tt>.htaccess</tt>, or by using something like this as the
+control file <code>.htaccess</code>, or by using something like this as the
file to be redirected:</p>
-<pre>
+<p class="emph-box"><code>
<meta http-equiv="refresh" content="0;
url=http://www.gnu.org/target">
-</pre>
+</code></p>
-<h4>System administrators</h4>
+<h4 id="sysadmins">System administrators</h4>
<p>The system administrators for GNU change from time to time. Please
-email the sysadmin list (address@hidden) rather than an individual,
+email the sysadmin list <address@hidden> rather than an individual,
unless you have a specific reason to do so.</p>
+
<h3 id="readme">More README pages</h3>
<ul>
@@ -1195,20 +1238,19 @@
at www.gnu.org
</li>
<li>
- <a href="README.savannah.html">Administration Guide</a> to
- <a href="http://savannah.gnu.org/";>Savannah</a>, the
- SourceForge clone dedicated to the GNU project.
+ <a href="//savannah.gnu.org/maintenance/FrontPage/">Documentation for
+ Savannah</a>, the SourceForge clone dedicated to the GNU Project.
</li>
<li>
- Here is the <a href="/server/tasks.html">help (14k characters)</a>
+ Here is the <a href="/server/tasks.html">help</a>
we need with our <a href="/server/server.html">web server</a>
</li>
<li>
- <a
href="http://cvs.savannah.gnu.org/viewvc/gnumaint/README?root=womb&view=markup";>
- README</a> for the <tt>gnumaint</tt> directory in the <tt>womb</tt>
+ <a
href="//cvs.savannah.gnu.org/viewvc/gnumaint/README?root=womb&view=markup">
+ README</a> for the <code>/gnumaint</code> directory in the
<code>womb</code>
Savannah group. (Those files are used by <a
href="/prep/maintain/">GNU maintainer administrators</a> to update
- the */allgnupkgs.html files here in www.)
+ the <code>/*/allgnupkgs.html</code> files here in www.)
</li>
<li>
<a href="/software/trans-coord/manual/gnun/html_node/Webmaster-Tips.html">
@@ -1261,7 +1303,7 @@
<p class="unprintable">Updated:
<!-- timestamp start -->
-$Date: 2017/08/09 13:41:55 $
+$Date: 2017/09/08 06:27:58 $
<!-- timestamp end -->
</p>
</div>
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- www/server/standards README.webmastering.html,
Therese Godefroy <=