headers
Dylan Schiemann | 3 Jul 2008 01:21

A modest proposal: being honest to ourselves and our users about when we'll fix tickets


As a project, we're notoriously bad about committing to fixing more than
we possibly can fix.  As a result, trac gets overloaded with tickets.
When it comes time for a release, a bunch of tickets get punted to the
next release, which then get punted to the next release.

Tickets with patches, or that break really key things tend to get fixed,
as do things that are easy to fix, or with clear testcases, etc.

But this doesn't change the fact that people count on Trac to let them
know when to expect a fix to their issue.

So, I'm going to propose the following new approach:

* Nothing gets assigned a milestone until there's a committment to fix it
* Explicit release goals get set for a milestone, and related tickets
get added to that release, but only if there's someone that will
actually fix that issue
* Tickets with cla and a patch get reviewed regularly and with some priority
* Every other tickets gets sent to a future milestone, until someone
lobbies for a fix, or even better steps up to the plate to fix it
* New tickets get placed in a "to be reviewed" milestone, where they are
either put into the current milestone, or future, based on commitment.

Thoughts, ideas, and suggestions are appreciated.  I just want us to be
more realistic and honest about what we can get done.

Regards,
-Dylan
(Continue reading)

Permalink | Reply | 9 comments |
headers
Tom Trenka | 3 Jul 2008 01:23
Picon

Re: A modest proposal: being honest to ourselves and our users about when we'll fix tickets

+1 on everything you said.

trt

On Wed, Jul 2, 2008 at 6:21 PM, Dylan Schiemann <mail <at> dylans.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> As a project, we're notoriously bad about committing to fixing more than
> we possibly can fix.  As a result, trac gets overloaded with tickets.
> When it comes time for a release, a bunch of tickets get punted to the
> next release, which then get punted to the next release.
>
> Tickets with patches, or that break really key things tend to get fixed,
> as do things that are easy to fix, or with clear testcases, etc.
>
> But this doesn't change the fact that people count on Trac to let them
> know when to expect a fix to their issue.
>
> So, I'm going to propose the following new approach:
>
> * Nothing gets assigned a milestone until there's a committment to fix it
> * Explicit release goals get set for a milestone, and related tickets
> get added to that release, but only if there's someone that will
> actually fix that issue
> * Tickets with cla and a patch get reviewed regularly and with some priority
> * Every other tickets gets sent to a future milestone, until someone
> lobbies for a fix, or even better steps up to the plate to fix it
> * New tickets get placed in a "to be reviewed" milestone, where they are
> either put into the current milestone, or future, based on commitment.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tom Trenka | 3 Jul 2008 01:47
Picon

Re: A modest proposal: being honest to ourselves and our users about when we'll fix tickets

Something else to consider:

We've had a lot of committers over the years of the project, and
there's been some "turnover"--people get jobs, new people come on,
etc.  Some of the tickets that languish tend to be assigned to a
committer that is no longer active, or at least hasn't been active for
a time.

Might I suggest that we conduct a periodic (say, quarterly) of these
things, and maybe try to figure out what to do about it in a realistic
sense?

regards,
trt

On Wed, Jul 2, 2008 at 6:23 PM, Tom Trenka <ttrenka <at> gmail.com> wrote:
> +1 on everything you said.
>
> trt
>
> On Wed, Jul 2, 2008 at 6:21 PM, Dylan Schiemann <mail <at> dylans.org> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> As a project, we're notoriously bad about committing to fixing more than
>> we possibly can fix.  As a result, trac gets overloaded with tickets.
>> When it comes time for a release, a bunch of tickets get punted to the
>> next release, which then get punted to the next release.
>>
>> Tickets with patches, or that break really key things tend to get fixed,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Keese | 3 Jul 2008 01:48
Favicon
Gravatar

Re: A modest proposal: being honest to ourselves and our users about when we'll fix tickets

Dylan Schiemann wrote:
> * Nothing gets assigned a milestone until there's a committment to fix it
> * Explicit release goals get set for a milestone, and related tickets
> get added to that release, but only if there's someone that will
> actually fix that issue
> * Tickets with cla and a patch get reviewed regularly and with some priority

