[OpenLayers-Dev] Ticket Triage

Wed Mar 18 01:27:10 EDT 2009

Just in summary, the major changes that you are proposing here (which aren't
really particularly _major_, but still) are:

1) tickets should only go into the 'none' milestone if you don't understand
our ticket system.
2) tickets without a patch or that are not being actively worked on should
go into "Future".
3) Only tickets with an attached patch should be marked "needs more work"
4) Any ticket that has a patch and is ready to go into trunk should be put
in the current milestone and marked "review"

yes?

Also, I would like to give another vote of confidence to the section of your
email here in which you encourage
other, not-necessarily-committers, to take a crack at reviewing patches.
Well put. Just because you don't
yourself have commit rights doesn't mean that your voice isn't heard. On the
contrary. The mere fact of knowing
that someone has actually looked at a ticket -- actually cares about it --
is reason enough for someone who
does have commit access to give it more serious consideration.

I would also note in particular that comments like "tests pass in
BROWSER_NAME" or even "great patch,
worked for me" are both big helps to this cause.

I once again suggest this ticket triage policy be wikified. :-)
Erik

On Tue, Mar 3, 2009 at 08:59, Christopher Schmidt
<crschmidt at metacarta.com>wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20090317/de298e31/attachment.html