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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
