The New Reviewers List

Benton, Kevin kevin.benton at amd.com
Fri Mar 25 16:13:09 UTC 2005


> > That's my whole point - if the reviewer changes in the role address
> > model (versus the personal address model), the destination doesn't
> > change.  They still use the filename-... role account.  It also
allows
> > the people doing the reviews for a particular component of Bugzilla
to
> > see the entire list of reviews being requested rather than some get
one
> > list and others get a different one.  :)  I've thought this through
and
> > used this type of method before - it really works well. :)
> 
> IMO, role accounts don't cut it. A review in your personal queue feels
> considerably more urgent than one in a "anyone can do it" queue. For
me,
> it's a personal matter of honor to keep my review queue short (not
that
> I hadn't failed at times, though), but I wouldn't take the same
attitude
> towards a "component queue". Remember, the whole debate started from
the
> fact that the current role queue ("from the wind", aka "any reviewer")
> never got any attention.

I agree that a personal queue feels more urgent, however, I think we can
agree that a team queue is more urgent than "from the wind".  Does that
sound like a better "happy medium"?  I don't think any of us would
really want to look at the "from the wind" review list much because we'd
already know before looking at it that the list would be filled with
"stuff" to be reviewed that we're not reviewing for.  On the other hand,
if we had a role list, I think I would be more inclined to check it than
the "wind list."

> Besides, one of the key aims here is to get new contributors closer to
> the reviewer team, and it's easier to become friends with a person
> instead of a role. That said, your arguments do have validity (and
I've
> successfully used the system you described, too) - it's just that I'm
> not sure the concept would be the best solution _here_. I say we
should
> try the personal approach and think again if this fails.

Okay - that's perfectly reasonable if the reviewer is the only person
for a particular piece of the code.  Why not encourage individual
contributors to email their "favorite" reviewer after they've assigned
the review to the role account giving that reviewer the opportunity to
take it for themselves?  That way, if the reviewer is over-loaded (or
not available), one of the other team members has the opportunity to
pick it up.  Again, my main concern is accounting for what happens when
reviewers are (for whatever reason) not available for this particular
review.

I too agree that you bring up valid points.  I hope we can come to an
agreement mid-way :)  That made me think - what is the harm in
establishing the role accounts and still publishing the list?  The role
accounts could be set up as mailing lists for potential reviewers of
that product.  When the review is requested, the requested reviewer
account should be emailed, which would cause the team of reviewers for a
particular item to be emailed.  Then, people who would prefer to use the
role accounts could, and those who would prefer to use the personal
emails could do that too.  We could see how both work for a while and
make a decision later whether or not to keep the role accounts.  How
does that sound?


---
Kevin Benton
Perl/Bugzilla Developer
Advanced Micro Devices
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have
received this communication in error, please notify the sender, then
destroy any remaining copies of this communication.





More information about the developers mailing list