add this to a wiki for posterity?<br><br>sounds good to me.<br>erik<br><blockquote style="margin: 1.5em 0pt;"></blockquote><br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Christopher Schmidt</b> <span dir="ltr"><<a href="mailto:crschmidt@metacarta.com">crschmidt@metacarta.com</a>></span><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>
<font color="#888888">--<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>
</font></div><br>