r1005 - html/trunk/hints

justin at linuxfromscratch.org justin at linuxfromscratch.org
Sun Jun 12 15:24:30 PDT 2005


Author: justin
Date: 2005-06-12 16:24:28 -0600 (Sun, 12 Jun 2005)
New Revision: 1005

Modified:
   html/trunk/hints/submit.html
Log:
[www] Corrected spelling mistakes in hints submission guide.

Modified: html/trunk/hints/submit.html
===================================================================
--- html/trunk/hints/submit.html	2005-06-12 03:58:10 UTC (rev 1004)
+++ html/trunk/hints/submit.html	2005-06-12 22:24:28 UTC (rev 1005)
@@ -49,7 +49,7 @@
 	<em><a href="#projectnav" class="hidden">Skip to subproject-navigation</a></em>
 	<em><a href="#generalnav" class="hidden">Skip to sitewide navigation</a></em>
 
-<h2>Hint style and submisson guide</h2>
+<h2>Hint style and submission guide</h2>
 <h3 id="howtowrite">How to write a hint</h3>
 	<p>A good hint provides information which is not otherwise easily obtainable. In general, we're not interested in hints which copy information already in LFS or BLFS and hints which simply list the steps needed for installing a package as explained in the INSTALL or README of a package.</p>
 	<p>This still leaves a broad scope of subjects. Hints can be about anything for which a non-obvious or non-trivial fix or hack is required. A hint can also explain a complicated package installation or a particular setup. Have a look at some <a href="list.html">other hints</a> to get an idea of what a hint may include. Also check out the <a href="adoptahint.html">Adopt a hint program</a> in case there is some cute little hint that you would like to nurture or if someone has suggested a topic for a hint.</p>
@@ -57,17 +57,17 @@
 
 <h3 id="submit">Submission guidelines</h3>
 <ul>
-	<li>Before submitting a hint, check if there is an already existing hint on the topic. If there is then contact the author if you have any updates. If the previous author is not interested in maintaining the hint, or if there is no response from the author for at least a month, then you may take over maintainence of the hint. Remember to CC hints-owner@linuxfromscratch.org  regarding all correspondence with the author so that the hint maintainers are aware of the changeover.<br />
+	<li>Before submitting a hint, check if there is an already existing hint on the topic. If there is then contact the author if you have any updates. If the previous author is not interested in maintaining the hint, or if there is no response from the author for at least a month, then you may take over maintainance of the hint. Remember to CC hints-owner@linuxfromscratch.org  regarding all correspondence with the author so that the hint maintainers are aware of the changeover.<br />
 		<em>Note that this does not mean that duplicate hints on the same topic are not allowed. If you feel that the current author has a different approach to a problem and you have one which does not match the current hint, feel free to submit a separate hint. We suggest communicating with the current author(s) before writing the hint. We suggest writing a short blurb on how the new hint differs from the existing one.</em></li>
-	<li>Hints should be reserved for things that cannot be included into the book. Hints that relate to installation of packages and which would easily fit into the book (usually the BLFS book) should be submitted to the relevant development list.  If you are conversant with docbook and XML, then feel free to submit a patch to the current CVS Book version. If not, submit a text file matching the current format of the book and a book editor will do the neccessary modifications. </li>
+	<li>Hints should be reserved for things that cannot be included into the book. Hints that relate to installation of packages and which would easily fit into the book (usually the BLFS book) should be submitted to the relevant development list.  If you are conversant with docbook and XML, then feel free to submit a patch to the current CVS Book version. If not, submit a text file matching the current format of the book and a book editor will do the necessary modifications. </li>
 	<li>If you are in the process of writing a hint on a topic, it would be good to drop a line to the relevant list in case someone else is working on something similar.</li>
 	<li>A hint should not duplicate documentation that is already available elsewhere on a particular topic, it should complement it. Documentation available elsewhere includes <a href="http://www.tldp.org/">LDP documentation</a>, documentation available from the package website, documentation available by a simple <a href="http://www.google.com">google</a> search. Also, things that are already well documented in the book(s) or at the LDP should not be repeated in the hint unless the hint describes matters in more detail, in a different way, or from a different perspective. So things such as installation of db, freetype, zlib, etc can just be referenced by pointers to the book. </li>
 	<li>Authors who are not interested in maintaining their hints any more should send a message to the hints mailing list specifying that the hint is <a href="adoptahint.html">up for adoption</a>. The author should also notify the hints list if the hint is not relevant anymore.</li>
 	<li>Hints that have been integrated into the book will be retired after a stable version of the book is released.</li>
 	<li>Keep the file name of the hint short, but descriptive. The extension for the hint should be .txt. The name may be composed of a combination of lowercase letters, numbers, and a few symbols <code>_</code> <code>-</code> <code>+</code>.</li>
 	<li>The hint document is text based. The format for the hints is as explained at the end of this document.</li>
