launchpad-dev team mailing list archive

[Martin Albisetti <martin.albisetti@xxxxxxxxxxxxx>]

On 12/06/2009 06:45 PM, Jonathan Lange wrote:
> On Thu, Dec 3, 2009 at 8:34 AM, Martin Albisetti
> <martin.albisetti@xxxxxxxxxxxxx>  wrote:
> > So, bugtasks.
> >
> > I'd like to bring forward a problem that seems to be popping up more and
> > more as we focus on breaching the gap: bugtasks and context.
> >
> > As it stands today, if you're looking at an upstream bug that also has a
> > bugtask for a package in Ubuntu, and you want to nominate that bug, you
> > can't. You need to start hacking around to get to the bug from the package
> > context (if you manage to figure out that's what you need to do).
> > A quick hack^fix would be to let people click on bugtasks and the context
> > gets automagically changed.
>
> Interesting.
>
> This might be a naive question, but why do bugs need to have a context at all?

We discussed context-less bugs during our UI sprint as well, it solved a few 
problems, but introduced others like:
- What's the URL like?
- What happens when I click on, say, code?
...and other that are not at the top of my head


> > A profound fix could be to collapse targeting to milestones and series into
> > one column/widget, and offering nomination for those who are
> > permission-less, and optionally for those permission-ful(?).
>
> Do you think this would help newer users "get" milestones and series?
> My kneejerk reaction is that this will make them more confusing

Agreed, but it would also hide the complexity for people who just don't care.
My feeling is that the default path should be clear with not many questions on how
to proceed, and people caring about more complex structures when, well, they care.



> > The "target" is the only bit that is context-specific outside of the bugtask
> > row (creating this problem).
> >
> > Collapsing these two ties into an additional change that slipped 3.0, which
> > was to *not* automatically create a new bugtask when targeting a series, as
> > the only case that seems to make sense is backports.
> > I'd be happy to hash out the UI, I've had a gazillion discussions already
> > around this, and have a pretty clear idea of what it could look like
>
> Seeing a UI would really help me, since I haven't been a part of those
> discussions and don't have a clear idea.

I'll try and make time for it then. It's mostly being able to show a series in 
the same place we show milestones today. If you really want another bugtask 
because you need to track a status separately, you can say so explicitly.
To help you visualize the problem, I'll give you a quick story on how I manage 
bugs in loggerhead:
- At some point I decide to release, and create a series for that release
- I target all the bugs that absolutely need to be fixed in that release to the 
series (a loose target)
- As I get to the bugs, I target them to specific milestones

Launchpad today makes me create a separate bugtask for the series target, but 
in reality, there aren't 2 statuses there, only 1.


> > I'd love to argue that collapsing the two "Also affects" into one is part of
> > this, but it probably isn't (but please do).
>
> It isn't. We should do it. Bridging the gap and all that.

/me stares at over-worked Deryck

--
Martin