| *** udesale has joined #storyboard | 04:56 | |
| *** udesale has quit IRC | 04:57 | |
| *** udesale has joined #storyboard | 04:58 | |
| *** udesale has quit IRC | 04:59 | |
| *** udesale has joined #storyboard | 05:22 | |
| *** udesale has quit IRC | 05:31 | |
| *** udesale has joined #storyboard | 06:06 | |
| *** udesale has quit IRC | 06:48 | |
| *** udesale has joined #storyboard | 06:55 | |
| SotK | huh, the only thing I can think is https://storyboard.openstack.org/#!/story/2001272 | 07:08 |
|---|---|---|
| * SotK remembers he never got round to finishing that patch | 07:08 | |
| SotK | the problem is that we need to update ui-bootstrap to a version that supports some way of working around the fact that fully typing the name doesn't select the item from the dropdown, which also means lots of code churn because of name changes | 07:09 |
| SotK | regarding not sending email if its from a robot, for now we could add a header around https://git.openstack.org/cgit/openstack-infra/storyboard/tree/storyboard/plugin/email/workers.py#n331 containing the user ID for local filtering pretty easily | 07:17 |
| persia | Does X-StoryBoard-Subscription-Type provide the class "story, task, etc." and ID already? | 07:20 |
| SotK | it provides the class but not the ID | 07:23 |
| *** tosky has joined #storyboard | 07:58 | |
| *** jpich has joined #storyboard | 07:59 | |
| *** dtantsur|afk is now known as dtantsur | 09:44 | |
| *** dtantsur is now known as dtantsur|afk | 15:44 | |
| *** udesale has quit IRC | 15:59 | |
| *** jpich has quit IRC | 16:39 | |
| *** tosky has quit IRC | 18:23 | |
| *** openstackgerrit has joined #storyboard | 20:31 | |
| openstackgerrit | Merged openstack-infra/storyboard master: Add a test openid server https://review.openstack.org/397998 | 20:31 |
| *** jtomasek has quit IRC | 21:38 | |
| dhellmann | my performance issue has grown bad enough that I've built a command line tool to assign tasks: https://review.openstack.org/597244 | 21:50 |
| dhellmann | is there a way in the GUI for a user to determine their numerical id? | 21:52 |
| clarkb | dhellmann: kind of hacky butit looks like if you search for yourself the url has your id number in it | 21:56 |
| clarkb | I am 38 apparently | 21:56 |
| clarkb | https://storyboard.openstack.org/#!/search?assignee_id=38&creator_id=38 | 21:56 |
| dhellmann | how did you start that search? | 21:57 |
| dhellmann | going to https://storyboard.openstack.org/#!/search and typing my name in the box does nothing | 21:57 |
| dhellmann | well reloading the page and trying again made it work | 22:01 |
| persia | Are there metrics for the host on which storyboard.openstack.org resides? Do we know how it is bottlenecked? (CPU, memory, IO, etc.). | 22:03 |
| diablo_rojo | dhellmann, hopefully we can get the issues cleared up soon. I can add it to the PTG discussions. | 22:03 |
| dhellmann | diablo_rojo : I'm sure this is a *very* unusual case | 22:04 |
| diablo_rojo | dhellmann, thousands of comments on the same story is definitely not something we have had to deal with yet, but I know there are a number of other places where things could also be sped up. | 22:05 |
| dhellmann | and it is making me think I need to reconsider how we track goals for the Turbo release | 22:05 |
| clarkb | persia: http://cacti.openstack.org should have system level stats for storyboard | 22:05 |
| dhellmann | one story per repo with one task per task would work if they are all tagged so they can be pulled together into a common view | 22:06 |
| diablo_rojo | dhellmann, not the turnt release? :) | 22:06 |
| dhellmann | heh | 22:06 |
| diablo_rojo | Yeah Board view seems to work better for viewing larger pieces of work than a single story. | 22:06 |
| diablo_rojo | My example being tracking all the migrations | 22:07 |
| dhellmann | I managed the number of tasks ok. I did not anticipate so many comments, though. | 22:07 |
| diablo_rojo | I have a story, but its WAY easier to visualize in a board. | 22:07 |
| diablo_rojo | Yeah thats hard to prepare for. | 22:07 |
| dhellmann | every time a patch is rebased or modified, every time it lands, and there are so so many patches | 22:07 |
| diablo_rojo | Nice that all the history is in one place though? | 22:07 |
| persia | clarkb: Thanks for the pointer. Nothing there seems obvious, although the load average seems high all the time (but without network, disk, memory, or CPU overloads, I don't understand why) | 22:08 |
| dhellmann | diablo_rojo : if I could see it, yes ;-) | 22:08 |
| dhellmann | anyway, it'll provide a nice big example for load testing :-) | 22:09 |
| diablo_rojo | dhellmann, fair. Maybe we need some sort of paging. Only show the most recent 100 comments at a time or something | 22:09 |
| diablo_rojo | dhellmann, much appreciated :) | 22:09 |
| dhellmann | yeah, I think SotK said it used to work that way but was confusing, and I could see that being the case | 22:09 |
| dhellmann | a big red flashing 'click to load more comments' button might help there | 22:10 |
| * dhellmann is not the best UI designer | 22:10 | |
| persia | dhellmann: Experimentation with bugtasks in Launchpad for the Ubuntu project suggested that more than about 10 tasks in a story quickly became too many. One experiement with 122 initial bugtasks (one of the library migrations) ended up being a source of developing a feature to explicitly unsubscribe from one story while one's team was subscribed to it, in part due to comments every time anyone fixed any of the transitions in any of the tasks for | 22:10 |
| persia | any of the releases of any of the operting systems that ended up being part of it. | 22:10 |
| persia | I think you've done an excellent job of demonstrating that these limits also apply for Storyboard. | 22:10 |
| dhellmann | persia : the problem isn't the number of tasks. It's that there are many patches for a given task, and each patch in turn produces *many* comments | 22:10 |
| diablo_rojo | dhellmann, finishing the implementation of epics might help. One epic to track the goal and a story per project and a task per repo. | 22:10 |
| dhellmann | I'm not really sure how epics differ from a work list, but that's not something I've given a lot of thought to | 22:11 |
| persia | dhellmann: Yes. Automated comment system + large number of bugtasks + limited features for negative filtering == notificaiton frustration. Same limitation I meant. | 22:11 |
| dhellmann | yeah | 22:11 |
| persia | Launchpad later developed other limitations with massive numbers of bugtasks, but at first it was snappy even with tens of bugtasks in a single bug. | 22:11 |
| dhellmann | anyway, again, I'm not complaining, just trying to provide data | 22:11 |
| diablo_rojo | dhellmann, my understanding is that an epic is an abstracted story type thing? I don't know much of the inital discussions but I feel like it might be the solution? | 22:12 |
| diablo_rojo | dhellmann, I do love data :) | 22:12 |
| dhellmann | the SB API works great so I still think this is a UI rendering problem | 22:12 |
| persia | An "epic" as a semantic concept is something of which there are a few different viewpoints: I don't believe the StoryBoard community has a consensus. | 22:12 |
| dhellmann | diablo_rojo : usually an epic is just a very big story, and having another way to nest/combine stories other than worklists seems odd to me | 22:13 |
| persia | For those that follow the same semantic value for "epic" as is used in JIRA, I think the use of a worklist is a reasonable implementation. | 22:13 |
| diablo_rojo | Perhaps another discussion to have in Denver | 22:13 |
| diablo_rojo | dhellmann, yeah that does seem redundant | 22:13 |
| dhellmann | maybe an epic is just a dressed up worklist :-) | 22:13 |
| persia | And, yeah, having a story that is both real and pushes the boundaries of what is sensible is an excellent source of information, not only for performance analysis but also for determining how to document best practices for usage patterns. | 22:13 |
| dhellmann | slap some paint on it and give it a new logo... | 22:13 |
| persia | That's one way to do it. | 22:13 |
| persia | In a different project that involved requirements processing, I worked with the idea of an "epic" being a collection of "stories", each of which was processed to have several "scenarios", where each "scenario" was a given-when-then test structure. In that case, "epic" might be a worklist + a summary of dramatis personae for the stories (although "story" meant something different in that context, although a StoryBoard "story" can definitely map to | 22:15 |
| persia | that "Story" as well). | 22:15 |
| persia | Although, in terms of the conceptual model that lead to worklists, I was more driven by the idea of trying to make a list of LP-style bugtasks that could be curated by a manager as instruction to direct reports. The idea of using it as a list of Stories, rather than just Tasks is interesting to me (and may cover "epic"), but an accident of the extreme flexibility of StoryBoard and ingenuity of the StoryBoard developers, rather than part of the | 22:17 |
| persia | intiial design elements. | 22:17 |
| *** fatema_ has joined #storyboard | 23:59 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!