Launchpad Entry: updated-revu-workflow
Created:
Contributors: mok0,
Packages affected:
The Problem
The processing of new packages submitted to REVU by the community could benefit from a clearer workflow. At the moment, packages are queing up on the REVU site, and are reviewed partly on a first-come-first serve basis, partly on requests on IRC, and partly on an ad hoc reviewer interest basis.
Many uploads slip through the cracks, and sit for months without receiving attention.
Summary
The processing of new packages could benefit from a clearer workflow. The proposal is not fundamentally different from what we have now, in fact I think it can be implemented with very few modfications to the existing software. What is required is mostly a re-organization of the current REVU HTML page into several distinct "lists".
ASCII-graphics sketch of the proposed workflow:
1 2 3 4 5
Unreviewed ====> In Process <====> Advocacy <====> Upload ====> Archive
| | | |
<===== <=====The above workflow is virtually identical to the current one. What is different in this proposal is:
- Each of the stages 1-5 is represented by its own web-page.
The 'Unreviewed' list (stage 1) is separate and can be closed for new uploads.
A package in 'Advocacy' (stage 3) stays there, even after a new upload.
- Current "updated packages" category is abolished, packages enter the normal workflow, but are labelled as "update to existing package".
- Main web page entry point is static with a list of links to individual stages, help pages etc.
Proposal
* The proposal is enumerated to facilitate a discussion.
Unreviewed List
1.1 New uploads, never reviewed, are stored on a separate 'Unreviewed' list.
1.2 This list can be CLOSED for new uploads at the decision of the MOTUs.
1.3 When a package on the 'Unreviewed' list receives a review, it will automatically move to the "needs-work" section of the 'In Process' list
1.4 Packages in the 'Unreviewed' list can be deleted by MOTUs
In Process List
2.1 When a package on the 'In Process' list receives a new upload, it moves to the "needs-review" section
2.2 When a package receives a review, it moves to the "needs-work" section.
2.3 When a package has one advocate, it moves to the "needs-review" section of 'Advocacy' list.
Advocacy List
3.1 When a package on the 'Advocacy' list receives a new upload, it moves to the "needs-review" section.
3.2 When a package receives a review, it moves to the "needs-work" section of 'Advocacy'.
3.3 When a package receives a 2nd advocate, it moves to the 'Upload' list.
3.4 If an advocate of a package in the 'Advocacy' list removes the advocacy, the package moves back to 'In process'.
Upload List
4.1 The package remains here until it is uploaded.
4.2 After upload, the package moves to the 'Archive' list.
4.3 If an advocate of a package in the 'Upload' list removes the advocacy, the package moves back to 'Advocacy'.
Misc
5.1 "Updated packages" as a separate list is abolished. Those packages appear in the normal workflow, but are labelled with a special icon or text string.
Rationale
The 'Unreviewed' list can be closed, giving MOTUs a way to regulate the in-flux of new uploads to match the number of available reviewers.
Packages can remain in the 'Advocate' list even if another reviewer asks for another upload. This eliminates the frustration uploaders have when having to ask a MOTU to reconfirm an earlier advocacy. When a package moves to 'Advocacy' stage, uploaders gets a sense that "things are moving forward".
- Upgrades of existing packages are clearly labelled as such, but otherwise participate in the same workflow. MOTUs can easily spot upgrades, which are often "bite-size" reviews.
Design
The proposal requires only minor modifications to the existing REVU software.
Use Cases
- Jill wants to upload a package to Ubuntu, but discovers a message saying the upload queue is closed because the next release is in Feature Freeze. Jill is happy not to waste her time, and decides to get a Debian Sponsor instead.
Theodor is new at packaging, and his package has gone through many review cycles in the 'In Process' list. When his package receives an advocate and moves to the 'Advocacy' list, Theodor is pleased and proud of his accomplishments. He goes on IRC to look for another advocate.
Morten is a MOTU with limited time, but wants to process a bite-size review. He grabs a package from the 'Advocacy' List, knowing that it's close to being ready. He finds a problem with Theodors package, and is not worried about asking for another upload, because he knows it will not send a desparate Theodor back looking for an advocate all over again.
Mark is a MOTU with an interest in software that enhances the desktop. He goes to the 'Unreviewed' list and finds an exiting new utility that allows the user to draw on the root window. Mark becomes exited and sets Bug #1 to "Fix committed".
BoF agenda and discussion