| *** jtomasek has quit IRC | 03:48 | |
| *** jtomasek has joined #storyboard | 03:59 | |
| *** zaro_ has joined #storyboard | 05:43 | |
| *** jjardon__ has joined #storyboard | 05:43 | |
| *** zaro has quit IRC | 05:48 | |
| *** jjardon has quit IRC | 05:48 | |
| *** persia_ has quit IRC | 05:48 | |
| *** zaro_ is now known as zaro | 05:48 | |
| *** persia_ has joined #storyboard | 05:49 | |
| *** jjardon__ is now known as jjardon | 05:51 | |
| *** fay has joined #storyboard | 07:35 | |
| *** fay is now known as Guest99410 | 07:36 | |
| *** matthewbodkin has joined #storyboard | 07:40 | |
| *** mrmartin has joined #storyboard | 07:42 | |
| *** Guest99410 has quit IRC | 07:50 | |
| *** Guest99410 has joined #storyboard | 07:50 | |
| *** Guest99410 is now known as faybrocklebank | 07:50 | |
| openstackgerrit | Matthew Bodkin proposed openstack-infra/storyboard: Fix to slight errors in docs https://review.openstack.org/353891 | 08:02 |
|---|---|---|
| *** jtomasek_ has joined #storyboard | 08:02 | |
| *** mrmartin has quit IRC | 08:10 | |
| *** mrmartin has joined #storyboard | 08:12 | |
| *** mrmartin has quit IRC | 08:13 | |
| Zara | morning, storyboard! | 09:38 |
| SotK | morning! | 09:39 |
| Zara | today's storyboard musical interlude is not a piece, but an interesting contraption I found on the interwebs last night: https://scratch.mit.edu/projects/14488396/ | 09:58 |
| Zara | is https://review.openstack.org/#/c/340506/ failing on the same test each time? | 10:39 |
| *** alexismonville has joined #storyboard | 10:39 | |
| Zara | (wondering if the test is the issue or if it just needs another recheck...) | 10:40 |
| Zara | I doubt it's the patch, there | 10:40 |
| * SotK thinks its a weird timing out issue | 10:41 | |
| SotK | since it passed the same test in check | 10:41 |
| Zara | oh yeah | 10:41 |
| Zara | hah, didn't notice that | 10:41 |
| * Zara rechecks | 10:42 | |
| *** alexismonville has quit IRC | 10:51 | |
| Zara | time to try this db migration | 11:26 |
| Zara | about 2 days later than I originally intended to. \o/ | 11:26 |
| Zara | 400 again :( | 11:27 |
| Zara | haha, I forgot to run the actual upgrade command and just got a wall of errors | 11:28 |
| * Zara actually upgrades db this time | 11:28 | |
| Zara | hopefully that won't have confused it | 11:29 |
| Zara | a warning about timestamp columns, don't think I've seen that before when running the commands, though it seems vaguely familiar from some logs | 11:30 |
| Zara | upgrade went smoothly, anyway | 11:30 |
| Zara | oh yeah, when testing notifications things, might be a good idea to have the notifications worker running... ^^ | 11:32 |
| *** alexismonville has joined #storyboard | 11:36 | |
| *** alexismonville has quit IRC | 11:41 | |
| *** alexismonville has joined #storyboard | 11:46 | |
| openstackgerrit | Merged openstack-infra/storyboard: Add example commands for the Worklists api https://review.openstack.org/340506 | 11:46 |
| *** alexismonville has quit IRC | 11:48 | |
| *** alexismonville has joined #storyboard | 11:48 | |
| SotK | finally! | 11:49 |
| *** alexismonville has quit IRC | 11:49 | |
| Zara | \o/ | 11:49 |
| *** alexismonville has joined #storyboard | 11:49 | |
| Zara | I'm wondering with notifications for worklists and boards-- how easy will they be to filter out from other notifications? eg: for cards moving between lanes, that's going to be a lot of duplication from task status changes, and I'd personally want to hide that. | 11:51 |
| *** alexismonville has quit IRC | 11:54 | |
| Zara | hahahaha, seems like messing around with branches can lead to exciting results | 11:56 |
| Zara | just found by accident while creating a test story | 11:57 |
| Zara | clicking 'save' gives me: 404: POST /api/v1/tasks: Master branch of project 21 not found. ) | 11:57 |
| Zara | so I daresay I changed that branch with the python client a while back | 11:57 |
| Zara | the id looks familiar for that | 11:57 |
| Zara | ah yes, I renamed it from 'master' to 'pickle' | 11:58 |
| Zara | so I guess that means that atm stories can only be posted against master | 11:58 |
| Zara | well that's handy to know | 11:58 |
| * Zara goes to post a new master branch for that project to see if that works | 11:59 | |
| SotK | they won't show up at all on the events timeline for stories | 11:59 |
| SotK | since they are pretty much unrelated | 11:59 |
| Zara | I meant for the recent events | 11:59 |
| SotK | oh! | 12:01 |
| SotK | yeah, I should probably make them configurable like I said I would | 12:01 |
| persia | Zara: Regarding duplicate notifications: can you expand on a case where that would happen? | 12:02 |
| Zara | persia: someone moves a task to 'review' lane in a board, but they also want that information visible from the story page, so they go to the story and change the status there | 12:04 |
| Zara | I think that's going to happen a lot, and we don't want to discourage people from changing the status on the story | 12:04 |
| persia | From my perspective, if a task is in review, that information is only in the task, not in the story or in lanes. | 12:04 |
| Zara | the task status in the story. | 12:04 |
| persia | And if someone had a "review" lane, wouldn't they use an automatic worklist (without subscriptions)? | 12:04 |
| Zara | not necessarily, because that would require browsing to the story to change the task status each time. | 12:05 |
| persia | Especially with gerrit integration, where the task status just updates. | 12:05 |
| persia | Hmm.. | 12:05 |
| * SotK notes that there is no "card added/disappeared" events for automatic worklists, while we're on the topic | 12:06 | |
| Zara | this is why automatic lanes that apply rules are THE FUTURE | 12:06 |
| Zara | phew xD | 12:06 |
| persia | I have trouble understanding the mindset behind the workflow you describe, but I have seen it. I had hoped it wouldn't be necessary, given the number of complaints I've heard about doing things that way, but ... | 12:06 |
| persia | SotK: To my mind, that is a feature, and that behaviour should be preserved. | 12:06 |
| * SotK is glad we're in agreement | 12:07 | |
| persia | I think I don't care about the potential for duplicates there, because I don't think people should do it that way. | 12:08 |
| persia | If they want lanes-with-status, they should use automatic worklists, or the task status will probably be wrong anyway, because nobody wants to change things in two places. | 12:08 |
| persia | With gerrit integration, people can manually updates 0 places, with automatic worklists, which makes life easier. | 12:09 |
| persia | automatic-apply would be cool, but I don't think there is any reason to complicate subscriptions for worklists or boards before that lands. | 12:10 |
| Zara | it works for openstack and anywhere else sensible enough to pursue gerrit integration, though it assumes people will always put the task id in a change and nobody will be put on cleanup duty for those times when it doesn't happen. | 12:10 |
| Zara | the other cool thing with applying rules is that there could be a chain-reaction per storyboard instance (eg: all things in this lane in this board (different per project) get tagged 'x'; things move into lane automatically when patch is submitted') | 12:13 |
| SotK | part of me feels that we shouldn't work lots on making life better for people not using the tools properly (ie, not linked to some kind of patch tracking system) | 12:13 |
| persia | I completely agree applying rules is cool. I think it's a separate discussion, and don't see any reason to block worklist subscription for that. | 12:13 |
| SotK | Zara: that makes me wonder how rules would be applied in a general case actually | 12:14 |
| persia | And while not everyone uses gerrit, there's no reason one can't attach to *any* patch tracking system, if one likes. | 12:14 |
| SotK | its easy to apply a rule to a manually added card, but there is nothing actually in automatic worklists to apply rules to | 12:14 |
| Zara | persia: oh yeah, I'm just saying I'd prefer to be able to filter boards notifications out, because I can't assume every person who has a board I care about will use it the same way. + for the case of 'review' changing to 'doing' and back (when a patch needs a rework), gerrit doesn't send any information for that (and I don't know how it would) | 12:15 |
| * SotK feels now is a good time to point out there is no subscribing to boards yet | 12:16 | |
| persia | SotK: heh | 12:16 |
| persia | SotK: Even so, one can subscribe to all the worklists in a board, which only multiplies the issue (because one gets both a "card-removed" and "card-added" event when moving) | 12:16 |
| persia | Zara: I still think that doing that is doing it the wrong way, and don't see why we want to support a behaviour that requires manual updates in two places. | 12:17 |
| Zara | there isn't an alternative that I've found for that scenario | 12:17 |
| SotK | moving a card from one worklist to another is a single operation (so you get a "card-updated" event where the update is changing the list which contains the card) | 12:17 |
| persia | Zara: Update the task status and use automatic worklists? | 12:18 |
| Zara | which requires going to a board, clicking on a story and then changing a task status there each time | 12:19 |
| persia | Why start from a board? | 12:19 |
| persia | If you're working on something, you're assigned, which means the story is on your dashboard, which is easier to reach, conceptually, as it is the default when you log in. | 12:20 |
| Zara | because that's where one's manager will put things if they want to prioritise items, and where they'll look to see how things are doing. | 12:20 |
| persia | And I suppose there are plenty of managers who would not be willing to figure out how to use automatic worklists, sadly. | 12:21 |
| persia | I still think it is very broken. | 12:21 |
| Zara | and it's a lot easier to send a team to a board for 5 mins in a meeting than it is to go 'okay, everyone, please go to the story for each task you're looking at and change all the task-statusees to 'doing' if you're reworking something you sent a patch for' | 12:22 |
| Zara | rather than 'if you see something in the 'review' lane that you're reworking, please move it back to 'doing'' | 12:22 |
| persia | That presumes the team hasn't bothered to update status in realtime, which implies that the team finds updating status onerous, which implies we're doing it wrong. | 12:22 |
| SotK | I find that updating status is onerous if it is anything more complicated than "it automatically changes when I send a patch" | 12:23 |
| persia | Yes, which means that any board that isn't using automatic worklists is usually going to be a useless view of status. | 12:23 |
| Zara | right, and gerrit can't change a status back to 'doing' when a patch needs reworking, since that's down to a human | 12:23 |
| persia | Which means we should document how to do it correctly, so that we don't have this use case. | 12:24 |
| persia | Zara: Yes, but in that specific case, the developer has that story on the dashboard, so it is easy to adjust while ignoring the board completely. | 12:24 |
| Zara | I don't think there's a 'correct' way to do it, just different workflows that are suited by different approaches. | 12:24 |
| persia | To me, this is no more complicated than assigning oneself something to indicate one is starting work. | 12:24 |
| persia | I very strongly believe that the only sensible way to create a tool is to define correct behaviours, and then enable them. | 12:25 |
| persia | When one follows the path of workflow relavatism, one ends up with a tool that tries to do everything, and ends up doing nothing well. | 12:25 |
| persia | I don't assert that my view of the correct option is always right, but only that it doesn't make sense to deal with corner cases where there is consensus that the workflow is broken. | 12:26 |
| persia | I'm happy if you disagree with my opinon about the workflow, and maybe my opinion can be changed, but I believe that if you try to make everything work, you'll end up with something that doesn't work. | 12:26 |
| Zara | people still are not going to update status every time from the dashboard, or always assign themselves. so that's why a board can help make the status in storyboard catch up with realtime status, and that's the best you're going to get, for reporting purposes. | 12:27 |
| Zara | to actually fix this scenario, you'd need the patch-tracker to update statuses when someone said they were reworking | 12:27 |
| persia | Considering that all the users are migrating from LP, where there are no boards, I think most folk are going to be very conditioned to a workflow of update-status-in-task-from-story(bug)-view. | 12:27 |
| SotK | so, this is the main reason I want automatic lanes to be able to apply rules | 12:28 |
| SotK | the only rule I actually see myself using is one which sets task status based on lane | 12:28 |
| Zara | +1 | 12:28 |
| persia | SotK: You earlier said that anything other than automatic adjustment from a patch tracker was onerous. WHy would you want to do it as you have just described? | 12:29 |
| SotK | some tasks might not end up in a patch tracker | 12:30 |
| persia | Why not? | 12:30 |
| Zara | they might not be code. | 12:30 |
| persia | What task that should be performed against a repository does not end up as a commit, if complete? | 12:31 |
| persia | (where there is a previous one-to-one mapping between "project" and "repository" in storyboard) | 12:31 |
| Zara | projects don't have to be repositories, that's just a convention. and in practice projects encompass more than their code, and tasks related to developing a project don't always comprise code. | 12:33 |
| persia | For clarity, by "code", I mean "code, documentation, configuration, orchestration, integration, etc.". Does this match your definition? | 12:34 |
| persia | (essentially, anything that ends up as a text file that is shared with the world) | 12:34 |
| Zara | much project work is comms. you might have a task like 'email list about x', or all sorts of preliminary things that aren't ready to go up as a patch (where you might want to document, but not in the repo, since they're too sketchy to be much use officially (like the task notes examples from the other week)) | 12:36 |
| SotK | a task such as "research a thing" or "talk to a person" which are still useful activities to track, but may result only in an irc conversation | 12:36 |
| SotK | https://storyboard.openstack.org/#!/search?q=investigate for example | 12:37 |
| Zara | 'test patch with a lot of data' is another, that's currently blocking a storyboard patch; it might require running against a bigger db, but there's no new code for that. | 12:38 |
| persia | Indeed. I think I am no longer convinced that requirements tracking and effort tracking belong in the same system, but I am now convinced that each sort of notification (story, task, worklist, etc.) should have some tag (subject entry, special header, something) that lets one distinguish it for mail filtering purposes. | 12:38 |
| SotK | the in-reply-to header is in a different format for worklists, which should make it possible to filter there | 12:45 |
| persia | I think it should be more explicit than that, if possible. | 12:45 |
| persia | Perhaps "X-Storyboard-subscription-type:" or similar. | 12:46 |
| persia | Otherwise the documentation for how to filter becomes very hard to maintain. | 12:46 |
| SotK | seems sensible | 12:46 |
| persia | Zara: Does that meet your immediate needs? | 12:47 |
| Zara | I was actually thinking of all recent events, so that's also the dash. | 12:47 |
| Zara | but these also aren't needs, but preferences | 12:47 |
| persia | heh | 12:47 |
| persia | I was thinking of all subscribable events, for email. | 12:48 |
| Zara | (in fairness, if I'm like 'hm, that could be annoying', we can later get a chorus of people saying it's annoying, so I like to bring stuff up early) | 12:48 |
| persia | Filtering on the dash is more complicated in some ways (because it requires filter UI design), and simpler in some ways (because the types are already distinguished in the data representation) | 12:48 |
| * SotK doesn't really want to filter that list on the dash | 12:49 | |
| persia | Personally, I like early discussion of any potential issue: often the discussion ends up exposing other things, that can have wide-ranging implementation implications: delaying the discussions just makes it harder to do it right when the time comes. | 12:49 |
| persia | Not that all the things discussed deserve to be implemented in the upcoming "sprint" (or however folk organise their work), but rather that the discussion can be useful anyway. | 12:50 |
| SotK | I'd be happy to have a place where the full list of events can be paged through and filtered however people like, but I think that the top of the dashboard is not the place to add a filtering ui | 12:50 |
| persia | SotK: +1 | 12:50 |
| Zara | SotK: yeah, what I really want are no duplicate events, because otherwise that whole list stops being useful. so if I can subscribe to a worklist (for priority purposes) but not get notifications, that works for me anyway. | 12:51 |
| Zara | otherwise, yay since board subscriptions aren't a thing yet, but it may bite us later if we get to that | 12:52 |
| * persia hopes that potential for "duplicate" events helps nudge people towards using more automatic worklists | 12:52 | |
| SotK | I agree with persia on that | 12:54 |
| SotK | since its not really a duplicate | 12:54 |
| SotK | "changed task status" != "moved a card" | 12:54 |
| * SotK would personally find any event notifications about card moving extremely noisy and annoying | 12:55 | |
| persia | Yep. It is two distinct operations that were performed by users. That maybe only one is interesting doesn't mean that there were not both events. | 12:55 |
| Zara | I think they're not going to change their habits, just complain at us and either unsubscribe or not use the tracker | 12:55 |
| persia | Zara: I think it depends on the user, but I think the more common case will be A) only subscribe to the board *OR* the story and B) ignore the dashboard if it is noisy and use email or the board view instead. | 12:56 |
| persia | The key thing is that we cannot easily tell in advance that two distinct events are "duplicate" in the sense that they represent the same intent. | 12:56 |
| Zara | well, that's why I don't want any 'card moved' notifications, which I think SotK and I agree on :) | 12:57 |
| persia | In some cases we can guess, but we'll have both false positives and false negatives: it's only a loose heuristic (and there is a limit to the strength of the AI in browser javascript with which people will be willing to wait for the delay) | 12:57 |
| Zara | (the problem is 'card moved' = 'card left this lane' 'card joined that lane', so I want to make sure this doesn't suddenly become an issue later if people get excited about board subscription) | 12:59 |
| Zara | otherwise I track priority and get noise OR I don't, and I know I'll pick the latter, but I'd rather people not feel a need to choose between complex priority and other features just because of a way notification is implemented. | 13:01 |
| * SotK is not excited about board subscription | 13:01 | |
| Zara | phew | 13:01 |
| Zara | I hope everyone is unexcited. | 13:01 |
| persia | I think board subscription is especially uninteresting. | 13:01 |
| persia | Essentially, if one wants to track current status, one should look at the board, rather than reading mail to try to maintain an internal state. | 13:01 |
| persia | Whereas worklist subscription is interesting, because it lets one be notified "This thing is now interesting" and "that thing is no longer interesting (either complete or deprioritised)" | 13:02 |
| SotK | indeed | 13:03 |
| persia | Story subscription is interesting, because it lets one track discussion and activity regarding a specific subject. | 13:03 |
| persia | I'm not sure why task subscription is interesting, outside of the context of story subscription, but I can imagine some folk care about specific things, so want more specificity. | 13:04 |
| persia | Project and Project Group subscription are the only sensible way for people actively maintaining a project (or group) to keep track of all the activity. | 13:05 |
| Zara | the only case where I could see board subscription being interesting is for permissions (you might want to know if someone had been added as a user in case they weren't supposed to be). I'm definitely not in favour of implementing anything for that corner case; I *can* imagine someone could be put on it at some point, and this discussion mainly serves to get a nice roundup of reasons of why that's a bad i | 13:08 |
| Zara | dea. :) | 13:08 |
| persia | ACL audit logs as events could indeed be interesting, although I think it ought apply to all sorts of ACLs, and I think it is very different than content subscriptions. | 13:09 |
| SotK | the audit log will still be there | 13:10 |
| SotK | timeline events for boards exist, you just can't subscribe to be notified when there is a new one | 13:10 |
| SotK | s/one/event/ | 13:11 |
| Zara | is this documented anywhere? I feel like it would be a good thing to comment on so nobody stumbles across it and mistakenly thinks that board subscription is half implemented and needs finishing in that respect | 13:13 |
| persia | SotK: I meant that it could be interesting to have an active eventstream for ACL changes to which users could subscribe, for offline review/parsing/storage, etc. | 13:16 |
| persia | I suspect this would end up using similar infrastructure to that used for subscriptions to content, but I suspect that some of the structure isn't in place yet (and I'm not requesting this feature, just acknowledging it might be interesting) | 13:16 |
| Zara | db change seems fine to me. it now seems possible to create an event which isn't linked to anything, but seems like it'd be ott to make it be linked to something, just not specify which thing... | 13:41 |
| Zara | I do wonder if that's going to have any effect when getting an event and not specifying what resource, since I'm not sure how it decides 'hey there's not enough information here', and it looks like technically it could be a valid request now | 13:43 |
| Zara | haha, python client currently gets timeline events via stories | 13:50 |
| Zara | eg: storyboard.stories.get(1).events.get(1) | 13:51 |
| openstackgerrit | Merged openstack-infra/storyboard: Allow timeline events to be related to worklists and boards https://review.openstack.org/342263 | 13:52 |
| persia | Zara: To be fair, until the patch just merged, that was a sensible way to do it. | 13:53 |
| Zara | yep! D | 13:53 |
| Zara | *:D | 13:53 |
| Zara | well, I think we could just do worklists the same way and have a nested events manager for those (and rename TimelineEventsNestedManager to something story-specific) | 13:53 |
| Zara | it's not that pretty but I'd assume it'd work | 13:54 |
| Zara | https://git.openstack.org/cgit/openstack-infra/python-storyboardclient/tree/storyboardclient/v1/timeline.py | 13:54 |
| Zara | so change the name of the class on 39 to be story-specific, add one for worklists with the relevant parent_url_key, and then I'm not sure if the timelineevent class would need more fields or if it'd need to be a different class for each | 13:56 |
| Zara | *TimeLineEvent | 13:56 |
| Zara | there's probably a much neater way but that's the first thing that occurs | 13:56 |
| Zara | I'll wait until people are likely to miss it, anyway. :) | 14:05 |
| SotK | shouldn't need to be a different class, but will need a board_id and a worklist_id | 14:06 |
| SotK | I also should send a patch to make it possible to get events by worklist and board I guess | 14:06 |
| Zara | okay. I'm still fairly fuzzy on classes in general so I planned to start there with trial and error, hahaha | 14:06 |
| Zara | so yay | 14:06 |
| Zara | btw, it says the 'create timeline events...' patch is in merge conflict, but afaik you're reworking it anyway. | 14:07 |
| Zara | just mentioning since I'm reviewbot | 14:07 |
| *** jtomasek_ has quit IRC | 14:40 | |
| Zara | oh, https://review.openstack.org/#/c/341562/ needs re-reviewing for latest patchset | 15:51 |
| Zara | (boards search) | 15:51 |
| *** matthewbodkin has quit IRC | 16:05 | |
| Zara | oh, I just noticed that the comment preview button is a different colour to the comment button, nice | 16:07 |
| *** gary_perkins has joined #storyboard | 16:10 | |
| Zara | hi, gary_perkins! :D | 16:10 |
| * gary_perkins waves | 16:10 | |
| SotK | hey gary_perkins | 16:15 |
| Zara | oh, hm, turns out storyboard only dislikes searching numbers when they're at the start of the search string | 16:15 |
| SotK | its because it tries to do a GET for the number directly I think | 16:15 |
| persia | Interpreting the number as a story ID? | 16:16 |
| Zara | yeah, or more generally resource id | 16:16 |
| SotK | or a project id, or a project group id, iirc | 16:16 |
| Zara | egL '404: GET /api/v1/project_groups/0: Project Group 0 not found ' | 16:16 |
| Zara | *eg | 16:16 |
| SotK | (this is in the quick navigation box in the header) | 16:16 |
| Zara | yeah | 16:16 |
| Zara | so actually, browse, not search | 16:16 |
| Zara | until now I thought it just didn't like numbers for some reason, so hey, that's way less bad. | 16:17 |
| Zara | oh, and https://review.openstack.org/#/c/279753/ passes linting now | 16:19 |
| Zara | I'd really prefer to land https://review.openstack.org/#/c/341562/ first, though | 16:19 |
| persia | You could use Depends-On: :) | 16:19 |
| Zara | yeah, it works without it so it's not a hard dependency | 16:20 |
| Zara | it's just that it's much nicer with a boards search that searches better | 16:20 |
| Zara | I'm really not sure how the user filter applies | 16:20 |
| Zara | and actually, looking at it now, I'm inclined to take projects out because it's misleading (implies they are related to boards in the api) | 16:21 |
| Zara | I thought it wouldn't make much difference, but when actually searching it's weird to have it as an option | 16:21 |
| Zara | since it will always give an empty list of results | 16:21 |
| Zara | I'll fix that now then | 16:27 |
| Zara | (I've just removed the 'project' line from the resource) | 16:31 |
| Zara | ugh, my rebase went weird | 16:35 |
| Zara | lost connection earlier, will fix ;_; | 16:35 |
| Zara | huh, we've lost gerritbot! | 16:36 |
| Zara | when did we lose it? | 16:37 |
| * SotK has no idea | 16:37 | |
| * Zara asks in #infra | 16:38 | |
| pleia2 | openstackgerrit is here | 16:38 |
| * SotK wonders why its so quiet | 16:39 | |
| Zara | pleai2: yeah, it's in the channel, just didn't update with the last few patches (and I was wrong, we last saw it 13:52 UTC today) | 16:39 |
| Zara | I only just noticed because I sent those and they showed up in #infra, but it might have been quiet for a while | 16:40 |
| Zara | pleia2: do you know what might be going on? | 16:42 |
| pleia2 | no, it seems to be working ok in other channels :\ | 16:42 |
| Zara | :/ I don't think we've done anything weird today | 16:42 |
| SotK | it sometimes does this in here, idk why | 16:43 |
| Zara | oh well, it's not urgent, just as long as I'm aware | 16:47 |
| Zara | I updated the boards search patch, anyway | 16:47 |
| Zara | projects aren't in it any more | 16:47 |
| Zara | https://review.openstack.org/#/c/341562/ is in need of +1s, if anyone wants to take a look | 17:08 |
| Zara | I'm heading home soon | 17:08 |
| * Zara discovers that pagination is broken for the admin page listing users | 17:19 | |
| Zara | \o/ | 17:19 |
| Zara | (increasing the total works fine, you just can't get to the next page.) | 17:19 |
| Zara | suspect it's gone unnoticed because it's not used much | 17:19 |
| Zara | so not mega urgent, will investigate tomorrow | 17:19 |
| *** alexismonville has joined #storyboard | 19:41 | |
| *** alexismonville has quit IRC | 22:47 | |
| *** alexismonville has joined #storyboard | 23:05 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!