Sounds good.  I wonder what this would mean in practice... I wounder 
what percentage of dojox/dijit/dojo bugs would have no milestone set. 
(Probably most of the dojox bugs would be no-milestone, but what about 
core and dijit?)

I also wonder about the explicit release goals for milestones... for 
dijit I think about half of the work (for any month) is just bug fixes; 
probably same for core... which makes a roadmap only half-useful.

> * Every other tickets gets sent to a future milestone, until someone
> lobbies for a fix, or even better steps up to the plate to fix it
 > * New tickets get placed in a "to be reviewed" milestone, where they are
 > either put into the current milestone, or future, based on commitment.

This seems to contradict the previous text about not assigning 
milestones until there's a committment.  Can you elaborate on what you mean?
Permalink | Reply | 2 comments |
headers
Dylan Schiemann | 3 Jul 2008 01:52

Re: A modest proposal: being honest to ourselves and our users about when we'll fix tickets


Bill Keese wrote:
| Dylan Schiemann wrote:
|> * Nothing gets assigned a milestone until there's a committment to fix it
|> * Explicit release goals get set for a milestone, and related tickets
|> get added to that release, but only if there's someone that will
|> actually fix that issue
|> * Tickets with cla and a patch get reviewed regularly and with some
priority
|
| Sounds good.  I wonder what this would mean in practice... I wounder
| what percentage of dojox/dijit/dojo bugs would have no milestone set.
| (Probably most of the dojox bugs would be no-milestone, but what about
| core and dijit?)

I would expect 90%+ to live in "future", and only get plucked when
people say "I'm working on this".

| I also wonder about the explicit release goals for milestones... for
| dijit I think about half of the work (for any month) is just bug fixes;
| probably same for core... which makes a roadmap only half-useful.

Yes, this would only be useful for taking groups of long-lived bugs and
deciding we're going to focus on really polishing that feature.
Obviously there will be things that get fixed that aren't part of the
roadmap, because someone provides a fix.

|> * Every other tickets gets sent to a future milestone, until someone
|> lobbies for a fix, or even better steps up to the plate to fix it
|  > * New tickets get placed in a "to be reviewed" milestone, where
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bill Keese | 3 Jul 2008 02:22
Favicon
Gravatar

Re: A modest proposal: being honest to ourselves and our users about when we'll fix tickets


> What I mean is, new tickets should go to a milestone, where they are
> triaged, either to no milestone, or the current milestone if it is
> something that has a committment to fix it, a patch, or is such a
> critical bug that it must be fixed now.

OK, sounds good.  If redmine has features that would support this, like 
security so that only certain people can set the milestone, that would 
be even better.   (One of the main problems we have now is that every 
user that files a bug marks it against 1.2)
Permalink | Reply | 0 comments |
headers
Bryan Forbes | 3 Jul 2008 18:54
Gravatar

Re: A modest proposal: being honest to ourselves and our users about when we'll fix tickets

On Wed, 2008-07-02 at 16:21 -0700, Dylan Schiemann wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> As a project, we're notoriously bad about committing to fixing more than
> we possibly can fix.  As a result, trac gets overloaded with tickets.
> When it comes time for a release, a bunch of tickets get punted to the
> next release, which then get punted to the next release.
> 
> Tickets with patches, or that break really key things tend to get fixed,
> as do things that are easy to fix, or with clear testcases, etc.
> 
> But this doesn't change the fact that people count on Trac to let them
> know when to expect a fix to their issue.
> 
> So, I'm going to propose the following new approach:
> 
> * Nothing gets assigned a milestone until there's a committment to fix it
> * Explicit release goals get set for a milestone, and related tickets
> get added to that release, but only if there's someone that will
> actually fix that issue
> * Tickets with cla and a patch get reviewed regularly and with some priority
> * Every other tickets gets sent to a future milestone, until someone
> lobbies for a fix, or even better steps up to the plate to fix it
> * New tickets get placed in a "to be reviewed" milestone, where they are
> either put into the current milestone, or future, based on commitment.

Might I suggest some other practices that might help us in the long run?

* A predictable release schedule.  This will help not only our users to
(Continue reading)

