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