| *** jcoufal has quit IRC | 00:22 | |
| *** cody-somerville has quit IRC | 00:40 | |
| *** openstackgerrit has quit IRC | 00:51 | |
| *** openstackgerrit has joined #storyboard | 00:52 | |
| *** coolsvap|away is now known as coolsvap | 03:50 | |
| *** coolsvap is now known as coolsvap|afk | 07:32 | |
| *** coolsvap|afk is now known as coolsvap | 07:56 | |
| *** persia has joined #storyboard | 08:46 | |
| persia | SotK: I don't think there should be any manual way to change whether or not a given item appears in an automatic worklist (although reordering may be interesting for some folk). | 08:49 |
|---|---|---|
| persia | That said, there's no reason that a UI can't present things to make it look like it does this (e.g. if one has an automatic worklist for items in reivew, the UI could represent attempting to place an item in that worklist as an attempt to change the item status so that it would meet the automatic criteria) | 08:50 |
| persia | On the pasted API model: I have always imagined it being interesting to be able to see all the worklists in which a given task is included (to answer the question: is someone else doing this? Should I focus on something else). | 08:54 |
| *** sambishop has joined #storyboard | 09:34 | |
| SotK | persia: interesting point about viewing all the worklists which contain a given task | 09:55 |
| SotK | that makes me feel like there should be a /worklists API endpoint, rather than adding it to the project/users API | 09:56 |
| persia | The idea being that if I am a development manager at a company, and I want to target my engineers, I may want to point them at tasks that aren't being prioritised by someone else. | 09:56 |
| SotK | the reason I was asking if anyone cared about manually messing with automatic worklists is that it would be much easier to implement them as "look at all the tasks in the db and apply a filter" than having to update a bunch of records which link the task and the automatic worklist, having to check for a match with *all* the automatic worklist filters when creating a task... | 09:58 |
| *** sambishop has quit IRC | 10:01 | |
| persia | I hope that my comment helped move you towards a filter-baed implementation. | 10:03 |
| persia | s | 10:03 |
| SotK | persia: it did, except for the bit about reordering being interesting :) | 10:03 |
| persia | You might want to ask other folk then. I don't think order is interesting for things that I imagine being automatic worklists (i.e. "Assigned", "Under Review", "Done"), but others may have other ideas about how to use them that would involve a need to order. | 10:05 |
| persia | My main interest is being able to define an automatic worklist that would act as a *negative* filter to my regular worklists. | 10:05 |
| persia | For some worklist purposes, I'm uninterested in anything that is already underway, but from the various folk I've spoken with about this stuff, some seem interested in a kanban-like view, including being able to view things that were completed. | 10:06 |
| *** sambishop has joined #storyboard | 10:13 | |
| * SotK starts considering kanban views and how to enforce task uniqueness properly | 10:13 | |
| SotK | I envision being able to define a kanban view by creating a new board, then adding worklists to the board (either from existing lists, or by creating a new one), with an error being raised if you attempt to add two lists containing the same task. | 10:15 |
| SotK | I think it will be fairly easy to restrict it once the board is in use, either give an error when someone tries to, or treat it as them moving the task from one list to another | 10:16 |
| persia | I think as much of the "kanban" functionality ought exist in the client as possible. | 10:22 |
| persia | The server should really only care about the state of the data: the application logic doesn't belong there. | 10:22 |
| persia | I agree it ought be fairly easy, once we have the data model for worklists. | 10:23 |
| persia | I also envison a simpler interface for worklists: just something so I can check what my supervisor wants done, or what is important for the next release, etc. | 10:23 |
| SotK | yup, I *think* the only things to be stored in the database for boards should be the name of the board, its owner and the worklists it contains | 10:24 |
| persia | That sounds about right. | 10:25 |
| persia | Another source of confusion with arbitrary worklists is how to construct the "priority" of a task in the standard view. | 10:25 |
| *** coolsvap is now known as coolsvap|away | 10:25 | |
| Zara_ | (looking at the tags spec again; wondering if worklists, favourites, etc could be obtained via tagging and filtering those tags. maybe reserve certain names for special tags (eg: *-favourites will put those things on *'s worklist)? or maybe that's too prescriptive) | 10:26 |
| persia | Zara_: To me the difference is that tags are global, whereas worklists/priority is local. | 10:26 |
| persia | If I tag something, I want everyone to see the tag. | 10:26 |
| persia | If I worklist something, I don't care if everyone sees it, so long as the people I expect to consume my worklist see it. | 10:27 |
| SotK | persia: I'm not sure that showing priority in the standard view is possible with arbitrary worklists, a person could easily have a task in different places in multiple lists. | 10:28 |
| * SotK thinks more | 10:28 | |
| *** coolsvap|away is now known as coolsvap | 10:28 | |
| persia | SotK: That matches my thought. Some prior discussion around this area talked about separating "Priority" and "Importance". | 10:28 |
| persia | I've generally seen "Importance" set based on some guidelines that were project-wide: the main issue is that this fails to align with the development priorities of most folk that assign engineers. | 10:29 |
| persia | (specifically including, as a majority of assignment, self-assignment) | 10:29 |
| SotK | hmm, so "Importance" being what is represented by the current implementation of Task priority? | 10:31 |
| persia | I don't know. | 10:32 |
| persia | I think the current "Priority" is a placeholder, beause the worklist model is really complex, and doesn't match most folk's experience with other task trackers, bug trackers, etc. | 10:34 |
| persia | Unfortunately, I can't remember all the conversations about it, and many have limited logs available. | 10:35 |
| Zara_ | yeah, I was wondering if it would be possible (and simpler?) to use tags for everything, and determine scope with a prefix attached to the tag. I think that would require reserving characters and would offer less flexibility than alternatives, but would be easier to implement. but I could be horribly wrong! | 10:36 |
| persia | Something like that is how some folk are using Malone, but it is generally painful. | 10:38 |
| Zara_ | I haven't heard of Malone; what is it? | 10:42 |
| *** coolsvap is now known as coolsvap|away | 10:43 | |
| *** CTtpollard has joined #storyboard | 11:26 | |
| persia | Zara_: Apologies: Malone is the old name for the bug tracking part of Launchpad. | 11:42 |
| persia | http://launchpad.readthedocs.org/en/latest/malone.html | 11:43 |
| Zara_ | ah, I see | 11:44 |
| *** coolsvap|away is now known as coolsvap | 11:44 | |
| persia | Note that the current implementation of that functionality in Launchpad does not match the vision posted there (hence being under "Documents of Historical Interest") | 11:44 |
| SotK | the more I think about it, the more I decide that worklists need their own API endpoint | 12:03 |
| * SotK rewrites his notes | 12:03 | |
| SotK | My current thoughts are here: http://sprunge.us/PUYa | 12:32 |
| SotK | what do people think regarding public/private worklists and boards? | 12:32 |
| * persia mumbles about paste.openstack.org being nice, and then reads the content | 12:34 | |
| persia | I don't see value to worklists being private to a project: I don't even really know what that might mean in terms of ACL. | 12:35 |
| * SotK removes that bit | 12:36 | |
| persia | I think worklists are personal, and shouldn't be changed by other users, but that might just be me. | 12:36 |
| persia | One use-case that might benefit from group-edited worklists would be something like a release-team-approved set of tasks. | 12:37 |
| persia | I guess I think a worklist should belong to a User or to a Team, and that makes the ACL easier. | 12:37 |
| persia | But if there's some easy implementation that is a superset of that, I think I don't care much. | 12:38 |
| SotK | that makes sense, though Teams appear to only be partly implemented at the moment :) | 12:38 |
| persia | Teams are one of those organisational gropus that are hard to specify. | 12:38 |
| persia | Because some folk like to break down teams based on the target of work (i.e. some project), whereas others like to break them down in terms of the source of the work (e.g. some employer). | 12:39 |
| persia | And the self-identity of members of these teams gets quickly complicated when both models prevail. | 12:40 |
| SotK | part of me wonders if it would be useful to have a Trello-like ACL system for worklists, whereby one can add a different User to the board as well as oneself | 12:40 |
| persia | That appeals to the team-manager use case that I usually have in mind when thinking about worklists. | 12:40 |
| persia | It could be modelled as a one-lane kanban, but that's not how I usually imagine looking at it. | 12:40 |
| SotK | I read somewhere in the depths of backscroll for this channel (I think) about Project pages linking to some "Official" worklists... I'm not sure how this should work. StoryBoard doesn't seem to have any kind of "PTL" ACL at the moment. | 12:44 |
| SotK | here: http://eavesdrop.openstack.org/irclogs/%23storyboard/%23storyboard.2014-02-21.log.html#t2014-02-21T17:13:20 | 12:45 |
| openstackgerrit | Adam Coldrick proposed openstack-infra/storyboard-webclient: Stop using fixed-width containers https://review.openstack.org/201124 | 13:32 |
| *** mrmartin has joined #storyboard | 13:48 | |
| *** mrmartin has quit IRC | 13:54 | |
| SotK | persia: do you have any comments on the data model I described in that paste? | 14:11 |
| * SotK ponders Trello-like ACLs some more | 14:31 | |
| SotK | I think that ACLs for boards should just be a UI which allows the setting of ACLs for a bunch of worklists at once, rather than boards having their own ACLs separate from the worklists that make them up. Do people agree with that? | 14:33 |
| *** mrmartin has joined #storyboard | 14:34 | |
| paulsherwood | not really | 14:36 |
| persia | I like the idea of worklists having ACL, rather than some other construct: it makes it easier to deal with worklists where folk aren't trying to manage multiple simultaneous worklists. | 14:36 |
| persia | heh. We have achieved controversy :) | 14:36 |
| paulsherwood | maybe i'm misunderstanding | 14:36 |
| paulsherwood | if i have a board with 6 lanes, i don't want to have to do 6 acl operations | 14:36 |
| persia | SotK: On the data model: back when I did data models, the fashion was all to strive for full normalisation, which this isn't. The content, and relationships seem relatively sane. | 14:37 |
| persia | paulsherwood: That makes sense. From my POV, if I have a worklist, I don't want to fuss with needing to define a "board" just to set an ACL. | 14:37 |
| paulsherwood | i'm ok with each worklist having its own acl, so long as the ux allows me to add team members to the whole board with minimum fuss | 14:37 |
| SotK | paulsherwood: I envision you having to do 1 operation in the UI which causes a change to the ACL of each of the 6 lanes | 14:38 |
| persia | But I agree that this particular issue could possibly be hidden in UI. | 14:38 |
| paulsherwood | SotK: ok then. i do note, however, that the two other solutions i've studied in depth (hobokan and trello) do it at board level, rather than lane level | 14:39 |
| SotK | paulsherwood: I want worklists to have their own ACLs, so that they make sense when not in a board. I also want to avoid having to try to resolve conflicts between board and lane ACLs (what happens if a board contains a lane that someone who can edit the board can't edit?) | 14:42 |
| SotK | hm, but then board-level ACLs do make sense for things like "who can add lanes? who can rename the board?" situations | 14:44 |
| * SotK goes back to thinking | 14:44 | |
| paulsherwood | re: (what happens if a board contains a lane that someone who can edit the board can't edit?) | 14:44 |
| paulsherwood | should not be possible, imo | 14:45 |
| paulsherwood | but i'm aware that others here may have use-cases for a worklist without a board. | 14:45 |
| paulsherwood | maybe board has acl. if worklist does not have board, worklist has acl? | 14:46 |
| persia | At least for me, the first proposal to organise worklists into a board came years after the first discussion to use worklists as a sensible way to prioritise work for an open task tracker. | 14:46 |
| persia | That said, the worklists-in-board proposal did arrive in the very early days of Storyboard discussions, so it is less alien for others perhaps than for me. | 14:47 |
| paulsherwood | i should have caused the hobokan work to be done in public... :/ | 14:48 |
| SotK | paulsherwood: that seems fine except for the situation where a worklist which is in a board is also used elsewhere not in a board? | 14:51 |
| persia | I suspect it is safe to assume that is uncommon. | 14:51 |
| persia | As a worklist owner, I probably either want a board or don't when I set up the worklist. | 14:51 |
| persia | Unless there is some speculation that one could have a "board" that consisted of several worklists, but in such a case, I think it would be better to consider that a "dashboard", where one doesn't have any of the constraints normally applied to a "board". | 14:52 |
| persia | (the idea being that I might want to see several other people's ideas of priorities in parallel, but when doing so, I don't mind duplicates, etc.) | 14:52 |
| paulsherwood | do we have clear needs to potentially have a given worklist appear in multiple 'boards'? | 14:54 |
| SotK | OK then, it seems that I should be treating kanban boards as something more special than "an group of worklists that has some constraints" in my head | 14:54 |
| * SotK is happy with "board has acl. if worklist does not have board, worklist has acl?" given the new separation of ideas he has | 14:55 | |
| SotK | paulsherwood: I think that that would be useful in "dashboards", but perhaps not in "boards" | 14:57 |
| paulsherwood | SotK: sounds right | 15:05 |
| *** cody-somerville has joined #storyboard | 15:06 | |
| * SotK tries to discover what the "permissions" table in the db is actually for | 15:06 | |
| paulsherwood | in which db? | 15:07 |
| SotK | storyboard's | 15:07 |
| SotK | I'm wondering if that is a prior attempt at implementing some kind of ACL | 15:08 |
| SotK | git blame is entirely un-useful | 15:09 |
| *** SotK has quit IRC | 15:36 | |
| *** paulsherwood has quit IRC | 15:36 | |
| *** jjardon has quit IRC | 15:36 | |
| *** SotK has joined #storyboard | 15:37 | |
| *** paulsherwood has joined #storyboard | 15:37 | |
| *** jjardon has joined #storyboard | 15:49 | |
| *** MarkAtwood has joined #storyboard | 15:53 | |
| Zara_ | hm... was playing around with the search function, hoping to eventually get stories searchable by tags. instead managed to break my storyboard instance. :D changed all files back to how they were before I messed with the search function, but it's still broken. something to look into tomorrow... | 16:54 |
| persia | You might find it interesting to play with various git functions to make sure that the changes made aren't just the changes you expected. | 17:00 |
| persia | There's ways to tell git not to ignore the normally ignored generated files, etc. | 17:00 |
| *** cody-somerville has quit IRC | 18:09 | |
| *** persia has quit IRC | 19:21 | |
| *** persia has joined #storyboard | 19:23 | |
| *** persia has quit IRC | 19:45 | |
| *** cody-somerville has joined #storyboard | 20:03 | |
| *** cody-somerville has quit IRC | 20:03 | |
| *** cody-somerville has joined #storyboard | 20:03 | |
| *** persia has joined #storyboard | 20:07 | |
| *** persia has joined #storyboard | 20:07 | |
| *** lifeless has quit IRC | 20:20 | |
| *** lifeless has joined #storyboard | 20:21 | |
| *** mrmartin has quit IRC | 20:46 | |
| * persia stumbles across https://wiki.openstack.org/wiki/StoryBoard/Task_Lists , finding it has a nice summary of when tags make sense and when worklists make sense, and also discusses a bit the different use cases for lists-of-worklists and kanban-like boards. | 21:22 | |
| persia | Interestingly, it asserts that tags belong to stories and worklists belong to tasks, in a strict fashion. I think I agree with tags being only for stories, but with recent discussions, I'm weakening my opinion that worklists should always be tasks (to cover the "We need to assign tasks for this story" meta-task) | 21:23 |
| SotK | persia: I think I found that at some point too, it was useful | 21:24 |
| SotK | I definitely agree on the "assign tasks for stories" use-case | 21:24 |
| persia | It also helps for the higher-level view, where someone doesn't actually care about the implementation details. Something like tracking which approved specifications are landing within a development period, etc. | 21:25 |
| * persia still has a vague dream about using a patch-tracker like interface to land stories into a task tracker, but suspects that is a successor or successor^2 project | 21:26 | |
| SotK | I suspect so to ;) | 21:28 |
| SotK | s/to/too/ | 21:28 |
| *** coolsvap has quit IRC | 21:28 | |
| SotK | also, the kanban UI concept I mentioned hacking up elsewhere is visible here if you're interested: http://81.147.115.101/#!/dashboard/kanban (you may need to log in) | 21:29 |
| *** coolsvap|away has joined #storyboard | 21:33 | |
| persia | I think I do need to log in. Be nice if that wasn't a requirement. | 21:35 |
| persia | Interesting. That seems more like a set of worklists than a kanban, but is interesting to use. Are some of the lanes different than others in some way? | 21:37 |
| SotK | not right now, I just threw it together to let me think about kanbans a bit :) | 21:39 |
| SotK | the three that have tasks in load all the active stories, the other two load all the merged and all the invalid stories respectively | 21:40 |
| persia | I dragged stories around a bit. | 21:43 |
| persia | So for my view, the first column has some stuff, the second column some other stuff, the third column three copies of Mr. Boop, and the remaining columns everything not Mr. Boop. | 21:44 |
| *** cody-somerville has quit IRC | 21:44 | |
| persia | Do those sort of changes show for other folk? | 21:44 |
| * persia gets distracted by non-IRC | 21:45 | |
| SotK | not here, it doesn't actually make any changes to the underlying data yet, but that shouldn't be too hard to prototype quickly in a similar way | 21:46 |
| SotK | s/here/yet/ | 21:46 |
| SotK | its too late for typing for me :) | 21:46 |
| * SotK disappears | 21:50 | |
| *** cody-somerville has joined #storyboard | 21:58 | |
| *** jcoufal has joined #storyboard | 22:02 | |
| *** jcoufal_ has joined #storyboard | 22:04 | |
| *** jcoufal has quit IRC | 22:07 | |
| *** jcoufal_ has quit IRC | 22:15 | |
| *** cody-somerville has quit IRC | 22:58 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!