diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml
index abf0890d65..4d99e39530 100644
--- a/documentation/dev-manual/dev-manual-newbie.xml
+++ b/documentation/dev-manual/dev-manual-newbie.xml
@@ -79,8 +79,8 @@
 
         <para>
             Systems across a large team should meet the needs of
-            two types of developers: those working on the direction of the
-            software stack itself and those developing applications.
+            two types of developers: those working on the contents of the
+            operating system image itself and those developing applications.
             Regardless of the type of developer, their workstations must
             be both reasonably powerful and run Linux.
         </para>
@@ -131,8 +131,11 @@
                 build system itself available on the developer workstations
                 so developers can run their own builds and directly
                 rebuild the software stack.
-                You should keep the core system standard as much as
+                You should keep the core system unchanged as much as
                 possible and do your work in layers on top of the core system.
+                Doing so gives you a greater level of portability when
+                upgrading to new versions of the core system or Board
+                Support Packages (BSPs).
                 You can share layers amongst the developers of a particular
                 project and contain the policy configuration that defines
                 the project.
@@ -357,14 +360,17 @@
                     Git repositories.</para></listitem>
                 <listitem><para>Set up the directory for the shared state cache
                     (<ulink url='&YOCTO_DOCS_REF_URL;#var-SSTATE_DIR'><filename>SSTATE_DIR</filename></ulink>)
-                    where they make sense.
-                    For example, set up the sstate cache for developers using the
-                    same office and share source directories on the developer's
-                    machines.</para></listitem>
+                    where it makes sense.
+                    For example, set up the sstate cache on a system used
+                    by developers that share the same office and share the
+                    same source directories on their machines.
+                    </para></listitem>
                 <listitem><para>Set up an autobuilder and have it populate the
                     sstate cache and source directories.</para></listitem>
-                <listitem><para>Follow the project commit guidelines for
-                    writing good commit messages.
+                <listitem><para>The Yocto Project community encourages you
+                    to send patches to the project to fix bugs or add features.
+                    If you do submit patches, follow the project commit
+                    guidelines for writing good commit messages.
                     See the "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
                     section.</para></listitem>
                 <listitem><para>Send changes to the core sooner than later