Commit Access: super-reviewer "from outside the modules" requirement
Gavin Sharp
requirement, since the two are separate issues.)
On Fri, May 22, 2009 at 4:12 PM, Robert Kaiser <ka...@kairo.at> wrote:
> Mitchell Baker wrote:
>>
>> --one super-reviewer from outside the modules in which you have been
>> working. The goal here was to make sure we didn't have unintentional
>> "group-think" or that a couple of module owners/peers being overly
>> optimistic as a result of being friendly with the candidate.
>
> Not sure if it belongs into this thread but as this is the only
> "anti-group-think" clause left in the proposal, I think it needs to be said
> that this is problematic by itself as people with the super-reviewer hat on
> are supposed to *not* considers themselves as belonging to any specific
> module but as someone overlooking the interaction and integration of the
> whole or large parts of the codebase.
> Somehow this rule contradicts itself and I heard super-reviewers being
> unsure of who to take this rule, actually.
Indeed, this part of the rule has bothered me for a long time (I think
I objected to it when the current policy was initially proposed). It's
never been clear what it means for a superreviewer to be "from outside
the modules in which you've been working", as Robert points out, since
super reviewers are not explicitly assigned to modules. I don't think
this rule has fulfilled its purpose of preventing "group-think" in
practice. I watch account request bugs, and I don't recall seeing any
cases where enforcing this requirement has been beneficial, in my
opinion. I have seen it delay account requests unnecessarily while
people argued about whether a given superreviewer or patch was "in" a
module.
I'm not convinced there's a need for this kind of requirement at all,
since I trust our currently eligible vouchers/superreviewers to make
these decisions based on more than just camaraderie, despite the often
strong forces of peer pressure. If people feel strongly that this kind
of requirement is necessary, I think that changing the requirement to
be something along the lines of "your vouchers must collectively be
owners/peers of at least 3 different modules" or "your vouchers must
not all be owners/peers of the same module" would be an improvement,
since it's far less subjective and simpler to enforce.
Gavin
Mike Connor
On 22-May-09, at 6:07 PM, Gavin Sharp wrote:
> I'm not convinced there's a need for this kind of requirement at all,
> since I trust our currently eligible vouchers/superreviewers to make
> these decisions based on more than just camaraderie, despite the often
> strong forces of peer pressure. If people feel strongly that this kind
> of requirement is necessary, I think that changing the requirement to
> be something along the lines of "your vouchers must collectively be
> owners/peers of at least 3 different modules" or "your vouchers must
> not all be owners/peers of the same module" would be an improvement,
> since it's far less subjective and simpler to enforce.
I think the current group of superreviewers all have established their
sense responsibility and discretion, so I generally agree that the SR
group can likely be trusted to make objective and often difficult
decisions. That said, I do think that some check against group
optimism would be great.
If we are treating the two vouchers as the technical evaluation
portion, perhaps the SR is the primary person for ensuring that people
are integrated reasonably. Perhaps a good criteria is that the SR
can't have reviewed any patches from the potential committer? This
would be objectively verifiable, and would generally mean that the SR
would have less direct history (i.e. I would be a good SR for a Gecko
hacker, unlikely for a Firefox/toolkit hacker).
Thoughts?
-- Mike
timeless
> If we are treating the two vouchers as the technical evaluation portion,
> perhaps the SR is the primary person for ensuring that people are integrated
> reasonably. Perhaps a good criteria is that the SR can't have reviewed any
> patches from the potential committer? This would be objectively verifiable,
> and would generally mean that the SR would have less direct history (i.e. I
> would be a good SR for a Gecko hacker, unlikely for a Firefox/toolkit
> hacker).
While generally not unreasonable, I think some provision should be
provided for the silly edge case where someone has actually interacted
with all or perhaps even most sr's. It shouldn't happen, but it isn't
impossible for someone to not actively request an account, or perhaps
to even have had their account expire. In either case it could be that
they've interacted with most of the sr's. There are actually some
recent cases where people are surprised to find out that a certain
person doesn't have an account.