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)
Tracking
()
NEW
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.
Comment 1•20 years ago
|
||
> 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."
Comment 2•20 years ago
|
||
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.
Comment 3•20 years ago
|
||
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).
Comment 4•20 years ago
|
||
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.
Comment 5•20 years ago
|
||
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.
Comment 6•20 years ago
|
||
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?
Comment 7•20 years ago
|
||
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.
Comment 9•20 years ago
|
||
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.
Comment 10•20 years ago
|
||
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.
Comment 14•20 years ago
|
||
Right. 18 people is a good number for a drop-down list. 400 (my site) to 40000 (bmo) are a bit much.
Comment 15•20 years ago
|
||
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.
Yeah, that'd be great :-)
Updated•18 years ago
|
QA Contact: mattyt-bugzilla → default-qa
Updated•18 years ago
|
Assignee: myk → attach-and-request
Comment 17•15 years ago
|
||
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.
Comment 19•15 years ago
|
||
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.
Comment 21•15 years ago
|
||
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.
Description
•