Open Stack

On Wed, Sep 26, 2018 at 9:50 AM Ben Nemec <openstack at 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-request at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180926/db68e6b2/attachment.html>