[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
www/server/standards gnu-website-guidelines.html
|
From: |
Therese Godefroy |
|
Subject: |
www/server/standards gnu-website-guidelines.html |
|
Date: |
Sun, 9 Sep 2018 06:22:42 -0400 (EDT) |
CVSROOT: /webcvs/www
Module name: www
Changes by: Therese Godefroy <th_g> 18/09/09 06:22:42
Added files:
server/standards: gnu-website-guidelines.html
Log message:
New name for fsf-html-style-sheet.html; complete overhaul;
this page is specifically for gnu.org, and is aimed at both package
maintainers and webmasters (RT #1318643).
CVSWeb URLs:
http://web.cvs.savannah.gnu.org/viewcvs/www/server/standards/gnu-website-guidelines.html?cvsroot=www&rev=1.1
Patches:
Index: gnu-website-guidelines.html
===================================================================
RCS file: gnu-website-guidelines.html
diff -N gnu-website-guidelines.html
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ gnu-website-guidelines.html 9 Sep 2018 10:22:42 -0000 1.1
@@ -0,0 +1,1031 @@
+<!--#include virtual="/server/header.html" -->
+<!-- Parent-Version: 1.84 -->
+<title>Website Guidelines - GNU Project - Free Software Foundation</title>
+<style type="text/css" media="print,screen"><!--
+ul li { margin-top: 1em; }
+--></style>
+<!--#include virtual="/server/po/fsf-html-style-sheet.translist" -->
+<!--#include virtual="/server/banner.html" -->
+<h2>GNU Website Guidelines</h2>
+
+<p>Our goal is to get information to people. Keeping the site
+design simple helps accomplish that.</p>
+
+<p>Please be considerate of all who access our web pages, and accommodate
+them, including those who use text-only browsers or old browsers, as well
+as those with slow connections. We wish to prevent HTML design that looks
+great under one version of one browser, and ugly under many others. Of
+course, please don't install any of the proprietary software browsers
+available if you don't already use them anyway.</p>
+
+
+<div class="summary">
+<h3 class="no-display">Table of Contents</h3>
+<ul>
+ <li><a href="#GeneralGuidelines">General Guidelines</a></li>
+ <li><a href="#CopyrightGuidelines">Copyright Guidelines</a></li>
+ <li><a href="#orthography">Spelling and Punctuation</a></li>
+ <li><a href="#filenames">Filenames</a></li>
+ <li><a href="#urls">URLs</a></li>
+ <li><a href="#HTMLGuidelines">HTML Guidelines</a></li>
+ <li><a href="#tables">Tables and menus</a></li>
+ <li><a href="#templating">Using our page template</a></li>
+ <li><a href="#styling">Page Styling</a></li>
+ <li><a href="#UseofGraphics">Use of Graphics</a></li>
+ <li><a href="#pollinking">Appendix 1 - Linking Policies</a></li>
+ <li><a href="#repo">Appendix 2 - Working with Web CVS Repositories</a>
+ <ul>
+ <li><a href="#cvs">Basic CVS commands</a></li>
+ <li><a href="#symlinks">Symbolic links</a></li>
+ <li><a href="#htaccess">.htaccess and redirections</a></li>
+ <li><a href="#scripts">Scripts</a></li>
+ <li><a href="#sysadmins">System administrators</a></li>
+ </ul>
+ </li>
+ <li><a href="#UsefulResources">Useful Resources</a></li>
+</ul>
+</div>
+<hr class="no-display" />
+
+
+<h3 id="GeneralGuidelines">General Guidelines</h3>
+
+
+<ul>
+<li>The GNU web server has only <a href="/philosophy/free-sw.html">free
+software</a> available. We prefer that only free software be used to
+prepare pages for the GNU web server.</li>
+
+<li>The GNU website lists and links
+<strong>only</strong> to free software. The software's source code and
+executables have to be freely redistributable and modifiable to and by
+all people and organizations. If in doubt, ask <a
+href="mailto:address@hidden";><address@hidden></a>.</li>
+
+<li>The GNU website gives priority to software covered by either
+the GNU General Public License or GNU Lesser General Public
+License.</li>
+
+<li>The GNU website is more interested in substance than style.
+The use of graphics should be minimized so pages load fast over
+slow links.</li>
+
+<li>Offer a document in as many formats as the GNU Project has it.
+For an example, see <a href="/licenses/fdl.html">The GNU Free
+Documentation License</a>. This lets users get the document in the
+format most useful to them.</li>
+
+<li>In addition to <a href="#CopyrightGuidelines">copyright and license
+notices</a>, all pages should have contact info for both the FSF (or
+responsible party) and the address for bug reports (webmasters for
+general pages, but project-specific addresses otherwise) at the bottom
+of each page. The reason to note this at the bottom is so the user
+always finds this information at the same place on each page.</li>
+
+<li>Before you take any graphics or text from another website,
+please ask for permission to use it. It's polite to do so. It is also
+essential for us to avoid copyright infringement.</li>
+
+<li>Before adding a link, check that it follows our <a
+href="#pollinking">linking criteria</a>.</li>
+
+<li>Do not list an address of an individual, including the
+maintainer of a GNU package, unless explicitly asked to have it
+listed. Most GNU maintainers do not want a lot of extra mail and prefer
+to get bug reports, etc. from the GNU bug report <a
+href="/prep/mailinglists.html">mailing lists</a>.</li>
+
+<li>On pages with dated entries (e.g., /philosophy/latest-articles.html),
+the newer entries should be first (i.e., reverse chronological order).</li>
+
+<li>Pages should not load CSS from servers other than those run
+by the FSF.</li>
+</ul>
+
+
+<h3 id="CopyrightGuidelines">Copyright Guidelines</h3>
+
+
+<ul>
+<li>Every page should have a copyright notice. See the <a
+href="//web.cvs.savannah.gnu.org/viewvc/*checkout*/www/server/standards/boilerplate.html?root=www&content-type=text%2Fplain">
+boilerplate</a>, referred below.</li>
+
+<li>Every page should have a notice giving everyone permission
+to distribute it. If you cannot get such a permission from the author,
+please discuss the issue with the webmasters before posting it. This
+applies to CSS as well as to HTML.</li>
+
+<li>Normally you shouldn't post a page that isn't copyright FSF unless
+we have permission to modify the version we publish. If you cannot
+get such a permission from the author, please discuss the issue with
+the FSF before posting it. This applies to CSS as well as to HTML.</li>
+
+<li>
+If ultimately we decide to post a new page we don't have permission to
+modify, put the text “Posted in 20XX without FSF permission to
+modify” inside an HTML comment, just after the copyright notice.</li>
+
+<li>The user of our pages should always find the copyright information
+at the same place on each page. If the page is copyrighted by some
+other person or entity, use per or its copyright notice instead of the
+FSF copyright notice. Use the rest of the FSF's normal footer
+material, except when there is a specific reason to change something
+in it.</li>
+
+<li>All pages that explain how to do something, such as how to use
+certain programs, are documentation. This includes all the pages in
+<code>/software/</code> that describe specific programs. By our
+principles, <a href="/philosophy/free-doc.html"> documentation must be
+free</a>. So these pages must carry
+a <a href="/licenses/license-recommendations.html">free
+license</a>. If such a page doesn't have a free license, please report the
+problem to <a
+href="mailto:address@hidden";><address@hidden></a>.</li>
+
+<li>For other pages, use the same license as some other page that serves
+a similar kind of purpose.</li>
+</ul>
+
+
+<h3 id="orthography">Spelling and Punctuation</h3>
+
+
+<ul>
+<li>English pages should follow the standard American spelling,
+hyphenation and punctuation conventions.</li>
+
+<li>Since these conventions are not always very specific, especially as
+regards hyphenation and quotes, gnu.org adds its own rules for the sake of
+consistency:
+ <ul>
+ <li>“Nonfree” is preferred over “non-free;”
+ likewise, “noncommercial” over “non-commercial”.</li>
+ <li>In ordinary text, HTML entities
+ “&ldquo;...&rdquo;” and
+ “&lsquo;...&rsquo;” are preferred over straight quotes
+ ("..." and '...'). This doesn't apply to script-generated documents.</li>
+ <li>Where they exist, the double spaces after sentence breaks should be
+ preserved. They enable Emacs sentence commands to do the right thing.</li>
+ </ul>
+</li>
+</ul>
+
+
+<a href="FilenameAndURLGuidelines"></a>
+<h3 id="filenames">Filenames</h3>
+
+
+<ul>
+<li>To make simultaneous edition of many files easier,
+try and give each HTML file a unique name; the filename
+<code>index.html</code> should only be used as a symbolic link, as
+explained next.</li>
+
+<li>Each directory in the web server tree should have a
+symbolic link named <code>index.html</code> to the top-level HTML file
+for that directory. Use the <a
+href="#symlinks"><code>.symlinks</code></a>
+file to handle this.</li>
+
+<li id="NamingTranslations">If you translate your web page in different
+languages, please name the English file <code>ARTICLE.html</code>, and
+its translations <code>ARTICLE.LANG.html</code>. LANG should contain the
+two-letter language code from <a
+href="https://www.loc.gov/standards/iso639-2/php/code_list.php";>ISO 639</a>,
+and optionally an hyphen followed the two-letter country code given in
+ISO 3166. For example, the German translation of <code>not-ipr.html</code>
+should be named <code>not-ipr.de.html</code>; the Brazilian Portuguese
+translation should be named <code>not-ipr.pt-br.html</code>.</li>
+</ul>
+
+
+<h3 id="urls">URLs</h3>
+
+
+<ul>
+<li>Hand-written URLs that refer to other files on www.gnu.org should be
+absolute, starting from the root page. That is, paths should start
+with <code>/</code> (e.g., <code>/gnu/about-gnu.html</code>; <em>not</em>
+<code>http://www.gnu.org/gnu/about-gnu.html</code>, and <em>not</em>
+<code>about-gnu.html</code>). This makes it easier to copy and paste
+links from other pages. Besides, links like
+<code>http://www.gnu.org/</code> will be wrong when the visitor uses
+HTTPS.</li>
+
+<li>Collections of files produced automatically from Texinfo source
+contain links with relative file names. They always refer to another
+file in the same directory. These relative links are to be
+tolerated.</li>
+
+<li>Don't use just a directory name in a URL; always include the
+specific filename. E.g., use <code>/gnu/gnu.html</code>, not just
+<code>/gnu/</code>. Never use <code>index.html</code> in a URL. Both of
+these are kindnesses to the user, as browsers change the highlighting on
+a link after it has been visited. If links to a given file use several
+different URLs, the URLs that haven't been explicitly referenced will
+not be highlighted as visited. So the user goes to pages he/she has
+already seen, which is irritating. Also, this eases maintenance of the site
+as things get moved around.</li>
+
+<li>Be sure to omit the filename entirely when linking to an anchor in
+the same file.</li>
+
+<li>Consider others linking to your page when removing an anchor or
+<code>id</code> attribute.</li>
+
+<li>Cite FTP locations of source code with the full URL of the
+directory they are in:
+<p class="emph-box"><code>
+<a
href="https://ftp.gnu.org/gnu/foo">https://ftp.gnu.org/gnu/foo</a>
+</code></p>
+which browsers display this way:<br />
+<a href="https://ftp.gnu.org/gnu/";>https://ftp.gnu.org/gnu/foo</a><br />
+
+We encourage FTP sites to use a directory for each package, and only put
+one package's files in each directory, so that the users can see what
+versions of that package and related information can be downloaded
+(e.g., a <code>README</code> file, information of what versions are
+available, documentations, fonts, etc.). Also, it means that the FTP
+location URLs do not need to be changed, on this and other sites, as new
+versions are released into that directory.</li>
+
+<li>Cite people with e-mail addresses this way:
+<p class="emph-box"><code>
+<a href="https://www.stallman.org/">Richard Stallman</a>
+<a href="mailto:address@hidden">&lt;address@hidden&gt;</a>
+</code></p>
+which browsers display this way:<br />
+<a href="https://www.stallman.org/";>Richard Stallman</a>
+<a href="mailto:address@hidden";><address@hidden></a><br />
+It is less confusing to the user, because it's clear what is a
+<code>http(s):</code> link to another web page and what is a
+<code>mailto:</code> anchor that
+will bring up a mail form to fill out and send, if this is
+supported by the client. Also, if users save a copy of the page,
+they will have a copy of the e-mail address they can use without
+going back to their web browser. If the person doesn't have a web
+page, leave the name unanchored.</li>
+</ul>
+
+
+<h3 id="HTMLGuidelines">HTML Guidelines</h3>
+
+
+<ul>
+<li>HTML on the GNU web server should be strictly compliant with
+<a href="https://www.w3.org/standards/";>W3C standards</a>.</li>
+
+<li>Please follow the above mentioned web standards strictly. Don't
+neglect <a
+href="https://www.w3.org/TR/html401/struct/global.html#h-7.1";>required
+elements</a> such as <html> <head> <title>
+<body>, etc. when using (X)HTML, and always include the
+appropriate DTD or Schema reference. This appeases overly pedantic
+browsers.</li>
+
+<li>Do not add comments at the top of a document. Web browsers
+expect the doctype, XML declaration, or Schema to be at the top.
+Comments will confuse them, and often cause them to
+incorrectly interpret your markup.</li>
+
+<li>The <head> element should contain this line:
+<p class="emph-box">
+<code><link rev="made" href="mailto:address@hidden"></code></p>
+Some browsers use this information to allow users to easily report
+problems they find on a page.</li>
+
+<li>The first header tag, <h[n]>, should have its text
+duplicated at the start of the <title> tag. The <title> tag
+is used by many browsers in menus like the history and bookmarks lists,
+as a link to that page. Repeating the main heading in the <title>
+ensures that, when
+users click on an item in these menus, they get a page with the expected
+heading. Please properly use your headers in numerical order: 1, 2,
+etc. These are not used for looks, but for the organization of the
+document.</li>
+
+<li>The <title> tag should include the phrases “GNU Project”
+and “Free Software Foundation” so the pages will be found
+when web search engines are used. The default is to add this at the
+end: <code> - GNU Project - Free Software Foundation</code>.</li>
+
+<li>Acronyms/abbreviations:
+ <ul>
+ <li>Never use <code><acronym></code>: HTML5 obsoletes it in
+ favor of <code><abbr></code>.</li>
+
+ <li>Don't use <code><abbr></code> unless for a really
+ compelling reason. Browsers render it in an ugly way.</li>
+
+ <li>When an abbreviation may be unfamiliar to a reader, give its
+ expansion the first time it is used in a document, like this:
+ <code><abbr title="Expanded
+ Abbreviation">EA</abbr></code> or <code>EA
+ (Expanded Abbreviation)</code>.</li>
+
+ <li>Further occurrences, in any case, should be written without any
+ markup: just <code>EA</code>.</li>
+
+ <li>For common-enough initialisms, such as GNU, FSF, BSD, RAM, HTML,
+ DVD, and so on and so on, no markup is needed at all.
+ Use your judgment.</li>
+ </ul>
+</li>
+</ul>
+
+
+<h3 id="tables">Tables and menus</h3>
+
+
+<ul>
+<li>Please use tables to organize data, not the presentation of the
+web page.</li>
+
+<li>Screen reader software used by most blind people reads the text
+from left to right, ignoring any tables that you make. If you use
+tables, you should make sure that reading a whole
+page left to right doesn't confuse such software. Please follow the
+<a href="https://www.w3c.org/wai";>W3C web accessibility guidelines</a>
+to ensure that tables are properly marked for accessibility.</li>
+
+<li>Some people like to organize links as a menu to
+the left or right of the main text when using graphical browsers. That
+does not work very well with text browsers since they will make the
+menu appear either on top of the page or at the bottom. If you have
+a menu that is more than 30 lines long, then it's very probable
+that a user viewing the page will never bother to read the text
+because it will be too far down. You should make an effort to keep
+such menus under 20 lines long so that the beginning of the article is
+visible on the first page when viewing it with a text browser. A
+menu bar of one or two horizontal lines might accomplish your
+purpose as well. Providing a “skip link” to the main text
+is another option.</li>
+</ul>
+
+
+<h3 id="templating">Using our page template</h3>
+
+
+<ul>
+<li>To help people follow the above guidelines, a page template (or
+“boilerplate”) is provided for both the main part of the GNU
+website, and the software projects. Its use is mandatory for new pages in
+www.gnu.org, and highly recommended for software pages. Please don't start
+out with an existing page to create a new one; use the <a
+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.</li>
+
+<li>The templated pages must be valid XHTML.</li>
+
+<li>Our server-side includes declare UTF-8 as the character encoding, so
+using any other encoding is problematic.</li>
+</ul>
+
+
+<h3 id="styling">Styling</h3>
+
+
+<h4>Styling of templated pages</h4>
+
+<ul>
+<li>Generic styling for desktops and smartphones is provided by two CSS:
+<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. A few responsive elements are defined
+in <code>/layout.css</code>. They cover most of our use cases.</li>
+
+<li>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.</li>
+
+<li>Printers use <code>/print.css</code>. Note that the header, navigation
+bars and footer (except copyright and license) are unprintable.</li>
+
+<li>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 <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.</li>
+
+<li>If you specify any color attribute in the HTML, you should specify all of
+them that are allowed for that tag. This is because some browsers
+allow users to specify defaults for the color attributes, and the
+user's choices could conflict with your choices, as your choices
+override the user's choices. In the worse case, the foreground and
+background could end up the same. Please use a stylesheet for
+this, and not HTML 3.2 (HTML 4 Transitional) deprecated
+markup.</li>
+
+<li><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="//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.</li>
+</ul>
+
+
+<h4>Other stylesheets</h4>
+
+<ul>
+<li>Historical pages (unmaintained translations for the most part) refer
+to <code>/gnu.css</code>, which in turn loads the <code>/mini.css</code>,
+as these pages are
+usually very basic, plain pages with little or no formatting.</li>
+
+<li>Some software manuals use a dedicated CSS, <code>/style.css</code>.</li>
+
+<li>Translators maintain stylesheets (<code>/style.LANG.css</code>) that
+modify layout.css according to their own needs. The RTL languages (Arabic,
+Persian, and Hebrew) use <code>/style.rtl.css</code>.</li>
+</ul>
+
+
+<h3 id="UseofGraphics">Use of Graphics</h3>
+
+
+<ul>
+<li>The use of graphics should be minimized, so pages load fast
+over slow links, especially animations.</li>
+
+<li>We do not use background images on our pages, as they make text
+significantly harder to read.</li>
+
+<li>In the past, GIFs have had patent problems. However, now that
+the IBM and Unisys patents (and other patents worldwide that are
+relevant to LZW compression) have expired, GIFs that are based on the
+87a or 89a standard are acceptable. Please be wary of proprietary
+applications that may include non-standard patented technologies (we'd
+prefer you use free software applications when authoring for our
+websites). In general, PNG or JPEG format are still safe, and are
+probably better from a technical standpoint. For details regarding the
+old GIF problem, see <a
+href="/philosophy/gif.html">https://www.gnu.org/philosophy/gif.html</a>.
+Other formats are also allowed, though JPEG is the one most widely
+recognized by web browsers (avoid JPEG 2000, and be careful with PNG
+alpha channels; the former is not widely supported, and the latter are
+not fully supported by some older browsers).</li>
+
+<li>Before you take an image from another website, please ask for
+permission to use it.</li>
+
+<li>Always have a textual alternative for in-line images, for people
+who have text-only access to the web. For instance:
+<p class="emph-box"><code><img src="/graphics/*.jpg"
+alt="&nbsp;[DESCRIPTIVE TEXT]&nbsp;"></code></p>
+We add the non-breaking spaces (&nbsp;) and square brackets to
+separate the DESCRIPTIVE TEXT from adjacent text, and help the user
+realize that this is a stand-in for an image. The point of using
+non-breaking spaces rather than normal ones is to make sure they find
+their way to the translatable strings that are extracted by the
+POA4/Gettext tools.</li>
+
+<li id="image-size">Make sure the image doesn't look too big or too small
+when displayed at its original size, using the browser's default font
+size.</li>
+
+<li>Adjust image width or height in a style attribute, using scalable
+units such as <code>em</code> or <code>%</code>; for instance:
+<p class="emph-box"><code><img src="/graphics/*.jpg"
+alt="&nbsp;[DESCRIPTIVE TEXT]&nbsp;"
+style="width: 10em" /></code></p>
+This way, the page will look the same if the reader increases or
+decreases font size.</li>
+
+<li>If you are adding a small floating image to a page that uses
+<code>layout.css</code> (the stylesheet for <a
+href="/server/standards/README.webmastering#templating">templated pages</a>),
+you may want to use the <code>imgright</code> or <code>imgleft</code> class
+(defined in the IMAGES section of the stylesheet). This will ensure that
+the floating direction is reversed if the page is translated into an RTL
+language.</li>
+
+<li>If the image you are adding is 12em wide or more, and the page is
+templated, you may find it convenient to use one of the responsive
+<code>pict</code> classes that are defined in the IMAGES section of
+<code>layout.css</code> (you can adjust the width in a style
+attribute if none of the predefined ones fits your needs); for instance:
+
+<p class="emph-box"><code><div class="pict wide"
+style="width: 25em"><img src="/graphics/*.jpg"
+alt="&nbsp;[DESCRIPTIVE TEXT]&nbsp;"
+/></div></code></p>
+
+Note that the <code>div</code> container is necessary because some browsers
(e.g.,
+NetSurf) don't know how to apply <code>max-width</code> to images.</li>
+
+<li><p>Link all images that are displayed throughout the website to the
+relevant page, usually in <code>/graphics/</code>. This can be done with
+code similar to this, which corresponds to the image on the left:</p>
+
+<p class="imgleft">
+<a href="/graphics/agnuhead.html"><img
+ src="/graphics/gnu-head-sm.jpg"
+ alt=" [Image of the Head of a GNU] "
+ style="width: 8em" />
+</a></p>
+
+<pre class="emph-box">
+<p class="imgleft">
+<a href="/graphics/agnuhead.html">
+<img src="/graphics/gnu-head-sm.jpg"
+ alt=" [Image of the Head of a GNU] "
+ style="width: 8em" />
+</a></p>
+</pre>
+<div style="clear: both"></div>
+
+This will allow users to quickly go to pages related to the pictures they
+are interested in.</li>
+</ul>
+
+
+<h3 id="pollinking">Appendix 1 - Linking Policies</h3>
+
+
+<p>One of the most complex aspects of maintaining web pages 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
+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>
+
+<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 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>
+
+<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
+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
+a difference between mentioning proprietary software and making a
+sales pitch for it. Indeed, the GNU Project website mentions
+proprietary software throughout, but never gives people the impression
+that its use does not present ethical problems.</p>
+
+<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>
+
+<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>
+
+<p>If the page requires <a href="/philosophy/javascript-trap.html">nonfree,
+nontrivial JavaScript</a> and has serious failures with
+JavaScript disabled, the link shouldn't be made. Similarly, if the page
+has embedded Flash that plays an important role, so that a person would
+be missing something important if the videos do not play, the link
+should not be made.</p>
+
+<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>
+
+<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>
+
+<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></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>
+</dd>
+
+<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 used to provide a good example of a tactful way to do it:</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 contents of other websites,
+or how up-to-date their information is.”</p>
+</dd>
+
+<dt>How does the page treat the GNU Project?</dt>
+
+<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
+and user group pages should almost never, if ever, fail to do this.
+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
+criteria. For example, suppose we were to make a link to a page on a free
+software news site. Any advertisements or reader comments attached to the
+article would not be considered when determining whether it met or linking
+guidelines, since they're understood to be the opinion of their individual
+authors. Similarly, on user group pages, the contents of forums and wiki
+pages should not hold weight in these regards.</p>
+
+<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>
+
+<p>As a final explanation (coming from RMS):
+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
+RMS. New exceptions will always come up; keep an open mind to that
+possibility and be ready to handle them properly.</p>
+</dd>
+</dl>
+
+
+<h3 id="repo">Appendix 2 - Working with Web CVS Repositories</h3>
+
+
+<h4 id="cvs">Basic CVS commands</h4>
+
+<ul>
+<li>
+Before the initial checkout, set the environment variable
+<code>CVS_RSH=ssh</code>.</li>
+
+<li>
+<p>If you have write access to www, check out the main www repository
+with your Savannah login:</p>
+
+<pre class="emph-box">
+cvs -z3 -d:ext:<username>@cvs.savannah.gnu.org:/web/www co www
+</pre>
+
+<p>You will get a working directory, <code>www</code>, with the same
+structure as our main website.</p>
+</li>
+
+<li>
+<p>If you don't have write access to www, you can still make an
+anonymous checkout of www:</p>
+
+<pre class="emph-box">
+cvs -z3 -d:pserver:address@hidden:/web/www co www
+</pre>
+</li>
+
+<li>
+<p>Check out the web repository of the fooproject:</p>
+
+<pre class="emph-box">
+cvs -z3 -d:ext:<username>@cvs.savannah.gnu.org:/web/fooproject co
fooproject
+</pre>
+
+<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>Webmasters, please read <a
+href="/server/standards/README.webmastering.html#gnupackages">Web pages for
+official GNU software</a> before committing anything to the web repository
+of a software project.</em></p>
+</li>
+
+<li>
+<p>Add a file or directory:</p>
+
+<pre class="emph-box">
+cvs add foo
+</pre>
+</li>
+
+<li>
+<p>Update before you edit a file:</p>
+
+<pre class="emph-box">
+cvs update -P foo
+</pre>
+</li>
+
+<li>
+<p>Check the changes you are going to commit:</p>
+
+<pre class="emph-box">
+cvs diff -U2 foo
+</pre>
+</li>
+
+<li>
+<p>Perform the commit (no need for <code>cvs add</code> if the file is
+already in the repository):</p>
+
+<pre class="emph-box">
+cvs commit foo
+</pre>
+
+<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
+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>
+
+<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="/software/trans-coord/manual/cvs/">CVS documentation</a>.</p>
+
+
+<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
+links, as follows. (Actual symbolic links are no longer created on
+www.gnu.org; mod_rewrite rules are used instead. But we'll
+keep this discussion talking about symlinks since it is easier to
+understand that way.)</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 <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>The .symlinks files obey the <code>ln -s</code> format, as described
below:</p>
+
+<ul>
+<li>Lines starting with a sharp sign (“#”) are ignored.</li>
+
+<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 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 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>
+
+<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>. 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 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 <code>.htaccess</code>, or by using something like this as the
+file to be redirected:</p>
+
+<p class="emph-box"><code>
+<meta http-equiv="refresh" content="0;
+ url=http://www.gnu.org/target">
+</code></p>
+
+
+<h4 id="scripts">Scripts</h4>
+
+<p>A <a href="/server/source/source.html">description of scripts and
+software</a> used on www.gnu.org is available. Please read it before
+writing any scripts, and also update it as needed if you have write
+access to www.</p>
+
+
+<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,
+unless you have a specific reason to do so.</p>
+
+
+<h3 id="UsefulResources">Useful Resources</h3>
+
+
+<ul>
+<li>Outside gnu.org:
+ <ul>
+ <li>We follow the guidelines of the <a
+ href="https://www.anybrowser.org/campaign/";>Best Viewed with Any
+ Browser</a> campaign.</li>
+
+ <li>Basic info on the web and its technical specifications can be
+ found at <a href="https://www.w3.org/";>The World Wide Web
+ Consortium</a>.</li>
+
+ <li>Use of the <a
+ href="https://www.cs.tcd.ie/15445/UG.HTML";>ISO</a> standard for the
+ <a href="https://www.w3.org/MarkUp/";>Hypertext Markup Language
+ (HTML)</a> allows for consistent backwards compatibility among web
+ user agents.</li>
+
+ <li>The GNU web server follows the w3.org <a
+ href="https://www.w3.org/Provider/Style/Overview.html";>Style
+ Guide</a>.</li>
+ </ul>
+</li>
+
+<li>On gnu.org:
+ <ul>
+ <li><a href="/server/standards/gnu-website-guidelines.html">The
+ GNU Website Guidelines</a>;</li>
+
+ <li>Guidelines for
+ <a href="/server/standards/README.editors.html">Web Page Creation</a> at
+ www.gnu.org;</li>
+
+ <li><a href="/software/texinfo/manual/texinfo/html_node/Tips.html">
+ Appendix B Tips and Hints</a>, and other style tips in the <a
+ href="/software/texinfo/manual/texinfo/">Texinfo Manual</a>;</li>
+
+ <li><a href="/accessibility/accessibility.html">GNU Accessibility
+ Statement</a>;</li>
+
+ <li><a href="/server/standards/README.webmastering.html">GNU
+ Webmastering Guidelines;</a></li>
+
+ <li>Guide to
+ <a href="/server/standards/README.translations.html">translating</a> GNU
+ web pages into other languages;</li>
+
+ <li><a
href="/software/trans-coord/manual/gnun/html_node/Webmaster-Tips.html">
+ Tips for webmasters</a> to make translators' job easier;</li>
+
+ <li><a href="//savannah.gnu.org/maintenance/FrontPage/">Documentation for
+ Savannah</a>, the SourceForge clone dedicated to the GNU Project;</li>
+
+ <li><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 <code>/*/allgnupkgs.html</code> files in www);</li>
+
+ <li>Here is the <a href="/server/tasks.html">help</a> we need with our
+ <a href="/server/server.html">web server</a>.</li>
+ </ul>
+</li>
+</ul>
+
+</div><!-- for id="content", starts in the include above -->
+<!--#include virtual="/server/footer.html" -->
+<div id="footer">
+<div class="unprintable">
+
+<p>Please send general FSF & GNU inquiries to
+<a href="mailto:address@hidden";><address@hidden></a>.
+There are also <a href="/contact/">other ways to contact</a>
+the FSF. Broken links and other corrections or suggestions can be sent
+to <a href="mailto:address@hidden";><address@hidden></a>.</p>
+
+<p><!-- TRANSLATORS: Ignore the original text in this paragraph,
+ replace it with the translation of these two:
+
+ We work hard and do our best to provide accurate, good quality
+ translations. However, we are not exempt from imperfection.
+ Please send your comments and general suggestions in this regard
+ to <a href="mailto:address@hidden";>
+ <address@hidden></a>.</p>
+
+ <p>For information on coordinating and submitting translations of
+ our web pages, see <a
+ href="/server/standards/README.translations.html">Translations
+ README</a>. -->
+Please see the <a
+href="/server/standards/README.translations.html">Translations
+README</a> for information on coordinating and submitting translations
+of this article.</p>
+</div>
+
+<!-- Regarding copyright, in general, standalone pages (as opposed to
+ files generated as part of manuals) on the GNU web server should
+ be under CC BY-ND 4.0. Please do NOT change or remove this
+ without talking with the webmasters or licensing team first.
+ Please make sure the copyright date is consistent with the
+ document. For web pages, it is ok to list just the latest year the
+ document was modified, or published.
+
+ If you wish to list earlier years, that is ok too.
+ Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
+ years, as long as each year in the range is in fact a copyrightable
+ year, i.e., a year in which the document was published (including
+ being publicly visible on the web or in a revision control system).
+
+ There is more detail about copyright years in the GNU Maintainers
+ Information document, www.gnu.org/prep/maintain. -->
+
+<p>Copyright © 2010, 2013, 2014, 2015, 2016, 2017, 2018 Free Software
+Foundation, Inc.</p>
+
+<p>This page is licensed under a <a rel="license"
+href="http://creativecommons.org/licenses/by-nd/4.0/";>Creative
+Commons Attribution-NoDerivatives 4.0 International License</a>.</p>
+
+<!--#include virtual="/server/bottom-notes.html" -->
+
+<p class="unprintable">Updated:
+<!-- timestamp start -->
+$Date: 2018/09/09 10:22:42 $
+<!-- timestamp end --></p>
+</div>
+</div>
+</body>
+</html>
- www/server/standards gnu-website-guidelines.html,
Therese Godefroy <=