Open Stack

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. :-)