-	<li>Avoid including scripts and patches in the hints. Keep these as separate files to avoid spoiling the beauty of the hint:) Patches should follow the <a href="http://patches.linuxfromscratch.org">patches format</a>. The patches that you submit will be comitted to the patches repository (so be sure to mention the hint in the patch description) under the appropriate package name. The scripts or patches that don't fit into the patches project will be available from the <a href="downloads/attachments">Attachments</a> link in the left menu. If you need to reference any patches in your hint, point to the patches subproject (e.g. http://www.linuxfromscratch.org/patches/<package_name>/<patch_name>). If you need to reference to any attachments, point to the attachments directory (e.g. http://www.linuxfromscratch.org/hints/downloads/attachments/<hint_name>/) Don't worry if the URIs are incorrect, the maintainer will modify the URIs before submitting. Since maintainers are sometimes lazy, you may need to give them a bit of a push/shove to "do the right thing".</li>
-	<li>To submit or update a hint, send an e-mail to the <a href="http://linuxfromscratch.org/mailman/listinfo/hints" title="Archive and subscription information for the hints mailinglist">hint mailing list</a>. From there it will be picked up by the hint maintainer, who will update the hint index and the tarball. To check if your hint has already been included, you can <a href="http://linuxfromscratch.org/mailman/listinfo/hints">subscribe</a> to the hints mailinglist and check for the CVS commit message. Keep the hints list solely for <strong>submitting hints and updates to hints</strong>.</li>
+	<li>Avoid including scripts and patches in the hints. Keep these as separate files to avoid spoiling the beauty of the hint:) Patches should follow the <a href="http://patches.linuxfromscratch.org">patches format</a>. The patches that you submit will be committed to the patches repository (so be sure to mention the hint in the patch description) under the appropriate package name. The scripts or patches that don't fit into the patches project will be available from the <a href="downloads/attachments">Attachments</a> link in the left menu. If you need to reference any patches in your hint, point to the patches subproject (e.g. http://www.linuxfromscratch.org/patches/<package_name>/<patch_name>). If you need to reference to any attachments, point to the attachments directory (e.g. http://www.linuxfromscratch.org/hints/downloads/attachments/<hint_name>/) Don't worry if the URIs are incorrect, the maintainer will modify the URIs before submitting. Since maintainers are sometimes lazy, you may need to give them a bit of a push/shove to "do the right thing".</li>
+	<li>To submit or update a hint, send an e-mail to the <a href="http://linuxfromscratch.org/mailman/listinfo/hints" title="Archive and subscription information for the hints mailing list">hint mailing list</a>. From there it will be picked up by the hint maintainer, who will update the hint index and the tarball. To check if your hint has already been included, you can <a href="http://linuxfromscratch.org/mailman/listinfo/hints">subscribe</a> to the hints mailinglist and check for the CVS commit message. Keep the hints list solely for <strong>submitting hints and updates to hints</strong>.</li>
 	<li><strong>Note that by submitting a hint, you agree to the conditions mentioned on this page with respect to the hint. In particular, you allow other users to take over the maintainership of the hint if another user contacts you with a request (for taking over the maintainership or integrating his/her work in your hint) and you fail to respond to the request for a month. If you would not like someone to take over the maintainership of the hint, please state so clearly in the hint. Authors should also keep the contact information updated.</strong></li>
 </ul>
 
@@ -86,19 +86,19 @@
 		<dt>SYNOPSIS:</dt>
 			<dd>A one line description about the hint. Please keep this short and sweet and restrict it to a single line since this is the title that would be included on the hints page.</dd>
 		<dt>PRIMARY URI:</dt>
-			<dd>This is an optional section for authors who like to host their own hints and only submit ocassional updates to the official hints site.</dd>
+			<dd>This is an optional section for authors who like to host their own hints and only submit occasional updates to the official hints site.</dd>
 		<dt>DESCRIPTION:</dt>
 			<dd>A short description on why the hint was written, who is the target audience, etc. This would help a user in determining whether the hint is useful for her/him.</dd>
 		<dt>ATTACHMENTS:</dt>
 			<dd>Links to additional downloads such as patches, scripts, config files, etc. This section is optional.</dd>
 		<dt>PREREQUISITES:</dt>
-			<dd>In this section list the pre-requsites that the user needs to be aware of before following the hint. This section can be used to indicate if the hint is applicable only for a particular LFS version.</dd>
+			<dd>In this section list the pre-requisites that the user needs to be aware of before following the hint. This section can be used to indicate if the hint is applicable only for a particular LFS version.</dd>
 		<dt>HINT:</dt>
 			<dd>This is the heart of the hint. List the details about your hint here. There is no restriction on how you format things in this section, except (there is always some exception) to avoid lines that look like a section (i.e. Text in all UPPERCASE followed by a semi-colon). Also, make your best effort to restrict each line to 80 columns (though this can be relaxed on case-by-case basis). Avoid including material that is already in the book.</dd>
 		<dt>ACKNOWLEDGEMENTS:</dt>
 			<dd>Acknowledgements for people who have contributed to the hint. This section is optional.</dd>
 		<dt>CHANGELOG:</dt>
-			<dd>Include timestamped changes that have occured in the hint. Add latest entries at the end. Entries in this section should be as follows:<br />
+			<dd>Include timestamped changes that have occurred in the hint. Add latest entries at the end. Entries in this section should be as follows:<br />
 			<ul class="code">
 				<li>[YYYY-MM-DD]</li>
 				<li> * Changed A</li>




More information about the website mailing list