Membership in a Swarm project identifies users as belonging to the project, making them part of the team.
The are only a few notable differences between project members and non-members:
| Difference | Member | Non-Member | Description |
|---|---|---|---|
| Notifications |
|
|
Members receive project notifications; non-members do not. |
| Avatars |
|
|
The project's home page features member's avatars. |
| States |
|
|
Members can transition code review states; non-members cannot. |
There are two ways to become a member of a project in Swarm:
Ask a member of an existing project to add you as a member.
If the project has any owners specified, you need to ask a project owner to add you as a member.
Users with super privileges in Helix Server can always adjust the settings for any project, including adjusting membership.
If you are an owner of a project, or a member of a project without specified owners:
The Members text field lets you specify a Swarm project, Helix Server group, or Helix Server user to add to the members for this project. The field auto-suggests projectids, groupids, and userids by matching what you have typed so far against the list of users in the Helix Server.
When you specify a project or group, all of the members of that project or group become members of this project. Swarm does not display all of the individual users, but it does provide a visual separation: project or group names are displayed first, with a darker blue background.
When you hover your mouse over a member project or group, a tooltip appears displaying up to 100 of the userids of the project's or group's users.
If you are an owner of a project, or a member of a project without specified owners:
Click Settings in the project's toolbar.
Known members of the project are displayed beneath the Members text field, with a medium blue button representing projects or groups and a light blue button representing individual users.
You are able to remove your own membership or ownership. Doing so could prevent you from managing the project.
A project owner is a Helix Server user that controls the configuration for a project. An owner does not need to be a member of a project, but once Only Owners and Super Users can edit the project has been set, only an owner or user with super privileges in Helix Server can edit any project settings.
A project moderator is a user assigned to moderate reviews for a specific branch associated with a project. See how to specify moderators.
When Only Moderators can approve or reject reviews is set for a project branch, changing the state of any review associated with the moderated branch is restricted as follows:
Moderators prevent the automatic approval of reviews. Workflow is disabled by default: for more information about automatically approving reviews using workflow rules, see Workflow rules.
By default, when a review spans multiple branches that have different moderators, only one moderator from any one of the branches needs to approve the review.
Swarm can be configured to require that one moderator from each branch must approve the review, this is a global setting. If a moderator belongs to more than one of the branches spanned by the review, their approval will count for each of the branches they belong to. For instructions on how to configure moderator behavior, see Moderator behavior when a review spans multiple branches.
The review's author, when not a moderator, can change the review's state to Needs Review, Needs Revision, Archived, and can attach committed changelists.
Normally, the review's author cannot change the review's state to Approved or Rejected on moderated branches. However, authors that are also moderators have moderator privileges, and may approve or reject their own review.
When disable_self_approve is enabled, authors who are moderators (or even users with admin privileges) cannot approve their own reviews.
These restrictions have no effect on who can start a review.
User and group default reviewers can be set for individual projects and project branches. Each time a new review is created in the project or project branch, the default reviewers will be added to the review. See projects and project branches for adding default reviewers.
When a review is part of multiple projects/project branches:
Example: A review is created and it is part of Project A, Project B, and Project Branch b.
Project A: default reviewer X is an Optional reviewer
Project B: default reviewer X is an Optional reviewer
Project Branch b: default reviewer X is a Required reviewer
Result: default reviewer X is added to the review as a Required reviewer
If users or groups are @mentioned in a new changelist description that includes #review, they will be added to the review as reviewers. If any of these reviewers are already specified as default reviewers they will not be added to the review again, the reviewer's most restrictive reviewer option is used for the review.
If a default reviewer is deleted from Helix Server they will not be added to new reviews.
By default, default reviewers can be removed from an individual review by using the edit reviewers button on the review display page. Individual projects and branches can be configured to prevent default reviewers from being removed from individual reviews. For instructions on how to enable Retain default reviewers for a project or branch, see project or project branch.
Example: if a user is a Required reviewer, the voting option cannot be reduced to a less strict option such as Optional reviewer.
Example: if a group is an Optional reviewer, the voting option can be increased to a stricter option such as Required reviewer (one vote).
When an individual user/group default reviewer is retained for some of the projects and branches the review spans but not for others, the strictest voting option is used for a default reviewer on the review. The strictest retained default reviewer voting option is the minimum voting option for the user/group default reviewer in the review.
Example:
      |
|