buildbot five magic sentences updated

1 files changed, 7 insertions, 11 deletions

diff --git a/developers-manual.rst b/developers-manual.rst
index e84b3d45..145b3223 100644
--- a/developers-manual.rst
+++ b/developers-manual.rst
@@ -322,26 +322,22 @@ GNU Taler uses a buildbot implementation (front end at https://buildbot.taler.ne
 
 Here are some highlights:
 
-- The WORKER is the config that that lives on a shell account on a
-localhost which has buildbot-worker.  The WORKER executes the commands
-that perform all end-functions of buildbot.
+- The WORKER is the config that that lives on a shell account on a localhost (taler.net), where this host has buildbot-worker installed.  The WORKER executes the commands that perform all end-functions of buildbot.
 
-- The WORKER running buildbot-worker receives these commands by
-authenticating and communicating with the buildbot server.
+- The WORKER running buildbot-worker receives these commands by authenticating and communicating with the buildbot server using parameters that were specified when the worker was created in that shell account with the `buildbot-worker` command.
 
-- The buildbot server's master.cfg file contains FACTORY declarations
-which specify the commands to run on localhost.
+- The buildbot server's master.cfg file contains FACTORY declarations which specify the commands that the WORKER will run on localhost.
 
 - The FACTORY is tied to the WORKER in master.cfg by a BUILDER.
 
-- The master.cfg also allows for SCHEDULER that defines how and when the
-BUILDER is executed.
+- The master.cfg also allows for SCHEDULER that defines how and when the BUILDER is executed.
+
+- Our master.cfg file is checked into git, and then periodically updated on a particular account on taler.net (ask Christian for access if needed).  Do not edit this file directly/locally on taler.net, but check changes into Git.
 
-- The master.cfg file is checked into git, and then periodically updated on the local account on taler.net (ask Christian for access if needed).  Do not edit this file directly/locally for permanent changes.
 
 Best Practices:
 
-When creating a new WORKER in the `master.cfg` file, leave a comment specifying the server and user account that this WORKER is called from.  (At this time, taler.net is the only server used by this implementation, but it's still good practice.)
+- When creating a new WORKER in the `master.cfg` file, leave a comment specifying the server and user account that this WORKER is called from.  (At this time, taler.net is the only server used by this implementation, but it's still good practice.)
 
 
 Documentation Builder