| *** MaxV has quit IRC | 01:06 | |
| *** mrmartin has joined #storyboard | 01:53 | |
| *** MaxV has joined #storyboard | 02:07 | |
| *** MaxV has quit IRC | 02:12 | |
| *** mrmartin has quit IRC | 02:51 | |
| *** MaxV has joined #storyboard | 05:06 | |
| *** MaxV has quit IRC | 05:11 | |
| *** mrmartin has joined #storyboard | 06:16 | |
| *** k4n0 has joined #storyboard | 06:24 | |
| *** cody-somerville has quit IRC | 07:09 | |
| *** cody-somerville has joined #storyboard | 07:22 | |
| *** jtomasek has joined #storyboard | 07:37 | |
| ttx | jdimike, yolanda: the main issue with notconfirmed/confirmed stories is that it forces everyone in a given workflow ("stories have to be triaged and confirmed") while it's nobody's job to actually triage them | 07:52 |
|---|---|---|
| ttx | jedimike, yolanda: To find "things you should work on" I trust the new multidimensional priority concept (using story/task lists) | 07:53 |
| yolanda | ttx, but i find there is a lack of control now | 07:53 |
| ttx | Example: you work on storyboard and want to find your next action, you can have a look at the team story/tasklist and pick what has been prioritized there | 07:54 |
| ttx | yolanda: also in Launchpad, it's the task that is triaged, not the bug | 07:54 |
| ttx | at least that way it's someone's task to triage it | 07:54 |
| ttx | yolanda: I agree that right now we are missing the concept that will make that work on storyboard | 07:55 |
| ttx | While we refine the story/task list concept, I'd recommend using tags | 07:55 |
| ttx | (which apply to story) | 07:56 |
| yolanda | yes, concern is that someone can file a story now, and we don't have a way to mark them as invalid, prioritize, etc... | 07:56 |
| ttx | yolanda: we can prioritize with the unidimensional priority (same as in Launchpad) | 07:56 |
| ttx | and we can set status to Invalid as well | 07:57 |
| yolanda | well, to a task, not to a story... or am i missing something? | 07:57 |
| yolanda | maybe is that an admin power? | 07:57 |
| ttx | yolanda: not sure I follow you. You're using Launchpad in your comparison in the discussion above. Bugs in Launchpad do not have invalid status | 07:58 |
| ttx | only Bugtasks have | 07:58 |
| ttx | so we are in the same situation | 07:58 |
| ttx | That's a necessary approach, since a story may be valid for some groups and invalid for some others | 07:58 |
| yolanda | oh yes, but well, when you create a bug in launchpad, you associate to the package, the Affects to... and then the entry is just created, so is easier to follow | 07:59 |
| yolanda | here in storyboard you can have stories without any task created, so that info is missing by default | 07:59 |
| ttx | A story is a theme, which will result in several action items. Each of those have a separate status and can be confirmed or invalidated | 07:59 |
| ttx | each of those may be handled by a different team | 08:00 |
| ttx | That is what we are trying to solve here -- complex cross-project coordinated actions | 08:00 |
| ttx | That's where Launchpad lets us down | 08:00 |
| ttx | That is what Storyboard is supposed to solve | 08:00 |
| *** jcoufal has joined #storyboard | 08:00 | |
| ttx | It's easy to lose sight of it at this stage | 08:00 |
| yolanda | mm, maybe when we create the story types, if we have the ability to create a workflow, if the story type is a bug, we could create some task by default, with the status, priority.... | 08:00 |
| ttx | sicne we are using it mostly on single-project stories | 08:01 |
| ttx | But the goal is to use it for OpenStack | 08:01 |
| ttx | yolanda: so yes, I agree that the taskless story is confusing | 08:01 |
| ttx | in Launchpad all "bugs" have at least a task | 08:01 |
| yolanda | ttx, as the story concept is wider than the launchpad blueprint/bugs, this can be a bit confusing by some of the cases, i think that the concept as we have now matches better features than bugs | 08:01 |
| ttx | I've been going back and forth with krotscheck on that one. should we allow stories with no tasks, and what do they mean | 08:02 |
| ttx | The problem being, a story with no task is nobody's job to handle | 08:03 |
| yolanda | ttx, if we dig on the workflow for the story types, and have the workflow that creates a task automatically for bug/security bugs, that could help | 08:03 |
| ttx | yolanda: yes, we could create a task by default when no task is provided, to go to some triager group | 08:04 |
| yolanda | that sounds good to me | 08:04 |
| ttx | yolanda: that's what LP does when you don't set any affected project | 08:04 |
| ttx | the trick then is to staff that team :) | 08:05 |
| yolanda | well, it could be a daily routine as we do with code reviews | 08:05 |
| ttx | yolanda: also, removing he only task of a story should probably be disallowed | 08:05 |
| yolanda | ttx, then you remove the story... | 08:06 |
| ttx | yolanda: but I certainly agree with you that we covered the task tracking case much more than the bugtracking case so far | 08:06 |
| petefoth | Excuse me for butting, in, but in our process we will start by creating a draft of a story, which will then progress through several statuses before it is 'agreed' or ready to have tasks associated with it. | 08:06 |
| ttx | in task tracking, you eznter tasks you have the intention to do. In bugtracking, you suggest stuff to be fixed, but require some triaging step | 08:07 |
| petefoth | So it would be useful for us for a story to be able to have a status (preferably configurable) in the same way as a task | 08:07 |
| yolanda | ttx, i started to see the problem recently, when people are starting to raise concerns or small bugs into storyboard, and there is a bit of mess | 08:07 |
| yolanda | petefoth, this is one of the points we are working on, having configurable task status | 08:07 |
| ttx | petefoth: so, in theory you can have a task for "refining the story", which when completed will result in several other tasks being added | 08:08 |
| ttx | tasks don't necessarily have to be associated to a code repo | 08:08 |
| ttx | they can track other types of work | 08:08 |
| ttx | If the first step in handling that story is refine it to the point where you can have more tasks entered... you should track that as a task | 08:09 |
| petefoth | yolanda: yes I saw that :) That will really helpful for us | 08:09 |
| petefoth | ttx: yes that would work | 08:09 |
| petefoth | I’ll get back to lurking :) | 08:09 |
| * ttx filed story for ability to add non-code tasks | 08:10 | |
| ttx | files* | 08:10 |
| yolanda | ttx, i think that a spec for task statuses should be needed. I started to work on it, but i saw that it's relying now on some status for reporting and grouping tasks, so if we want to configure them, we should need to adapt it | 08:10 |
| ttx | yolanda: don't we already have task statuses ? | 08:11 |
| ttx | invalid, todo... | 08:12 |
| yolanda | ttx, yes, but one of the stories was to be able to configure them | 08:12 |
| yolanda | so you can have different ones | 08:12 |
| ttx | which one do you think is missing ? Would they be different for each project ? | 08:12 |
| yolanda | well, have the ability to adapt to any workflow. For example having the "draft" as petefoth told | 08:13 |
| yolanda | or just naming them in a different way, there was a conversation yesterday about that | 08:14 |
| yolanda | i don't think we miss anything but we miss the ability to adapt to the people's workflow, not only to openstack | 08:14 |
| yolanda | https://storyboard.openstack.org/#!/story/331 | 08:14 |
| ttx | yolanda: there are some pitfalls ahead with that approach. For example we want to rely on Gerrit to set the status automatically | 08:14 |
| *** wdutch has joined #storyboard | 08:15 | |
| ttx | if each project has its own set of statuses... | 08:15 |
| yolanda | well, not for projects, but generally for deployment | 08:15 |
| ttx | yolanda: then the pitfall becomes federation | 08:16 |
| ttx | it will be more difficult to federate deployments with different set of statuses | 08:16 |
| petefoth | ttx: we too want to use gerrit, but in a configurable way and probably not in *all* or projects. We would like the interactions between gerrit an storyboard to be flexible. | 08:17 |
| ttx | tags is where we usually cater for projectspecific workflows | 08:17 |
| yolanda | ttx, that's true but then it's a matter of the end user to properly configure their task statuses to match | 08:18 |
| petefoth | so that gerrit tells storyborad this patch set has a +1, and StoryBoard sets the task status appropriately | 08:18 |
| ttx | anyway that would need a spec | 08:18 |
| yolanda | ttx, yes, not trivial | 08:19 |
| ttx | added a spec task to that story :) | 08:19 |
| yolanda | and even task priority needs the same approach | 08:19 |
| ttx | well, task priority as it stands is a placeholder | 08:22 |
| ttx | the roadmap is to refactor iot completely into a multidimensional priority system | 08:22 |
| ttx | because everyone's priority is different | 08:23 |
| ttx | See https://wiki.openstack.org/wiki/StoryBoard/Vision and https://wiki.openstack.org/wiki/StoryBoard/Task_Lists | 08:24 |
| ttx | If we follow that road we won't have "configurable task priorities". We'll just have team and personal tasklists | 08:25 |
| yolanda | ttx, that's quite an interesting concept | 08:25 |
| ttx | yolanda: it's because for complex cross-project tracking we realized that nobody liked whatever priority was set | 08:25 |
| ttx | it was someone's priority, not yours. | 08:26 |
| ttx | so it's useless to help you let you find your next action | 08:26 |
| ttx | The current Low/Med/High is just something we are using while we think about the long-term solution | 08:27 |
| ttx | because it's a bit unnatural to not have priority at all in a bugtracking system | 08:27 |
| ttx | so we need time to wrap our heads around the concept | 08:27 |
| yolanda | ttx, i like that concept and is something very new, not seen in most of the bug trackers | 08:27 |
| ttx | yolanda: it also makes federation possible. HP storyboard for example can consume upstream storyboard and have their own priorities exposed in their instance | 08:28 |
| ttx | i.e. your own milestones, your own tasklists | 08:29 |
| ttx | also the milestone concept from LP can be represented as a tasklist | 08:29 |
| ttx | currently milestones in LP are both a planning (task list) and a reporting (what landed when) concept, and the confusion is painful. | 08:30 |
| ttx | goal in storyboard is to separate the two | 08:30 |
| ttx | planning using milestone/sprint tasklists | 08:31 |
| ttx | and reporting by making storyboard tag-aware | 08:31 |
| ttx | (as inb git tags aware) | 08:31 |
| ttx | so it can tell in which version a given fix has landed | 08:31 |
| ttx | I'm trying to keep my eyes on the endgame. I don't want us to spend two years and find ourselves with the same limitations that prompted us to move away from Launchpad in the first place | 08:32 |
| yolanda | ttx, btw, problem with launchpad is the lack of investment and support | 08:34 |
| ttx | yolanda: well sure, but not only. It's also because it's not truly cross-project | 08:35 |
| ttx | it's ubuntu-centric :) | 08:35 |
| yolanda | ttx, yes, mostly for ubuntu bugs, it was horrible for blueprints as well | 08:35 |
| ttx | there are a number of hacks (especially around series/branch tracking) that are really weird and clearly an afterthought | 08:36 |
| ttx | I wrote countless scripts to work around those hacks | 08:36 |
| yolanda | ttx, yes, also api sucked and had very bad things. But it had some quite interesting concepts we could adapt | 08:38 |
| ttx | yolanda: well, the story/task thing is the main concept we adopted | 08:39 |
| ttx | (bug/bugtask in LP parlance) | 08:40 |
| yolanda | i liked the natural integration it had with the operating system, also marking a bug as hot if reported by so many people. That integration does not apply to storyboard, but the ability to add users interested in a story/task... maybe | 08:42 |
| *** petefoth1 has joined #storyboard | 08:54 | |
| *** MaxV has joined #storyboard | 09:01 | |
| paulsher1ood | i'm interested in this priority/status puzzle because we've explored the problems quite deeply on a series of projects (not openstack) | 09:05 |
| paulsher1ood | having used kanban extensively, one of the insights that seems hard to grasp for new folks is that 'priority' in a kanban worldview is entirely achieved by 'lane' | 09:06 |
| paulsher1ood | one of the key ideas in kanban is to limit number of tasks (here could be stories) per lane, where lane here would correspond to status. | 09:07 |
| paulsher1ood | so prioritization is implicit because folks are required to sort stories/tasks into lanes. and then folks take their work/todo from a given lane | 09:08 |
| paulsher1ood | one of the things i like about storyboard is the git integration on status for that part of the workflow. but it's not clear to me that one worklflow can possibly fit the whole of the space that storyboard is trying to cover | 09:09 |
| *** jedimike has joined #storyboard | 09:12 | |
| paulsher1ood | my experience with non-kanban systems is that the concept of 'priority' always falls apart in the real world. we had a project for example where they started with 'A' bugs... then had to raise to 'A+' when there were too many, then 'A++' | 09:12 |
| paulsher1ood | so one of the benefits of the kanban worldview is that it can make it extremely clear for the non-developers on a project that only so many tasks/stories can be 'prioritized' at a time. | 09:14 |
| paulsher1ood | i appreciate that the storyboard project doesn't have clear 'managers' trying to prioritize the work, but i do believe that a kanban visualization can be of significant help for stakeholders and contributors to grasp what is being done | 09:15 |
| * paulsher1ood gets back to lurking too | 09:16 | |
| jedimike | paulsher1ood, I 95% agree :) | 09:16 |
| paulsher1ood | jedimike: cool! what's the 5% please? | 09:17 |
| jedimike | paulsher1ood, just that the falling part doesn't *always* happen, just 95% of the time it does. I do like the kanban approach a lot though, I think it works very well. | 09:19 |
| paulsher1ood | jedimike: actually yes. after i wrote that i wanted to put s/always/nearly always/ :-) | 09:21 |
| jedimike | heh :)_ | 09:21 |
| paulsher1ood | jedimike: i like it too. the one thing to beware of is that for big, complex projects (as here) it can be easy to drown in kanban cards | 09:23 |
| paulsher1ood | kanban can only 'scale' by segregation to multiple boards for sub projects i think | 09:24 |
| jedimike | paulsher1ood, agreed, so I usually like a "not now" lane where everything starts, have a periodic review of what should come out of there into the first real work lane so we're not overwhelmed | 09:24 |
| jedimike | and yeah, has to be at least a board per project | 09:24 |
| paulsher1ood | jedimike: yes - we call it 'wishlist' by default.. then migrate the blessed cards to a lane called 'backlog' or 'todo' or 'next up' depending on the preferences of the project :) | 09:26 |
| jedimike | cool | 09:26 |
| paulsher1ood | but once wishlist has 50 cards in it, even that gets unweildy. so we tried a separate triage board, with extra lanes so that things can be separated out from 'incoming' into 'can wait' 'needs more info' etc | 09:27 |
| jedimike | yeah that makes sense | 09:28 |
| *** ridgerunner has joined #storyboard | 09:32 | |
| paulsher1ood | comparing our experience to the storyboard approach, i can't help thinking that organisations will need to experiment with and evolve their own custom workflows (lanes) | 09:36 |
| jedimike | yeah, i was thinking about the possibility of some plugin or sync script to interact with trello | 09:37 |
| paulsher1ood | and that makes me wonder if the linkage with git needs to be extended and made flexible to cope with custom workflows, or just restricted to the coding/testing/review/done part | 09:37 |
| paulsher1ood | elsewhere petefoth has started a religious war by proposing taigo instead of trello (which itself got adopted by folks when we couldn't figure out storyboard fast enough) | 09:39 |
| paulsher1ood | s/taigo/taiga/ | 09:39 |
| jedimike | heh, at least he didn't suggest leankit ;) | 09:40 |
| petefoth | which was odd as taiga is FOSS and Trello definintely isn’t :) But Trello has the advantages of a: working now and b: having an easy intuitive UI | 09:40 |
| * petefoth DDGs ‘leankit’ :) | 09:40 | |
| petefoth | Taiga has those things too | 09:43 |
| jedimike | so we'll probably end up with a module that wraps around our API and interfaces with trello and/or other kanban board, yeah? | 09:44 |
| petefoth | jedimike: that would be a cool palce to get to | 09:46 |
| jedimike | petefoth, I just think we have to be careful that whatever board we use, it only gets used as a workflow solution, and that any changes to the stories or tasks happen in storyboard directly. Otherwise we'd end up with a whole host of sync issues, or so I've seen with similar systems in the past | 09:49 |
| petefoth | jedimike: some of our guys worked on such a wrapper and made the interface with Storyboard read-only. | 09:50 |
| jedimike | petefoth, great :) | 09:50 |
| petefoth | Though it think, in a Kanban board I want to be able to move a card between lanes. I think we could work if storyboard provides an API that would allow us to change at least some of the data associated with a card. | 09:51 |
| petefoth | We don’t want to keep or manipulate our own copy of the data | 09:51 |
| petefoth | Thast way lise madness and grief :) | 09:52 |
| jedimike | so, something on the story in Storyboard that can reflact what lane it's in, and when we move it in the board, it's updated in Storyboard? | 09:54 |
| petefoth | jedimike: that would work for us I think | 09:55 |
| jedimike | sounds good to me | 09:55 |
| petefoth | And when stuff is updated in Storyboard, that change get reflected (eventually) in the board | 09:56 |
| petefoth | Where the value of ‘eventually’ is down to the implementor of the board that uses the API | 09:56 |
| jedimike | yep | 09:57 |
| petefoth | And such an API could be used (in a way that is configurable, with sensible defaults) by other clients to change status, eg Gerrit or Zuul or Jenkins can give a +1. (Though I’m not familiar with how these tools already interface with StroyBoard and it’ data, so I’ll go quiet now) | 10:02 |
| paulsher1ood | i disagree with petefoth on this. i don't see any problem with kanban being readonly, at least to explore the functionality. to move card, click on it and it takes you to the storyboard view of the story/task, where you can edit according to storyboard rules/workflow | 10:02 |
| petefoth | paulsher1ood: if StoryBoard does provide a writeable API, then a client can choose whether to use that API or take you to the appropriate StoryBoard view. But thqat is ‘implementation detail’ :) We could work with a readonly API though, if that’s all that is avaialable | 10:04 |
| jedimike | I think it should be read-only, except for the kanban lane, if we want Storyboard to have knowledge of that too then the kanban board should be able to set that | 10:06 |
| petefoth | jedimike: OK | 10:06 |
| paulsher1ood | that could work too. except i want 'todo' 'in progress' 'review' and 'merged' as kanban lanes too :) | 10:07 |
| jedimike | hmmm, so a lane change triggering a status change? | 10:11 |
| jedimike | there could be some config that mapped lanes to status | 10:11 |
| *** jfjoly has joined #storyboard | 10:18 | |
| petefoth | And a status change triggering a lane change, mapped using a smilar config? | 10:19 |
| jedimike | yeah, that could work | 10:26 |
| *** k4n0 has quit IRC | 11:20 | |
| *** jfjoly has quit IRC | 12:31 | |
| *** CTtpollard has joined #storyboard | 12:34 | |
| *** jcoufal has quit IRC | 12:56 | |
| *** jcoufal has joined #storyboard | 12:57 | |
| mrmartin | re | 13:03 |
| openstackgerrit | yolanda.robla proposed openstack-infra/storyboard-webclient: Story project is defaulted to the current project if available https://review.openstack.org/137057 | 13:25 |
| *** jcoufal has quit IRC | 14:03 | |
| *** jcoufal has joined #storyboard | 14:04 | |
| yolanda | krotscheck, NikitaKonovalov, i'm taking a look at the user preferences api, to remove local storage and use the api | 14:16 |
| yolanda | i see that the api is retrieving the preferences in bulk, as the webclient is relying on localStorage, to get/set preferences one by one | 14:16 |
| yolanda | what's the prefered approach here? use the concept of the backend api and do that in bulk? should be more optimal | 14:16 |
| NikitaKonovalov | yolanda: reading the preferences from API is easier when the whole dict is transferred, so I think the GET endpoint should stay the same | 14:21 |
| yolanda | and the POST? it assumes that we send a bulk of preferences as well | 14:22 |
| NikitaKonovalov | You dont need to send them all at once, the POST handler will delete the preference only if null is passed | 14:24 |
| NikitaKonovalov | the POST endpoint actually already contains the PUT logic also | 14:25 |
| yolanda | oh, looking at the code, i see now | 14:27 |
| yolanda | cool, i can work with it | 14:27 |
| *** jesusaurus has quit IRC | 14:35 | |
| *** jcoufal_ has joined #storyboard | 14:53 | |
| *** jcoufal has quit IRC | 14:53 | |
| *** jcoufal_ has quit IRC | 14:54 | |
| *** jcoufal has joined #storyboard | 14:54 | |
| *** jesusaurus has joined #storyboard | 14:58 | |
| *** mattfarina has joined #storyboard | 15:13 | |
| *** CTtpollard has quit IRC | 15:33 | |
| krotscheck | Ok, I’m setting a new rule for our channel. No more mentioning launchpad. | 15:33 |
| krotscheck | :) | 15:33 |
| krotscheck | We are not building launchpad | 15:33 |
| paulsher1ood | heh :-) | 15:34 |
| krotscheck | We can be respectful of someone’s past history, and the tooling and concepts that they are familiar with. | 15:34 |
| krotscheck | But our biggest challenge is to identify which common themes from ALL tools, and from OpenStack’s process, work. | 15:35 |
| krotscheck | And which don't. | 15:35 |
| krotscheck | So my question given the earlier discussion is: Does status make sense? Do workflows make sense? | 15:38 |
| *** mattfarina has quit IRC | 15:38 | |
| krotscheck | Do any of the concepts that we’re trying to bring in from other projects make sense? | 15:38 |
| krotscheck | Not even on a “Hey I need this thing” level, but more on a “Why are we doing it this way” level. | 15:38 |
| krotscheck | Because, at the end of the day, what I feel matters is that we can answer three questions. What do we need to do. What are we working on. What did we do? | 15:39 |
| krotscheck | And all the other concepts: workflow, priority, status, etc, are decorations. | 15:40 |
| krotscheck | Priority is meaningless for anyone other than the person who’s doing the work. If a manager wants to change priority, it’s up to them to either convince the person doing the work, or to build team consensus so that someone else will do the work. | 15:41 |
| krotscheck | Only the person who actually _does_ the work knows how to sequence items, and how to prioritize items. | 15:42 |
| krotscheck | Anything above and beyond that assumes that an IC is nothign more than a cog in a machine that is ordered to assemble widgets according to what their manager says. | 15:43 |
| krotscheck | But hey, I could be wrong. But what really matters is that I’m actually contributing code right now. | 15:44 |
| krotscheck | And if you disagree, we can chat on gerrit, or you can submit your own patches. | 15:45 |
| jedimike | hmmm | 15:54 |
| jedimike | priority should be obvious if you read the roadmap | 15:54 |
| krotscheck | jedimike: Why? If it’s grouped into a release, and everyone’s agreed that the next release is composed of X features, does it matter what the priority is? | 15:54 |
| krotscheck | Or what order the work happens in? | 15:55 |
| jedimike | krotscheck, that's true. The next priority is the next release, or any security fixes. | 15:55 |
| jedimike | so i guess what I want to see next is the answer to "What do we need to do", and for me, the next piece of that is being able to see if something is under discussion, or if it's been finalized and is ready to get implemented | 15:57 |
| *** jtomasek has quit IRC | 15:57 | |
| persia | "Status" has meaning in terms of whether something is currently being done (to prevent duplicate work), "Priority" is useful not only in terms of the person doing work, but in terms of a person choosing what to do next. That said, there is unlikely to be a meaningful global priority over a project, rather different teams/managers/etc, need different priority lists (which need not be comprehensive: many stories may have no priority for a given | 16:01 |
| persia | stakeholder). | 16:01 |
| persia | Workflows make sense for individual teams: while proposing some samples is useful, forcing a single workflow on many differently shaped teams will lead to workarounds by both teams who find it too much administration, and teams who are underserved by the available workflow. | 16:02 |
| * persia will really have some StoryBoard time this week, so that next meeting will not contain as much disappointment | 16:03 | |
| *** reed has joined #storyboard | 16:08 | |
| *** petefoth has quit IRC | 16:11 | |
| yolanda | krotscheck, you are right. For the ones we've been heavily involved on launchpad there is a natural desire of comparing with that | 16:17 |
| yolanda | miss the good things that we had with that tools, and improve the bad ones, but yes, we need to think on storyboard as an independent product, not a replacement of LP | 16:18 |
| *** mattfarina has joined #storyboard | 16:20 | |
| *** jtomasek has joined #storyboard | 17:02 | |
| *** petefoth has joined #storyboard | 17:18 | |
| *** jtomasek has quit IRC | 17:26 | |
| *** jcoufal has quit IRC | 17:40 | |
| *** mrmartin has quit IRC | 17:58 | |
| *** mrmartin has joined #storyboard | 18:08 | |
| *** MaxV has quit IRC | 18:08 | |
| *** timrc-afk is now known as timrc | 18:54 | |
| *** MaxV has joined #storyboard | 18:58 | |
| *** jtomasek has joined #storyboard | 18:58 | |
| *** MaxV has quit IRC | 19:19 | |
| *** jtomasek has quit IRC | 19:28 | |
| *** mrmartin has quit IRC | 19:54 | |
| *** jedimike has quit IRC | 20:05 | |
| *** MaxV has joined #storyboard | 20:29 | |
| openstackgerrit | Michael Krotscheck proposed openstack-infra/storyboard: Fixed bug in working directories. https://review.openstack.org/137197 | 20:33 |
| *** timrc is now known as timrc-afk | 20:36 | |
| *** timrc-afk is now known as timrc | 20:37 | |
| openstackgerrit | Michael Krotscheck proposed openstack-infra/storyboard: Fixed bug in working directories. https://review.openstack.org/137197 | 20:42 |
| *** MaxV has quit IRC | 20:51 | |
| *** MaxV has joined #storyboard | 21:11 | |
| *** MaxV has quit IRC | 21:15 | |
| *** MaxV has joined #storyboard | 21:33 | |
| openstackgerrit | Michael Krotscheck proposed openstack-infra/storyboard: Plugins may now register cron workers. https://review.openstack.org/129609 | 21:48 |
| *** mattfarina has quit IRC | 22:04 | |
| *** MaxV has quit IRC | 22:27 | |
| *** mattfarina has joined #storyboard | 22:35 | |
| *** mattfarina has quit IRC | 22:45 | |
| *** MaxV has joined #storyboard | 22:47 | |
| *** MaxV_ has joined #storyboard | 22:50 | |
| *** MaxV has quit IRC | 22:51 | |
| *** mattfarina has joined #storyboard | 22:53 | |
| *** mattfarina has quit IRC | 23:08 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!