Open Bug 242194 Opened 20 years ago Updated 7 years ago

Add a bit which prevents people from making requests of a person

Categories

(Bugzilla :: Attachments & Requests, enhancement)

Product:
Bugzilla
Component:
Attachments & Requests
Version:
2.17.6
Platform:
x86
Windows 2000
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

People

(Reporter: timeless, Unassigned)

Details

<rocWork> we *really* need a "not accepting reviews at this time" bit in Bugzilla

I'm fairly certain bz would use this. We should set it for nobody@mozilla.org too.

I think this should be per product. So I could say that I want to accept
requests for Webtools and nothing else.

<aaronlev> I think the "not accepting reviews at this time" bit should
automatically be set when the reviewer has ignored n requests >= m days old

I'm not sure on this point. If we do that, it should automatically email the
account and watchers indicating the list of requests that were outstanding and a
note that it (bugzilla) has automatically set this flag.
> I'm not sure on this point. If we do that, it should automatically email the
> account and watchers indicating the list of requests that were outstanding and a
> note that it (bugzilla) has automatically set this flag.

I like that. How about a warning email or two first, saying something like "This
is an automatic nag from Bugzilla. It looks like you're no longer an active
reviewer -- you have n unfulfilled requests greater than m days old. If this
isn't true, please clear some of the requests in your queue."
Another indicator that someone actually is active, is that they have fulfilled a
review request. That should automatically clear the flag for a few days afterward.
I don't really like that idea.  See my request queue for why.

We should be deciding active vs not active based on time of last review done, I
would think, not based on the queue... (though that has its own issues).

Also, I would in fact be unable to use this flag as suggested at the moment for
my current situation (accepting r= requests in components I peer but no other
requests).
If a request gets older than 7 days, shouldn't the requestee should at least
post a reason that they're not getting to it? I say clear it and give a reason
or just do the request.


You didn't look at my request queue like I asked, did you?  First of all, 7 days
is about how long it takes me to get to a request (and is about how long it
takes to get to a non-trivial request in general).  I'll always post with an
ETA, but for a request that takes 5-6 hours in a chunk to fulfill, getting to it
on short notice can be a little difficult.

Second of all, I have a request I set on myself as a reminder to look at the
diff sometime.  It's old, and will likely get older until I have several days or
weeks of free time on my hands.  At the same time, it's not like I'm not doing
reviews.
Boris, guys like you are obviously not the problem. If requestors had a clue
about the ETA when they post a review request in general, that would be awesome.
It would help Mozilla move along. As it is, requestors don't know whether the
reviewer intends to review it today, in a week, or has even noticed the request. 

How do we deal with stagnation in our project? Can the bugzilla infrastructure
help a bit more or do we just throw up our hands?

It really is possible to make it easier to get stuff done in Mozilla -- that's
all I'm saying. I'm just brainstorming here, and I don't disagree with your
"time of last fulfilled request algorithm". Feel free to join in with more good
ideas.

Does anyone disagree that the current solution of going on IRC or emailing
people to find out what's happening with a requestor doesn't work very well?
So what I think we should do is

1)  Exclude requests where the requester and requestee are the same from any
    algorithm we use (I'm not the only one who uses such requests as reminders).
2)  Factor in the last request time somehow.

I'm not sure how #2 should work exactly...

I agree that the mail/irc thing is unworkable in general.
> Also, I would in fact be unable to use this flag as suggested at the moment for
> my current situation (accepting r= requests in components I peer but no other
> requests).

Separate r and sr flags per component would enable this, right?

Having these flags that one could turn on and off would be a wonderful first
step. A policy for automatically turning them on and off might be useful but
it's not necessary. I think that should be split off to a separate discussion.

Note that with these flags, the review request field could become a list, which
would help a lot.
Is the point here to 
(a) Make it possible to ensure that only authorized reviewers can be requested
to review a patch or complete the review
or
(b) To enable users to declare themselves unwilling to be requested
???

For (a), this should be a group chosen on a per-flag basis. The pattern matching
code should use this also.


The point is (b).  (a) is not even technically feasible, in my opinion (that is,
whether a reviewer is authorized totally depends on the patch).
I'd say a secondary point is (a') help patch authors who aren't yet familiar
with the org structure by making sure that only people who might plausibly be
able to review a patch can be selected as requestees.
And yeah, this would help the pattern matching code. I could go back to typing
"dbaron" without worrying about matching Christopher D Baron :-).
but ideally we could stop using the pattern matching code for requestees and
just show a combobox with all the names. There shouldn't be too many.
Right.  18 people is a good number for a drop-down list.  400 (my site) to 40000
(bmo) are a bit much.

If we do a drop down list, would it be useful to have something like:

Name (days since last review)
Dbaron (3)
Bzbarsky (1)

or some useful info next to each name so you can gauge their status.
QA Contact: mattyt-bugzilla → default-qa
Assignee: myk → attach-and-request
Unless I've misunderstood what's being asked for here, this has been fixed as a b.m.o.-specific customization. 
https://bugzilla.mozilla.org/userprefs.cgi?tab=flags
Uncheck the boxes for request types you are not accepting requests for.

Gerv
That's cool! I guess this bug is fixed then.

However this bug hasn't really achieved what I want, because these flags are enabled by default. They should be disabled by default.
Roc: are the lists of people for whom the boxes should be checked already clearly defined? That is to say, if we were to migrate from default-on to default-off, are there, for each flag, complete and up-to-date lists of people we should turn back on?

Gerv
No.

However I think you could get pretty good results by setting the flag "accepts requests of type X" for everyone who has ever +ed a request of type X.
I propose that we disable requests for the following flags:

* super-reviews: disable the checkbox for everyone except the actual list of super-reviewers
* review and ui-review, disable the checkbox for everyone without "editbugs"
You need to log in before you can comment on or make changes to this bug.