[development] Perm for setting RTBC - Re: RTBC - how does it work?

[Derek Wright]

On Jul 2, 2007, at 8:22 AM, Augustin (Beginner) wrote:

> Well, there is a permission for "set issue status patch (ready to  
> commit)"
> in  ?q=admin/user/access .
> Why not make good use of it?

In theory, I'd support this.  The per-status permissions have always  
struck me as a bit weird, but this is actually a pretty reasonable  
use case for one of them. ;)

There are a few minor bugs in how these permissions work that we'd  
have to fix before this really worked.  For example, if we  
implemented this, once a blessed reviewer set to RTBC, if anyone else  
without the perm tried to followup, the status would revert.  We need  
to fix the perms so that even if you don't have permission to move it  
into RTBC in the first place, if it's already there, you can leave it  
there.  This is trivial, and there's already an issue open about  
this, but just wanted to point out there might be a few minor gotchas  
like this as we start to implement role-based issue status  
functionality.  Nothing that can't be solved, of course.

HOWEVER, the big problem here is that these permissions are site- 
wide.  And I'm not sure we want the same restriction to apply to who  
can RTBC in *all* issue queues across the site, do we?  I presume  
people are imagining this for the core queue, but not all queues.   
So, that's a big problem.  Either we accept that it's site-wide and  
basically make it harder for people to RTBC non-core issues, or we'd  
have to do a bunch of work to make these perms somehow per-project,  
not site-wide (og_project.module, anyone? ;) -- just kidding).

So, if people are going to +1 this proposal, please understand it'll  
basically have to be site-wide, and that we'd have to find ways to  
cope with that across all the contrib issue queues.  I don't get the  
sense that most contrib issue queues actually make much use of RTBC,  
anyway.  It seems rare to find non-core queues where it really  
matters, or where there are a pool of reviewers and testers outside  
of the maintainers themselves.  And in the rare cases where that's  
happening, I'm guessing the maintainers of those contribs would be  
happy to have the same pool of qualified reviewers with the perm to  
RTBC.

All of that said, I still think this is worth seriously considering.   
It certainly won't solve all the problems, and it might create a few  
of its own, but overall, I think this is a reasonable suggestion.

-Derek (dww)