Add some useful information to trooper doc.

site/dev/sheriffing/trooper.md

Index: site/dev/sheriffing/trooper.md
diff --git a/site/dev/sheriffing/trooper.md b/site/dev/sheriffing/trooper.md
index 4840f6376b9c7a074d81e1cb08cccb84c3fafe94..f56f417d256c5e94fe71740b2d6dd58d01f1a2da 100644
--- a/site/dev/sheriffing/trooper.md
+++ b/site/dev/sheriffing/trooper.md
@@ -37,4 +37,61 @@ If you need to swap shifts with someone (because you are out sick or on vacation
 <a name="tips"></a>
 Tips for troopers
 -----------------
-Add your tips here!
+
+- Make sure you are a member of
+  [MDB group chrome-skia-ninja](https://ganpati.corp.google.com/#Group_Info?name=chrome-skia-ninja@prod.google.com).
+  Valentine passwords and Chrome Golo access are based on membership in this
+  group.
+
+- These alerts generally auto-dismiss once the criteria for the alert is no
+  longer met:
+  - Monitoring alerts, including prober, collectd, and others
+  - Disconnected build slaves
+
+- These alerts generally do not auto-dismiss:
+  - Build slaves that failed a step
+  - Disconnected devices (these are detected as the "wait for device" step failing)

[borenet, 2015/09/03 12:23:05]

No need to add to docs, but it's possible to make these auto-dismiss as well. 
The solution is to periodically check for a subsequent build on the same
buildslave in which the step in question (update_scripts or wait-for-device)
succeeded.

[rmistry, 2015/09/03 12:30:27]

It will be useful to file a tracking bug for this. Eric should probably file it
since he knows the most about it.

[dogben, 2015/09/03 15:40:16]

Added bug link.

+
+- "Failed to execute query" may show a different query than the failing one;
+  dismiss the alert to get a new alert showing the query that is actually
+  failing.

[borenet, 2015/09/03 12:23:05]

More detail: All "failed to execute query" alerts are lumped into a single
alert, which is why the failed query which initially triggered the alert may not
be failing any more but the alert is still active because another query is
failing.

[dogben, 2015/09/03 15:40:16]

Done.

+
+- Where machines are located:
+  - Machine name like "skia-vm-NNN" -> GCE
+  - Machine name ends with "a3", "a4", "m3" -> Chrome Golo
+  - Machine name starts with "skiabot-" -> Chapel Hill lab
+  - Machine name starts with "win8" -> Chapel Hill lab (Windows machine
+    names can't be very long, so the "skiabot-shuttle-" prefix is dropped.)
+  - TODO(borenet): slave11-c3

[borenet, 2015/09/03 12:23:05]

I'm actually not sure where this one is.  This runs our presubmit trybot.

[rmistry, 2015/09/03 12:30:27]

Ben, this is a good question for the chrome-infra IRC channel:
https://comlink.googleplex.com/chrome-infra
(good link to bookmark)

[dogben, 2015/09/03 15:40:16]

Added IRC channel. Updated info on chrome infra based on discussion.

+
+- To log in to a Linux buildbot in GCE, use `gcloud compute default@<machine
+  name>`. Choose the zone listed for the
+  [GCE VM](https://pantheon.corp.google.com/project/31977622648/compute/instances)
+  (or specify it using the `--zone` command-line flag).
+
+- To log in to a Windows buildbot in GCE, use
+  [Chrome RDP Extension](https://chrome.google.com/webstore/detail/chrome-rdp/cbkkbcmdlboombapidmoeolnmdacpkch?hl=en-US)
+  with the
+  [IP address of the GCE VM](https://pantheon.corp.google.com/project/31977622648/compute/instances)
+  shown on the [host info page](https://status.skia.org/hosts) for that bot. The
+  username is chrome-bot and the password can be found on
+  [Valentine](https://valentine.corp.google.com/) as "chrome-bot (Win GCE)".
+
+- To access bots in the Chrome Golo,
+  [follow these instructions](https://chrome-internal.googlesource.com/infra/infra_internal/+/master/doc/ssh.md).
+  - Machine name ends with "a3" or "a4" -> ssh command looks like `ssh
+    build3-a3.chrome`
+  - Machine name ends with "m3" -> ssh command looks like `ssh build5-m3.golo`
+  - For MacOS and Windows bots, you will be prompted for a password, which is
+    stored on [Valentine](https://valentine.corp.google.com/) as "Chrome Golo,
+    Perf, GPU bots - chrome-bot".
+
+- Read over the [SkiaLab documentation](../testing/skialab) for more detail on
+  dealing with device alerts.
+
+- To stop a buildslave for a device, log in to the host for that device, `cd
+  ~/buildbot/<device name>/build/slave; make stop`. To start it again,
+  `TESTING_SLAVENAME=<device name> make start`.

[borenet, 2015/09/03 12:23:05]

This should be <slave name>

[dogben, 2015/09/03 15:40:16]

Done.

+
+- Sometimes on Mac and Linux you have to run
+  `~/skiabot-slave-start-on-boot.sh` after reboot.

[borenet, 2015/09/03 12:23:05]

Don't do this without running `ps aux | grep python` to ensure that neither
buildbot or gclient are running.  Sometimes it's just slow to sync before
launching the buildbot slave scripts.

[dogben, 2015/09/03 15:40:16]

Done.