Just in summary, the major changes that you are proposing here (which aren't really particularly _major_, but still) are:<br><br>1) tickets should only go into the 'none' milestone if you don't understand our ticket system.<br>
2) tickets without a patch or that are not being actively worked on should go into "Future".<br>3) Only tickets with an attached patch should be marked "needs more work"<br>4) Any ticket that has a patch and is ready to go into trunk should be put in the current milestone and marked "review"<br>
<br><br>yes? <br><br><br>Also, I would like to give another vote of confidence to the section of your email here in which you encourage<br>other, not-necessarily-committers, to take a crack at reviewing patches. Well put. Just because you don't <br>
yourself have commit rights doesn't mean that your voice isn't heard. On the contrary. The mere fact of knowing<br>that someone has actually looked at a ticket -- actually cares about it -- is reason enough for someone who <br>
does have commit access to give it more serious consideration. <br><br>I would also note in particular that comments like "tests pass in BROWSER_NAME" or even "great patch, <br>worked for me" are both big helps to this cause. <br>
<br>I once again suggest this ticket triage policy be wikified. :-)<br>Erik<br><br><div class="gmail_quote">On Tue, Mar 3, 2009 at 08:59, Christopher Schmidt <span dir="ltr"><<a href="mailto:crschmidt@metacarta.com">crschmidt@metacarta.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Tue, Mar 03, 2009 at 07:34:37AM -0600, Erik Uzureau wrote:<br>
> add this to a wiki for posterity?<br>
><br>
> sounds good to me.<br>
<br>
</div>Wanted some confirmation first :) Will wikify soon barring objections.<br>
<div><div></div><div class="h5"><br>
> erik<br>
><br>
><br>
><br>
> ---------- Forwarded message ----------<br>
> From: Christopher Schmidt <<a href="mailto:crschmidt@metacarta.com">crschmidt@metacarta.com</a>><br>
> Date: Tue, Mar 3, 2009 at 02:11<br>
> Subject: [OpenLayers-Dev] Ticket Triage<br>
> To: <a href="mailto:dev@openlayers.org">dev@openlayers.org</a><br>
><br>
><br>
> Yo,<br>
><br>
> So after a bunch of ticket triage, I've got a system I feel reasonably<br>
> confident can work out to help us keep our milestones slightly more in<br>
> check from here foreward. Here are my suggestions; we can see what<br>
> everyone thinks.<br>
><br>
> 1. New bugs in the code go into the current milestone, up until the<br>
> time when a release is starting to be prepared. (For 2.8, this is<br>
> 'now'.) At that point, bug reports go into the *next* release, and<br>
> the 'current' release is for new regressions only, generally.<br>
><br>
> 2. New feature requests go to the "Future" milestone, unless a<br>
> submitter is actively working on them or a patch is attached and<br>
> ready for discussion/review, at which point it moves to the 'curent'<br>
> milestone, with the same caveat re: releases.<br>
><br>
> 3. Anyone who writes a sufficient patch should make sure that ticket<br>
> is:<br>
><br>
> * in the current milestone<br>
> * Marked for review<br>
><br>
> If code is insufficient/needs more work, it sould be marked as<br>
> 'needs more work'. (Tickets which do not have patches should never<br>
> be marked 'needs more work'.)<br>
><br>
> This is the case until the release manager declaes a cutoff for new<br>
> patches. For the 2.8 release, I blieve there will be a hard deadline<br>
> of April 1st for "No new patches".<br>
><br>
> Side effects of this:<br>
><br>
> * Bugs should be in next release<br>
> * Features should be in 'future' unless they're actively in development<br>
> * Only things that have not yet been put into a milestone by someone<br>
> who feels competent to decide should be in the 'none' milestone.<br>
><br>
> Currently, 'none' is empty. I think that we should keep this as our<br>
> incoming triage queue for users/developers who don't know the system, so<br>
> this should be the default. Then we can triage from there.<br>
><br>
> I think that this solves all the needs I'm aware of us currently having.<br>
> Obviously, these are guidelines. Currently, a number of things in the<br>
> 2.8 milestone are there despite not having patches because I believe<br>
> developers plan to work on them before 2.8, but there are 104 tickets,<br>
> and I'm positive we won't get a chance to fix/review that many.<br>
><br>
> One thing about the previous state of our tickets is that there were 110<br>
> tickets in the 'none' milestone, with more than a dozen already having<br>
> patches. Anything which looked even vaguely committable went into 2.8's<br>
> 'review' queue; I xpect many of these will get a quick review and boot<br>
> to 2.9 with "Needs More Work", since many of them are likely old.<br>
><br>
> One thing I'd like to encourage is for other developers to participate<br>
> in the review process. Though thus far we've priarily encouraged trunk<br>
> committers to review, I think that a second pair of eyes on a ticket can<br>
> make the review process for a trunk committer *much* easier. Things to<br>
> do when reviewing:<br>
><br>
> * Check out a clean trunk copy of OpenLayers<br>
><br>
> * Apply the patch in question<br>
><br>
> * Run the tests in any browsers you have handy. (If there are no tests<br>
> for the patch, consider writing some! If you can't, explain why you<br>
> think that it's not easy to write tests. A manual test can often help<br>
> even if you can't do test.anotherway test writing very well.)<br>
><br>
> * Open the example, test the functionality. If this is a new feature,<br>
> it should have an example; if it's a bugfix, you should be able to<br>
> confirm the new behavior with the old example.<br>
><br>
> * If it's a new feature, attempt to -- using the documentation (and not<br>
> by reading the code) -- modify the example sufficiently to make it<br>
> do something different, and ask yourself if there is more that needs<br>
> to be demonstrated or written to help show off the feature. For<br>
> example, you might want to link to some documentation on a remot<br>
> eservice that describes how to set up the server sie component of a<br>
> feature or some such.<br>
><br>
> * Comment to the ticket, explaining what you did, how it turned out,<br>
> and whether you think the code in question is ready for trunk, or if<br>
> it needs more work in some way.<br>
><br>
> There are *many many* experienced JavaScript developers in the<br>
> OpenLayers community, and currently 50 tickets awaiting review in the<br>
> 2.8 release. If we had a dozen people each grab four, or two dozen<br>
> people each grab two, we could really make a difference in the current<br>
> mountain of todos before 2.8.<br>
><br>
> If you feel lost in reviewing any existing patches, please feel free to<br>
> comment to the list in this respect. I'd be glad to help out in<br>
> directing how to do things like write tests, apply patches, etc.<br>
><br>
> One last thing: if you review, don't leave your comments as the<br>
> 'openlayers' user. Especially now that you can create an account without<br>
> sending an email, please sign your comments so we can at least have a<br>
> unique identifier for who is talking.<br>
><br>
> I'm looking forward to feedback on my proposed triage system, or<br>
> other comments on this. Looking forward to a great release!<br>
><br>
> Regards,<br>
> --<br>
> Christopher Schmidt<br>
> MetaCarta<br>
> _______________________________________________<br>
> Dev mailing list<br>
> <a href="mailto:Dev@openlayers.org">Dev@openlayers.org</a><br>
> <a href="http://openlayers.org/mailman/listinfo/dev" target="_blank">http://openlayers.org/mailman/listinfo/dev</a><br>
<br>
</div></div><font color="#888888">--<br>
Christopher Schmidt<br>
MetaCarta<br>
</font></blockquote></div><br>