| *** mrmartin has joined #storyboard | 03:22 | |
| *** persia has quit IRC | 03:30 | |
| *** persia has joined #storyboard | 03:33 | |
| *** jtomasek has quit IRC | 06:09 | |
| *** openstackgerrit has quit IRC | 07:33 | |
| *** openstackgerrit has joined #storyboard | 07:33 | |
| *** fay has joined #storyboard | 07:33 | |
| *** fay is now known as Guest96228 | 07:34 | |
| *** ctgriffiths has joined #storyboard | 08:12 | |
| ctgriffiths | Hi, does anyone know if there is a publicly avalible storyboard docker container? Google doesn't seem to think so | 08:15 |
|---|---|---|
| *** jtomasek has joined #storyboard | 08:53 | |
| Zara | hi ctgriffiths! not as far as I know. at the moment, we have an ansible role and puppet scripts. | 09:05 |
| Zara | so I think that's the closest thing... which isn't that close. | 09:06 |
| ctgriffiths | cool just wanted to check before I had a go, thanks | 09:06 |
| Zara | np :) there's always a chance someone did something and we don't know about it, but it's safe to assume that would be > a year old. are you interested in making one? | 09:08 |
| ctgriffiths | yep I want one to experiment with for now, I'll share it with you when I get it going | 09:11 |
| Zara | cool! sounds interesting, thanks. :) | 09:17 |
| *** Guest96228 is now known as faybrocklebank | 09:18 | |
| Zara | (if it's any help, along with the developer install docs, there's some extra stuff here: https://storyboard.openstack.org/#!/story/2000684 (that should be a patch to the docs soon), and the ansible role is over here: https://galaxy.ansible.com/detail#/role/6187 . puppet-storyboard lives here: https://github.com/openstack-infra/puppet-storyboard ) | 09:28 |
| *** alexismonville has joined #storyboard | 11:25 | |
| *** alexismonville has quit IRC | 14:23 | |
| *** alexismonville has joined #storyboard | 14:27 | |
| *** alexismonville has quit IRC | 14:32 | |
| Zara | niiiice, tasks definitely change status correctly from 'todo' to 'review' when changes are submitted | 15:20 |
| pedroalvarez | oh! | 15:20 |
| pedroalvarez | must | 15:21 |
| pedroalvarez | install | 15:21 |
| pedroalvarez | now | 15:21 |
| pedroalvarez | Zara: can you point me to that story to have a look? | 15:21 |
| Zara | as do comments | 15:21 |
| Zara | https://storyboard-dev.openstack.org/#!/story/4, https://review-dev.openstack.org/#/c/5456/1 | 15:22 |
| Zara | just spent the last little while setting up an account on review-dev so I could have a play | 15:22 |
| pedroalvarez | and.. if you merge 5456... | 15:23 |
| pedroalvarez | ? | 15:23 |
| pedroalvarez | maybe you can't though | 15:24 |
| Zara | I can't check because I don't have admin privileges, but it did work in zaro's tests earlier. but we can probably poke someone to check jic. (it's not set up for review.o.o or storyboard.o.o yet) | 15:24 |
| pedroalvarez | I will setup this for my instance | 15:24 |
| pedroalvarez | one of these nights :) | 15:25 |
| Zara | \o/ | 15:25 |
| Zara | abandoning a change nicely sets it back to todo :) | 15:36 |
| persia | Where is the right place to submit something to remove the part that cross-posts comments? | 15:41 |
| * persia firmly believes in the separation of discussion over requirement and implementation | 15:41 | |
| Zara | it shouldn't cross post the comment content, just the link | 15:41 |
| Zara | though I htink it's noisy and I'd like to be able to filter it | 15:41 |
| persia | I might not be opposed to it if it could be filtered, ideally not shown by defailt. | 15:42 |
| persia | I'd also like it to assign the submitter, but I suppose that is somewhat difficult. | 15:43 |
| Zara | (also: if you upload a change so it's in review, then someone else duplicates it without realising and abandons the patch, the plugin will just pick up on the latest change. so there, we should possibly let people know that if abandoning because something's a duplicate, they shouldn't include a task id in the commit message) | 15:43 |
| persia | (because of identity lookups, etc.) | 15:43 |
| Zara | yeah, that was planned as a future thing | 15:43 |
| Zara | for that reason | 15:43 |
| Zara | you could probably do it lazily and get a good match most of the time | 15:43 |
| persia | Yeah, but I don't think lack of assignment is a blocker to go from review-dev/storyboard-dev to review/storyboard | 15:44 |
| Zara | yup | 15:44 |
| Zara | anyway, the actual plugin is over at: https://gerrit.googlesource.com/plugins/its-storyboard/ | 15:44 |
| persia | Whereas I do think the current comment situation is problematic. LP used to always conflate, and we're still training some users to separate discussion of the issue (in LP today) from discussion of the patch (in gerrit today). | 15:44 |
| * SotK thinks it is needlessly noisy to cross-post even comment links | 15:44 | |
| Zara | filtering on comment author could be implemented hackily in the ui layer if we *really* wanted, though that approach would probably make purists cry | 15:45 |
| Zara | and, yeah, people already get emails from gerrit. | 15:45 |
| persia | The people who need to be involved in the implementation discussion should be following the gerrit discussion, perhaps via email, perhaps another way. This is true even for changes not associated with a story. | 15:47 |
| persia | Conversely, people who are excitingly watching story status by the millions and posting about it in their blogs do not need to claim that someone asking for pep8-correctness is "blocking the change", or blame their employer for being anti-feature, both of which have happened in the past when the conversations were linked. | 15:48 |
| * persia finds StoryboardClient.java interesting, and wonders if there is a more general use for that class outside the ITS plugin | 15:48 | |
| Zara | at the moment all those comments do is let people know there *has* been an update; they force people to have the actual discussion elsewhere. but I still think it's noisy. posting a story ID is optional, though | 15:49 |
| persia | One can post a task: and no story: and the task will still be updated? | 15:50 |
| * persia has discovered that this comment thing is entirely in the configuration, so not something that needs a code-change to alter. | 15:50 | |
| Zara | oh, hang on, the comment link still goes up on the story even if you only have the task id. | 15:51 |
| pedroalvarez | stop cross-posting comments is just a matter of gerrit configuration | 15:51 |
| Zara | another somewhat confusing thing is that the topic goes after the colon, so it can look like hte body of a comment when it isn't | 15:52 |
| Zara | anyway, this is the location of the patch for putting it in review.o.o: https://review.openstack.org/#/c/347486/ , so that might be a good place for feedback | 15:53 |
| Zara | since we've gone the dev route first to make it possible to test | 15:54 |
| openstackgerrit | Adam Coldrick proposed openstack-infra/storyboard: Position archived items at the bottom of worklists https://review.openstack.org/351265 | 15:57 |
| openstackgerrit | Adam Coldrick proposed openstack-infra/storyboard-webclient: Complex priorities UI in stories https://review.openstack.org/312666 | 15:57 |
| Zara | ahahahaha | 15:58 |
| Zara | does that mean multiple things can have the same list_position? | 15:58 |
| Zara | *in a worklist | 15:58 |
| Zara | I'd assumed it was unique | 15:58 |
| Zara | and now I think we need task IDs in card modals | 16:06 |
| persia | There's something impressive about there being 39000 changes submitting whilst complex priorities has been under review. | 16:06 |
| persia | Zara: Why? I'd think anyone actually implementing anything should be looking at the story view, not just the worklist view. | 16:07 |
| Zara | I was thinking of a case where you go to check an id for a patch on the board/worklist you're currently using to list tasks, when it's time to submit, rather than when you first decide to do something | 16:08 |
| Zara | (plus it just makes demoing automatic boards easier, haha) | 16:09 |
| persia | I think it's good practice to check the story then as well. Humans have a tendency to rethink things, resulting in all sorts of changes in meaning if the context is not refreshed. | 16:11 |
| * persia has, more than once, needed to adjust a patch after looking up the bugid in LP and seeing the description | 16:11 | |
| Zara | the task modal displays the story description by default | 16:13 |
| persia | Is there a potential for feature-creep when solving parts of multiple tasks? | 16:15 |
| * persia is getting close to agreeing that the task ID should be shown, but wants to plumb as many counterarguments as possible | 16:16 | |
| persia | I think I'm fine with not showing the history, as I expect people will ignore that when checking IDs anyway. | 16:16 |
| Zara | if anything I think it stops people claiming that a task was meant to fix everything in a story, as people can say 'no, it's this task with this ID' | 16:17 |
| persia | That's an important point: one of the things about LP is that every task was supposed to completely address the bug for a specific project (or at least a specific branch), so that distinction wasn't available. I agree it is useful. | 16:18 |
| Zara | :D | 16:25 |
| Zara | okay, turns out the commenting was only enabled on dev for testing | 16:25 |
| Zara | zaro has sent a patch to turn it off on dev so that the plugin does the same things that it would do in prodcution: https://review.openstack.org/#/c/351273/ | 16:25 |
| zaro | persia: RE:StoryboardClient.java, i was thinking maybe creating a seperate project for storyboard java bindings, but maybe using httpOk or something. | 16:26 |
| persia | zaro: a separate repo definitely makes sense. I don't know which project (I am not sure it matters except for workflow). I do not have an opinion about the right base library. | 16:30 |
| zaro | Zara: what should it be called? 'java-storyboardclient' to keep with 'python-storyboardclient' theme? | 16:33 |
| Zara | that sounds fine to me! :) might be worth checking in infra in case there's a standard I don't know about, but I'm fine with it | 16:33 |
| Zara | (I'd like *some way of linking a patch when it's sent, but since comments are controversial, I'm not sure what would work yet. appending to task notes is an option, but it means the url gets pasted repeatedly with further changes.) | 16:35 |
| Zara | (so for now I'm just thinking about it) | 16:35 |
| Zara | I've made an automatic board on storyboard-dev for those who want hours of fun: https://storyboard-dev.openstack.org/#!/board/8 | 16:37 |
| persia | Am I reading 351273 correctly if I think it has the task status stanzas but not the comment stanza from the -dev configuration? | 16:39 |
| Zara | yeah, that updates the config for review-dev so it just updates task status, which is what it's set to do in review.o.o | 16:40 |
| Zara | before, the two were different, which I didn't realise | 16:40 |
| Zara | or possibly had at some version of one of the patches, but not the latest | 16:41 |
| zaro | Zara: quite possible in one of the older patches. i messed up on one, or maybe more of the rebases there :) | 16:43 |
| zaro | Zara: if your thinking of ways to squeeze more info into task the task row, it might indicate that tasks needs it's own page of info? | 16:43 |
| zaro | like i think it would be better to have a field for gerrit change id on that row and notes to appear on a more detailed info page for a task? | 16:44 |
| Zara | hm, maybe we could make the task_id link to a gerrit change where there is one. not sure how to do that | 16:45 |
| zaro | Zara: also, review-dev is kina in limbo right now. puppet wasn't running on it so the its-storyboard changes have not taken effect on it yet. fungi says he just re-enabled so it should take affect in about 30 mins | 16:46 |
| zaro | Zara: imo that would be confusing | 16:46 |
| persia | So, for notification that a change is submitted: I think most story subscribers would recognise that something is happening when one of the task statuses change. | 16:48 |
| persia | Those who are more familiar with the infrastructure will know to visit the associated change by looking at the task notes. | 16:48 |
| Zara | it's more for posterity. looking back at old stories, it's a pain when you see 'in review' and there's no change linked and you're left to hunt down the patch. at the moment, you have to manually link the change in the notes. | 16:49 |
| Zara | it's the reason I made task notes, though they might have other uses. | 16:49 |
| persia | Yes, the current situation is less than ideal. | 16:49 |
| persia | Help me understand how this situation might continue in a world where folk are using SB and gerrit with the its-storyboard plugin. | 16:50 |
| zaro | IMO, notes would be a bad spot for it. for one it's not obvious and secondly it take two clicks, one to open notes and another to find the gerrit url in the note | 16:50 |
| persia | I would expect the task notes to be auto-populated for anything once the plugin is enabled in production, so it's only legacy stories that can be frustrating. | 16:50 |
| Zara | at the moment the plugin just updates task-statuses. | 16:51 |
| persia | zaro: Yes, but this is only for story subscribers who are not following the project in gerrit. Is it not safe to assume that folk who are working on something are following the project in gerrit? | 16:51 |
| persia | Zara: Ah: yes, we should probably be posting the URL as a task note in the plugin. | 16:51 |
| Zara | zaro: fwiw I'd rather be able to get to changes quickly, I'd just rather start by linking them somewhere we already have than making a new home for them | 16:52 |
| zaro | as a developer one of my most important use case is to be able to associate and navigate from SB to gerrit and back. | 16:52 |
| zaro | url in notes would not be great for that | 16:53 |
| *** alexismonville has joined #storyboard | 16:53 | |
| persia | zaro: Yes, but a non-developer (bug reporter, product manager, etc.) SB user is likely to be very distracted by the comment noise. | 16:53 |
| zaro | i'm not suggesting to put it in comments either. | 16:53 |
| zaro | i think a seperate html field in the task row would work though | 16:54 |
| Zara | then if/when people get confused or frustrated, we can make it easier to get to them, I'd just rather not have linking to changes in gerrit blocked by us implementing something in the ui | 16:54 |
| Zara | because some changes will be lost in the meantime | 16:54 |
| persia | "notes" is a generic expression of "some HTML for the reference link". I'd prefer not to have two, if we can avoid that. | 16:54 |
| persia | Maybe we need to expose notes more (and maybe we can do that more easily once 312666 lands) | 16:55 |
| *** jtomasek has quit IRC | 16:55 | |
| Zara | task notes are currently just a whiteboard field. | 16:55 |
| Zara | so to separate 'link' and 'description', I think we'd need to adjust the db, then pick a layout that works and then set it up. | 16:56 |
| zaro | ++ | 16:56 |
| persia | Ah, yes, if "task notes" is intended to have task descriptions or similar, I agree entirely that the remote link should be extracted. | 16:57 |
| persia | I further believe that the remote link should be presented as active in the space that will be freed up by removal of priority in 312666 | 16:57 |
| Zara | yeah, I made it a whiteboard so it could be versatile for cases when people wanted to say 'this is blocked because of blah', but the thing that drove me to make it was the need to link to patches | 16:58 |
| persia | And now we discover it has become too versatile :) Personally, I'm not convinced that task descriptions, etc. shouldn't be put in the story description directly. | 16:59 |
| persia | Similar with blockers, as one presumably wants to know that when looking at the overview. | 16:59 |
| Zara | I don't think it's too versatile; the task-descriptions help people. it just isn't the best way to link to patches-- which we knew. :P | 17:00 |
| Zara | but yeah, I'd really rather not block linking to things in gerrit | 17:01 |
| Zara | even if they start off by being linked in a less-than-perfect way | 17:01 |
| Zara | I don't want to say 'linking to gerrit patches depends on a storyboard database migration' | 17:02 |
| Zara | that's just going to mean tasks without links to their patches ;_; | 17:02 |
| persia | I'd rather assume semantics that "task notes" are supposed to only contain the URL, and change the UI to make the link active by default (unless editing). | 17:03 |
| Zara | (also, 'blockers' was just an example there; it was meant as any implementation-specific info for that task. to stop people conflating goals with implementations) | 17:03 |
| persia | That way we can say they start of being linked in a perfect way. | 17:03 |
| persia | Oh, hrm. I like separation of implementation concerns, but I do believe they belong in gerrit. | 17:03 |
| persia | Maybe the social model is to upload a nearly-null WIP change for the impementation discussion? If complex, maybe this is in a spec repo? | 17:04 |
| zaro | persia: i don't understand your suggestion | 17:05 |
| persia | zaro: Apologies: it's expressed in several places confusingly. I'll try to summarise. | 17:05 |
| persia | 1) We assert that "task notes" should only contain a link to some relevant implementation source | 17:05 |
| persia | 2) When the "priority" field goes away, we display the link in "task notes" on the story detail page by default. | 17:06 |
| Zara | I don't want to get rid of the whiteboard field to make notes on tasks. I find it useful. | 17:07 |
| persia | 3) If there are complex implementation-specific issues that need to be noted, this be done in a WIP patch in gerrit against the project code repo or an initial spec in the project spec repo. | 17:07 |
| persia | /end | 17:07 |
| persia | Zara: If you are using it for implementation-specific notes, why should these not be in the patch manager (gerrit for OpenStack)? | 17:08 |
| Zara | because sometimes nobody has uploaded a patch. they can be for irc discussion of a suggested implementation, or for linking an error log that is blocking a task required before a patch can go up | 17:09 |
| Zara | and sometimes the title is too small a field to explain the thought behind a task, or you want to say 'I changed the title of this task because x' | 17:10 |
| zaro | persia: i'm not sure i like social enforcement of an open text field. i don't think that's gonna work too well | 17:10 |
| zaro | also i think zara makes a good point about not being able to use notes besides putting a link in there | 17:11 |
| zaro | if i had my choice i would just add a link in the story comment on an initial push of a gerrit patch. | 17:12 |
| zaro | as an interim solution, until task link to gerrit change is available | 17:12 |
| persia | So, if the task name changes, I'd rather see that in a comment (at the time of the task name change). Similarly, if the task description isn't long enough to be clear, the Story description should contain more information regarding the task. | 17:13 |
| persia | I am very strongly opposed to adding the link in a comment, because it loses the association with the task, and reconflates the discussion of the requirements with the discussion of the implementation. | 17:14 |
| persia | If there needs to be discussion prior to a specific implementation, this should happen in the comments, where folk can see it. | 17:15 |
| persia | If there is discussion related to a specific implementation that might address the story, I don't think having that happen in gerrit gets in the way. | 17:15 |
| persia | So I'm really not seeing any value to task-specific details aside from links. | 17:15 |
| persia | But I'd be happy to go thorugh an exhaustive list of use-cases: maybe there is one that doesn't make me immediately feel that the information is being placed in the wrong place, being made less accessible to the folk who need it, or being hidden. | 17:16 |
| Zara | well, we disagree on the usefulness of a whiteboard. for a story, 'allow users to do blah', on a task 'make buttons consistent', I'd much rather a note saying 'button foo is smaller than the others', than detailed notes about the size of the buttons in the story description; there I'm more interested in what problem people have and a suggested solution. | 17:17 |
| Zara | I don't want to scroll through reams of information to get an overview. | 17:17 |
| persia | I agree with that narrative, but I'd like to understand how one would get there, because it still feels like we're doing something wrong to reach that state. | 17:18 |
| Zara | https://storyboard.openstack.org/#!/story/2000535 is an example story of how I use them | 17:18 |
| persia | So, if in that situation, yes, we need this, but can we find a way to never have started from there? | 17:18 |
| persia | Critiquing that story: I think 2892 should have a clearer title (or the task should have been solved by the initial patch, and a new task created). | 17:20 |
| persia | I believe 2893 belongs in a different story: that's an actual issue that has nothing to do with Docs. | 17:20 |
| persia | 2981 has a bunch of notes that suggest something was tried, which I think should have been uploaded as a WIP | 17:21 |
| zaro | persia: hmm, task status transitions already gets added to comments. so i'm just suggesting that when task goes from 'todo' to 'review' there's an associated link to gerrit with that comment | 17:21 |
| persia | The note in 2982 doesn't seem to add info | 17:21 |
| Zara | it lets someone know why it hasn't happened. | 17:21 |
| persia | 2983 reports problems with an external tool that should belong in that bug tracker | 17:21 |
| persia | 2984 has no notes. | 17:22 |
| persia | zaro: The status transition is a timeline event, but not technically a "comment", so can be filtered away. I'd be delighted to show the URL in those, but think that ought be implemented by putting it in the right field, and then having the UI display it, rather than using a "comment" | 17:23 |
| persia | Zara: For clarity, which "it"? | 17:23 |
| Zara | (I'm also not particularly interested in arguing whether or not I fill out stories the 'right' way or getting into why I put notes there rather than wrote a bash script and uploaded it as a wip or somesuch. I'm probably not the only user who likes to journal that way, and it's not obvious that there's anything wrong with communicating with other users that way.) | 17:24 |
| zaro | persia: yeah i agree with you, my suggestion is just for the interim. | 17:24 |
| Zara | personally I'd rather have people document things so I know if it's a case of 'I didn't get round to this' or 'this wasn't the best way of doing it' or 'I got an error when I tried this and the person to ask was on holiday, here's a name' etc, and I'd rather those be associated with tasks. | 17:26 |
| persia | Zara: I'm not convinced I'm correct in my opinions, but I've very interested in discussing the 'right' way to do these, because I believe that how we do them has social implications that affect all consuming projects. I'm not interested in saying "you did it wrong: bad you", but more understanding "this is what was done: is that the best way we could do it in the future?" | 17:26 |
| persia | zaro: Perhaps: I don't want to block on an SB DB change: I just really think comments are not ideal for lots of reasons. I don't think I have a preference for which is worse: blocking vs. using comments. | 17:27 |
| zaro | well i think we have options, so maybe mull them in your heads for discussion at next sb or infra meeting? | 17:29 |
| persia | Zara: Hrm. Those are more complicated. Assignment/Deassignment/Scheduling changes are not interesting from a requirements history perspective, but they are essential from a "why is this in this state and how do I move it forward" perspective. I don't know a better place than task notes to indicate that. | 17:29 |
| Zara | persia: I think we disagree in how much we think the tool can influence the users. 'people will document things in story descriptions or comments if they don't have a whiteboard field for tasks', vs 'people won't document things'. based on storyboard as it was when I started, I think they won't document, or will maybe use an etherpad and not link it :P | 17:29 |
| persia | I would think "This wasn't the best way to do it" is probably best as an abandoned changeset, so others can see specifically what you mean. | 17:29 |
| persia | Similarly, "This almost worked, but it needs attention from foo" seems to me to be best as a WIP patch with foo as an invited reviewer (for when they return). | 17:30 |
| Zara | it can depend on whether people decide that just after a discussion on irc (in that case the link would be for logs), whether the task is code, and so on | 17:30 |
| persia | Zara: Ah, so cases where there wasn't actually anything really tried, or any code context that could be WIP/abandoned? | 17:31 |
| Zara | eg: there's no wip patch for one of the ops docs things because I got stuck at the 'try these commands manually' step, so never reached the 'write a script to automate this' step | 17:32 |
| persia | Hrm. Yes. I don't like it, but you're right that most of this sort of thing doesn't belong in either description or comments, and people won't put it anywhere if there isn't enough to mean something in that other place. | 17:34 |
| persia | I still think that some of the entries in story 2000535 would be better done as described above, but the further discussion causes me to beleive there are cases that are not so easily dismissed. | 17:35 |
| Zara | yeah. even if it's in irc logs, it's harder to find unless you're looking. | 17:35 |
| persia | So I guess we need another field :( | 17:35 |
| Zara | then the next fun part is: multiple links, WHAT DO YOU DO? | 17:36 |
| persia | Stack them ,making the row wider. | 17:36 |
| persia | Generally speaking, there should only be one or two, most of the time. | 17:37 |
| persia | If it is more than that, the users should probably separate things into more tasks. | 17:37 |
| Zara | heh. :) anyway, it is now 6:40pm and I should go have dinner or something exciting. | 17:37 |
| persia | Enjoy your meal :) Thanks for accepting the discussion and convincing me I was wrong despite not wanting to discuss it. | 17:38 |
| Zara | hahaha | 17:39 |
| Zara | I can never resist an argument, it's terrible | 17:39 |
| persia | Even an uninteresting one :) | 17:39 |
| Zara | task notes are like the one thing I've implemented from the db to the ui, fuelled by frustration, so they hold a special place in my heart~ | 17:40 |
| zaro | Zara: i already see a bug with the puppeting of its-storyboard settings on review-dev so maybe you'll want to hold off testing until i fix it. | 17:45 |
| *** alexismonville has quit IRC | 18:17 | |
| zaro | Zara: ok, should all be fixed now. patches are labeled with 'it-storyboard' topic | 23:23 |
| *** mrmartin has quit IRC | 23:34 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!