Add documentation for tree sheriffs

Add documentation for tree sheriffs

BUG=skia:
NOTRY=true
DOCS_PREVIEW= https://skia.org/?cl=1057883002

Committed: https://skia.googlesource.com/skia/+/0f05443bf1f8f851955a6ae4da6f6f6e6040deeb

[rmistry, 2015-04-02 15:36:02]

Patchset #1 (id:1) has been deleted

[rmistry, 2015-04-02 15:36:09]

Patchset #1 (id:20001) has been deleted

[rmistry, 2015-04-02 15:36:14]

Patchset #1 (id:40001) has been deleted

[rmistry, 2015-04-02 15:36:19]

Patchset #1 (id:60001) has been deleted

[rmistry, 2015-04-02 15:36:25]

Patchset #1 (id:80001) has been deleted

[rmistry, 2015-04-02 15:36:31]

Patchset #1 (id:100001) has been deleted

[rmistry, 2015-04-02 15:36:37]

Patchset #1 (id:120001) has been deleted

[rmistry, 2015-04-02 15:36:43]

Patchset #1 (id:140001) has been deleted

[rmistry, 2015-04-02 15:36:49]

Patchset #1 (id:160001) has been deleted

[rmistry, 2015-04-02 15:36:54]

Patchset #1 (id:180001) has been deleted

[rmistry, 2015-04-02 15:37:00]

Patchset #1 (id:200001) has been deleted

[rmistry, 2015-04-02 15:37:05]

Patchset #1 (id:220001) has been deleted

[rmistry, 2015-04-02 15:37:11]

Patchset #1 (id:240001) has been deleted

[rmistry, 2015-04-02 15:38:01]

rmistry@google.com changed reviewers:
+ borenet@google.com, hcm@google.com, jcgregorio@google.com, stephana@google.com

[hcm, 2015-04-02 15:50:02]

On 2015/04/02 15:38:03, rmistry wrote:

Thanks for starting this..looking good.  One thing I wanted to point out is that
we're trying very hard to weed out internal-only content from our external site.
 At least until the time we extend committer and sheriff roles to our public
contributors, we should probably move this to go/skia.  That takes away the
markdown coolness though (Debbie Downer here!)

[rmistry, 2015-04-02 16:28:46]

On 2015/04/02 15:50:02, hcm wrote:
> On 2015/04/02 15:38:03, rmistry wrote:
> 
> Thanks for starting this..looking good.  One thing I wanted to point out is
that
> we're trying very hard to weed out internal-only content from our external
site.
>  At least until the time we extend committer and sheriff roles to our public
> contributors, we should probably move this to go/skia.  That takes away the
> markdown coolness though (Debbie Downer here!)

AFAIK there are only public links in this documentation, and I dont think it
hurts to have this on skia.org. Actually I think it makes more sense to be in
skia.org because that is probably where our sheriffs will go first to look for
documentation (I know I would).

[rmistry, 2015-04-02 16:31:32]

On 2015/04/02 16:28:46, rmistry wrote:
> On 2015/04/02 15:50:02, hcm wrote:
> > On 2015/04/02 15:38:03, rmistry wrote:
> > 
> > Thanks for starting this..looking good.  One thing I wanted to point out is
> that
> > we're trying very hard to weed out internal-only content from our external
> site.
> >  At least until the time we extend committer and sheriff roles to our public
> > contributors, we should probably move this to go/skia.  That takes away the
> > markdown coolness though (Debbie Downer here!)
> 
> AFAIK there are only public links in this documentation, and I dont think it
> hurts to have this on http://skia.org. Actually I think it makes more sense to
be in
> http://skia.org because that is probably where our sheriffs will go first to
look for
> documentation (I know I would).

Also, it might be useful information for external contributors to learn about
how we sheriff their changes. i.e. what led (or could lead) to their changes
being reverted.

[jcgregorio, 2015-04-02 16:31:42]

On 2015/04/02 at 16:28:46, rmistry wrote:
> On 2015/04/02 15:50:02, hcm wrote:
> > On 2015/04/02 15:38:03, rmistry wrote:
> > 
> > Thanks for starting this..looking good.  One thing I wanted to point out is
that
> > we're trying very hard to weed out internal-only content from our external
site.
> >  At least until the time we extend committer and sheriff roles to our public
> > contributors, we should probably move this to go/skia.  That takes away the
> > markdown coolness though (Debbie Downer here!)
> 
> AFAIK there are only public links in this documentation, and I dont think it
hurts to have this on skia.org. Actually I think it makes more sense to be in
skia.org because that is probably where our sheriffs will go first to look for
documentation (I know I would).

