1 files changed, 45 insertions, 30 deletions

diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml
index 0efcbbb9b0..1422384e48 100644
--- a/documentation/dev-manual/dev-manual-newbie.xml
+++ b/documentation/dev-manual/dev-manual-newbie.xml
@@ -545,44 +545,59 @@
     <title>Tracking Bugs</title>
 
     <para>
-        The Yocto Project uses <ulink url='http://www.bugzilla.org/about/'>Bugzilla</ulink> to track bugs.  
-        This bug-tracking application works well for group development because it tracks bugs and code 
+        The Yocto Project uses its own implementation of 
+        <ulink url='http://www.bugzilla.org/about/'>Bugzilla</ulink> to track bugs.  
+        Implementations of Bugzilla work well for group development because they track bugs and code 
         changes, can be used to communicate changes and problems with developers, can be used to 
-        submit and review patches, and can be used to manage quality assurance.  
-        You can find a good overview of Bugzilla <ulink url='http://www.bugzilla.org/about/'>here</ulink>.     
+        submit and review patches, and can be used to manage quality assurance. 
+        The home page for the Yocto Project implementation of Bugzilla is   
+        <ulink url='http://bugzilla.yoctoproject.org'>http://bugzilla.yoctoproject.org</ulink>.
     </para>
 
     <para>
         Sometimes it is helpful to submit, investigate, or track a bug against the Yocto Project itself
         such as when discovering an issue with some component of the build system that acts contrary 
         to the documentation or your expectations.  
-        You can find information 
-        for Bugzilla configuration and bug tracking procedures specific to the Yocto Project 
+        Following is the general procedure for submitting a new bug using the Yocto Project
+        Bugzilla.
+        You can find more information on defect management, bug tracking, and feature request
+        processes all accomplished through the Yocto Project Bugzilla on the wiki page
         <ulink url='https://wiki.yoctoproject.org/wiki/Bugzilla_Configuration_and_Bug_Tracking'>here</ulink>.     
-    </para>
-
-    <para>
-        The Yocto Project uses its own version of the Bugzilla application.  
-        You can find the home page <ulink url='http://bugzilla.yoctoproject.org'>here</ulink>.  
-        You need to use this implementation of Bugzilla when logging a defect against anything released 
-        by the Yocto Project team.     
-    </para>
-
-    <para>
-        Here are some things to remember when dealing with bugs against the Yocto Project:   
-        <itemizedlist>
-            <listitem><para>The Yocto Project follows a bug-naming convention: 
-                <filename>[YOCTO #&lt;number&gt;]</filename>, where <filename>&lt;number&gt;</filename> is the 
-                assigned defect ID used in Bugzilla.  
-                So, for example, a valid way to refer to a defect when creating a commit comment 
-                would be <filename>[YOCTO #1011]</filename>.   
-                This convention becomes important if you are submitting patches against the Yocto Project 
-                code itself.
-                See the following section for more information.</para></listitem>
-            <listitem><para>Defects for Yocto Project fall into one of four classifications:  Yocto Projects, 
-                Infrastructure, Poky, and Yocto Metadata Layers.</para></listitem>
-        </itemizedlist>
-    </para>
+        <orderedlist>
+            <listitem><para>Always use the Yocto Project implementation of Bugzilla to submit
+                a bug.</para></listitem>
+            <listitem><para>When submitting a new bug, be sure to choose the appropriate
+                Classification, Product, and Component for which the issue was found.
+                Defects for Yocto Project fall into one of four classifications:  Yocto Projects, 
+                Infrastructure, Poky, and Yocto Metadata Layers.
+                Each of these Classifications break down into multiple Products and, in some 
+                cases, multiple Components.</para></listitem>
+            <listitem><para>Use the bug form to choose the correct Hardware and Architecture
+                for which the bug applies.</para></listitem>
+            <listitem><para>Indicate the Yocto Project version you were using when the issue
+                occurred.</para></listitem>
+            <listitem><para>Be sure to indicate the Severity of the bug.  
+                Severity communicates how the bug impacted your work.</para></listitem>
+            <listitem><para>Provide a brief summary of the issue. 
+                Try to limit your summary to just a line or two and be sure to capture the 
+                essence of the issue.</para></listitem>
+            <listitem><para>Provide a detailed description of the issue.  
+                You should provide as much detail as you can about the context, behavior, output, 
+                and so forth that surround the issue.  
+                You can even attach supporting files for output or log by using the "Add an attachment"
+                button.</para></listitem>
+            <listitem><para>Submit the bug by clicking the "Submit Bug" button.</para></listitem>
+        </orderedlist>
+    </para>
+ 
+    <note>
+        Bugs in the Yocto Project Bugzilla follow naming convention: 
+        <filename>[YOCTO #&lt;number&gt;]</filename>, where <filename>&lt;number&gt;</filename> is the 
+        assigned defect ID used in Bugzilla.  
+        So, for example, a valid way to refer to a defect would be <filename>[YOCTO #1011]</filename>.   
+        This convention becomes important if you are submitting patches against the Yocto Project 
+        code itself.
+    </note>
 </section>
 
 <section id='how-to-submit-a-change'>