On Thu, Dec 10, 2009 at 7:43 AM, Martin Albisetti <[email protected]> wrote: > On 12/06/2009 06:45 PM, Jonathan Lange wrote: >> >> On Thu, Dec 3, 2009 at 8:34 AM, Martin Albisetti >> <[email protected]> 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?
That one is easy, I think, since https://bugs.launchpad.net/bugs/ID already is a valid URL for the bug. > - What happens when I click on, say, code? Yeah, that one's tougher. I can think of some solutions though, but maybe they are worse than the problem. > ...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. > I agree with the principle, certainly. > > >>> 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. > Thanks. I'm going to have to think more about this. >>> 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 > I didn't say we should do it *now*. :) jml _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
