On 9/25/18 3:29 AM, Thierry Carrez wrote:
Doug Hellmann wrote:
I think we need to reconsider that position if it's going to block
adoption. I think Ben's case is an excellent second example of where
having a field to hold some sort of priority value would be useful.

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

I'm also not sure I agree with the statement that setting a priority for a blueprint is useless. Prioritizing feature work is something everyone needs to do these days since no team has enough people to implement every proposed feature. Maybe the proposal is for everyone to adopt Nova-style runways, but I'm not sure how well that works for smaller projects where many of the developers are only able to devote part of their time to it. Setting a time window for a feature to merge or get kicked to the back of line would be problematic for me.

That section also ends with an unanswered question regarding how to do bug triage in this model, which I guess is the thing we're trying to address with this discussion.

That said, it definitely creates friction, because alternatives are less convenient / visible, and it's not how other tools work... so the "right" answer here may not be the "best" answer.

[1] https://wiki.openstack.org/wiki/StoryBoard/Priority

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.

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to