dev-manual: Edits to "How to Submit a Change" section.

(From yocto-docs rev: 8b9cff0c35eb76665edca6c8474935d6dc62e7ed)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

1 files changed, 8 insertions, 7 deletions

diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml
index da5595d65d..d939b44c54 100644
--- a/documentation/dev-manual/dev-manual-newbie.xml
+++ b/documentation/dev-manual/dev-manual-newbie.xml
@@ -1271,9 +1271,10 @@
     </para>
 
     <para>
-        The following is some guidance on which mailing list to use for what type of change:
+        Here is some guidance on which mailing list to use for what type of change:
         <itemizedlist>
-            <listitem><para>For changes to the core metadata, send your patch to the
+            <listitem><para>For changes to the core 
+                <link linkend='metadata'>Metadata</link>, send your patch to the
                 <ulink url='&OE_LISTS_URL;/listinfo/openembedded-core'>openembedded-core</ulink> mailing list.
                 For example, a change to anything under the <filename>meta</filename> or
                 <filename>scripts</filename> directories
@@ -1288,7 +1289,7 @@
                 layer's documentation specifies otherwise), tools, and Yocto Project
                 documentation, use the
                 <ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'>yocto</ulink> mailing list.</para></listitem>
-            <listitem><para>For additional recipes that do not fit into the core metadata,
+            <listitem><para>For additional recipes that do not fit into the core Metadata,
                 you should determine which layer the recipe should go into and submit the
                 change in the manner recommended by the documentation (e.g. README) supplied
                 with the layer. If in doubt, please ask on the
@@ -1356,7 +1357,7 @@
                 This summary is typically viewable in the "shortlist" of changes.
                 Thus, providing something short and descriptive that gives the reader
                 a summary of the change is useful when viewing a list of many commits.
-                This should be prefixed by the recipe name (if changing a recipe), or
+                This short description should be prefixed by the recipe name (if changing a recipe), or
                 else the short form path to the file being changed.
                 </para></listitem>
             <listitem><para>For the body of the commit message, provide detailed information
@@ -1371,7 +1372,7 @@
                 references - any commit that addresses a specific bug should include the
                 bug ID in the description (typically at the beginning) as follows:
                 <literallayout class='monospaced'>
-     [YOCTO #&lt;bug-id&gt;]
+     Fixes YOCTO #&lt;bug-id&gt;
 
      &lt;detailed description of change&gt;
                 </literallayout></para></listitem>
@@ -1387,8 +1388,8 @@
     </para>
 
     <para>
-        Following are general instructions for both pushing changes upstream and for submitting
-        changes as patches.
+        The next two sections describe general instructions for both pushing 
+        changes upstream and for submitting changes as patches.
     </para>
 
     <section id='pushing-a-change-upstream'>