phorge / src / docs / user / userguide / owners.diviner

@title Owners User Guide
@group userguide

Group files in a codebase into packages and define ownership.

Overview
========

The Owners application allows you to group files in a codebase (or across
codebases) into packages. This can make it easier to reference a module or
subsystem in other applications, like Herald.


Creating a Package
==================

To create a package, choose a name and add some files which belong to the
package. For example, you might define an "iOS Application" package by
including these paths:

  /conf/ios/
  /src/ios/
  /shared/assets/mobile/

Any files in those directories are considered to be part of the package, and
you can now conveniently refer to them (for example, in a Herald rule) by
referring to the package instead of copy/pasting a huge regular expression
into a bunch of places.

If new source files are later added, or the scope of the package otherwise
expands or contracts, you can edit the package definition to keep things
updated.

You can use "exclude" paths to ignore subdirectories which would otherwise
be considered part of the package. For example, you might exclude a path
like this:

  /conf/ios/generated/

Perhaps that directory contains some generated configuration which frequently
changes, and which you aren't concerned about.

After creating a package, files the package contains will be identified as
belonging to the package when you look at them in Diffusion, or look at changes
which affect them in Diffusion or Differential.


Dominion
========

The **Dominion** option allows you to control how ownership cascades when
multiple packages own a path. The dominion rules are:

**Strong Dominion.** This is the default. In this mode, the package will always
own all files matching its configured paths, even if another package also owns
them.

For example, if the package owns `a/`, it will always own `a/b/c.z` even if
another package owns `a/b/`. In this case, both packages will own `a/b/c.z`.

This mode prevents users from stealing files away from the package by defining
more narrow ownership rules in new packages, but enforces hierarchical
ownership rules.

**Weak Dominion.** In this mode, the package will only own files which do not
match a more specific path in another package.

For example, if the package owns `a/` but another package owns `a/b/`, the
package will no longer consider `a/b/c.z` to be a file it owns because another
package matches the path with a more specific rule.

This mode lets you to define rules without implicit hierarchical ownership,
but allows users to steal files away from a package by defining a more
specific package.

For more details on files which match multiple packages, see
"Files in Multiple Packages", below.


Auto Review
===========

You can configure **Auto Review** for packages. When a new code review is
created in Differential which affects code in a package, the package can
automatically be added as a subscriber or reviewer.

The available settings allow you to take these actions:

  - **Review Changes**: This package will be added to reviews as a reviewer.
    Reviews will appear on the dashboards of package owners.
  - **Review Changes (Blocking)** This package will be added to reviews as a
    blocking reviewer. A package owner will be required to accept changes
    before they may land.
  - **Subscribe to Changes**: This package will be added to reviews as a
    subscriber. Owners will be notified of changes, but not required to act.

If you select the **With Non-Owner Author** option for these actions, the
action will not trigger if the author of the revision is a package owner. This
mode may be helpful if you are using Owners mostly to make sure that someone
who is qualified is involved in each change to a piece of code.

If you select the **All** option for these actions, the action will always
trigger even if the author is a package owner. This mode may be helpful if you
are using Owners mostly to suggest reviewers.

These rules do not trigger if the package has been archived.

The intent of this feature is to make it easy to configure simple, reasonable
behaviors. If you want more tailored or specific triggers, you can write more
powerful rules by using Herald.


Auditing
========

You can automatically trigger audits on unreviewed code by configuring
**Auditing**. The available settings allow you to select behavior based on
these conditions:

  - **No Owner Involvement**: Triggers an audit when the commit author is not
    a package owner, and no package owner reviewed an associated revision in
    Differential.
  - **Unreviewed Commits**: Triggers an audit when a commit has no associated
    revision in Differential, or the associated revision in Differential landed
    without being "Accepted".

For example, the **Audit Commits With No Owner Involvement** option triggers
audits for commits which:

  - affect code owned by the package;
  - were not authored by a package owner; and
  - were not accepted (in Differential) by a package owner or the package
    itself.

Audits do not trigger if the package has been archived.

The intent of this feature is to make it easy to configure simple auditing
behavior. If you want more powerful auditing behavior, you can use Herald to
write more sophisticated rules.


Ignored Attributes
==================

You can automatically exclude certain types of files, like generated files,
with **Ignored Attributes**.

When a package is marked as ignoring files with a particular attribute, and
a file in a particular change has that attribute, the file will be ignored when
computing ownership.

(This feature is currently rough, only works for Differential revisions, and
may not always compute the correct set of owning packages in some complex
cases where it interacts with dominion rules.)


Files in Multiple Packages
==========================

Multiple packages may own the same file. For example, both the
"Android Application" and the "iOS Application" packages might own a path
like this, containing resources used by both:

  /shared/assets/mobile/

If both packages own this directory, files in the directory are considered to
be part of both packages.

Packages do not need to have claims of equal specificity to own files. For
example, if you have a "Design Assets" package which owns this path:

  /shared/assets/

...it will //also// own all of the files in the `mobile/` subdirectory. In this
configuration, these files are part of three packages: "iOS Application",
"Android Application", and "Design Assets".

(You can use an "exclude" rule if you want to make a different package with a
more specific claim the owner of a file or subdirectory. You can also change
the **Dominion** setting for a package to let it give up ownership of paths
owned by another package.)