Re: [openstack-dev] [storyboard] Prioritization?
On Tue, 2018-09-25 at 18:40 +, CARVER, PAUL wrote: [...] > There is certainly room for additional means of juggling and > discussing/negotiating priorities in the stages before work really gets > under way, but if it doesn't eventually become clear > > 1) who's doing the work > 2) when are they targeting completion > 3) what (if anything) is higher up on their todo list Its entirely possible to track these three things in StoryBoard today, and for other people to view that information. 1) Task assignee, though this should be set when someone actually starts doing the work rather than being used to indicate "$person intends to do this at some point" 2) Due date on a card in a board 3) Lanes in that board ordered by priority The latter two assume that the person doing the work is using a board to track what they're doing, which is probably sensible behaviour we should encourage. Its admittedly difficult for downstream consumers to quickly find the board-related information, but I think that is a discoverability bug (it doesn't currently become clear where exactly these things can be found) rather than a fundamental issue which means we should just abandon the multi-dimensional approach. > then it's impossible for anyone else to make any sort of plans that > depend on that work. Plans could include figuring out how to add more > resources or contingency plans. It's also possible that people or > projects may develop a reputation for not delivering on their stated top > priorities, but that's at least better than having no idea what the > priorities are because every person and project is making up their own > system for tracking it. I would argue that someone who wants to make plans based on upstream work that may or may not get done should be taking the time (which should at worst be something like "reading the docs to find a link to a worklist/board" even with the current implementation) to understand how upstream are expressing the state of their work, though I can understand why they might not always want to. I definitely think that defining an "official"-ish approach is something that should probably be done, to reduce the cognitive load on newcomers. - Adam __ 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
Re: [openstack-dev] [storyboard] Prioritization?
On Tue, 2018-09-25 at 13:41 -0400, Doug Hellmann wrote: > Adam Coldrick writes: > > For tasks I am less concerned in that aspect since cross-project > > support > > isn't hurt, but remain of the opinion that a global field is the wrong > > approach since it means that only one person (or group of people) gets > > to > > visibly express their opinion on the priority of the task. > > While I agree that not everyone attaches the same priority to a given > task, and it's important for everyone to be able to have their own say > in the relative importance of tasks/stories, I think it's more important > than you're crediting for downstream consumers to have a consistent way > to understand the priority attached by the person(s) doing the > implementation work. I think you're right. The existing implementation hasn't really considered the case of a downstream consumer unused to the differences in StoryBoard just turning up at the task tracker to find out something like "what are the priorities of the oslo team?", and it shows in how undiscoverable to an outsider that is no matter which of the workflows we suggest is being used. > > Allowing multiple groups to express opinions on the priority of the > > same > > tasks allows situations where (to use a real world example I saw > > recently, > > but not in OpenStack) an upstream project marks a bug as medium > > priority > > for whatever reason, but a downstream user of that project is > > completely > > broken by that bug, meaning either providing a fix to it or persuading > > someone else to is of critical importance to them. > > This example is excellent, and I think it supports my position. I can see that, but I also don't think our positions are entirely incompatible. In the example, the downstream user was one of the main users of the upstream project and there was some contributor overlap. In my ideal world the downstream project would've expressed the priority in a worklist or board that upstream people were subscribed (or otherwise paying attention) to. Then, the upstream project would've set their priority in a board or worklist which the downstream folk also pay attention to somehow (since they are interested in how upstream are prioritising work). This way a contributor interested in the priorities of both projects could see the overlap, and perhaps use that to decide what to work on next. Also, since downstream have a way to pay attention to upstream's priority, they can see the low "official" priority and go and have any discussions needed. > An important area where using boards or worklists falls short of my own > needs is that, as far as I know, it is not possible to subscribe to > notifications for when a story or task is added to a list or board. So > as a person who submits a story, I have no way of knowing when the > team(s) working on it add it to (or remove it from) a priority list or > change its priority by moving it to a different lane in a board. > Communicating about what we're doing is as important as gathering and > tracking the list of tasks in the first place. Without a notification > that the priority of a story or task has been lowered, how would I know > that I need to go try to persuade the team responsible to raise it back > up? It is indeed not possible for the scenario I describe above to work neatly in StoryBoard today, because boards and worklists don't give notifications. That's because we've not got round to finishing that part of the implementation yet, rather than by design. Worklists do currently generate history of changes made to them, there is just no good way to see it anywhere and no notifications sent based on it. > Even if we add (or there is) some way for me to receive a notification > based on board or list membership, without a real priority field we have > several different ways to express priority (different tag names, a > single worklist that's kept in order, a board with separate columns for > each status, etc.). That means each team could potentially use a > different way, which in turn means downstream consumers have to > discover, understand, and subscribe to all of those various ways, and > use them correctly, for every team they are tracking. I think that's an > unreasonable burden to place on someone who is not working in the > community constantly, as is the case for many of our operators who > report bugs. This is the part I've not really considered before for StoryBoard. Perhaps we should've been defining an "official" prioritisation workflow and trying to make that discoverable. > > With global priority there is a trade-off, either the bug tracker > > displays > > priorities with no reference as to who they are important to, > > downstrea
Re: [openstack-dev] [storyboard] Prioritization?
On Mon, 2018-09-24 at 22:47 +, Jeremy Stanley wrote: > On 2018-09-24 18:35:04 -0400 (-0400), Doug Hellmann wrote: > [...] > > At the PTG there was feedback from at least one team that > > consumers of the data in storyboard want a priority setting on > > each story. Historically the response to that has been that > > different users will have different priorities, so each of them > > using worklists is the best way to support those differences of > > opinion. > > > > 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. I'm strongly against reverting to having a single global priority value for things in StoryBoard, especially so for stories as opposed to tasks. Having a single global priority field for stories at best implies that a cross-project story has the same priority in each project, and at worst means cross-project discussions need to occur to find an agreement on an acceptable priority (or one affected project's opinion overrules the others, with the others' priorities becoming harder to understand at a glance or just completely lost). For tasks I am less concerned in that aspect since cross-project support isn't hurt, but remain of the opinion that a global field is the wrong approach since it means that only one person (or group of people) gets to visibly express their opinion on the priority of the task. Allowing multiple groups to express opinions on the priority of the same tasks allows situations where (to use a real world example I saw recently, but not in OpenStack) an upstream project marks a bug as medium priority for whatever reason, but a downstream user of that project is completely broken by that bug, meaning either providing a fix to it or persuading someone else to is of critical importance to them. With global priority there is a trade-off, either the bug tracker displays priorities with no reference as to who they are important to, downstream duplicate the issue elsewhere to track their priority, or their expression of how important the issue is is lost in a comment in order to maintain the state of "all priorities are determined by the core team". > The alternative suggestion, for teams who want to be able to flag > some sort of bucketed priorities, is to use story tags. We could > even improve the import tool to accept some sort of > priority-to-tag-name mapping so that, say, when we import bugs for > Oslo their oslo-critical tag is applied to any with a critical > bugtask, oslo-medium to any with medium priority tasks, and so on. > Not all teams using StoryBoard will want to have a bucketed priority > scheme, and those who do won't necessarily want to use the same > number or kinds of priorities. This approach will work fine, but as far as I can tell the only benefit of this rather than just creating say a board with a lane for each priority bucket is better discoverability when browsing stories. In my opinion that is a bug in our browse/search implementation, and the story list should be able to be filtered by worklist or board. Using this as a workaround is sensible, but I think I'd rather encourage the recommended workflow of tracking priority in ordered worklists or boards. In my eyes the correct solution to Ben's issue of losing all the priority information is to cause the migration scripts to create (or allow an existing board to be specified) a board with lanes representing the different Launchpad priorities used, and populate it accordingly. Its probably also worth noting that the database still tracks the deprecated task-level global priority, and the migration script imports priority data into that field, so it would be possible to write a script to interrogate the API and build such a board post-migration. See [0], [1], and [2] for example. I would strongly advise against actively using the existing global priority field for tracking priority though, since it is deprecated and the intent is for it to go away at some point. In general I think most of the complaints about complex priority vs global priority that I've seen can be reduced to issues with how the complex priority approach as implemented in StoryBoard makes it somewhat harder to actually discover what people think about the priority of things, and the inability to order search results by priority. I believe that can be solved by improving our implementation, rather than falling back to a flawed global priority approach. - Adam [0]: https://storyboard-dev.openstack.org/api/v1/tasks?project_id=574 rity=high [1]: https://storyboard-dev.openstack.org/api/v1/tasks?project_id=574 rity=medium [2]: https://storyboard-dev.openstack.org/api/v1/tasks?project_id=574 rity=low __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [OpenStack-Infra] [StoryBoard] Project Update/Some New Things
On Mon, 2018-09-10 at 12:14 -0400, Zane Bitter wrote: > On 10/09/18 10:34 AM, Jeremy Stanley wrote: > > On 2018-09-10 14:43:18 +0100 (+0100), Adam Coldrick wrote: > > [...] > > > # Linking to projects by name > > > > > > Keen observers might've noticed that StoryBoard recently grew the > > > ability > > > to link to projects by name, rather than by ID number. All the links > > > to > > > projects in the UI have been replaced with links in this form, and > > > its > > > probably a good idea for folk to start using them in any > > > documentation > > > they have. These links look like > > > > > > https://storyboard.openstack.org/#!/project/openstack-infra/story > > > board > > Thanks for this!!! > > > [...] > > > > Worth noting, this has made it harder to find the numeric project ID > > without falling back on the API. Change > > https://review.openstack.org/600893 merged to the releases > > repository yesterday allowing deliverable repositories to be > > referenced by their StoryBoard project name rather than only the ID > > number. If there are other places in tooling and automation where we > > relied on the project ID number, work should be done to update those > > similarly. > > In the docs configuration we use the ID for the generating the bugs > link. We also rely on it being a numeric ID (as a string - it crashes > if > you use an int) rather than a string to determine whether the target is > a launchpad project or a storyboard project. If it'll be a big task to change this, I'm happy to make the ID more discoverable from the StoryBoard web UI so that it isn't painful for folk in the meantime. __ 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
[openstack-dev] [StoryBoard] Project Update/Some New Things
Hi all, Its been a long while since a "project update" type email about StoryBoard, but over the past few months we merged some patches which either are worth mentioning or changed things in ways that would benefit from some explanation. # Linking to projects by name Keen observers might've noticed that StoryBoard recently grew the ability to link to projects by name, rather than by ID number. All the links to projects in the UI have been replaced with links in this form, and its probably a good idea for folk to start using them in any documentation they have. These links look like https://storyboard.openstack.org/#!/project/openstack-infra/storyboard # Linking to project groups by name More recently (yesterday) it also became possible to similarly link to project groups by name rather than ID number. Links to project groups in the UI have been replaced with links in this form, and again if you have any documentation using the ID links it might be nice to update to using the name. These links look like https://storyboard.openstack.org/#!/project_group/storyboard # Finding stories from a task ID It is now possible to navigate to a story given just a task ID, if for whatever reason that's all the information you have available. A link like https://storyboard.openstack.org/#!/task/12389 will work. This will redirect to the story containing the task, and is the first part of work to support linking directly to an individual task in a story. # UI updates There have been some visual changes in the webclient's user interface to attempt to make things generally feel nicer. This work is also not totally finished and there are further changes planned. One big change is that the "Profile" button in the sidebar used for setting preferences and managing access tokens has gone away. The URLs used to access this functionality are unchanged, but the links in the UI can now be found by clicking the user name in the top-right to open the dropdown menu, which previously only contained the log out button. # Bugfixes Various minor bugs and annoyances have also been addressed. For example search should behave somewhat more predictably than it did at the start of the year, syntax highlighting actually works again, and the markdown parser should be less aggressive in its swallowing of line breaks. Stay tuned in the future for more fixes and features, and feel free to pop into #storyboard with any questions or comments you may have. We're always open to suggestions and even more open to patches! We also have a PTG session on Tuesday afternoon, currently intended to be in Blanca Peak. Feel free to drop by to join the discussions and/or add to the etherpad[0]. Best regards, Adam (SotK) [0]: https://etherpad.openstack.org/p/sb-stein-ptg-planning __ 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
Re: [openstack-dev] [storyboard] need help figuring out how to use auth with storyboard client
On Fri, 2018-01-12 at 21:30 +, Jeremy Stanley wrote: > On 2018-01-12 15:57:44 -0500 (-0500), Doug Hellmann wrote: > > The storyboard client docs mention an "access token" [1] as > > something > > a client needs in order to create stories and make other sorts of > > changes. They don't explain what that token is or how to get one, > > though. > > > > Where do I get a token? How long does the token work? Can I safely > > put a token in a configuration file, or do I need to get a new one > > each time I want to do something with the client? > > https://docs.openstack.org/infra/storyboard/webapi/v1.html#api > suggests that logging in and going to > https://storyboard.openstack.org/#!/profile/tokens will allow you to > issue one (with up to a 10-year expiration based on my modest > experimentation). I believe this to be the same solution we're using > to grant teh storyboard-its Gerrit plugin to update tasks/stories > from review.openstack.org. This is likely the easiest solution. Some other options: - Admin users can issue tokens for any users, so an automation user could have a token granted by infra-root using the API directly (see the API docs[0] for detail). - Add some functionality in python-storyboardclient to handle authenticating with the OpenID provider that the API sends a redirect link for. [0]: https://docs.openstack.org/infra/storyboard/webapi/v1.html#post--v 1-users--user_id--tokens __ 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
Re: [openstack-dev] [storyboard][infra][docs] Report a bug and storyboard
Hi Andreas, On 2017-06-28 07:33, Andreas Jaeger wrote: Hi Storyboard team, the openstackdocstheme has a "Report a bug" feature, where you can click on the Bug icon and get a link to project's bug area in launchpad together with information about the documentation (bug tag, git URL of build, date, SHA, extra text). How can this be done with storyboard? Currently there is no support for this exact functionality in StoryBoard itself. You could add some JavaScript to the docs theme to make a POST request to the StoryBoard API with the relevant parameters set, but this would need some work to also get a valid StoryBoard access token to use in the request somehow. Other than that you could settle for linking to an individual project view in StoryBoard, for example https://storyboard.openstack.org/#!/project/456 has a button on it for logged-in users to create a story which automatically has a task in that project. The ability to construct an link to StoryBoard's web UI which automatically populates part of the things needed to create a story seems generally useful though. In particular I can see it potentially being helpful for resolving our lack of bug templates, which has been raised as a problem on more than one occasion. Supporting this type of feature would allow folk to construct URLs which automatically populate the description field with some template of their choice, which should hopefully be useful enough to solve both that problem and the need to replicate this "Report a bug" feature adequately. I intend to take a look at how much work it'd be for us to implement that kind of thing in the near future, and hopefully that'll lead to a more ideal solution than those I outlined above. Best Regards, Adam __ 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
[openstack-dev] [OpenStack-Infra] [StoryBoard] Meeting Time Rearrangement
Hi folks, Last week at the StoryBoard meeting we discussed the fact that the meeting time has become inconvenient for most of the people who attend. As a result, we took the decision to move the meeting slot to 1900 UTC on Wednesdays in #openstack-meeting We'll be having our first meeting at the new time tomorrow. Anyone interested in seeing the state of StoryBoard or finding out more about the project is welcome to attend. Our agenda can be found on the wiki[0] and anybody should feel free to add topics they wish to discuss to it. If anyone is interested in stopping by for a chat and doesn't feel like they want to do so in the meeting, you can find us in #storyboard. Hope to see some folk around! Adam (SotK) [0]: https://wiki.openstack.org/wiki/Meetings/StoryBoard __ 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
