| *** alexismonville has joined #storyboard | 01:00 | |
| *** alexismonville has quit IRC | 02:04 | |
| *** matthewbodkin has joined #storyboard | 08:00 | |
| *** openstackgerrit has quit IRC | 08:03 | |
| *** openstackgerrit has joined #storyboard | 08:04 | |
| *** jtomasek has joined #storyboard | 08:48 | |
| Zara | yay, wip js draft has built, so we can discuss the task layout and things with an actual example of the wip | 09:41 |
|---|---|---|
| Zara | http://docs-draft.openstack.org/06/357306/1/check/gate-storyboard-webclient-js-draft/673c9df//dist/#!/story/34 | 09:41 |
| Zara | is on a story with lots of tasks | 09:41 |
| persia | For comparison, here is a bug with a vast number of tasks and milestones on launchpad: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/706999 | 09:44 |
| openstack | Launchpad bug 706999 in linux (Ubuntu Raring) "CVE-2010-3448" [Low,Fix released] | 09:44 |
| Zara | ah, that seems to group by project and then by status | 09:45 |
| persia | By project, then by branch/release, then by status. | 09:45 |
| *** jtomasek has quit IRC | 09:46 | |
| persia | (well, the "group by status" is mostly a side-effect of the per-project/per-branch stuff, but ...) | 09:46 |
| Zara | though I think there there's no task-story separation, so that has the task title where we have the story title, and task notes as story description | 09:46 |
| *** jtomasek has joined #storyboard | 09:47 | |
| SotK | grr, the js-draft isn't working for me | 09:47 |
| Zara | :( | 09:47 |
| SotK | I know what it looks like anyway though | 09:47 |
| persia | Hrm. When I try to load that docs-draft URL (or just navigate to docs-draft from the patch in gerrit), I get a spinner that seems to last a very long time (minutes) | 09:47 |
| Zara | phew | 09:47 |
| Zara | maybe try refreshing? | 09:47 |
| Zara | huh, it's not loading now | 09:48 |
| persia | refreshing doesn't help. | 09:48 |
| SotK | persia: try https://... instead | 09:48 |
| Zara | (oh, there we go, took a while) | 09:48 |
| persia | SotK: Works: thanks | 09:48 |
| persia | Well, at least the page loads, rather. Seems that anonymous view is broken in that docs-draft, or all the stories are private. | 09:49 |
| Zara | it works for me | 09:49 |
| Zara | is it a caching thing? | 09:50 |
| persia | Not a caching thing: this isn't my hyper-caching browser, but one that I normally use with storyboard (and works with storyboard, normally) | 09:50 |
| SotK | persia: can you log in? | 09:51 |
| persia | SotK: Yes, but I end up logged out again if I navigate a bit, or refresh. | 09:51 |
| persia | Anyway, doesn't matter much. To me, the key thing is to figure out what information we need to represent, after which we can discuss how to display it. | 09:51 |
| persia | It may be that we need to be tricky about it, like is done in 312666 for "in which worklists does this task appear?" | 09:52 |
| * SotK will be happy to have that discussion in a couple of minutes | 09:53 | |
| Zara | here are my thoughts on where things that are currently there lie on the continuum of 'needs to be visible immediately' to 'visibility can be deferred' | 09:58 |
| Zara | http://paste.openstack.org/show/561228/ | 09:58 |
| Zara | so stuff in the middle is stuff that makes it annoying/clunky not to have, but which doesn't render it unusable without further clicks. | 09:58 |
| persia | Zara: To confirm, does "delete task" mean the same as "remove from story"? | 09:59 |
| Zara | yeah | 09:59 |
| Zara | as far as I know they don't stick around to be reassociated with any stories | 10:00 |
| * SotK will reply with thoughts in a second | 10:00 | |
| persia | I believe "that the task is assigned"[binary] is only lightly interesting, whereas "task assignee"[user] is more interesting. | 10:00 |
| persia | I'm happy with "delete" and "remove" meaning the same thing: I'm just reviewing your thoughts against the list from yesterday. | 10:00 |
| Zara | cool | 10:00 |
| persia | Where do you see "Milestone" and "Branch" in your view? | 10:01 |
| Zara | my thought was that you're first looking to see if anyone has the task covered, then, if they do, you want to know who it is | 10:01 |
| Zara | I've just included items that are currently there | 10:01 |
| Zara | imo the things that aren't are not essential | 10:02 |
| persia | I don't trust a boolean, mostly because I've seen "Assignee" misused so many ways in the past. | 10:02 |
| Zara | as otherwise someone would have said something by now. | 10:02 |
| persia | Folk have said things :) | 10:02 |
| persia | But yeah, nobody has been screaming. | 10:02 |
| Zara | yeah, compared to, say, gerrit link, which has come up repeatedly | 10:02 |
| persia | I think branch support is *very* important, for example, but less important than complex priorities, or review links. | 10:03 |
| persia | (as I don't understand how someone could track progress towards addressing a security issue without branch support) | 10:03 |
| Zara | If we end up organising the view by project, it could possibly also be organised by branch | 10:03 |
| Zara | then by status. I think that would be my preference, anyway | 10:04 |
| persia | Where it matters, and hidden where it doesn't matter (this is what LP does: there is a navigation button on a task that, if activated, allows one to specify branches) | 10:04 |
| persia | For example, something not currently done, with no clear timeframe to be done, and no promise to be backported to some earlier release, probably has no reason to have a branch. | 10:05 |
| SotK | ok, I would say status is something which needs to be visible at a glance | 10:06 |
| SotK | also the id | 10:06 |
| Zara | I agree on status (wondered about that) but not on id. | 10:06 |
| Zara | I think it's much nicer to have it visible at a glance, though | 10:06 |
| SotK | since hiding the ID makes utilising the gerrit integration properly that bit more difficult | 10:06 |
| SotK | to the point where I expect people will just use the story id and miss out on most of the benefits | 10:07 |
| Zara | right, I was starting from absolutely essential vs 'really nice to have', but I agree that will happen | 10:07 |
| persia | If the ID isn't incredibly obvious, people won't put it in commit messages. | 10:07 |
| persia | And if that doesn't happen, the status will usually be incorrect, unless there is an army of volunteers doing it manually (but probably even then) | 10:07 |
| SotK | indeed, whihc is why that is in the "absolutely essential" category for me | 10:08 |
| *** jtomasek has quit IRC | 10:08 | |
| SotK | other than id, title, project, and status, I don't think the other things are absolutely crucial | 10:08 |
| persia | SO, do we have consensus that MUST includes title, project, ID, status? | 10:08 |
| Zara | (storyboard was usable before we displayed task ids, so I disagree on that, I'm still not in favour of removing it or anything, so it's fine if we disagree there) | 10:08 |
| Zara | that list is short enough to work for me | 10:08 |
| persia | Well, for some value of usable. I don't know any users who were not eagerly anticipating active development, but if you're happy with that list, let's use that. | 10:09 |
| SotK | it was, but we have since grown functionality since then | 10:09 |
| * Zara updates the box to http://paste.openstack.org/show/561231/ | 10:09 | |
| persia | My SHOULD list is then link, assignee, add-to-worklist, delete | 10:10 |
| persia | COULD then being notes, branch | 10:10 |
| * SotK would move delete to could | 10:10 | |
| persia | (and REMOVE being Milestone, but we can debate that later: I need to read the code more to argue it well) | 10:10 |
| SotK | and perhaps add-to-worklist to could too | 10:11 |
| Zara | my own is 'link, assignee, more...' | 10:11 |
| Zara | and I'd put notes, add to worklist, and delete in the 'more' | 10:11 |
| SotK | yeah, that matches my gut instinct | 10:11 |
| Zara | it's a shame to lose 'delete' but we do it for other things | 10:11 |
| SotK | I'm a little wary of hiding our replacement for priority, but ehh | 10:12 |
| SotK | I don't think delete is useful enough to need to be displayed by default | 10:12 |
| persia | Would it make sense to implement "more..." as inserting content immediately beneath the task, before the next one, so the full text of notes could be displayed, etc.? | 10:12 |
| Zara | yep, in practice someone can rename a task and give it a different project. | 10:12 |
| SotK | persia: that is my thinking | 10:12 |
| persia | And, despite what I've written above, I'd like to make another argument for branch being on the primary display. | 10:13 |
| Zara | (we may have room for priority at that point, I just think it'll be nice if we have an agreed understanding of what we're going to prioritize (haha))) | 10:13 |
| persia | The idea being that there is no other way to differentiate the same task on the same project. It is blank most of the time, so shouldn't take up room except for people who really need to know the value. | 10:13 |
| Zara | (so that if someone then comes and says 'branches branches branches' we don't have a discussion of which thing should go to make room.) | 10:13 |
| persia | Zara: How do you mean? | 10:13 |
| * persia doesn't understand "room for priority", having thought that was being dropped by 312666 | 10:14 | |
| Zara | atm we're proposing putting 'add to worklist' on the 'more...' menu | 10:14 |
| Zara | since that's the way we assign priority now | 10:14 |
| persia | Oh, right, so whether that ends up above. | 10:14 |
| persia | So, if I understand the current candidate, we have: | 10:15 |
| Zara | (so I'm saying there might be room for the button after the new layout, in which case I think we should put it there because NEW FEATURE, but I'd be fine with shifting it to 'more' later) | 10:15 |
| persia | MAIN: id, title, project, status, link, assigee, more... | 10:15 |
| persia | SECOND: notes, add-to-worklist, delete, branch | 10:15 |
| persia | With Zara suggesting add-to-worklist be promoted, and me suggesting branch be promoted. | 10:16 |
| persia | Have I captured that correctly? | 10:16 |
| SotK | I believe so | 10:16 |
| persia | SotK: Is there anything you want to promote from SECOND? | 10:16 |
| Zara | well, I'm suggesting that if there's room, we promote add-to-worklist, but we don't squeeze it in | 10:16 |
| *** alexismonville has joined #storyboard | 10:16 | |
| Zara | so I'm not lobbying for it to be in the MUST category | 10:16 |
| persia | Zara: I'm about the same for branch, although since I think it is mostly 0 characters, squeezing is easy :) | 10:17 |
| SotK | I can see value in promoting either or both of the two already suggested | 10:17 |
| persia | SotK: Do you think both could fit? That sounds ideal if it works. | 10:17 |
| Zara | also, once things are behind a 'more' curtain, I think we can put n things in there | 10:17 |
| SotK | it depends, how do folk feel about the LP method of displaying lists of tasks organised by project? | 10:17 |
| persia | Because folk really should read the notes before adding to worklists or deleting. | 10:17 |
| Zara | I'd like to organise by project, then by branch, then by status | 10:18 |
| Zara | it might even be worth just displyain g'master' by default and in cases with more branches, click to show? | 10:18 |
| SotK | that is how I feel, I like the layout of that bug linked before | 10:18 |
| persia | SotK: So, being clear, LP doesn't really allow mutiple tasks against a project in a single bug. It allows a single bug to affect multiple projects, and multiple releases/branches for each project. | 10:18 |
| persia | If we're copying LP, I think "master" is the headline task, with any other branches subsidiary to it. | 10:19 |
| Zara | also, if we go the 'info displayed via organisation' route, the tricky thing is *changing* values | 10:20 |
| persia | And that way we can reuse the "project" space for "branch" in the subtasks. | 10:20 |
| Zara | ie: moving a task from one project to another, changing a task's status | 10:21 |
| persia | Which should leave space in MAIN for add-to-worklist (although I think people should read notes before doing that) | 10:21 |
| * SotK is happy to leave add-to-worklist behind a click in order to make people read the notes | 10:21 | |
| persia | Zara: Because the ordering changes, and users are surprised by the reordering? | 10:22 |
| SotK | persia: that reuse was what I was hoping to achieve | 10:22 |
| Zara | because if the button is removed in favour of order, you need some way of telling the order to change. | 10:22 |
| persia | Also, I like the idea of non-master branches being behind more... | 10:22 |
| persia | Although explaining the status is tricky that way. | 10:23 |
| SotK | Zara: I wonder how drag-and-drop between the project sections would work | 10:23 |
| SotK | ? | 10:23 |
| Zara | I'd like it | 10:23 |
| Zara | I don't know how it would be done | 10:23 |
| persia | That seems overly complex. | 10:23 |
| persia | Generally, I want to edit values in-place. | 10:23 |
| persia | Rather than having to move things around to put them in the right order. | 10:23 |
| persia | But that might be from me spending too much time with LP :) | 10:24 |
| Zara | well, we're thinking of organisation as a way of removing the 'project title' field from each task | 10:24 |
| persia | Also, unless every project is listed, it becomes tricky to change a task to an arbitrary project with drag-and-drop | 10:24 |
| SotK | persia: good point | 10:24 |
| persia | Zara: I don't think we want to remove it from "master", just other branches. | 10:25 |
| Zara | if we don't, then right now for these purposes I don't think we get a benefit to ordering by project. | 10:26 |
| persia | Given that we expect most deployments to be broad enough that most stories have less tasks than the number of projects in the deployment, I'm fairly sure we don't want to provide that information *only* by ordering. | 10:27 |
| Zara | an option would be to click the project title for all the tasks and then do something from there, but that could be irritating | 10:29 |
| Zara | http://paste.openstack.org/show/561233/ | 10:29 |
| Zara | imagine that's nicely spaced and project bar continues on to the horizon | 10:30 |
| persia | Thanks for that: it makes it easier to understand. | 10:30 |
| persia | My concern is that it makes it almost impossible to change the values except to other values already entered for the story. | 10:30 |
| Zara | well, http://paste.openstack.org/show/561234/ is a better comparison | 10:31 |
| persia | Well, that, and that it may make it very easy to inadvertantly change projects. | 10:31 |
| Zara | we could treat the project title as an 'edit projects' button in both cases, just in the first it could go to a submenu for changing project of individual tasks | 10:32 |
| Zara | the downside is that it's more longwinded. | 10:32 |
| Zara | and might be harder to guess | 10:32 |
| Zara | we could keep it as an option in reserve if we have no room and just press on | 10:33 |
| Zara | with project titles listed per task for now | 10:33 |
| Zara | aw I forgot assignee on that list | 10:33 |
| persia | http://paste.openstack.org/show/561237/ is my failed attempt to mirror your excellent demonstrations with my thought. | 10:33 |
| persia | Although I wonder if "task title" needs to be repeated for non-master branches. | 10:34 |
| Zara | (we could also have a small 'change project' button for changing project, rather than the full title) | 10:34 |
| Zara | if we used ordering | 10:34 |
| persia | I'd like that, because it could make the project title a navigation element to all stories against that project. | 10:35 |
| Zara | it probably doesn't | 10:35 |
| Zara | for repeating task title, I mean | 10:35 |
| * SotK agrees | 10:36 | |
| Zara | yeah, I was picturing something like that for branches, whatever the surrounding layout; that makes sense to me. :) | 10:37 |
| SotK | hmm | 10:37 |
| persia | OK, then removing the branch confusion, if we're just talking about multiple-tasks-against-one-project, I think I don't mind the duplicate info. | 10:37 |
| SotK | but what if the non-master branch has a task with a different title for whatever reason | 10:37 |
| persia | Just because I think it is easier to edit/understand at a glance. | 10:37 |
| *** alexismonville has quit IRC | 10:38 | |
| persia | SotK: Right. I can think of cases where a project in which I was involved needed to do that, so yeah, let's not try to hide the titles. | 10:38 |
| Zara | (can i just say how much I love asciiflow :')) | 10:39 |
| persia | Abstracted Example: bugfix in trunk, 2.5 that could not be backported to 2.4, which needed a completely different workaround to avoid a similar user experience. | 10:39 |
| persia | Zara: And now I understand why you produce those quickly, and I spend lots of time fussing with the differences between backspace and delete, or space counting, in the pastebin :p | 10:40 |
| Zara | ahahahaha | 10:40 |
| Zara | I only ended up familiar with it because I don't have the css skill to demo fast | 10:42 |
| persia | So, did we end up with consensus? | 10:42 |
| Zara | (so if I tried to do it in the webclient codebase, it'd take a week and be on the wrong side of the screen) | 10:42 |
| persia | I think I'm satisfied, but I'm uncertain if we're all thinking the same thing. | 10:42 |
| Zara | that matches my interpretation | 10:43 |
| Zara | organised by project, with 'change project' button per task? | 10:43 |
| Zara | and displaying task title, status, link, assignee and more...? | 10:44 |
| persia | I'm still very uncertain about that, but might be convinced if I saw it clearly. | 10:44 |
| persia | What about ID? | 10:44 |
| SotK | can someone define "organised by project"? | 10:44 |
| SotK | since I think you both have something different in mind | 10:44 |
| Zara | the first example here: http://paste.openstack.org/show/561234/ | 10:44 |
| * persia is now even more unsure about "organised by project" | 10:44 | |
| Zara | is what I'm picturing | 10:44 |
| Zara | (oh sorry, add taskid to the things displayed there) | 10:45 |
| persia | And one can see the "priority" of tasks at-a-glance once 312666 lands, in that UI element, and set "priority" in more...? | 10:46 |
| * persia wants to make sure there is a good story for this when people start asking where it went | 10:46 | |
| Zara | yeah, that matches my understanding | 10:46 |
| Zara | updating my ascii... | 10:47 |
| SotK | wait, how do we hope to display the "priority" of tasks? | 10:47 |
| persia | SotK: The box in the upper right from 312666 | 10:47 |
| persia | So nothing on the actual task line. | 10:48 |
| Zara | http://paste.openstack.org/show/561240/ | 10:48 |
| SotK | aha, good | 10:48 |
| Zara | (is an updated comparison for demoing 'organising by project' vs not) | 10:48 |
| persia | Zara: My fear with the "organised by project" layout is that with that I *really* want branch as a primary thing. | 10:49 |
| persia | Whereas with organised-by-task, if one can identify subsidiaries, one can use the space where "project name" goes to be "branch name" | 10:49 |
| persia | (yes, this is rare, but if an import run is made from LP, there will be many, many, many with associated branches) | 10:51 |
| Zara | what do you mean by 'organised by task'? matching on task-title? | 10:51 |
| persia | Zara: I mean like the "project foo" stuff in the bottom section of your diagram. | 10:51 |
| persia | Where every task is a top-level item, rather than being hierarchical under projects. | 10:52 |
| Zara | so that's just not organised by anything | 10:52 |
| persia | "Organised by task (where task has no subitem)" and "not organised by anything" mean the same thing to me. Do they to you? | 10:52 |
| Zara | yeah, I typed that before I got the clarification | 10:52 |
| persia | For me, the main difference applies if one has items that are subitems to tasks (e.g. subsidiary tasks that apply to non-master branches) | 10:53 |
| persia | Ah, cool. | 10:53 |
| Zara | but branches are brances of projects, so to me it just makes sense to order things by branch *within* projects | 10:53 |
| Zara | so that coud be added somehow if it makes sense | 10:53 |
| persia | (the problem with IRC is that the order of messages is not guaranteed, making some conversations make little sense) | 10:53 |
| Zara | :) | 10:54 |
| persia | I think that well over 90% of tasks will only be against master. | 10:54 |
| persia | But I think the cases where this isn't true involve important and vocal users (release team, stable maintenance team, vulnerability management team, etc.) | 10:55 |
| persia | So I'm not that fussed about having fancy UI to *set* branches, because these folk have lots of scripts anyway, so one more isn't that hard. | 10:55 |
| persia | But I am concerned about having a means to *display* branches, or these teams will need to encode the information in the task title, which prevents certain sorts of automation (e.g. CVE coverage status) | 10:56 |
| persia | WHich makes me want to figure out *how* branch would be displayed as long as the task display is being rewritten. | 10:57 |
| persia | As doing it later only opens up the same discussion again. | 10:57 |
| persia | I do agree with ordering things by branch within a project, where tasks are on multiple branches. | 10:58 |
| * Zara updates the ascii http://paste.openstack.org/show/561242/ | 10:58 | |
| persia | I'm just not sure about organising *all* tasks against a given project as a group. | 10:58 |
| Zara | the top one there is vaguely what I was thinking of | 10:58 |
| Zara | this is just for tasks per story. | 10:58 |
| SotK | Zara: then we'll need a "change branch" button too | 11:00 |
| persia | That makes sense to me, and covers all the information I want. That said, my habit is to think of tasks as higher-level concepts, with branches subsidiary to them, rather than think about branches as places to work, with lists of work to do against them. | 11:00 |
| Zara | sotk: I think that could go on 'more...' | 11:00 |
| persia | +1 on change-branch being in more... | 11:00 |
| Zara | it's not going to be as frequent as changing project imo | 11:01 |
| persia | For that matter, change-project could be there also. | 11:01 |
| persia | Zara: How often does the project need to be changed? | 11:01 |
| Zara | I tend to use it when triaging, as people lodge all webclient bugs as being against 'storyboard' | 11:01 |
| Zara | it might vary from project to project | 11:01 |
| Zara | the other case is where you get more information about a task so you realise it's for a different project. | 11:02 |
| persia | My intuition is that most projects have the main UI as part of the headline project, but you might be right. | 11:02 |
| persia | Actually, I think "change-branch" should not exist. | 11:02 |
| persia | Only "add-branch". | 11:02 |
| persia | If there is a task against the wrong branch, it is better to record that as "Invalid", as someone made that decision. | 11:03 |
| Zara | okay, I think that's an action for a project rather than something on the view of story tasks. | 11:03 |
| persia | I violently disagree. | 11:03 |
| persia | I'm happy for a project to also have a list of branches, if someone wants. | 11:03 |
| persia | But I think most tasks should be against master by default, and only against other branches when specifically indicated. | 11:04 |
| persia | And having all tasks be automatically against all configured branches means lots of very tedious work for triagers, with frustration by subscribed users who would regularly receive notifications that their bug will not be fixed in their branch. | 11:05 |
| Zara | I don't think those things conflict. I'm saying that branches are against projects. tasks can still be against master by default | 11:05 |
| Zara | then you'd post a task against x branch, master unless specified | 11:05 |
| Zara | otherwise | 11:05 |
| persia | So which is the action for the project? | 11:05 |
| Zara | 'add branch to this project' | 11:05 |
| persia | Because this sounds like what I thought, except you said that, which raised by violent objection. | 11:05 |
| Zara | then 'associate task with this branch' would be an action performed when creating a new task | 11:06 |
| persia | Ah, so if one wants to add a branch to a task, one creates a new task, specifying another branch? | 11:06 |
| *** alexismonville has joined #storyboard | 11:06 | |
| SotK | yeah | 11:06 |
| persia | I like that: I think if that is there, tasks need no branch-management UI at all. | 11:06 |
| Zara | yeah, I think I got confused because you're using 'add a branch' to mean what I'd describe as 'associate with a branch' | 11:07 |
| Zara | and yeah. of course, atm we can only post tasks against master | 11:07 |
| persia | Further, I like that because it can be deferred, with API-only branch task creation for now, and maybe later adding branch to the create-task UI. | 11:07 |
| * SotK is happy to mark invalid things that change-branch would be used for | 11:10 | |
| persia | Zara: To confirm consensus, would you mind updating http://paste.openstack.org/show/561242/ with the results of the latest discussion above the bar, and showing an example of an expanded task (after "more..." is activated) below the bar? | 11:10 |
| Zara | okay, I think the bit above the bar would look the same | 11:11 |
| * persia is still uncertain about project/branch/task vs project/task/branch, but is rethinking preconceptions about the relationship | 11:11 | |
| Zara | will see if I remember everything in more... | 11:11 |
| persia | Also, I think the line with "master" should be removed: tasks against master would appear directly under the project, and other tasks would appear beneath branch names, just to reduce vertical space, if that doesn't make all the tables horrid. | 11:13 |
| persia | (because so many stories will consist only of tasks against master, which adds lots of extra lines) | 11:13 |
| Zara | yeah, that's fine by me | 11:13 |
| Zara | I added it so it was clear how I was envisioning things being grouped | 11:14 |
| Zara | but I agree that should be the default | 11:14 |
| persia | I'm happy you added it before, because it made it easier to understand, but I just don't think it belongs there :) | 11:14 |
| SotK | so are we envisioning something like this? https://jsfiddle.net/aqrptL2L/1/ | 11:17 |
| -openstackstatus- NOTICE: Precise tests on OSIC provider are currently failing, please stop your checks until the issue is resolved. | 11:18 | |
| Zara | (I'm not sure how the 'more' layout should work; if it's a modal like the task card modal, we probably want to repeat stuff so it's visible, like http://paste.openstack.org/show/561269/) | 11:18 |
| Zara | sotk: that looks right to me | 11:18 |
| * SotK is imagining similar to how stories can expand in the project view | 11:18 | |
| SotK | to view the notes at least | 11:19 |
| SotK | and maybe the rest of the more things can just be a dropdown menu then | 11:19 |
| Zara | I'm not too fussed, really; beyond 'if info is obscured then it needs to be repeated.) | 11:20 |
| persia | I would prefer inline expansion to a modal. I can think of several cases where I want to compare notes, etc. | 11:20 |
| * SotK too | 11:20 | |
| Zara | cool, I have no preference | 11:20 |
| persia | And both of you prefer project/branch/task to project/task/branch? | 11:21 |
| Zara | I think project/task/branch would only work with a filter on task titles, and those could be different between branches | 11:22 |
| Zara | so I can't see how to do it | 11:22 |
| -openstackstatus- NOTICE: DSVM jobs on OSIC currently failing because of IP collisions, fix is in the gate - https://review.openstack.org/#/c/357764/ - please hold rechecks until merged | 11:23 | |
| Zara | http://paste.openstack.org/show/561271/ | 11:23 |
| Zara | edited so only non-repeated fields are present | 11:23 |
| *** alexismonville has quit IRC | 11:24 | |
| persia | By "filter" do you mean not repeating the title? | 11:25 |
| Zara | I mean 'how does storyboard know to group these things together?' | 11:26 |
| *** SotK has quit IRC | 11:26 | |
| persia | The only place I have used different-title-tasks-against-different-branches was Savannah at GNA, but those were tied to patch names, so very different. | 11:26 |
| Zara | so either it's duplicating tasks and associating each with a different branch, or it's associating multiple branches with a single task, which isn't supported in the api afaik | 11:27 |
| *** SotK has joined #storyboard | 11:27 | |
| Zara | 12:26 < persia> The only place I have used | 11:27 |
| Zara | different-title-tasks-against-different-branches was Savannah | 11:27 |
| Zara | at GNA, but those were tied to patch names, so very different. | 11:27 |
| *** matthewbodkin has quit IRC | 11:27 | |
| Zara | 12:27 < Zara> so either it's duplicating tasks and associating each with a | 11:27 |
| persia | Oh, right, because "branch" is just a field in the task record, rather than another data structure. | 11:27 |
| Zara | different branch, or it's associating multiple branches with a | 11:27 |
| Zara | single task, which isn't supported in the api afaik | 11:27 |
| Zara | SotK^ | 11:27 |
| Zara | since you just lost connection | 11:27 |
| persia | I now completely agree with project/branch/task. | 11:27 |
| SotK | good :) | 11:28 |
| SotK | Zara: thanks | 11:28 |
| Zara | yw :) | 11:28 |
| persia | Thank you for following the argument to conclusion. | 11:28 |
| * persia is much happier to be convinced vs. outvoted | 11:29 | |
| Zara | haha :) | 11:29 |
| * persia <- not a strong supporter of democracy | 11:29 | |
| Zara | well, we know that, what with the plans to take over the world | 11:30 |
| SotK | https://jsfiddle.net/aqrptL2L/3/ ? | 11:31 |
| persia | I don't want to take over the world, I just want it to be organised so that everything is decided by loose consensus, and everyone has direct access to a representative willing to argue their position. | 11:31 |
| persia | SotK: How does one toggle notes? | 11:32 |
| persia | Also, "stable/mitaka" is probably a more sensible example branch name. | 11:33 |
| persia | SotK: Also, I thought we dropped "Change branch" | 11:33 |
| *** alexismonville has joined #storyboard | 11:34 | |
| Zara | (hm, fairly sure you have used the exact words 'take over the world' on multiple occassions. =D) | 11:35 |
| persia | I often try to help others take over the world, or support ideas/projects/etc. that I hope will become exceedingly widespread (for which I might use that phrase), but I don't want to personally deal with the administrative overhead of running the world. | 11:36 |
| persia | If someone else wants to take over the world, I'm happy to advise them, as long as they commit to continuing to take my advice after they succeed. | 11:36 |
| SotK | https://jsfiddle.net/aqrptL2L/4/ may be clearer | 11:36 |
| SotK | similar to the way things get expanded on https://storyboard.openstack.org/#!/project/457 | 11:37 |
| SotK | (note that jsfiddle doesn't actually do any expanding) | 11:37 |
| persia | Aside from the "change branch" bit, I like it. | 11:38 |
| SotK | yeah, s/branch/project/ on that | 11:39 |
| persia | Ah, makes sense. | 11:39 |
| persia | All three actions under "more" bring up modals? | 11:40 |
| persia | (with "delete" just being a confirmation) | 11:40 |
| * persia worries about people clicking "more" to see what happens, and then not cancelling smoothly | 11:40 | |
| SotK | yeah, that would make sense | 11:40 |
| persia | I'm happy without any more comments, I think :) | 11:41 |
| persia | Zara: Does that work for you, with the s/change-branch/change-project/ and more..-creates-modals additions? | 11:42 |
| Zara | so the arrows work for notes in practice? | 11:43 |
| Zara | I think I'm fine with it, wondering about where 'edit' will go for notes, and we need 'edit' for links | 11:44 |
| Zara | trying to think if I've missed anything | 11:45 |
| persia | Good catch on the edit buttons. | 11:45 |
| persia | edit for notes could be on the extreme right of the expanded display | 11:45 |
| SotK | yep | 11:46 |
| Zara | it's a shame that changing project is now quite involved but we can change it if it turns out to be annoying (I can see us repeating it and making it editable inline uner notes or something, but I'd rather only do that if we have to) | 11:47 |
| Zara | *under | 11:47 |
| persia | What do others think about renaming "more..." to "actions"? | 11:47 |
| Zara | I prefer 'more' since I've seen it used as a shorthand elsewhere | 11:47 |
| persia | My imagination of change-project workflow is choose "change-project" from the actions pull-down, enter the new project name, press "change". | 11:48 |
| persia | My concern with "more" is that people might think it shows more information. | 11:48 |
| Zara | ('actions' might sound like something to do with meetings) | 11:48 |
| persia | Whereas, with the field selection we've made, everything in there makes a significant change to the task | 11:48 |
| Zara | also wondering how easy it is to copy an id if it also functions as an expansion for notes | 11:48 |
| persia | I thought the expansion was the little triangle on the left, not the ID. | 11:49 |
| SotK | yeah, that is the plan | 11:49 |
| Zara | okay, cool | 11:49 |
| Zara | I think the placement of 'more' suggests more things to do, but we could always change the wording if we find it confuses people. | 11:50 |
| persia | I'm fine with waiting for feedback to change the name. | 11:50 |
| -openstackstatus- NOTICE: OSIC has burned through the problematic IP range with failures, things should be back to normal now. | 11:50 | |
| * SotK actually prefers actions xD | 11:51 | |
| SotK | https://jsfiddle.net/aqrptL2L/7/ | 11:51 |
| persia | For now, it's just arguing fuschia vs. chartreuse | 11:51 |
| SotK | (just imagine it has consistent names for buttons) | 11:51 |
| Zara | thanks, that's much clearer | 11:52 |
| persia | How long does jsfiddle keep things around? | 11:52 |
| Zara | I'm not sure notes are findable enough but hm. | 11:52 |
| persia | Could we add "Show Notes" to "Actions", as a second way to expand? | 11:53 |
| Zara | I was wondering if we should just have one 'expand' (or whateveR) button that then reveals notes with buttons for 'edit notes, change project, add to worklist, delete task', but could look messy | 11:54 |
| persia | Actually, I like that better. | 11:54 |
| persia | It preserves the idea of making sure people read the notes before deleting the task, switching projects, etc. | 11:54 |
| persia | In my imagination, there is a row of action buttons at the top, and the notes appear below. | 11:55 |
| Zara | (I also now like the idea of naming the button 'whateveR'. time for more tea.) | 11:55 |
| Zara | (though I'm happy, this feels very productive) | 11:55 |
| persia | But if it is done that way, I think we don't need a "more..." button: the expand-view widget that is consistent with expand-view elsewhere in storyboard-webclient seems enough to me. | 11:55 |
| Zara | makes sense to me | 11:57 |
| * SotK doesn't know how long jsfiddle keeps things around | 11:58 | |
| SotK | I don't recall ever stumbling across an expired one, and it certainly *used* to be "forever" | 11:58 |
| persia | SotK: How long do you think it takes to go from jsfiddle prototype to another WIP revision? | 11:58 |
| SotK | persia: not very long | 11:59 |
| persia | Then there's no reason to capture the fiddle. | 11:59 |
| persia | I just wanted to capture the conversation while we still all had the same thoughts. | 11:59 |
| SotK | does https://jsfiddle.net/yr59rzad/1/ match the discussion above? | 12:09 |
| persia | It does to me. The "Edit Notes" button could go to the actions row, or it could stay: I have no preference. | 12:09 |
| SotK | Zara? | 12:11 |
| persia | As a matter of curiosity, is there a data structure for link currently? | 12:13 |
| SotK | There is not | 12:13 |
| persia | Ah, oops :) | 12:13 |
| * SotK goes to get lunch before translating that jsfiddle into something that works | 12:17 | |
| Zara | oh, sorry, I was afk | 12:20 |
| Zara | links aren't hard to add btw, notes started as links and then morphed into notes so we can probably just fix those in the backend and then repeat. | 12:21 |
| persia | Indeed. I just remember that there was a grandiose plan to add links as a field in a separate series. | 12:22 |
| persia | Doing it here makes sense, because it means only one redesign of the task appearance, but it complicates the stack. | 12:22 |
| persia | On a related topic, it appears to me that milestones are only meaningful to the API and python client. Is there something in the UI of which I'm not aware? | 12:24 |
| *** matthewbodkin has joined #storyboard | 12:27 | |
| persia | Interesting: there is some policy embedded in the code for milestones: e.g. it is impossible to set a status for a milestone other than "merged". | 12:34 |
| Zara | yeah, they're all historic, you can't set a future one | 12:36 |
| persia | I consider not being able to set a future milestone as a feature. | 12:38 |
| persia | Oh, wait, and that implies that everything recorded in milestones already happened, so there's no point in storing anything other than "merged". | 12:39 |
| persia | I get it now. | 12:39 |
| * persia learns about alembic migrations | 12:40 | |
| persia | is there any sensible way to query the production DB to see if any milestones are set, or used in any tasks? | 12:40 |
| *** jtomasek has joined #storyboard | 12:48 | |
| *** jtomasek has quit IRC | 13:11 | |
| openstackgerrit | Matthew Bodkin proposed openstack-infra/storyboard-webclient: Make sidebar submenu the same length as sidebar https://review.openstack.org/355554 | 13:15 |
| SotK | persia: https://storyboard.openstack.org/api/v1/milestones | 13:17 |
| Zara | btw, on that js fiddle, I was picturing the 'change project' as working as it currently does (so just an editable project title inline) so it's a bit quicker, but it's not a strong preference. so both organised by project, then iff the task details are expanded, there's an editable title per-task | 13:19 |
| Zara | *editable project title | 13:19 |
| Zara | anyway, yeah, I don't feel strongly and it might not work | 13:20 |
| SotK | ehhh, I think that'll look confusing if its always there | 13:21 |
| persia | WIth the action buttons, rather than an action menu, I'm less strongly in favour of modals for everything, so inline would work for me. | 13:21 |
| persia | But I agree that it might look confusing. | 13:21 |
| persia | (and click, edit, save is about the same amount of effort with and without modals, except for folk (like me) that find modals distracting and confusing. | 13:22 |
| persia | ) | 13:22 |
| Zara | yeah, it's a 'maybe there'd be a way to make it work but I don't really know and there's no point going to painstaking effort over it' | 13:22 |
| Zara | worst case, it annoys people, they suggest a fix | 13:22 |
| Zara | (best case, it doesn't annoy anyone; middle case, it annoys people and they fix it) | 13:23 |
| Zara | :P | 13:23 |
| persia | SotK: From the milestones API, I get "[]", which I take to mean none are defined anywhere or used anywhere. Does that match your understanding of such a response? | 13:23 |
| Zara | (ignored case, it annoys people, they don't offer any suggestions or patches) | 13:23 |
| persia | That case is always better ignored :) | 13:24 |
| SotK | persia: yes | 13:25 |
| SotK | https://jsfiddle.net/yr59rzad/2/ ? | 13:25 |
| persia | That does look distracting and funny to me. | 13:25 |
| Zara | I don't mind it so much but that's partly because I'm imagining it laid out in the real thing (so assignee won't be right on top of it like that) | 13:28 |
| Zara | no strong feelings either way, the familiarity might be good, people might navigate to project when they wanted to edit it | 13:28 |
| persia | I wasn't looking at the upper line: just the idea that I suddenly have a navigation link in the middle is confusing to me. | 13:28 |
| persia | But my taste differs from many, so maybe I'm wrong. | 13:28 |
| Zara | I think I lean on the side of pro button, change if people complain | 13:29 |
| Zara | just for consistency | 13:29 |
| SotK | then I think we have consensus | 13:29 |
| persia | So like the first revision, rather than the second? | 13:29 |
| Zara | yup | 13:29 |
| persia | Works for me. | 13:29 |
| persia | Zara: Do you have an opinion about the position of the edit notes button? | 13:30 |
| Zara | it looks a bit odd but I've yet to think of a better way of doing it, and I htink we can move it later if we think of something | 13:30 |
| Zara | *think | 13:30 |
| persia | I was thinking putting it in line with the other buttons, but it might get lost there. | 13:31 |
| Zara | yeah, I think that would be worse | 13:31 |
| SotK | https://jsfiddle.net/yr59rzad/4/ | 13:31 |
| * SotK also thinks it is worse | 13:31 | |
| * persia doesn't have a real opinion on edit notes position either way, just wanted to point out that it was odd. | 13:31 | |
| persia | If you both think it worse, then I'm happy with it floating on the right. I think it looks lonely, but I don't have a good suggestion to fix it. | 13:32 |
| Zara | I have a spec of dirt on my monitor that meant 'delete' looked like 'delefe' and I wondered why there was something that looked vaguely french in there suddenly | 13:32 |
| Zara | I'm fine with this | 13:33 |
| SotK | what is "this"? | 13:33 |
| Zara | position of edit notes button | 13:34 |
| Zara | floating on the right | 13:34 |
| Zara | for now | 13:34 |
| * SotK tries it underneath the notes, but it doesn't work great | 13:35 | |
| SotK | https://jsfiddle.net/yr59rzad/5/ | 13:35 |
| Zara | yeah, I think it needs to be high up so someone can edit it quickly | 13:35 |
| Zara | instead of scrolling every time | 13:35 |
| Zara | I guess we could make like a card modal and have the notes themselves be clickable | 13:36 |
| Zara | erm, as in, have it behave the way text does in a card modal | 13:36 |
| Zara | I realised that was ambiguous | 13:36 |
| * SotK idly wonders if links work in card modals | 13:36 | |
| Zara | I think they do but hm | 13:36 |
| Zara | (do they even work liek that any more? it's been a while | 13:37 |
| SotK | they do work, but also begin editing | 13:37 |
| Zara | ah yes | 13:37 |
| persia | I think a modal to make it editable will be even more confusing. | 13:37 |
| Zara | and then once the thing loads, the editing screen is lost | 13:37 |
| Zara | (but they allow you to open link in new tab) | 13:38 |
| persia | Unless the markdown specified a remote target, etc. | 13:38 |
| SotK | persia: the idea is that clicking on the text itself causes it to become editable, rather than a modal | 13:38 |
| persia | SotK: Oh, that's a bit better, but still there is a lot of potential for user confusion or irritation, especially with touchpads. | 13:38 |
| SotK | (or rather on the div containing the text, but that is an implementation detail) | 13:38 |
| SotK | yeah, I can imagine it being annoying trying to scroll on a phone | 13:38 |
| Zara | I'm in favour of it floating on the right and then if ever we think of something better, we change it | 13:39 |
| Zara | the button | 13:39 |
| persia | +1 | 13:39 |
| SotK | wfm | 13:40 |
| persia | Sadly, I am soon to be distracted by $work, so I won't be able to comment on anything for some time. | 13:40 |
| persia | (hours, rather than days) | 13:40 |
| Zara | I think the discussion has done its work, so that seems fine \o/ | 13:41 |
| * SotK too | 13:42 | |
| Zara | I'm happy :D | 13:42 |
| Zara | I think we should link the fiddle (or equivalent) in a story today | 13:43 |
| persia | SotK said it would be nearly as fast to do another WIP revision including the template updates we've discussed, which I think would be better. | 13:43 |
| persia | It won't work (because it needs DB changes, API changes, etc.), but it will record consensus well. | 13:44 |
| Zara | yup, there should be a story linking to that. | 13:44 |
| persia | There are also 5 or 6 changes in the queue with +2s and no +As that might be worth addressing. | 13:44 |
| * SotK is sad that notes are still called "link" in the db, else I could send a mergable patch | 13:45 | |
| Zara | I'm sorry about that, it's been on a backburner for ages :( | 13:45 |
| Zara | it's not a big change, just haven't got around to it because of other priorities | 13:45 |
| persia | Perhaps the change should be to create a "notes" field :) | 13:46 |
| Zara | you'd want to rename 'link' to 'notes' and then make a new link field | 13:46 |
| Zara | otherwise we'd lose old ones. or the names wouldn't match up | 13:46 |
| SotK | well, we could just do that switch in the migration actually | 13:47 |
| Zara | the point where the js meets the api would need a check | 13:47 |
| persia | Doing that switch in the migration seems the sanest plan. | 13:47 |
| SotK | ah yeah, we have a problem in that the webclient currently sets task.link all over the place | 13:48 |
| Zara | eg: this sort of thing https://github.com/openstack-infra/storyboard-webclient/blob/4397c971fe0a84e51f36b191d696eccda3224ee4/src/app/stories/template/detail.html#L438 | 13:49 |
| Zara | yup | 13:49 |
| Zara | so those need to be merged close together. | 13:49 |
| Zara | which is a reason I procrastinated, since I wanted to do it when I had time to check I hadn't messed up and broken them | 13:50 |
| Zara | that + no immediate demand until now \o/ | 13:50 |
| Zara | (as it requires a db migration, it needs to be coordinated in order for it not to clash when I'm reviewing) | 13:53 |
| Zara | it doesn't work well if we're both hacking on the db and reviewing changes to a different version | 13:53 |
| persia | Depends-On: ? | 13:57 |
| Zara | what I mean is that I have to perform a migration to review, then go back to code, and so on, and there's a big potential for fires | 13:59 |
| *** jtomasek has joined #storyboard | 14:27 | |
| *** jtomasek has quit IRC | 14:28 | |
| *** jtomasek has joined #storyboard | 14:29 | |
| persia | storyboard patches with +2, +V, no -1, no +A: 356021, storyboard-webclient patches with +2, +V, no -1, no +A: 354736, 355912, 357257. | 15:20 |
| Zara | we were talking this morning and we don't like to merge things on a friday afternoon. also urls are generally more useful to send if you want eyes on things (from me, anyway) | 15:22 |
| persia | Yeah, well, some of those were in that state last Friday also :) I don't think any of them are urgent for anything. | 15:23 |
| Zara | so the first of those is missing +1 | 15:25 |
| persia | You could add one :) | 15:25 |
| persia | (or a -1) | 15:26 |
| Zara | no I couldn't, I +2d | 15:26 |
| Zara | 2nd is ready for merge, but got to that state on tues | 15:26 |
| persia | Actually, for that list, I don't think you can do much. | 15:27 |
| Zara | 3rd needs a +1 and that's just one I havne't got to yet, but that is one where I can do a thing | 15:27 |
| persia | I think there is one on which you could comment, but half of them are yours. | 15:27 |
| Zara | (but again, went up on tues) | 15:27 |
| Zara | and yeah, last is mine xD | 15:27 |
| Zara | yeah, there's on of that list that I can be helpful, and I've just had other things in the queue | 15:28 |
| Zara | what is that sentence | 15:29 |
| persia | And that one isn't very important, because it doesn't actually do anything. | 15:29 |
| Zara | (*There's one item on that list for which I can do a helpful thing) | 15:29 |
| persia | But it's late on Friday, so next week :) | 15:30 |
| Zara | yeah. I also generally don't look to +2 things until they have at least a +1 beyond the feature I'm looking at. | 15:30 |
| persia | Makes sense. The reason I made the list is that there were a few things that had +2 without +1 or +2 and +1, but no +A, and I wasn't sure if anyone was running queries. | 15:31 |
| * SotK looks | 15:31 | |
| * persia does that check every week or so, just to see if anything can be done, but may be alone | 15:32 | |
| Zara | I do it but I tend not to bang doors until something's been stuck missing the requisite +1 for a week. | 15:32 |
| * SotK breaks the no-merge rule :) | 15:32 | |
| Zara | hahaha | 15:33 |
| Zara | well, if you're willing to stay up if it somehow breaks everything | 15:33 |
| Zara | I don't know why it would | 15:33 |
| Zara | I'm not making that commitment this evening so I'm not intending to merge anything tonight | 15:33 |
| SotK | :) | 15:33 |
| * SotK is happy to check back later | 15:34 | |
| SotK | its not like they are particularly dangerous patches, so I'm not expecting to have to do anything | 15:34 |
| Zara | I've almost given up trying to guess which ones will be dangerous | 15:35 |
| Zara | after a misadventure with the story detail controller | 15:36 |
| persia | heh | 15:40 |
| *** jtomasek has quit IRC | 15:50 | |
| openstackgerrit | Merged openstack-infra/storyboard-webclient: Fix Pagination for Admin Users Page https://review.openstack.org/354736 | 15:54 |
| openstackgerrit | Merged openstack-infra/storyboard-webclient: Prettify Task-Status-Changes in Recent Events https://review.openstack.org/357257 | 15:54 |
| persia | Hurrah! | 15:55 |
| openstackgerrit | Merged openstack-infra/storyboard: Describe Storyboard in more detail https://review.openstack.org/356021 | 15:56 |
| matthewbodkin | persia: so is your about page ready to be merged then and I'll just abandon my patch and do all the tweaking that was required with on new page? | 16:03 |
| persia | matthewbodkin: Don't abandon it. | 16:03 |
| persia | matthewbodkin: If you think mine will land first, review mine (to make sure I'm not doing something stupid that will break yours), then rebase yours on mine, and submit another revision. | 16:04 |
| persia | gerrit will check the parent: information in the commits, and automatically stack them. | 16:04 |
| persia | I believe the only place we're still colliding is around the contributing part. I'm not sure of the best answer there: some of your improvemnts can stack on mine, some probably need a bit of thinking (because README moved) | 16:05 |
| matthewbodkin | Okay yours looks ready to go and I'd say is more important so I'll just do all the tweaks on yours | 16:06 |
| persia | `git fetch` + `git rebase` is your friend here. | 16:06 |
| matthewbodkin | The only part that I was going to add to the contribution part was about where to store bugs | 16:06 |
| matthewbodkin | Well specific bugs | 16:07 |
| persia | Plus, my grammar probably needs tweaking, so if you want to clean up my new text, feel free. | 16:07 |
| matthewbodkin | Okay we'll do that then | 16:07 |
| persia | Yep, and I added the link to README, so someone needs to figure out which one goes on top, etc. | 16:07 |
| matthewbodkin | Also one for everyone, on the sidebar submenu, when you scroll down the icons at the top stay where they are, should I make it so that they move down with the page for ease of use? | 16:08 |
| persia | Please, no. Floating navigation elements break more pages than anything else for me. | 16:09 |
| matthewbodkin | Hahaha okay no worries | 16:09 |
| persia | It works fine, as long as one doesn't use non-standard browsers or screens with resolutions and/or pixel ranges well outside the expectations of the browser/framework developers. | 16:10 |
| matthewbodkin | That's me done for the day then I think, have a great weekend everyone :D | 16:10 |
| Zara | you too, night! | 16:11 |
| * persia has worked with screens with diagonal measures from 1cm to 8m, and resolutions from 120x48 to 8640x3600 | 16:11 | |
| persia | Good night :) | 16:11 |
| persia | (and DPI from <1 to >1000) | 16:11 |
| matthewbodkin | It should be fine for all screens I'd think but I'll take your word for it, you've got far more experience that me :) | 16:14 |
| persia | I only mention the ranges because they are larger ranges that some people use. I am probably oversensitive, having had issues with these sorts of things for a long time. | 16:15 |
| matthewbodkin | Better to be safe | 16:15 |
| persia | But some frameworks don't work: a common tool for showing floating links on the right side overflows if one makes one's browser about 350px wide, and keeps it > 1500 tall, so everything is overwritten (no, I haven't checked which) | 16:16 |
| *** matthewbodkin has quit IRC | 16:21 | |
| openstackgerrit | Adam Coldrick proposed openstack-infra/storyboard-webclient: WIP: Rework the task list layout https://review.openstack.org/357306 | 17:06 |
| Zara | ooh | 17:06 |
| SotK | da daaaaa! | 17:06 |
| Zara | I mean it hasn't built yet dohoho | 17:06 |
| SotK | (none of the buttons on it work yet either) | 17:06 |
| Zara | details, details, +2, +A | 17:08 |
| persia | What does ng-if do again? | 17:08 |
| persia | Display the element if the conditoin is true? | 17:08 |
| SotK | yes | 17:09 |
| * Zara can never remember when it should be ng-if and when it should be ng-show | 17:09 | |
| persia | That is why I felt I needed to ask :) | 17:09 |
| SotK | different from ng-show in that if the condition is false the element is not rendered at all | 17:09 |
| persia | ng-show has the element, but not the content, right? | 17:09 |
| Zara | ah, that sounds better; I guess ng-show makes more sense if you're toggling between them a lot? | 17:10 |
| SotK | ng-show has both, just hidden with css | 17:10 |
| persia | Ah. | 17:10 |
| SotK | Zara: yep | 17:10 |
| Zara | \o/ | 17:10 |
| Zara | I'll forget in a week but thanks | 17:10 |
| Zara | I fear I've used them indiscriminately depending on 'which I remembered existed based on the surrounding code' | 17:11 |
| * persia fails to understand how task_list_item fits in the new task_table | 17:12 | |
| SotK | it doesn't I just forgot it exists :) | 17:13 |
| persia | Oh, heh. In the diff I'm reading, it seems you updated it before you forgot :) | 17:14 |
| persia | So I was wondering if there was some magic reason for the duplication: there is certainly a reference in the table to the tabe item. | 17:14 |
| SotK | ha, indeed I did | 17:14 |
| *** alexismonville has quit IRC | 20:01 | |
| *** alexismonville has joined #storyboard | 20:03 | |
| *** alexismonville has quit IRC | 20:51 | |
| *** alexismonville has joined #storyboard | 23:56 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!