[OpenLayers-Dev] Ticket Triage

[Christopher Schmidt]

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 <crschmidt at metacarta.com>
> Date: Tue, Mar 3, 2009 at 02:11
> Subject: [OpenLayers-Dev] Ticket Triage
> To: dev at 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 at openlayers.org
> http://openlayers.org/mailman/listinfo/dev

-- 
Christopher Schmidt
MetaCarta