Re: Schedulator inside your BTS
Avery Pennarun
> > I think you've got that backwards - Schedulator should have a unified
> > interface and the BTS's bugs should show up there. That way we don't have
> > to repeat the "just hack your BTS" step for every BTS.
>
> Getting Schedulator to be aware of every single system sounds sort of
> sketchy. I mean, you don't want to have you BTS integrated into your
> schedule. Your want your schedule to be part of your BTS.
The reason this is easier to implement is that Schedulator is
inherently designed to assume the existence of bug-tracking systems
(and other to-do list type systems), but bug-tracking systems are
rarely designed around the existence of scheduling systems.
> Of course, a sensible fallback is for Schedulator to have its own
> interface that knows how to construct URLs for your BTS. But that's not
> half as convenient.
Well, "half as convenient" sounds about right to me. Programming
wise, since exactly that URL-construction feature already exists in
schedulator, it's a time saver :)
Also note that increasingly, people are needing to deal with multiple
bug tracking systems at once and work them into their schedule:
googlecode and sourceforge both have their own bug tracking systems,
one per project. Your company will have at least one internal BTS and
maybe one for outside customers, etc. So it may not be feasible to
display schedulator from each of those systems, while it's definitely
possible to display data from those systems inside schedulator.
(Schedulator already has a googlecode plugin, incidentally.)
Have fun,
Avery
Avery Pennarun
> is the one that shows them a priority list of their own bugs.
>
> It just so happens that almost all bug tracking systems have one of
> those too. Only they suck. So you want Schedulator to replace the "My
> Bugs" query with itself.
Other than the lack of due dates, I'm not sure the "My Bugs" screen in
most bug tracking systems really sucks all that much. And generally
you can narrow your search terms down even further, which schedulator
doesn't (currently) really offer.
A simple hyperlink from the BTS bug viewer to the "schedule view"
might work for this case.
> For managing estimates and predictions, you may want to replace a "Bugs
> in Release 47" page with Schedulator. You get a complete table of bugs
> and also a little calendar.
>
> The whole point is to make your bug tracking system your scheduling
> system, by incrementally adopting Schedulator. It just shows up when
> people do their normal work.
This is more like "augmenting" the release view with Schedulator. I
think that's a reasonable thing to want, and probably pretty easy to
implement with an iframe or something - no fancy javascript required.
> > Yes, all that would be good fun (of course, dragging around and
> > rescheduling your bugs by hand is somewhat contrary to schedulator
> > philosophy - I rarely want to sort my bugs by hand, I just want them
> > in the "right" order).
>
> Right. But having to juggle priorities by hand sucks. Wouldn't it be
> nice to be able to juggle release dates, reprioritize or reschedule
> bugs, and then commit with a comment?
Er, I guess, but how is that different from what we do today? Other
than substituting drag-and-drop for manual priority editing, I guess.
(The concept of using drag-and-drop for rescheduling sounds shady to
me: I'd rather consider the "priority level" of a bug than its
relative order. That makes juggling bugs between different releases
more sane in the long run, because "priority level" is an attribute of
the bug, but "relative order" is an attribute of the schedule and
would be lost if you move a bug from one place to another.)
> > This project looks like they have the UI part down, if only they had a
> > powerful schedulator-like backend :)
> > http://macournoyer.wordpress.com/2007/07/30/me-rain-sleep-girlfriend-donebox/
>
> Yeah, I heard about Donebox.
> I guess you can drive it using their API.
> Unfortunately, they only do polling. Which is sad.
...and fixable, presumably.
In the end, what I'd like to see is Schedulator having a powerful
plugin system to retrieve tasks from any kind of storage backend, and
a powerful API so you can view/edit tasks from any kind of frontend
you want to construct (including a BTS if you want).
That way we don't have to debate the merits of any particular way of
accessing schedulator... people can just do it however they want. I
pointed out Donebox because it seems to have a pretty web ui for
viewing its tasks, and a relatively nice way of importing new tasks.
The idea would be to use schedulator's infrastructure with Donebox's
(or another existing) management UI and avoid duplicating effort.
Have fun,
Avery
Simon Law
> > Of course, a sensible fallback is for Schedulator to have its own
> > interface that knows how to construct URLs for your BTS. But that's not
> > half as convenient.
>
> Well, "half as convenient" sounds about right to me. Programming
> wise, since exactly that URL-construction feature already exists in
> schedulator, it's a time saver :)
Yeah, but I only have to do this once. Having a nice UI is sometimes
worth it.
> Also note that increasingly, people are needing to deal with multiple
> bug tracking systems at once and work them into their schedule:
> googlecode and sourceforge both have their own bug tracking systems,
> one per project. Your company will have at least one internal BTS and
> maybe one for outside customers, etc. So it may not be feasible to
> display schedulator from each of those systems, while it's definitely
> possible to display data from those systems inside schedulator.
> (Schedulator already has a googlecode plugin, incidentally.)
Well, that's nice in one way.
But are you telling me that your BTS isn't aware of other BTSes? Are
you living in the twentieth-century or something?
Cheers,
--
Simon Law http://www.law.yi.org/~sfllaw/
Simon Law
> (The concept of using drag-and-drop for rescheduling sounds shady to
> me: I'd rather consider the "priority level" of a bug than its
> relative order. That makes juggling bugs between different releases
> more sane in the long run, because "priority level" is an attribute of
> the bug, but "relative order" is an attribute of the schedule and
> would be lost if you move a bug from one place to another.)
Well, when you drag and drop a bug, I'd certainly say that you'd have it
change priorities as it went down the list. I know of no bug tracking
system that actually makes this easy.
Preserving relative order across schedules is possible, but probably
undesirable.
Avery Pennarun
> you living in the twentieth-century or something?
The only one that I've heard of that's even vaguely aware of other
BTSes is the Canonical one (https://bugs.launchpad.net/ubuntu). Which
is neat, but certainly not widespread. And it doesn't appear that
their system understands *schedules*, in any case.
Have fun,
Avery