Permalink | Reply | 3 comments |
headers
Brad Neuberg | 3 Jul 2008 20:13
Picon

Re: A modest proposal: being honest to ourselves and our users about when we'll fix tickets

Big + 1 on this. I have lots of old issues I actually entered for myself as reminders that are pretty low priority that I always have to bump at various releases. I'd rather choose a handful of issues I will address for some upcoming release, change their numbers, and then fix them, and not have to constantly bump the others.



Message: 1
Date: Wed, 02 Jul 2008 16:21:14 -0700
From: Dylan Schiemann <mail <at> dylans.org>
Subject: [dojo-contributors] A modest proposal: being honest to
       ourselves and our users about when we'll fix tickets
To: "dojo dev." <dojo-contributors <at> dojotoolkit.org>
Message-ID: <486C0D6A.3090309 <at> dylans.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As a project, we're notoriously bad about committing to fixing more than
we possibly can fix.  As a result, trac gets overloaded with tickets.
When it comes time for a release, a bunch of tickets get punted to the
next release, which then get punted to the next release.

Tickets with patches, or that break really key things tend to get fixed,
as do things that are easy to fix, or with clear testcases, etc.

But this doesn't change the fact that people count on Trac to let them
know when to expect a fix to their issue.

So, I'm going to propose the following new approach:

* Nothing gets assigned a milestone until there's a committment to fix it
* Explicit release goals get set for a milestone, and related tickets
get added to that release, but only if there's someone that will
actually fix that issue
* Tickets with cla and a patch get reviewed regularly and with some priority
* Every other tickets gets sent to a future milestone, until someone
lobbies for a fix, or even better steps up to the plate to fix it
* New tickets get placed in a "to be reviewed" milestone, where they are
either put into the current milestone, or future, based on commitment.

Thoughts, ideas, and suggestions are appreciated.  I just want us to be
more realistic and honest about what we can get done.

Regards,
- -Dylan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIbA1q8nLgh/JJsxERAg1cAJ9FfRXaYd1OC0/67JeqHZmALL0XHgCgje40
tNRQic+0zhba2OT6OFHLBTU=
=0NWJ
-----END PGP SIGNATURE-----



_______________________________________________
dojo-contributors mailing list
dojo-contributors <at> dojotoolkit.org
http://turtle.dojotoolkit.org/mailman/listinfo/dojo-contributors
Permalink | Reply | 0 comments |
headers
James Burke | 4 Jul 2008 00:43
Favicon

Build option to strip console.* statements and how to use try/catch with isDebug

There is a build option now to strip console.* calls: stripConsole.
stripConsole=normal will strip all console.* calls except console.warn
and console.error. stripConsole=all will strip all console.* calls.

I am considering running the CDN build will stripConsole=normal.

Also, there were recent updates to handling try/catch blocks in the
code (let the error bubble out with dojo.config.isDebug = true, but
use a try/catch with console.error(e) with dojo.config.isDebug = false
if you want the code to keep running in the non-debug case):
http://trac.dojotoolkit.org/ticket/6863

Because of those two things, you should consider carefully how you use
dojo.debug statements inside dojo/dijit/dojox. Do not expect them to
useful in a release build, and if they are really for error reporting,
consider using console.error or console.warn.

If this causes problems for you, please let me know.

BTW, using stripConsole=normal, the gzipped dojo.js from a normal
build is only reduced by 63 bytes. So a good sign: we are not using
lots of console calls that bloat the dojo base code.

James
Permalink | Reply | 0 comments |
headers
Dustin Machi | 4 Jul 2008 05:16

LDAP Enabled for Trac

Hi Everybody,

Tonight I enabled LDAP authentication for our Trac instance.  This means 
that any registered user is a valid user of our Trac instance.  If you 
would like to register, simply go to dojotoolkit.org and follow the 
normal registration process.

Since anyone can have their own account now.  There is no need for the 
guest account for trac any longer.  It has been disabled.   Please 
direct people to http://dojotoolkit.org/user/register if they need an 
account to file a ticket.

Please let me know if you have any problems. 

Thanks
Dustin
Permalink | Reply | 0 comments |

Gmane