>> needs-spec >> needs-design >> needs-patch >> (needs-testing?) >> needs-review > > Actually, it would need a different name, because "needs-testing" is for > patches that were already committed and need testing on the staging server. > (Sez Mark.) Perhaps "early testing" or "mass testing"?
Alternately, we could rename this to needs-verification. So the idea is: 1) feature is requested 2) needs-spec? = spec is designed 3) needs-design? = design is made based on spec 4) needs-patch? = both of the above are ready (or not needed), coder GO 5) needs-testing? = new proposed step for someone who wants external testing (optional?) 6) needs-review? = ready to review 7) needs-commit? = ready to commit 8) needs-verification? = is committed, and someone should verify the behavior on stage (this is like needs-testing but later?) 9) needs-merge? = all's good, let's merge this for the next live release Wow, that's a lot of steps. Too many? Let's optimize. How can we make sure this process is NOT overwhelming for everybody? >> (needs-review I'm taking to be Mark officially reviewing the patch for >> committing into the codebase. > > It includes that, but I don't see any reason why it should be limited to > that. (Eg, if someone else is working in an overlapping area of the code, > they may want to have a look. Or if it creates a dependency with another > bug, maybe because it uses DW::Request in a way that doesn't work yet, but > that will work when another bug is fixed.) +1, the idea is for other people to become reviewers and hopefully committers in their particular areas. At this point, I don't think we need to spread out yet, but we're getting pretty close. I've been contemplating when to ask one or two people to start handling reviews. Then I can wait for the needs-commit? and go from there. (And eventually, things will get reviewed and committed by volunteers/staff, but we'll probably maintain one merge point for the forseeable future. Even the Linux kernel operates this way, and it's a huge project!) >> I think that could work, but I worry that without any way to notify >> interested parties explicitly, the patch could just sit there and be >> ignored. > > True, but that's also true of the current needs-testing. There should be a list of "here, if you're interested in $x, use this Bugzilla query and bookmark it" sort of things. I have a few right now, one is "review?" and it shows all OPEN bugs with needs-review? on an attachment. >> Doing a shout-out on IRC, or over here in DW-discuss could be better >> for pinging potential testers, but possible problems: I think that not >> everyone interested hangs out in IRC, and that it could potentially >> get spammy if posted on dw-discuss. It's less spammy if only the >> original shout-out is posted to the list, and all other discussion is >> done either through one-to-one correspondence, or on the bugzilla >> report itself, but I'm still worried that the additional volume could >> force other subscribers to start tuning out all mail from dw-discuss. > > Maybe another mailing list for discussing code? Or one for coding > specifically, and one for testers? We've talked about having a dw-dev or something. I'm still leaning towards "not enough traffic to warrant a separate list". Although I guess there are 280-ish people on dw-discuss... If anybody has any strong opinions about separating out development chatter, feel free to speak up! -- Mark Smith / xb95 [EMAIL PROTECTED] _______________________________________________ dw-discuss mailing list [email protected] http://lists.dwscoalition.org/cgi-bin/mailman/listinfo/dw-discuss
