On Wed, Sep 26, 2018 at 9:50 AM Ben Nemec <openst...@nemebean.com> wrote:
> > > 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. > The information is being migrated[1], we just don't expose it in the webclient. You could still access the info via the API. > __________________________________________________________________________ > 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 -Kendall (diablo_rojo) [1] https://github.com/openstack-infra/storyboard/blob/master/storyboard/migrate/launchpad/writer.py#L183
__________________________________________________________________________ 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
