CVSROOT: /web/www
Module name: www
Changes by: Karl Berry <karl> 10/10/04 21:33:04
Modified files:
server/standards: README.webmastering.html
Log message:
add toc, semi-regularize <p> tagging
CVSWeb URLs:
http://web.cvs.savannah.gnu.org/viewcvs/www/server/standards/README.webmastering.html?cvsroot=www&r1=1.107&r2=1.108
Patches:
Index: README.webmastering.html
===================================================================
RCS file: /web/www/www/server/standards/README.webmastering.html,v
retrieving revision 1.107
retrieving revision 1.108
diff -u -b -r1.107 -r1.108
--- README.webmastering.html 4 Oct 2010 21:18:36 -0000 1.107
+++ README.webmastering.html 4 Oct 2010 21:33:01 -0000 1.108
@@ -32,7 +32,23 @@
href="mailto:chief-webmas...@gnu.org";><chief-webmas...@gnu.org></a>.</p>
-<h3>Working as a www.gnu.org webmaster</h3>
+<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">Site structure</a> -
+<a href="#announcements">Announcements</a> -
+<a href="#pollinking">Linking policies</a> -
+<a href="#mirrors">Mirrors</a> -
+<a href="#commonreq">Handling common requests</a> -
+<a href="#repo">Working with our repositories</a>.
+
+<p>By the way, please edit and improve this document!
+
+<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
@@ -87,113 +103,45 @@
Please inform the www-discuss list if you take a task.</li>
</ul>
-<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 summary of what you
-found on the page back to the webmasters list (but not to the requester!),
-and ask someone else to take it from there.
-</p>
-
-<p>
-We do not have links to web sites of the well-known GNU/Linux
-system distributions, or to the well-known BSD system
-distributions, because all those sites explicitly describe, and
-facilitate access to, various non-free programs.
-</p>
-
-<p>
-Sometimes you might be tempted to rearrange the hierarchy
-or change the formatting and layout.
-Before doing so you should consult the www-discuss list.
-the chief webmaster.
-</p>
-
-
-<h3>Handling press releases</h3>
-
-<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:jo...@gnu.org";>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>
-
-<p>To handle one of these requests, here is what you should do:</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.
-</li>
+<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
+summary of what you found on the page back to the webmasters list (but
+not to the requester!), and ask someone else to take it from there.</p>
+
+<p>We do not have links to web sites of the well-known GNU/Linux system
+distributions, or to the well-known BSD system distributions, because
+all those sites explicitly describe, and facilitate access to, various
+non-free programs.</p>
+
+<p>Sometimes you might be tempted to rearrange the hierarchy or change
+the formatting and layout. Before doing so you should consult the
+www-discuss list. the chief webmaster.</p>
-<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>
+<h4>Webmaster organization</h4>
-<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>
-
-
-<h3>Webmaster organization</h3>
-
-<p>
-The following organizational rules are not rigid; they are designed to
+<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
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.
-</p>
+these policies.</p>
-<p>
-The GNU Webmaster Group is led by the Chief Webmaster <a
+<p>The GNU Webmaster Group is led by the Chief Webmaster <a
href="mailto:chief-webmas...@gnu.org";><chief-webmas...@gnu.org></a>.
You can always find out the identity of the Chief Webmaster by looking at
-the aliases file on the GNU mail server.
-</p>
+the aliases file on the GNU mail server.</p>
-<p>
-The Chief Webmaster is responsible for making sure that every message sent
+<p>The Chief Webmaster is responsible for making sure that every message sent
to webmasters <a href="mailto:webmast...@gnu.org";><webmast...@gnu.org>
</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
-doing her best to correct mishandled webmaster email, when necessary.
-</p>
+doing her best to correct mishandled webmaster email, when necessary.</p>
-<p>
-If it isn't clear to the webmasters how to handle a particular issue, the
+<p>If it isn't clear to the webmasters how to handle a particular issue, the
message should be sent to <a href="mailto:webmaster-escal...@gnu.org";>
<webmaster-escal...@gnu.org></a>. Replies from
<webmaster-escal...@gnu.org> are typically sent back to the
@@ -202,24 +150,19 @@
future. It's also useful to cc the whole webmasters list on message
to <webmaster-escal...@gnu.org>, so the other webmasters know
the message has been escalated and that they should wait for a
-response.
-</p>
+response.</p>
-<p>
-Mail to <webmaster-escal...@gnu.org> is usually answered in a week
+<p>Mail to <webmaster-escal...@gnu.org> is usually answered in a week
or so, at worst. If anyone notices a message sent there has been pending
for longer, please do send a message to <webmaster-escal...@gnu.org>
-checking on the status.
-</p>
+checking on the status.</p>
-<h3>Leaving webmasters</h3>
+<h4>Leaving webmasters</h4>
-<p>
-We realize that people's lives change, and we know that you may not want
+<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
-us know when you want to move on: please don't simply disappear.
-</p>
+us know when you want to move on: please don't simply disappear.</p>
<p>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
@@ -231,9 +174,7 @@
changes.</p>
-
-<a name="rt"></a>
-<h3>Using RT</h3>
+<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
@@ -328,20 +269,15 @@
<h4>RT - correspondence vs. comments</h4>
-<p>
-You can attach two kinds of information to a ticket: correspondence and
-comments.
-</p>
+<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>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.
-</p>
+it's finished, and so on.</p>
-<p>
-Comments are only seen by the ticket staff: the owner and people listed
+<p>Comments are only seen by the ticket staff: the owner and people listed
as AdminCCs. You can use comments to make internal notes about ticket
work. For instance, if you do some work on converting an essay of RMS's to
HTML, but didn't get a chance to finish yet, you could add a comment saying
@@ -349,80 +285,59 @@
(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>
+comments, however.</p>
-<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>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
-send mail to <webmast...@gnu.org> with
-</p>
+<p>To add correspondence, use one of the "reply" links on the ticket page, or
+send mail to <webmast...@gnu.org> with</p>
<pre>
[gnu.org #1234]
</pre>
-<p>
-in the subject line, where 1234 is the ticket number.
-</p>
+<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
-mail to <webmasters-comm...@gnu.org> with
-</p>
+<p>To add comments, use one of the "comment" links on the ticket page, or send
+mail to <webmasters-comm...@gnu.org> with</p>
<pre>
[gnu.org #1234]
</pre>
-<p>
-in the subject line, where 1234 is the ticket number.
-</p>
+<p>in the subject line, where 1234 is the ticket number.</p>
-<p>
-There is no way to make other modifications except through the
+<p>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.
-</p>
+format. Please check with www-discuss for these.</p>
<h4>RT - coordination with others</h4>
-<p>
-You will often need to ask other people for more information about how to
+<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
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.
-</p>
+mail a comment to the ticket as well.</p>
-<p>
-So, say for example that you wanted to ask the chief webmaster whether
+<p>So, say for example that you wanted to ask the chief webmaster whether
a certain link on a page was permissible. You can do this by using
one of the "comments" links on the ticket page, and listing the other
party (in this case, <chief-webmas...@gnu.org>) as a CC:. You
-could also do this by sending a mail with headers like this:
-</p>
+could also do this by sending a mail with headers like this:</p>
<pre>
To: <chief-webmas...@gnu.org>, <webmasters-comm...@gnu.org>
Subject: [gnu.org #1234] Question about link policy
</pre>
-<p>
-1234 should be the appropriate ticket number.
-</p>
+<p>1234 should be the appropriate ticket number.</p>
-<p>
-The former method is more foolproof: RT will change the outgoing mail so
+<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 e-mail, however.</p>
<h4>RT - ticket status</h4>
@@ -565,34 +480,23 @@
webmasters get several hundred spams every day.</p>
-<!-- Some of the following information is redundant. If you find it above -->
-<!-- or in the style guidelines, feel free to edit out the -->
-<!-- appropriate portion, or combine it with the guidelines section. -->
+<h3 id="structure">Site structure and navigation</h3>
+<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. This page is the main page for this section of the
+site, and so should provide access to all the material within that
+directory.</p>
-<h3>Inter-site structure and navigation</h3>
-
-<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. This page
-is the main page for this section of the site, and so should provide access
-to all the material within that directory.
-</p>
-
-<p>
-In turn, every other page in the directory should link back to this main
-page, to allow people to get more information about a given topic.
-</p>
+<p>In turn, every other page in the directory should link back to this
+main page, to allow people to get more information about a given topic.</p>
-<p>
-Links should include a full path, if possible. For example, within a
+<p>Links should include a full path, if possible. For example, within a
specific article in the philosophy section, link to
-/philosophy/philosophy.html, rather than just philosophy.html. This eases
-maintenance of the site as things get moved around. Omitting the host also
-allows our site to work well on mirrors.
-</p>
+/philosophy/philosophy.html, rather than just philosophy.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
@@ -602,18 +506,17 @@
present, our pages should do an include of
<tt></server/banner.html></tt>, as shown in
<tt></server/standards/boilerplate.html></tt>. This reads
-<tt>/style.css</tt>, which in turn reads
-<tt>/combo.css (Yahoo's User Interface CSS for <a
+<tt>/style.css</tt>, which in turn reads <tt>/combo.css (Yahoo's User
+Interface CSS for <a
href="http://developer.yahoo.com/yui/reset/";>reset</a>, <a
href="http://developer.yahoo.com/yui/grids/";>grids</a>, <a
href="http://developer.yahoo.com/yui/fonts/";>fonts</a> and <a
href="http://developer.yahoo.com/yui/base/";>base</a></tt> plus
-<tt>/layout.css</tt>, which contains gnu.org specific CSS
-formatting. In addition, users of mobile devices (cellphones, music
-players, etc) are sent to <tt>/mini.css</tt>
-instead. This stylesheet is just the YUI reset and base stylesheets,
-as mobile devices typically have minimal need for various fonts and no
-need for fancy layouts.</p>
+<tt>/layout.css</tt>, which contains gnu.org specific CSS formatting. In
+addition, users of mobile devices (cellphones, music players, etc) are
+sent to <tt>/mini.css</tt> instead. This stylesheet is just the YUI
+reset and base stylesheets, as mobile devices typically have minimal
+need for various fonts and no need for fancy layouts.</p>
<p>Historical pages refer to <tt>/gnu.css</tt> which also loads the
mobile CSS, as these pages are usually very basic, plain pages with
@@ -731,28 +634,23 @@
<h3 id="pollinking">Linking policies</h3>
-<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>
+<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>
-<p>
-We strive to ensure that all pages we promote—all pages which are given
+<p>We strive to ensure that all pages we promote—all pages which are
given
links on our site—are friendly to the free software movement. Some
pages will obviously not meet such standards; if the site flames the Free
Software Foundation, or has no apparent relation to free software and
surrounding issues, the link shouldn't be made. Beyond that, however,
there are criteria used in determining whether or not it is appropriate to
provide a link to a page from ours. They are listed below, in order of
-descending general importance.
-</p>
+descending general importance.</p>
<ul>
<li>What's the context of the link?</li>
</ul>
-<p>
-The link's purpose on our site will play a role in determining how
+<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,
@@ -761,156 +659,124 @@
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>
+aspect of these policies.</p>
<ul>
<li>Does the page promote proprietary software?</li>
</ul>
-<p>
-The big point made by the free software movement is that proprietary
+<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
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>
+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
proprietary software throughout, but never gives people the impression
-that its use does not present ethical problems.
-</p>
+that its use does not present ethical problems.</p>
-<p>
-There are two things to keep in mind when determining whether a
+<p>There are two things to keep in mind when determining whether a
reference to proprietary software promotes it, or simply mentions
it. First, how much information does it offer about the software?
Second, how much information is the reader likely to actually gain
-from this page?
-</p>
+from this page?</p>
-<p>
-Different pages provide different amounts of information about
+<p>Different pages provide different amounts of information about
proprietary software; the more it provides, the more of a problem
it poses for us. For example, some pages may link to the primary
site for a proprietary software program. Others may describe its
functionality in detail. Even the product name given matters;
there's a difference between "Windows" and "Microsoft Windows XP
-Home Edition."
-</p>
+Home Edition."</p>
-<p>
-The subject of the reference will also play a role in determining
+<p>The subject of the reference will also play a role in determining
how problematic a reference is. If the software is already very
popular, it's unlikely that a basic mention of it will be news to
the reader. Some examples of proprietary software which are common
enough to be considered "well-known" are major operating systems
(Windows, Mac OS, Sun OS, HP-UX) and primary common applications
such as Office, Internet Explorer, Photoshop, Acrobat Reader, and
-Flash.
-</p>
+Flash.</p>
-<p>
-GNU software project pages feel the full force of this policy.
+<p>GNU software project pages feel the full force of this policy.
Proprietary software should only be mentioned when the software
provides support for it, or to compare it against the features of
well-known proprietary software. For example, the following
-text—and not much else—would be acceptable:
-</p>
+text—and not much else—would be acceptable:</p>
-<p>
-w3 is a web browser for GNU Emacs, similar to Internet Explorer.
+<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>
-<p>
-Links which appear in other areas, such as the testimonials or
+<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>
<ul>
<li>How does the page compare free software to open source?</li>
</ul>
-<p>
-Almost all pages which have links on our site should, at the very
+<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>
-<p>
-GNOME is part of the GNU project, and is free software (sometimes
-referred to as open source software).
-</p>
+<p>GNOME is part of the GNU project, and is free software (sometimes
+referred to as open source software).</p>
-<p>
-Any exceptions to this rule should be apparent from the context.
+<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>
+or how up-to-date their information is."</p>
<ul>
<li>How does the page treat the GNU project?</li>
</ul>
-<p>
-Pages which we link to should treat the GNU project well. The
+<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
and user group pages should almost never, if ever, fail to do this.
-Again, exceptions for other pages should be apparent from context.
-</p>
+Again, exceptions for other pages should be apparent from context.</p>
-<p>
-That said, certain parts of a page should not be considered against these
+<p>That said, certain parts of a page should not be considered against these
criteria. For example, suppose we were to make a link to a page on a free
software news site. Any advertisements or reader comments attached to the
article would not be considered when determining whether it met or linking
guidelines, since they're understood to be the opinion of their individual
authors. Similarly, on user group pages, the content of forums and Wiki
-pages should not hold weight in these regards.
-</p>
+pages should not hold weight in these regards.</p>
-<p>
-Finally, some sites are understood to always have exception with most of
+<p>Finally, some sites are understood to always have exception with most of
these guidelines. These sites are usually about issues which are
important, but somewhat peripheral, to the free software movement. Several
times we have linked to the Electronic Frontier Foundation's site, even
though they encourage the use of Flash and talked exclusively about open
source software. It's generally understood that since these pages are not
primarily about free software, the policies do not hold full force for
-them.
-</p>
+them.</p>
-<p>
-As a final explanation (coming from RMS):
+<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>
+promote any non-free software.</p>
-<p>
-If all this seems complicated, that's because, unfortunately, it is. Don't
+<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
RMS. New exceptions will always come up; keep an open mind to that
-possibility and be ready to handle them properly.
-</p>
+possibility and be ready to handle them properly.</p>
<a id="distros"></a>
@@ -983,69 +849,56 @@
lack information for many older mirrors.</p>
-<h3>Handling common requests</h3>
+<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>
+<p>There are a number of requests which recur frequently. This section
+documents guidelines for handling these types of requests.</p>
-<p>
-Those requests which are extremely straightforward—for example, fixing
+<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>
+here. Only requests which may require non-obvious action are listed.</p>
<h4>Fixing dead links</h4>
-<p>
-If a link has gone bad because a page has moved, try to find its
+<p>If a link has gone bad because a page has moved, try to find its
replacement. If you are successful, re-check the page to ensure that it
meets our linking criteria, and if so, add it. If you do not find a
-replacement, remove the link—if it's central to the page, you may need
-to make a note explaining that the resource is no longer available. If the
-page no longer meets our linking criteria, you'll have to make a judgment
-call, and weigh the value of the link against its problems'; you may want
-to mail the person who wrote the page with the link to get a second
-opinion.
-</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>
+replacement, remove the link—if it's central to the page, you may
+need to make a note explaining that the resource is no longer available.
+If the page no longer meets our linking criteria, you'll have to make a
+judgment call, and weigh the value of the link against its problems';
+you may want to mail the person who wrote the page with the link to get
+a second opinion.</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>Adding links</h4>
-<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>
+<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>
<h4>Adding new articles</h4>
@@ -1071,7 +924,6 @@
<p><a href="#announcements">Announce the page on the site.</a></p>
-
<a id="gnupackages"></a>
<h4>Web pages for official GNU software</h4>
@@ -1087,26 +939,21 @@
changes, if a maintainer asks us to, or confirms a particular
change.</p>
+<h4>Translations: Adding and deleting</h4>
-<h4>Adding translations</h4>
-
-<p>
-Occasionally, someone will send us a translation of a single page. You
-can put these in place; all you need to do is upload it and add a link from
-the main (English) page to it. Be sure to write them back thanking them
-for the page, and encourage them to get in touch with a translation team if
-they'd like to help more. Refer them to
+<p>Adding: Occasionally, someone will send us a translation of a single
+page. You can put these in place; all you need to do is upload it and
+add a link from the main (English) page to it. Be sure to write them
+back thanking them for the page, and encourage them to get in touch with
+a translation team if they'd like to help more. Refer them to
http://www.gnu.org/server/standards/README.translations.html; a list of
-translation teams is available there as well.
-</p>
-
-<h4>Deleting translations</h4>
+translation teams is available there as well.</p>
-<p>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
+<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 web-translat...@gnu.org 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
@@ -1131,8 +978,61 @@
something we should give permission for. Feel free to discuss any
requests with www-discuss before responding to them.</p>
+<h4 id="pressreleases">Handling press releases</h4>
+
+<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:jo...@gnu.org";>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>
+
+<p>To handle one of these requests, here is what you should do:</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.
+</li>
-<h3>Working with webmaster-related repositories</h3>
+<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>
+
+
+<h3 id="repo">Working with webmaster-related repositories</h3>
<p><i>Main www repository:</i>To make an initial checkout, set the
environment variable CVS_RSH=ssh, and run</p>
@@ -1172,7 +1072,6 @@
<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>
-
<h4><a id="scripts">Scripts</a></h4>
<p>A <a href="/server/source/source.html">description of scripts and
@@ -1180,8 +1079,7 @@
writing any scripts, and also update it as needed.</p>
-<a id="symlinks"></a>
-<h4>Symbolic links</h4>
+<h4 id="symlinks">Symbolic links</h4>
<p>Since CVS is not able to handle symbolic links directly, a separate
mechanism has been implemented to allow webmasters to maintain symbolic
@@ -1280,7 +1178,7 @@
<p>Updated:
<!-- timestamp start -->
-$Date: 2010/10/04 21:18:36 $
+$Date: 2010/10/04 21:33:01 $
<!-- timestamp end -->
</p>
</div>
