Re: [boost] Tracking Review Requests and RM Applications

From: Douglas Gregor (dgregor_at_[hidden])
Date: 2007-06-15 08:16:23

João Abecasis wrote:
> For those who missed it, I suggested on the "Languishing review 
> requests" thread that we keep track of Review Requests and Applications 
> for Review Managers in the ticketing system. The goal being to avoid the 
> "silent rejection" problem.
>   
I'm not convinces this problem is really a serious problem. Sometimes, 
there just isn't much interest in a given library, and the silence that 
comes along with that means that the library shouldn't move forward into 
the "formal" parts of the review process (finding a review manager, 
scheduling a review, etc.). Still, my view on this doesn't mean that I 
don't agree with your ideas below... because I do.
> Below I offer some suggestions on how this could work, just to get the 
> discussion rolling.
>
> * Ticket Type: we could use one or two more ticket types: (Library) 
> Review Requests and a Review Manager Application. Perhaps a single 
> generic "Review Request" would work just as well, to begin with.
>   
Let's just have one ticket type. I suggest calling it "Library 
Submission", because that seems to cover the whole process.
>
> * Reporter: The person submitting the review request or RM application
>
> * Status: Assigned would be used when a Review Manager has been 
> assigned. He is responsible for "closing" the review ticket.
>   
Sounds good. Actually, we might want to take this one step further: once 
a review manager is assigned, the ticket is passed to that person. When 
the formal review is completed (and assuming the library is accepted), 
the review manager could bounce the ticket back to the author. The 
ticket is closed, and milestone assigned, when the library is integrated 
in CVS/Subversion (and we therefore know the version in which the 
library will appear). That means one will be able to easily tell which 
version of Boost a library will appear in, just from the ticket system.
> * Owner: per above, this would be the Review Manager for a library 
> submission and the Review Wizard for other types of requests.
>   
Ah, okay. So initially,. the review wizard would own the ticket, then 
pass it to the review manager, then finally to the library author before 
it's closed?
> * Milestone: Perhaps a bit far-fetched, but this could be used to follow 
> the library library submission process 
> (http://boost.org/more/submission_process.htm). This allows one to check 
> at a glance libraries in each stage. It could also clutter the Roadmap 
> page. None of these Milestone Steps would advance: tickets would 
> progress from one to another.
>   
Let's not do this. Milestones should be reserved for Boost and tool 
releases.

Anyway, we can easily create custom reports that would only look for 
library submissions, grouping them by milestone (which automagically 
shows which Boost release a library will appear in). Creating new 
reports in Trac is as simple as adding a new SQL query to 
http://svn.boost.org/trac/boost/report

> * Version: Version of Boost with which the library was tested? Version 
> for inclusion after acceptance?
>   
"Milestone" seems a better match for this, but either one will do.
> * Component: "Boost Process"
>   
Okay.
> And if you've got this far... Do you think this is a good idea in 
> general? Do you think something like this adds more "process" with
> no or little gain? Is it any friendlier to potential submitters? How 
> about potential review managers? ...
>   
I think this is a good idea. It gives us a better "paper" trail to see 
where each submission is, and can help automate some of the tasks that 
the review wizards and review managers are already doing.

Here's my suggestion: write up a page on the Trac describing how to use 
the ticket system to track the library submission process (which will 
probably just be called LibrarySubmissionProcess). Write it as if this 
were *the* submission process documentation, integrating all of the 
material from http://boost.org/more/submission_process.htm along with 
the instructions/links to the right places in the Trac system.

If you like the names "Boost Process" (for the component) and "Library 
Submission" (for the ticket type), then drop me a line and I'll add 
those to the Trac.

I've enabled the ability to create and modify reports on the Trac 
(assuming you already have access to the Subversion repository; if not, 
see http://svn.boost.org/trac/boost/wiki/BoostSubversion). I would 
suggest that you take some of the entries on 
http://boost.org/more/formal_review_schedule.html and create tickets for 
them retroactively (even for older, accepted libraries). Then, you could 
add a Trac report that shows the status of all of the library submissions.

I like your idea to use the Trac ticket system to keep track of reviews. 
I'm also interested in migrating developer-centric content from the web 
site over to the Trac, where it can be more easily maintained, and in 
replacing hand-maintained web pages (like the formal review schedule) 
with auto-generated reports, where possible. In the end, however, Tom 
Brinkman and Ron Garcia manage the formal reviews, and these tools are 
meant to make their jobs easier along with helping others better 
understand the process.

  - Doug