diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml
index 37f705b0ee..76d4180c47 100644
--- a/documentation/dev-manual/dev-manual-newbie.xml
+++ b/documentation/dev-manual/dev-manual-newbie.xml
@@ -75,8 +75,8 @@
Experience shows that buildbot is a good fit for this role.
What works well is to configure buildbot to make two types of builds:
incremental and full (from scratch).
- See Welcome to the buildbot for the
- Yocto Project for an example implementation that uses buildbot.
+ See "Welcome to the buildbot for the Yocto Project"
+ for an example implementation that uses buildbot.
@@ -117,6 +117,40 @@
force any particular policy on users, unlike a lot of build systems.
The system allows the best policies to be chosen for the given circumstances.
+
+
+ In general, best practices exist that make your work with the Yocto
+ Project easier in a team environment.
+ This list presents some of these practices you might consider following.
+ Of course, you need to understand that you do not have to follow these
+ practices and your setup can be totally controlled and customized by
+ your team:
+
+ Use Git
+ as the source control system.
+ Maintain your metadata in layers that make sense
+ for your situation.
+ See the "Understanding
+ and Creating Layeres" section for more information on
+ layers.
+ Separate the project's metadata and code by using
+ separate Git repositories.
+ See the "Yocto Project
+ Source Repositories" section for information on these
+ repositories.
+ See the "Getting Set Up" section
+ for information on how to set up various Yocto Project related
+ Git repositories.
+ Set up the directory for the shared state cache
+ (SSTATE_DIR)
+ 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.
+ Set up an autobuilder and have it populate the
+ sstate cache and source directories.
+
+