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[1] 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 [1], 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).
[1] 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. :-)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
