DMB: Proposal for a different review process
Chase Douglas
chase.douglas at canonical.com
Wed Aug 3 19:04:14 UTC 2011
On 08/02/2011 09:33 AM, Chase Douglas wrote:
> My proposal would be to do away with formal meetings, at least for
> evaluating typical applications, and move them to Launchpad. Create a
> project (maybe "ubuntu-developer-membership") and then have people open
> bugs when they have something to bring up before the board.
There seem to be people who are in favor of this and people who are
sceptical. That's fine for now, but I think it would be worthwhile to
explore this option. This could also be used to supplement rather than
replace the current mechanism in cases where timezones don't line up or
at the applicants preference.
I created a script that would process Launchpad based DMB applications.
To do this, I am (ab)using the qastaging LP instance. I've created a
test scenario as follows:
New team: test-dmb-team
Members: Me
New project: test-dmb
The scenario is: I (Chase Douglas) am filing an application for Core
Dev. I created a bug for the application:
https://bugs.qastaging.launchpad.net/test-dmb/+bug/800139
If the bug disappears, it's because they wiped the qastaging instance. I
can recreate the bug with a script, so let me know if you want to see it
but it's gone
Here's where it gets a bit confusing: I can create a bunch of stuff on
qastaging, but I can't create new LP users to act as dummy DMB board
members. Thus, in the bug you see a mix of stuff from myself (the
applicant), and myself (the dummy DMB member), and myself (the output of
the script). I also had to set the threshold for approval to +1 since I
can't get anyone else to vote :).
If you go to the bug you'll see the end result. I'll explain what
happened in a timeline fashion:
1. I filed the bug. The description started at "I, Chase Douglas, apply
for core developer membership". The header was not present. The status
is New and no one is assigned.
2. The DMB ran the script (remember, I am also the DMB so it says I made
these changes). The status is moved to In Progress and the DMB team is
assigned. The comments are searched for anyone on the DMB who has made a
comment with only the following text: "+1", "0", or "-1". These are
considered votes and are tallied and prepended as a header to the
comment description. If a DMB member votes more than once, only the last
vote counts. The approval threshold is checked, but is not met yet.
3. A DMB member (myself again!) leaves a comment and a vote ("+1"). The
script is re-run, and the votes are tallied. The application meets the
threshold, so the header is updated and an "Official" notification of
approval is made as a comment. Since anyone can edit a description, this
official notification serves as the real testament of approval since the
comment creater is authenticated and obvious. The status is moved to Fix
Committed.
4. (Not done yet) A DMB member follows up and twiddles any bits required
to give Core Dev status. The member would then move the bug status to
Fix Released.
-----
The next step would be to generate a web page with the status of all the
open applications so the DMB team can review it and quickly determine
what needs to be done. The web page would list vote totals, who has
reviewed, who still needs to review, and the status for each
application. I didn't do this yet because I was interested in feedback
on this approach overall.
P.S.: Code can be found at lp:~chasedouglas/+junk/dmbscripts. It's very
raw and obviously copy/pasted in the current form
Thoughts?
Thanks!
-- Chase
More information about the ubuntu-devel
mailing list