You can go ahead and join groups with this method and still not
receive emails. We only email people individually if there is no
mailing list associated with the group. People can join the group but
not the mailing list and shouldn't see the emails.
Now, if you are on the target reviewer list or you ever review the
review request, you will be directly on the CC list. This we can make
optional in a future version.
On Tuesday, June 2, 2009, Helder Ribeiro <hel...@gmail.com> wrote:
> On Tue, Jun 2, 2009 at 3:52 PM, Chris Clark <chris.cl...@ingres.com> wrote:
>> Vesterbaek wrote:
>>> I would find it useful to to be able to configure this independently
>>> for groups and people, such that a user can choose to be member of a
>>> particular group, but not receive any emails from review requests to
>>> that group, but only get emails if a review request is directed at the
>>> user (listed in "people").
>>> - We have a number of development teams, which each map to one or
>>> more reviewboard groups. I've setup "default reviewers" for the
>>> different groups based on the repository paths of the files in the
>>> review requests. We do it this way to make sure that all developers
>>> can easily stay orientated about different review requests that is
>>> relevant for them, and possibly comment if they feel like doing so.
>>> They should not (be forced to) receive emails about these group review
>>> requests. Mandatory reviewers are put in the "peoples" field, and
>>> these should normally receive emails.
>> The way we tackle this is with (Mailman) mailing lists. People join the
>> mailing list and have the usual options; all emails, digest, or no emails.
>> We then making the mailing-list-email-address the group email address
>> and NEVER add anyone to the Reviewboard groups.
>> Then when posting a review add the group, and the specific people.
> Great idea! So this way the review requests don't get listed on
> people's reviewboard inbox right? Can they be browsed somewhere? I was
> looking for a way to make review requests feel more "optional" as a
> way to introduce code review in a company that's not used to it. This
> way I could install a post-receive-hook that would create a review
> request for every commit, but that wouldn't make anyone responsible
> for it. This way people could just browse past commits and comment on
> them if they felt like it. Hopefully feedback would increase to a
> point where more formal adoption could be established.
>> Not exactly what you asked for but can accomplish the same thing. This
>> works for us as we had an existing mailing list already in place,
>> reviewboard simply makes life easier for the people that want to use
>> Reviewboard, this use case may not work for everyone.
Christian Hammond - chip...@chipx86.com
Review Board - http://www.review-board.org
VMware, Inc. - http://www.vmware.com
You received this message because you are subscribed to the Google Groups
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to
For more options, visit this group at