[openstack-dev] [storyboard] Prioritization?
openstack at nemebean.com
Thu Sep 27 13:49:31 UTC 2018
On 9/27/18 4:17 AM, Thierry Carrez wrote:
> Ben Nemec wrote:
>> On 9/25/18 3:29 AM, Thierry Carrez wrote:
>>> Absence of priorities was an initial design choice based on the
>>> fact that in an open collaboration every group, team, organization
>>> has their own views on what the priority of a story is, so worklist
>>> and tags are better ways to capture that. Also they don't really work
>>> unless you triage everything. And then nobody really looks at them to
>>> prioritize their work, so they are high cost for little benefit.
>> So was the storyboard implementation based on the rant section then?
>> Because I don't know that I agree with/understand some of the
>> assertions there.
>> First, don't we _need_ to triage everything? At least on some minimal
>> level? Not looking at new bugs at all seems like the way you end up
>> with a security bug open for two years *ahem*. Not that I would know
>> anything about that (it's been fixed now, FTR).
> StoryBoard's initial design is definitely tainted by an environment that
> has changed since. Back in 2014, most teams did not triage every bug,
> and were basically using Launchpad as a task tracker (you created the
> bugs that you worked on) rather than a bug tracker (you triage incoming
> requests and prioritize them).
I'm not sure that has actually changed much. Stemming from this thread I
had an offline discussion around bug management and the gist was that we
don't actually spend much time looking at the bug list for something to
work on. I tend to pick up a bug when I hit it in my own environments or
if I'm doing bug triage and it's something I think I can fix quickly. I
would like to think that others are more proactive, but I suspect that's
wishful thinking. I had vague thoughts that I might actually start
tackling bugs that way this cycle since I spent a lot of last cycle
getting Oslo bugs triaged so I might be able to repurpose that time, but
until it actually happens it's just hopes and dreams. :-)
Unfortunately, even if bug triage is a "write once, read never" process
I think we still need to do it to avoid the case I mentioned above where
something important falls through the cracks. :-/
> Storyboard is therefore designed primarily a task tracker (a way to
> organize work within teams), so it's not great as an issue tracker (a
> way for users to report issues). The tension between the two concepts
> was explored in , with the key argument that trying to do both at the
> same time is bound to create frustration one way or another. In PM
> literature you will even find suggestions that the only way to solve the
> diverging requirements is to use two completely different tools (with
> ways to convert a reported issue into a development story). But that
> "solution" works a lot better in environments where the users and the
> developers are completely separated (proprietary software).
>  https://wiki.openstack.org/wiki/StoryBoard/Vision
>> Also, like it or not there is technical debt we're carrying over here.
>> All of our bug triage up to this point has been based on launchpad
>> priorities, and as I think I noted elsewhere it would be a big step
>> backward to completely throw that out. Whatever model for
>> prioritization and triage that we choose, I feel like there needs to
>> be a reasonable migration path for the thousands of existing triaged
>> lp bugs in OpenStack.
> I agree, which is why I'm saying that the "right" answer might not be
> the "best" answer.
Yeah, I was mostly just +1'ing your point here. :-)
More information about the OpenStack-dev