+1, I'd like to keep all the docs as consolidated as possible and only use
go/skia for things that are truly internal, i.e. use code names or service names
that shouldn't be mentioned in public.

[borenet, 2015-04-02 16:38:38]

https://codereview.chromium.org/1057883002/diff/260001/site/dev/sheriffing/in...
File site/dev/sheriffing/index.md (right):

https://codereview.chromium.org/1057883002/diff/260001/site/dev/sheriffing/in...
site/dev/sheriffing/index.md:36: * Follow up with the owners of existing
[BreakingTheBuildbots
bugs](https://code.google.com/p/skia/issues/list?q=label:BreakingTheBuildbots).
I'd like to have a point here about pinging (or filing) bugs for persistent
failures in the "failures" view.

https://codereview.chromium.org/1057883002/diff/260001/site/dev/sheriffing/in...
site/dev/sheriffing/index.md:40: * Ensure that [AutoRoll
Bot](http://www.chromium.org/blink/blinkrollbot)'s DEPS rolls land successfully.
Might be a good idea to point to our ARB front-end here.

https://codereview.chromium.org/1057883002/diff/260001/site/dev/sheriffing/in...
site/dev/sheriffing/index.md:113: A common cause of DEPS roll failures are
layout tests. Find the offending Skia CL by examining the commit hash range in
the DEPS roll and revert. Keep an eye on the next DEPS roll.
The answer here is not always a revert.  If we've intentionally changed the way
we render things, we'll need to stage suppressions and rebaseline the tests.  If
that's the case, the committer should let the sheriff know what's going on.

[hcm, 2015-04-02 17:05:32]

On 2015/04/02 16:31:42, jcgregorio wrote:
> On 2015/04/02 at 16:28:46, rmistry wrote:
> > On 2015/04/02 15:50:02, hcm wrote:
> > > On 2015/04/02 15:38:03, rmistry wrote:
> > > 
> > > Thanks for starting this..looking good.  One thing I wanted to point out
is
> that
> > > we're trying very hard to weed out internal-only content from our external
> site.
> > >  At least until the time we extend committer and sheriff roles to our
public
> > > contributors, we should probably move this to go/skia.  That takes away
the
> > > markdown coolness though (Debbie Downer here!)
> > 
> > AFAIK there are only public links in this documentation, and I dont think it
> hurts to have this on http://skia.org. Actually I think it makes more sense to
be in
> http://skia.org because that is probably where our sheriffs will go first to
look for
> documentation (I know I would).
> 
> +1, I'd like to keep all the docs as consolidated as possible and only use
> go/skia for things that are truly internal, i.e. use code names or service
names
> that shouldn't be mentioned in public.

I can see where perhaps sheriffing doc could help contributors, so I guess I'm
fine with it.  I just want to point out that one of the main feedback points
from the dev-rel reviews of our website was that we had muddied the water with
what Googlers need to know and what Devs on our open source project need to
know.  We need a clean strategy based on the subject matter.... and it will take
time for us to follow that strategy for something like go/skia to become a
"natural" place to look for those resources.  (Will take the discussion on this
with you guys offline)

[rmistry, 2015-04-02 17:34:05]

https://codereview.chromium.org/1057883002/diff/260001/site/dev/sheriffing/in...
File site/dev/sheriffing/index.md (right):

https://codereview.chromium.org/1057883002/diff/260001/site/dev/sheriffing/in...
site/dev/sheriffing/index.md:36: * Follow up with the owners of existing
[BreakingTheBuildbots
bugs](https://code.google.com/p/skia/issues/list?q=label:BreakingTheBuildbots).
On 2015/04/02 16:38:38, borenet wrote:
> I'd like to have a point here about pinging (or filing) bugs for persistent
> failures in the "failures" view.

Done.

https://codereview.chromium.org/1057883002/diff/260001/site/dev/sheriffing/in...
site/dev/sheriffing/index.md:40: * Ensure that [AutoRoll
Bot](http://www.chromium.org/blink/blinkrollbot)'s DEPS rolls land successfully.
On 2015/04/02 16:38:38, borenet wrote:
> Might be a good idea to point to our ARB front-end here.

Done.

https://codereview.chromium.org/1057883002/diff/260001/site/dev/sheriffing/in...
site/dev/sheriffing/index.md:113: A common cause of DEPS roll failures are
layout tests. Find the offending Skia CL by examining the commit hash range in
the DEPS roll and revert. Keep an eye on the next DEPS roll.
On 2015/04/02 16:38:38, borenet wrote:
> The answer here is not always a revert.  If we've intentionally changed the
way
> we render things, we'll need to stage suppressions and rebaseline the tests. 
If
> that's the case, the committer should let the sheriff know what's going on.

I have only encountered situations where the answer has been to revert. Even if
we intentionally change the way things are rendered, the suppressions need to
land first and then after the DEPS roll the tests are rebaselined.
This ofcourse does not apply when the committer lets the sheriff know beforehand
if there is another plan, but in that case this tip would not apply. I did
however add a small section about talking to the author if they are available.

[borenet, 2015-04-02 17:54:43]

LGTM

https://codereview.chromium.org/1057883002/diff/260001/site/dev/sheriffing/in...
File site/dev/sheriffing/index.md (right):

https://codereview.chromium.org/1057883002/diff/260001/site/dev/sheriffing/in...
site/dev/sheriffing/index.md:113: A common cause of DEPS roll failures are
layout tests. Find the offending Skia CL by examining the commit hash range in
the DEPS roll and revert. Keep an eye on the next DEPS roll.
On 2015/04/02 17:34:04, rmistry wrote:
> On 2015/04/02 16:38:38, borenet wrote:
> > The answer here is not always a revert.  If we've intentionally changed the
> way
> > we render things, we'll need to stage suppressions and rebaseline the tests.

> If
> > that's the case, the committer should let the sheriff know what's going on.
> 
> I have only encountered situations where the answer has been to revert. Even
if
> we intentionally change the way things are rendered, the suppressions need to
> land first and then after the DEPS roll the tests are rebaselined.
> This ofcourse does not apply when the committer lets the sheriff know
beforehand
> if there is another plan, but in that case this tip would not apply. I did
> however add a small section about talking to the author if they are available.

Right, this only happens when the committer does something wrong.

[rmistry, 2015-04-02 17:56:04]

On 2015/04/02 17:54:43, borenet wrote:
> LGTM
> 
>
https://codereview.chromium.org/1057883002/diff/260001/site/dev/sheriffing/in...
> File site/dev/sheriffing/index.md (right):
> 
>
https://codereview.chromium.org/1057883002/diff/260001/site/dev/sheriffing/in...
> site/dev/sheriffing/index.md:113: A common cause of DEPS roll failures are
> layout tests. Find the offending Skia CL by examining the commit hash range in
> the DEPS roll and revert. Keep an eye on the next DEPS roll.
> On 2015/04/02 17:34:04, rmistry wrote:
> > On 2015/04/02 16:38:38, borenet wrote:
> > > The answer here is not always a revert.  If we've intentionally changed
the
> > way
> > > we render things, we'll need to stage suppressions and rebaseline the
tests.
> 
> > If
> > > that's the case, the committer should let the sheriff know what's going
on.
> > 
> > I have only encountered situations where the answer has been to revert. Even
> if
> > we intentionally change the way things are rendered, the suppressions need
to
> > land first and then after the DEPS roll the tests are rebaselined.
> > This ofcourse does not apply when the committer lets the sheriff know
> beforehand
> > if there is another plan, but in that case this tip would not apply. I did
> > however add a small section about talking to the author if they are
available.
> 
> Right, this only happens when the committer does something wrong.

Will land in a few hours if there are no more comments.

[rmistry, 2015-04-02 20:30:21]

The CQ bit was checked by rmistry@google.com

[commit-bot: I haz the power, 2015-04-02 20:31:03]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1057883002/300001

[commit-bot: I haz the power, 2015-04-02 20:31:12]

Committed patchset #3 (id:300001) as
https://skia.googlesource.com/skia/+/0f05443bf1f8f851955a6ae4da6f6f6e6040deeb