Diff for "Code/Review/Relationships"

Not logged in - Log In / Register

Differences between revisions 1 and 2
Revision 1 as of 2009-12-09 21:51:40
Size: 3010
Editor: CPE001a7046c8f9-CM001e6b233d5a
Comment: Initial import of code review relationship pages.
Revision 2 as of 2009-12-09 21:57:03
Size: 2795
Editor: CPE001a7046c8f9-CM001e6b233d5a
Comment: Convert to moin
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
{{{#!rst
==========================
Code Review Relationships
==========================
= Code Review Relationships =
Line 6: Line 3:
Per-branch relationships
========================
Line 9: Line 4:
Owner
-----
== Per-branch relationships ==

=== Owner ===
Line 14: Line 11:
Review Team
-----------
=== Review Team ===
Line 23: Line 19:
Subscribers
-----------
=== Subscribers ===
Line 32: Line 27:
its owner to code review. It seems like a good idea to subscribe the
review team too, but we don't at present.
its owner to code review. In the future, the review team may also be subscribed.
Line 35: Line 29:
Per merge-proposal relationships
================================
== Per merge-proposal relationships ==
Line 38: Line 31:
Registrant
----------

===
Registrant ===
Line 43: Line 37:
Source branch owner
-------------------
=== Source branch owner ===
Line 47: Line 41:
Target branch owner and review team
-----------------------------------
=== Target branch owner and review team ===
Line 53: Line 47:
Team Reviewers
--------------
=== Team Reviewers ===
Line 60: Line 54:
Individual Reviewers
--------------------
=== Individual Reviewers ===
Line 63: Line 57:
   They receive all email about this merge proposal. If they have not They receive all email about this merge proposal. If they have not
Line 65: Line 59:
 Otherwise, they cannot opt out. Otherwise, they cannot opt out.
Line 67: Line 61:
Commenters
----------
=== Commenters ===
Line 76: Line 70:

}}}

Code Review Relationships

Per-branch relationships

Owner

Each branch has an owner, who is the only person or team, aside from admins, who can write to the branch.

Review Team

Each branch has a "review team". This is the group of people (or person) whose reviews are trusted input for deciding whether to accept a merge into this branch. By default, this team is requested to review any new proposal to merge into this branch. If the review team is not set, the branch owner is used as the review team. This setting does not cause any additional mail to be sent to members of the review team.

Subscribers

Each branch has zero or more subscribers. They may be subscribed to metadata changes, revision updates, and / or code review. Subscriptions allow the subscriber to control the kinds of email sent to them, and also the size of branch update diffs. They allow an individual to override the subscription settings their team may have. Subscribers to code review are notified when this branch is the source or target of a merge proposal. When a branch is created, we automatically subscribe its owner to code review. In the future, the review team may also be subscribed.

Per merge-proposal relationships

Registrant

The person who proposed the merge. This person has edit rights on the merge proposal.

Source branch owner

The source branch owner has edit rights on the merge proposal.

Target branch owner and review team

They have edit rights on the merge proposal. Their reviews are not shown as "(community)". They can set the overall status of the merge proposal (i.e. mark it "approved"/"rejected"/"work in progress").

Team Reviewers

Teams who have been requested to review. Members of these teams may claim their team's review. If a member of this team performs a review, and the requested review type doesn't conflict with the specified review type, the team review request is automatically reassigned to the reviewer.

Individual Reviewers

People who have been requested to review or who have performed reviews. They receive all email about this merge proposal. If they have not yet reviewed, they can only opt out by reassigning their review request. Otherwise, they cannot opt out.

Commenters

People who have made comments about the merge proposal. Being a commenter does not cause them to receive email, and there is no way for them to opt-in to email about this particular proposal.

They could subscribe to code review on the source branch, and this would have the same effect as being subscribed to the merge proposal, as long as no further merge proposals were made for the source branch.

Code/Review/Relationships (last edited 2009-12-09 22:09:39 by CPE001a7046c8f9-CM001e6b233d5a)