19:02:08 <zara_the_lemur__> #startmeeting storyboard
19:02:09 <openstack> Meeting started Wed Jan  4 19:02:08 2017 UTC and is due to finish in 60 minutes.  The chair is zara_the_lemur__. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:02:13 <openstack> The meeting name has been set to 'storyboard'
19:02:27 <zara_the_lemur__> #topic Announcements
19:02:36 <zara_the_lemur__> I have nothing listed
19:02:39 <zara_the_lemur__> HOWEVER
19:03:04 <zara_the_lemur__> SotK's patch to list teams that can access private stories has finally gone in!
19:03:22 <zara_the_lemur__> so this means that you no longer need to list who can view a private story user-by-user
19:03:36 <diablo_rojo_phon> Hello :)
19:03:42 <zara_the_lemur__> but can make a team once, and then give that team access wherever
19:03:46 <zara_the_lemur__> hi, diablo_rojo_phon!
19:04:24 <zara_the_lemur__> It's been in-progress for forever so I decided it was worthy of an announcement
19:04:28 <zara_the_lemur__> #topic urgent items
19:04:32 <zara_the_lemur__> Nothing I'm aware of
19:04:44 <zara_the_lemur__> we're ticking along
19:04:50 <zara_the_lemur__> #topic #In-progress work
19:05:05 <zara_the_lemur__> for some reason I'm putting hashes everywhere...
19:05:15 <fungi> SotK: thanks for group visibility for private stories! that will be a huge help to the vmt
19:05:39 <zara_the_lemur__> +1
19:06:09 <zara_the_lemur__> I've tested it, but it'll be good for people to try it out on things that aren't super-critical first, in case we've missed anything
19:06:11 <betherly> Brill!
19:06:36 <zara_the_lemur__> :)
19:07:01 <zara_the_lemur__> in other news... in a fit of desperation, I rechecked jeblair's patch to put tags in the task filter
19:07:09 <zara_the_lemur__> (So that we can filter tasks by story tag)
19:07:14 <zara_the_lemur__> and apparently it just needed a recheck
19:07:18 <zara_the_lemur__> well, a fourth recheck
19:07:36 <zara_the_lemur__> so that has fiiiiinally been merged, after probably-more-than-a-month-I-don't-even-want-to-look
19:08:08 <zara_the_lemur__> (that's in the api)
19:08:16 <fungi> oh nice
19:08:28 <fungi> so now we can filter tasks by story tag?
19:08:55 * zara_the_lemur__ goes to find patch
19:09:47 <zara_the_lemur__> #link https://review.openstack.org/#/c/404978/
19:10:00 <zara_the_lemur__> so yeah, for worklists
19:11:20 <zara_the_lemur__> so hopefully we'll need fewer workaround scripts for boards as time goes on.
19:11:31 <zara_the_lemur__> other in-progress things...
19:11:49 <zara_the_lemur__> I made yet another fresh StoryBoard install this weekend, so have updated some of the install docs
19:11:53 <zara_the_lemur__> nothing very exciting there
19:12:09 <zara_the_lemur__> #link https://review.openstack.org/#/c/415996/
19:12:21 <zara_the_lemur__> #link https://review.openstack.org/#/c/415942/
19:13:08 <zara_the_lemur__> and have submitted a 'fix' for a private stories bug; 'fix' in quotes since it fixes the problem but the logic isn't what we should really be doing
19:13:11 <zara_the_lemur__> #link https://review.openstack.org/#/c/416070/
19:13:25 <zara_the_lemur__> well, it's better than what was there before as far as I could tell, anyway
19:13:58 <zara_the_lemur__> so those are some patches awaiting reviews
19:14:17 <zara_the_lemur__> we also have some general maintenance patches awaiting review
19:14:28 <zara_the_lemur__> #link https://review.openstack.org/#/c/415493/
19:14:44 <zara_the_lemur__> #link https://review.openstack.org/#/c/415494/
19:15:05 <zara_the_lemur__> aaaand we are still using login.launchpad.net instead of login.ubuntu.com but I don't know how to even start changing the database for that.
19:15:53 <fungi> on 416070, i wonder why not just always make stories visible to the creator? it's not like hiding a story from its creator serves to create any additional security/secrecy (except maybe hiding later comments from them, not sure what the use case is though)
19:16:38 <fungi> on the login.ubuntu.com front, it's just a db query we'll need to run (probably an etl script like the one mordred wrote for gerrit)
19:16:45 <persia> A potential use case is to hide later comments/updates in the event that a story is private to a company, and the creator changes employment.
19:17:23 <fungi> so instead of always making it visible to the creator in perpetuity, just make it visible to teh creator by default unless they're removed?
19:17:37 <persia> I believe that is already in place.
19:17:41 <zara_the_lemur__> yeah, that's the idea (and that is our current default)
19:17:46 <clarkb> oh hey this is topical on the internet now
19:18:24 <zara_the_lemur__> (the problem atm is that it's possible to remove *everyone* from a story :D)
19:18:24 <clarkb> some ham radio software company used such features in whatever ticketing system they were using to remove evidence of being mean to their customers
19:18:25 <fungi> zara_the_lemur__: aha, got it. so the "fix" is to prevent them from removing themselves without having at least one other user able to view it
19:18:30 <zara_the_lemur__> yeah
19:18:34 <clarkb> and then the Internet found out and got mad
19:19:33 <zara_the_lemur__> that sounds interesting
19:19:44 <persia> clarkb: The internet will always find out, but from the perspective of most product managers, having that take three months can be a critical difference between being willing to use a common tracking system, and maintaining an internal JIRA (or whatever).
19:19:56 <clarkb> persia: oh sure its not the tracking systems fault
19:20:06 <clarkb> its just an interesting story of the past couple weeks directly related to such features
19:20:10 <zara_the_lemur__> (think I found the article, will read)
19:20:25 <fungi> also this same sort of thing crops up all the time with web forums where the company maintaining it decides to hide things they find embarrassing
19:20:29 <jeblair> our ticketing system has a 3-month fire rating!
19:20:48 <fungi> and then stuff leaks and... yeah
19:21:02 <fungi> it's more of a policy question than a feature question
19:21:44 <zara_the_lemur__> yeah, down the line it's worth considering who can make stories private
19:21:51 <persia> From a feature perspective, I think it is useful to be able to embargo things to arbitrary groups.  From a policy perspective, I think that people collaborating in a large public open-source project would do well not to behave in ways that could cause later leaks to be embarassing.
19:22:09 <fungi> my sentiments as well
19:22:45 <fungi> anyway, it's feature parity with lp's private bug handling and we're not seeing widespread issues there, so i'm not concerned really
19:22:59 <persia> There's still the odd corner case where one can set the permissions of a story to only be readable by a group that contains no members, just in case people are poking the corners of this.
19:23:29 <zara_the_lemur__> (right, and for now I'm fairly confident that if a company starts trying to hide things that were previously public all over storyboard, to hide bad behaviour, infra can say 'erm what?' and revert it.)
19:23:52 <fungi> persia: though in that corner case, someone can still readd users to the group in question, the story is not completely unreachable
19:23:56 <persia> zara_the_lemur__: Do SB admins have access to private stories, or only DB admins?
19:24:06 <zara_the_lemur__> DB admins
19:24:14 <persia> fungi: Ah, thanks for pointing out that.  It makes me less worried about the current state :)
19:24:44 <fungi> (unless i'm misunderstanding the privacy/data model)
19:24:53 <persia> I think you understand correctly
19:25:30 <fungi> i still haven't had time to play around with how user groups are managed
19:25:31 <zara_the_lemur__> (SB admins can add/remove people to/from teams; DB admins can see anything in StoryBoard as far as I'm aware)
19:25:40 <zara_the_lemur__> it'd be good to get more eyes on it
19:26:28 <fungi> yeah, db admins are always going to have access to everything (at least everything stored persistently in the db)
19:27:03 <zara_the_lemur__> yep
19:27:46 <zara_the_lemur__> so with the model atm, theoretically a sb admin could add themselves to a team and by that method gain access to things they can't see by default
19:28:25 <zara_the_lemur__> I don't yet know whether that's an issue, since I don't know how sb admins would be decided; if they're a subset of db admins then it's fine
19:28:25 <fungi> which is also true of lp, so again not concerned with that design choice
19:28:28 <zara_the_lemur__> cool
19:28:44 <persia> Generally speaking, if one can't trust the DB admins or the SB admins ,they probably shouldn't be using that SB instance.
19:29:13 <fungi> in lp in fact, you basically have project-specific admins and group-specific admins. so it boils down to trusting people in the groups to which you're delegating access anyway
19:29:46 <fungi> though i'm sure lp also has server-wide admins who can do those things, i'm just not one
19:30:17 <persia> My understanding is that there are several classes of wider LP admin permissions, but that becomes an implementation detail.
19:30:18 <zara_the_lemur__> great, if you're confident that it has feature-parity then that should be fine
19:31:03 <fungi> to reduce burden on the sb admins, it may make sense in the future to extend the group schema to incorporate group-specific admins or the ability for groups to self-manage their memberships
19:31:28 <fungi> but that doesn't strike me as a blocker
19:32:33 <zara_the_lemur__> +1
19:33:19 <zara_the_lemur__> plus, you have permissions for teams, who's on the list of admins who can assign members of groups admin permissions over the groups
19:33:25 <zara_the_lemur__> *plus if you have
19:33:58 <zara_the_lemur__> could get a bit infinite-regress-y
19:34:02 <jeblair> self-management has worked out really well in gerrit (it's optional -- a group has an owner, which is another group.  that could be an admin group if you want top-down management, or it could be the group itself if you want self-management)
19:34:51 <jeblair> zara_the_lemur__: that sounds adaptable to what you said -- maybe if you can acl management of a group to itself...
19:34:59 <persia> That seems a reasonable model, assuming the users don't make long nested loops.
19:35:13 <persia> Is there a story about that already?
19:35:18 <zara_the_lemur__> ah, so teams within teams?
19:35:35 <zara_the_lemur__> I suspect there isn't a story yet
19:35:49 <zara_the_lemur__> I think it's come up on irc before, vague memories of discussing it
19:35:57 <zara_the_lemur__> very vague, possibly imaginary
19:36:01 <fungi> zara_the_lemur__: not so much teams within teams as teams controlled by a team (which could be itself in some circumstances)
19:36:18 <persia> I read teams-within-teams is separate from team-owner-is-a-team(can be self).
19:37:26 <fungi> gerrit does also have teams-within-teams (you can specify a team to include other teams as members), and yes gerrit seems to have loop detection built in to handle that
19:37:55 <fungi> we have lots of examples of group inclusion loops in gerrit already, and there is even a recursive membership query in its api which dtrt with those loops
19:38:20 <zara_the_lemur__> I might be phrasing it badly, the only model I currently have for this would be something like linux user groups, so that membership of one group could depend on membership of another group (so a group acts like a subset of another group, but it's not the groups that are nested, but the membership status, if that makes sense)
19:39:09 <zara_the_lemur__> anyway, cool, there are ideas around it and people can see ways of doing things if we need it; I think that's promising :)
19:39:52 <persia> zara_the_lemur__: That matches my understanding (ignoring that I don't see linux groups that way), that for a given user, they are a member of  group directly, or they are a member of a group indirectly (because a group in which they are a member is a member of the indirect group)
19:41:06 <zara_the_lemur__> heh, that sounds different to mine but this meeting probably isn't the best time to work out if we're picturing the same thing or not; we should probably continue it later :)
19:41:23 <zara_the_lemur__> we only have about 20 mins left so probably best to move onto open discussion
19:41:24 * fungi apologizes for the tangent
19:41:37 <zara_the_lemur__> #topic open discussion
19:42:02 <zara_the_lemur__> Now everyone can go on tangents and I won't have a vague sense of guilt :)
19:42:31 <zara_the_lemur__> also, goodness, I said 'probably' a lot there
19:43:20 <diablo_rojo> probably is a good word
19:43:29 <zara_the_lemur__> :)
19:43:42 <fungi> i probably agree, probably is probably a good word
19:44:46 <zara_the_lemur__> on that note, I will probably try to get PTG attendance sorted out this week
19:45:50 <fungi> so i guess if we're short on other open discussion topics... gerrit's documentation has a bit to say about its group management which may be worth skimming
19:45:55 <fungi> #link https://gerrit-review.googlesource.com/Documentation/access-control.html#_account_groups
19:46:42 <zara_the_lemur__> cool, thanks
19:47:20 <fungi> it's pretty terse, but does a good job of explaining their model
19:49:13 <zara_the_lemur__> yeah, at a glance it looks clear
19:52:11 <zara_the_lemur__> anyone with any other topics?
19:52:13 <zara_the_lemur__> we have 8 mins
19:52:34 <fungi> i've got nothing else, other than a huge thank-you to everyone who works on storyboard
19:52:48 <fungi> you're building amazing stuff
19:53:23 <zara_the_lemur__> :D well, in turn I send a huge thank-you to everyone who works on the openstack infra!
19:54:57 <zara_the_lemur__> it's nice working on a project where review etc is so straightforward
19:55:37 <zara_the_lemur__> and, of course, the CI :)
19:56:55 <zara_the_lemur__> we have 4 mins left for everyone to compliment each other if they want
19:57:01 <zara_the_lemur__> 3 mins now
19:57:32 <jeblair> zara_the_lemur__: that's some first class counting down!
19:57:47 <zara_the_lemur__> :D
19:58:00 <zara_the_lemur__> you have some excellent hats!
19:59:56 <zara_the_lemur__> YOU ARE ALL FANTASTIC
19:59:58 <zara_the_lemur__> #endmeeting