Last modified: 2014-02-28 13:52:24 UTC
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.
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...
(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.
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
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...
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"...?
(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.
(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?
(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).
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.
(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.
(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.
