Page MenuHomePhabricator
Create Task
Maniphest T27270

Review queues in CodeReview
Closed, DeclinedPublicFeature
Actions

Description

I think CodeReview should have per-user review queues. If other folks agree with this plan, I'll hack at this at the Hack-A-Ton (could use a hand, though).

Basically my vision of this is that I'd set a few rules (path-based, probably) based on which new revs would automatically be added to my queue. I would also be able to add and remove individual revisions from/to my queue (in bulk, using the existing checkboxes). It should be possible to filter my queue by status so I can e.g. isolate fixme's. Revisions I mark as good (OK, deferred or verified) should be removed from my queue automatically. Revisions others marked as good should be hidden from the queue view by default and maybe be automatically removed from it too (not sure about the latter).

I'm personally responsible for reviewing a bunch of different, mostly unrelated things, and it'd be nice to have multiple review queues for this with their own filters, much like e-mail clients have folders with filters filling them.

Also, it may be nice to be able to push a revision into someone else's (read: Tim's) review queue. If the multiple queue thing is implemented, this could go into a separate "things other people think I should review" queue so as to not get in the way of other things.

Version: unspecified
Severity: enhancement

Details

Reference
bz25270

Event Timeline

• bzimport raised the priority of this task from to Low.Nov 21 2014, 11:14 PM
• bzimport added a project: MediaWiki-extensions-CodeReview.
• bzimport set Reference to bz25270.
• bzimport added a subscriber: Unknown Object (MLST).
Catrope created this task.Sep 23 2010, 6:27 PM
Reedy added a comment.Sep 24 2010, 11:08 AM

Giving the CodeReview extension a nice kicking whilst in DC (note the amount of stupid bugs it has doing daft things)

Tying in with this, bug 24380 "Allow CodeReview revisions to have multiple reviewers", might be a nice related thing to look at fixing...

Catrope added a comment.Sep 24 2010, 2:49 PM

(In reply to comment #1)

Giving the CodeReview extension a nice kicking whilst in DC (note the amount of
stupid bugs it has doing daft things)

Right! I'd totally forgotten about those.

Tying in with this, bug 24380 "Allow CodeReview revisions to have multiple
reviewers", might be a nice related thing to look at fixing...

Another personal pet peeve; didn't know a bug had been filed about this already, thanks for pointing me to it.

vvv added a comment.Dec 5 2010, 11:07 AM

Reassigning this to myself, with Roan's permission.

My plan is that we would have many review queues, each of them could be public or private. Each queue is merely a filter of different revisions.

As a technical detail, I plan to rewrite the CodeRevisionListView so all the filter conditions are handled by single class. That will help to clean up GET param mess (by passing all filters as queries to a single module) and easily implement the queue view as a CodeRevisionListView with appropriate params.

Oh, and the SQL scheme: http://www.mediawiki.org/wiki/User:VasilievVV/cr-queues.sql

Reedy added a comment.Dec 5 2010, 2:08 PM

It sounds like, (and thinking about it, I suppose was the original intention), is to implement something akin to the bugzilla saved searches

With Author, Path and Status being the 3 main (only?) "search" parameters. Looking at your schema, you've done path, status and timestamp. So I suppose, that's 4 now.

I see no need for revision ranges, or similar. Maybe add tags in there too?

If you can clean (or at least start), the query params (bug 26240), that'd be great.

I suppose, you're likely to find some more unindexed queries (bug 24479) too...

Reedy added a comment.Dec 5 2010, 2:21 PM

Also, can we add watchers (ie the user subscribes) to the queue like happens in Bugzilla?

ie
These are all the shared queues, Tick some, add to "My Queues"...?

vvv added a comment.Dec 5 2010, 4:32 PM

(In reply to comment #4)

It sounds like, (and thinking about it, I suppose was the original intention),
is to implement something akin to the bugzilla saved searches

Yes, this is pretty close.

With Author, Path and Status being the 3 main (only?) "search" parameters.
Looking at your schema, you've done path, status and timestamp. So I suppose,
that's 4 now.
I see no need for revision ranges, or similar. Maybe add tags in there too?

Right now in my working copy there are five: timestamp, author, path, status and tag.

(In reply to comment #5)

Also, can we add watchers (ie the user subscribes) to the queue like happens in
Bugzilla?

I thought about implementing Bugzilla-like CC lists.

• bzimport added a comment.Dec 5 2010, 4:44 PM

Bryan.TongMinh wrote:

(In reply to comment #6)

With Author, Path and Status being the 3 main (only?) "search" parameters.
Looking at your schema, you've done path, status and timestamp. So I suppose,
that's 4 now.
I see no need for revision ranges, or similar. Maybe add tags in there too?

Right now in my working copy there are five: timestamp, author, path, status
and tag.

Are they and-ed or or-ed?

vvv added a comment.Dec 5 2010, 4:57 PM

(In reply to comment #7)

(In reply to comment #6)

With Author, Path and Status being the 3 main (only?) "search" parameters.
Looking at your schema, you've done path, status and timestamp. So I suppose,
that's 4 now.
I see no need for revision ranges, or similar. Maybe add tags in there too?

Right now in my working copy there are five: timestamp, author, path, status
and tag.

Are they and-ed or or-ed?

The combinations are ANDed. The tags themselves are mostly ORed (e.g. author is filter by set of authors, etc).

Catrope added a comment.Dec 7 2010, 4:11 PM

I was personally hoping to be able to have queues that you can just throw random stuff in, but this saved searches stuff would be a big step forward already.

Peachey88 added a comment.Dec 8 2010, 1:36 AM

(In reply to comment #3)

Reassigning this to myself, with Roan's permission.

My plan is that we would have many review queues, each of them could be public
or private. Each queue is merely a filter of different revisions.

Why would we need/want private queues? the code is already public.

Reedy added a comment.Dec 8 2010, 9:46 AM

(In reply to comment #10)

(In reply to comment #3)

Reassigning this to myself, with Roan's permission.

My plan is that we would have many review queues, each of them could be public
or private. Each queue is merely a filter of different revisions.

Why would we need/want private queues? the code is already public.

Why would we need/want private bugzilla searches? the bugs are already public.

gpaumier unsubscribed.Jul 18 2018, 5:57 PM
Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:00 AM
Aklapper removed a subscriber: • wikibugs-l-list.
Bugreporter closed this task as Declined.Thu, Apr 11, 1:57 PM
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL