| *** mrmartin has joined #storyboard | 03:53 | |
| *** jtomasek__ has joined #storyboard | 05:51 | |
| *** mrmartin has quit IRC | 06:09 | |
| *** mrmartin has joined #storyboard | 06:09 | |
| *** jtomasek__ has quit IRC | 06:13 | |
| *** mrmartin has quit IRC | 06:15 | |
| *** mrmartin has joined #storyboard | 06:16 | |
| *** mrmartin has quit IRC | 06:16 | |
| *** alexismonville has quit IRC | 07:14 | |
| *** mrmartin has joined #storyboard | 08:29 | |
| *** jtomasek__ has joined #storyboard | 08:35 | |
| *** alexismonville has joined #storyboard | 10:06 | |
| * SotK goes to read persia's reply | 10:18 | |
| *** mrmartin has quit IRC | 10:33 | |
| * SotK replies, and apologises in advance for it becoming somewhat like a train of thought | 11:16 | |
| *** mrmartin has joined #storyboard | 11:45 | |
| persia | No worries: my posts have all been that way. The issue us that we all agree on the need to provide a means for managers to assign dates, and that it should work for multiple stakeholders, but this is *hard*. :) | 11:45 |
|---|---|---|
| *** alexismonville has quit IRC | 11:52 | |
| persia | I like Zara's table, but need to think more to respond to the other ideas. | 11:53 |
| Zara | SotK: QUICK, IMPLEMENT IT WHILE HE'S NOT LOOKING | 11:53 |
| Zara | :P but yeah, I think we're going to discover all the ways it's insufficient *by* implementing it | 11:54 |
| persia | And it would be frustrating to spend months implementing something that needed to be redone. | 11:55 |
| Zara | right, but less frustrating to spend a week or two implementing something that needs to be redone. | 11:55 |
| persia | Yes. I think iterative implementation of pieces if it makes sense. | 11:56 |
| Zara | :) ease-of-implementation factors in for me when trying to get an idea of how much of the theory we should look at before and after implementation, just in general | 11:57 |
| Zara | but I also don't want something too rigid to change, that doesn't really suit anyone | 11:57 |
| persia | I wonder if perhaps the story should be written behaviorally, and we can extract scenarios on which we agree for experimentation and feedback. | 11:58 |
| persia | Yes. Flexible is good :) | 11:58 |
| Zara | :) I think that might work later on, but I'd like to know which scenarios are more likely, first-- which we may only find out via complaints. In the meantime, I defer to SotK on what's going to be difficult to implement. I think we should steer clear of anything with more permissions, for now, because they always seem to be a pain. | 12:04 |
| Zara | so I want to be sure people need a solution involving them, first. | 12:05 |
| Zara | hm, 12:09 and I still haven't managed to make breakfast | 12:08 |
| persia | Food is good. Helps thought. | 12:11 |
| Zara | tbf I'm not sure how nutritious https://www.britishfoodstoreonline.co.uk/product_images/a/911/triple_choc_crunch_500g__83559.jpg is | 12:13 |
| *** alexismonville has joined #storyboard | 12:27 | |
| * SotK wonders how Zara's table relates to per-board targets | 12:29 | |
| * SotK expects we don't want due dates leaking from private boards | 12:30 | |
| Zara | ah, the table was for deadlines, targets were separate (at the time I was thinking those were per-card) | 12:30 |
| Zara | well, applied per-card, set per-board | 12:30 |
| SotK | hmm, so how ydo you pick which deadline you can't create a target later than? | 12:31 |
| SotK | is that the "filter by creator" bit? | 12:31 |
| Zara | yup | 12:31 |
| * SotK sees clearer now | 12:31 | |
| Zara | yeah, 'whose deadlines do I care about?' (maybe then defaulting to soonest deadline if 'all' is selected) there's probably all sorts of horrors that I haven't thought about yet. | 12:32 |
| *** mrmartin has quit IRC | 12:34 | |
| Zara | maybe a solution for the which-dates-on-cards problem is to make it configurable by the user, eg: 'show target dates' 'show deadlines' 'show both'. though then you might get people mistaking target dates for deadlines, and thinking they don't have any... so the view would need to account for that | 12:38 |
| Zara | I'm picturing 'BTW YOU MIGHT HAVE A DEADLINE CLICK THE DEADLINE VIEW CLICK IT CLICK IT CLICK IT' in a blinking comic sans marquee | 12:39 |
| SotK | I think that when picking between a per-board target and some deadlines, the choice is "show the closest date" | 12:39 |
| Zara | right, but then it's kind of pointless to be able to set one later (unless 'just targets' view is an option that's always deselected by default) | 12:40 |
| -openstackstatus- NOTICE: Infra running with lower capacity now, due to a temporary problem affecting one of our nodepool providers. Please expect some delays in your jobs. Apologies for any inconvenience caused. | 12:41 | |
| SotK | hm, we still want to set targets later than deadlines? :/ | 12:43 |
| Zara | I don't. I think persia did, afaik we hadn't settled it? | 12:44 |
| Zara | oh, but that's assuming a global deadline | 12:45 |
| * SotK asserts that if you can set targets later than deadlines then deadlines are just targets which aren't related to a specific board, and so one of the two would be pointless | 12:45 | |
| Zara | yeah, it's fine, I was thinking of deadlines that weren't filtered by creator | 12:46 |
| Zara | assume targets can't be later than the filtered deadlines | 12:46 |
| Zara | tricky if users pick one filter, then another | 12:46 |
| Zara | it'd have to be possible to *set* a later target, but only *show* it if it were earlier | 12:47 |
| * SotK is also worried about this getting too complicated | 12:49 | |
| Zara | yeah, there more I think about it, the more I'm inclined to think a user should just be able to toggle between deadlines view, targets view, and both, and sb shouldn't insist either way whether targets must be earlier or not. | 12:50 |
| Zara | s/there/the/ | 12:50 |
| * SotK is beginning to think we should get rid of targets entirely | 12:51 | |
| SotK | and have your table of due dates, each asserted by different people | 12:51 |
| SotK | these dates can optionally have a name | 12:52 |
| * SotK pauses to articulate his thoughts properly | 12:52 | |
| Zara | I thought it'd be easier to do that side of it per-board, because then there's no risk of six dates for the same thing with different spellings | 12:52 |
| Zara | otherwise when naming a due date, you may need to perform a search as the user types, to avoid duplicates, and yeahhhh. | 12:57 |
| Zara | afk while I walk over, brb | 12:58 |
| *** openstackgerrit has quit IRC | 13:02 | |
| *** openstackgerrit has joined #storyboard | 13:03 | |
| Zara | one thing I'm wondering is if stories should double as targets | 13:11 |
| Zara | they get used in a bunch of different ways, which muddies things | 13:11 |
| SotK | how d'you mean? | 13:11 |
| Zara | gimme a sec | 13:18 |
| Zara | +-------------------------------------+ | 13:18 |
| Zara | | Target name|Task ID(s) |Date | | 13:18 |
| Zara | | (story?) | | | | 13:18 |
| Zara | +-------------------------------------+ | 13:18 |
| Zara | |Make Demo |[22, 33,41] | 12.08.17 | | 13:18 |
| Zara | +-------------------------------------+ | 13:18 |
| Zara | |Fix network | [99, 105] | 03.03.09 | | 13:18 |
| Zara | +-------------------------------------+ | 13:18 |
| Zara | |Draft table | 4 | 06.01.15 | | 13:18 |
| Zara | | | | | | 13:18 |
| Zara | +-------------------------------------+ | 13:18 |
| Zara | | etc | | | | 13:18 |
| Zara | +------------+------------+-----------+ | 13:18 |
| Zara | b/c that way you'd link multiple tasks... so it'd make sense to then just have dates as metadata for *stories*. but it's whether the names of targets could overlap with the names of stories like that... | 13:19 |
| Zara | I see stories as targets anyway and think they just get misused when people mistake them for tasks, but ymmv. you can't have the same task in multiple stories, so I think that'd fail because you could easily have multiple targets a task worked toward | 13:20 |
| * SotK would be concerned about that encouraging people to create giant stories of vaguely related tasks too | 13:21 | |
| SotK | also, we can currently put stories in kanban lanes, so it would probably get confusing if they were also a representation of the due date | 13:21 |
| Zara | yup, the kanban lane argument wouldn't stop me if it were the only one (since we could change the lane behaviours) buuuut I think there are a bunch of good arguments against it | 13:22 |
| Zara | +------------------------------------------------+ | 13:23 |
| Zara | | Target name|Task ID(s) |Date |Private? | | 13:23 |
| Zara | | | | | | | 13:23 |
| Zara | +------------------------------------------------+ | 13:23 |
| Zara | |Make Demo |[22, 33,41] | 12.08.17 | YES | | 13:23 |
| Zara | +------------------------------------------------+ | 13:23 |
| Zara | |Fix network | [99, 105] | 03.03.09 | NO | | 13:23 |
| Zara | +------------------------------------------------+ | 13:23 |
| Zara | |Draft table | 4 | 06.01.15 | NO | | 13:23 |
| Zara | | | | | | | 13:23 |
| Zara | +------------------------------------------------+ | 13:23 |
| Zara | | etc | | | | | 13:23 |
| Zara | +------------+------------+-----------+----------+ | 13:23 |
| Zara | idk if we'd want less of a yes/no and more of a 'viewable to x', but that's getting into permissions, so that's where I run away. | 13:24 |
| Zara | hah, forgot 'created by'... | 13:25 |
| * SotK thinks we want 'viewable to x', else it won't work in shared private kanbans | 13:27 | |
| Zara | yeah... I'm wondering if it's wise to have the task IDs in the table | 13:27 |
| Zara | since they're already in the board | 13:27 |
| Zara | buuuut idk how else to relate them so :S | 13:28 |
| Zara | eh, I guess you can have multiple targets per board, ignore me | 13:28 |
| Zara | unless we're gonna start doing one board per target, it's relevant. | 13:29 |
| * SotK thinks it is useful to have targets usable in more than one board, since that is part of what "hard deadlines" were solving | 13:29 | |
| SotK | I also think having both targets and "hard deadlines" will be too confusing, and everyone will just use targets and talk to each other | 13:30 |
| SotK | or everyone will use hard deadlines and annoy each other | 13:30 |
| Zara | +------------------------------------------------+-----------+ | 13:32 |
| Zara | | Target name|Task ID(s) |Date +viewable | created by| | 13:32 |
| Zara | | | | |to | | | 13:32 |
| Zara | +------------------------------------------------------------+ | 13:32 |
| Zara | |Make Demo |[22, 33,41] | 12.08.17 | [SotK, Z]| bob | | 13:32 |
| Zara | +------------------------------------------------------------+ | 13:32 |
| Zara | |Fix network | [99, 105] | 03.03.09 | * | Aeris | | 13:32 |
| Zara | +------------------------------------------------------------+ | 13:32 |
| Zara | |Draft table | 4 | 06.01.15 | $creator | Z | | 13:32 |
| Zara | | | | | | | | 13:32 |
| Zara | +------------------------------------------------------------+ | 13:32 |
| Zara | | etc | | | $team | persia | | 13:32 |
| Zara | +------------+------------+-----------+----------+-----------+ | 13:32 |
| Zara | (idk if in practice $team would just be an array in the table, just including it as an example...) | 13:32 |
| SotK | getting there, but I think that they should also define a set of people who they are editable by too | 13:33 |
| SotK | "$oldPM created that due date, so now $newPM can't change it to account for the changes in the plan" | 13:33 |
| *** mrmartin has joined #storyboard | 13:35 | |
| Zara | +------------------------------------------------+-----------------------+ | 13:35 |
| Zara | | Target name|Task ID(s) |Date +viewable | created by|editable | | 13:35 |
| Zara | | | | |to | | by | | 13:35 |
| Zara | +------------------------------------------------------------------------+ | 13:35 |
| Zara | |Make Demo |[22, 33,41] | 12.08.17 | [SotK, Z]| bob | bob | | 13:35 |
| Zara | +------------------------------------------------------------------------+ | 13:35 |
| Zara | |Fix network | [99, 105] | 03.03.09 | * | Aeris |Aeris, Cait| | 13:35 |
| Zara | +------------------------------------------------------------------------+ | 13:35 |
| Zara | |Draft table | 4 | 06.01.15 | $creator | Z | * | | 13:35 |
| Zara | | | | | | | | | 13:36 |
| Zara | +------------------------------------------------------------------------+ | 13:36 |
| Zara | | etc | | | $team | persia | | | 13:36 |
| Zara | +------------+------------+-----------+----------+-----------+-----------+ | 13:36 |
| Zara | yeah, the fun thing is that you'd have to make editable_by role-based, in that situation | 13:36 |
| Zara | because otherwise $oldpm has to know ahead of time who $newpm would be | 13:36 |
| Zara | I'd imagine most of those would be 'selected names + admin', actually | 13:36 |
| SotK | when we get round to adding teams, that will provide role-based-ness I think | 13:37 |
| SotK | (a $project_name-managers team have edit permissions) | 13:38 |
| Zara | yeah, in the meantime we probably want it to be editable by admin by default. | 13:38 |
| * SotK wonders if created by is useful if we also have editable by | 13:39 | |
| Zara | well, editable_by could theoretically be * | 13:39 |
| Zara | so wouldn't work as a filter | 13:39 |
| * SotK offers http://paste.openstack.org/show/485850/ as the required changes to the various places in the database | 13:40 | |
| SotK | hmm, I don't know if editable_by being able to be * is all that useful | 13:41 |
| SotK | since that is just the same as having a single due date editable by all | 13:41 |
| SotK | ie. It is meaningless because no-one knows who thinks that date is the due-date | 13:41 |
| Zara | ah, actually, editing means created_by is ambiguous | 13:42 |
| Zara | because does it apply to making the target, or assigning a date to the target? | 13:42 |
| Zara | well, it'll apply to making it, but the interesting bit is assigning the date... | 13:42 |
| Zara | btw ## Due date in that example doesn't include task IDs? | 13:43 |
| SotK | heh yeah, I thought it through from the other direction (tasks are related to due dates bidirectionally, I just didn't make that obvious) | 13:44 |
| Zara | oh yeah, just saw at the end | 13:44 |
| SotK | (so we'd create a task_due_dates table which maps tasks to due dates) | 13:45 |
| Zara | if it's bidirectional then I thiiiink it looks fine to me | 13:46 |
| Zara | you know the db better anyway so your representation will be more grounded in reality xD | 13:46 |
| Zara | I just wanted an excuse to use asciiflow. | 13:47 |
| SotK | :D | 13:47 |
| SotK | I think we should provide the ability to "add" existing due dates to boards, and then those due dates are the ones used in the board | 13:48 |
| SotK | if that happens to mean a task in the board has more than one due date, we display the closest one and also some indication that there is more than one | 13:48 |
| * SotK wonders what persia thinks of all this | 13:50 | |
| * persia reads backscroll | 13:56 | |
| Zara | btw, searchable tags are in review https://review.openstack.org/#/c/274723/ | 14:05 |
| persia | I like the idea of one representation for targets and deadlines. I agree that there should be a way to handover a role between users, but have no immediate suggestions on how. | 14:06 |
| persia | Having deadlines/targets work both for kanban and non-kanban workflows is a very interesting concept. | 14:07 |
| * persia will think about this later | 14:07 | |
| * SotK notes that he doesn't really want to display due dates anywhere but kanbans and worklists | 14:09 | |
| paulsherwood | :) | 14:10 |
| persia | I do think a due date applies to a task, but the idea of applying to a story is very seductive. | 14:10 |
| * SotK is happy to apply them to stories too, especially since we already allow stories in boards and a way to show a due date for them there would probably be useful | 14:11 | |
| persia | For transfer: maybe an API change owner function (when POSTing the representation) that us not exposed in the UI? | 14:12 |
| SotK | persia: that is only accessible to an authed admin? | 14:13 |
| persia | Stories and/or tasks? That sounds mist flexible, to support various workflows. | 14:13 |
| persia | SotK: maybe admin+current_owner, so that cooperative handovers do not require admin action? | 14:14 |
| SotK | that makes sense | 14:14 |
| persia | e.g. If I go on holiday, I might want to hand admin of a role to someone else, etc. | 14:15 |
| * SotK wonders if admins should be able to see stuff that is set as "private" they don't have explicit permissions for | 14:21 | |
| Zara | hm. I'd incline toward 'yes', because I think they need to be able to delete anything, and it's helpful to see what it is... but it depends on how private the private data is likely to be, who's an admin, etc. | 14:23 |
| Zara | (I think the answer is to make sure they always have explicit permissions, actually() | 14:23 |
| Zara | (but we might be thinking of different things by 'explicit') | 14:24 |
| SotK | by explicit, I mean putting them in the "owners" permissions list for a board for example | 14:24 |
| SotK | I guess since the group of people who are admins are likely to be the same as the group of people with direct database access, the answer is likely to be yes | 14:25 |
| *** b3rnard0_away is now known as b3rnard0 | 14:25 | |
| Zara | if their status as admins is recorded differently to regular board owners, it should be relatively simple to hide them later if it's annoying. | 14:27 |
| persia | +1 on expecting admins to have DB access | 14:28 |
| *** alexismonville has quit IRC | 14:29 | |
| SotK | then in that case I think its safe to give them assumed access to everything | 14:29 |
| Zara | meeting in 30ish btw | 14:31 |
| SotK | oh, so it is | 14:32 |
| * persia will unfortunately miss the meeting today | 14:32 | |
| *** alexismonville has joined #storyboard | 14:42 | |
| SotK | right, lets clarify, is it likely to be useful for a milestone to be "owned" (and therefore editable) by more than one person? | 14:44 |
| Zara | yes, in case one dies | 14:44 |
| SotK | right, so we don't need to record the "creator" of it, since that is a worse representation than recording the set of people who can edit it | 14:46 |
| SotK | s/milestone/due date/ | 14:47 |
| paulsherwood | not true... | 14:49 |
| SotK | paulsherwood: why not? | 14:50 |
| paulsherwood | i've had real-life reasons to show who created a milestone, when it was originally set to, and what it included... | 14:50 |
| paulsherwood | as well as fully audit all changes to all of those data points | 14:50 |
| paulsherwood | (to prove that what was originally planned has changed over time) | 14:50 |
| SotK | ah, that makes sense | 14:51 |
| paulsherwood | full audit of project history is a necessity in many industries | 14:51 |
| persia | Audit is important, indeed. History reduces arguments. | 14:57 |
| * persia runs out of time | 14:57 | |
| SotK | hm, I wonder if it's better to store the original creator as part of tracking the changes to the due date rather than as part of the due date itself then | 14:59 |
| SotK | meeting time! | 15:00 |
| Zara | so we'll need created_at | 15:02 |
| Zara | for milestones | 15:02 |
| * SotK thinks we'll need to do something similar to the timeline events implementation to track history | 15:03 | |
| Zara | yup | 15:04 |
| *** mrmartin has quit IRC | 15:40 | |
| * SotK goes to update the story with the new plan | 16:26 | |
| Zara | :) | 16:32 |
| SotK | do we care about keeping the old story description? | 16:39 |
| Zara | I think it would be wise | 16:47 |
| *** NikitaKonovalov has quit IRC | 16:47 | |
| * SotK too | 16:48 | |
| Zara | (though old versions should be displayed in truncated form until clicked) | 16:48 |
| *** NikitaKonovalov has joined #storyboard | 16:49 | |
| * SotK meant in this particular case, though it has made me thing that we could probably do with a full history for the descriptions | 16:51 | |
| Zara | okay, just manually changed every file affected by my suspect patch, am absolutely certain it's that one | 16:53 |
| Zara | NikitaKonovalov: You will be delighted to hear we have found a bug that was introduced last March! https://review.openstack.org/#/c/155751/ stops timeline events displaying properly. =D | 16:55 |
| Zara | (story: https://storyboard.openstack.org/#!/story/2000478 -- if you have any quick tips on what might be happening, it'd be appreciated, though I realise that patch was nearly a year ago...) | 16:58 |
| Zara | 'night, all! | 17:27 |
| *** alexismonville has quit IRC | 17:27 | |
| persia | I was chatting with someone about Storyboard recently, and they suggested that it would be good to never delete anything. When things change, keep the old one (and an audit log). When things are "deleted" by admin, actually only archive them, so they do not appear by default, but can be accessed in case of confusion or dispute. | 17:28 |
| *** alexismonville has joined #storyboard | 17:28 | |
| persia | I'm not sure that informs any of the above discussion, but just to point out that some people want that sort of thing. | 17:28 |
| paulsherwood | in a previous implementation we discussed a CoW database for kanbans, even to the point of wanting to keep all data (versioned) in git | 17:30 |
| paulsherwood | s/database/approach/ | 17:30 |
| *** mrmartin has joined #storyboard | 17:31 | |
| persia | Storing databases in git is tricky (I'm seeing lots of corner cases in another project I'm watching), but yeah, the key is that for systems that express mangement desire, it is good to have an audit trail so that people can confirm the understanding they had at the time things happened when reviewing the history of something. | 17:32 |
| persia | Note that such "management desire" applies even to teams that are collectively self-managed, or otherwise appear to have no "management" layer. | 17:33 |
| *** alexismonville has quit IRC | 17:43 | |
| *** jtomasek__ has quit IRC | 17:59 | |
| *** mrmartin has quit IRC | 18:08 | |
| *** zara2 has joined #storyboard | 18:10 | |
| zara2 | I left early because I had a headache, but saw discussion as I was going-- I imagine best option would be to make something like the email worker, eg: a wiki-worker, that would listen for new timeline events and copy the data over somewhere to be committed... like a wiki. ;) | 18:12 |
| zara2 | story descriptions are markdown anyway | 18:12 |
| zara2 | and with that, adieu! | 18:12 |
| *** zara2 has quit IRC | 18:14 | |
| persia | While I like that idea, because it provides a useful archive, I'd prefer a model where it didn't require two writes, and there wasn't any possibility of races: the underlying data store itself should be one that supports archival use. That said, I don't think this is an important current feature :) | 18:22 |
| *** mrmartin has joined #storyboard | 18:57 | |
| *** mrmartin has quit IRC | 19:08 | |
| * SotK ponders how to "keep the old one" and not create a nightmare | 19:53 | |
| persia | Recording the event as e.g. "foo changed bar from baz to quux" rather than "foo changed bar" is usually the easiest. | 21:05 |
| SotK | I see, so you don't want to keep the full database record from each change? | 22:06 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!
