14:01:30 <ttx> #startmeeting next-tags-wg
14:01:31 <openstack> Meeting started Fri Jul 17 14:01:30 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:34 <openstack> The meeting name has been set to 'next_tags_wg'
14:01:45 <ttx> #link https://etherpad.openstack.org/p/next-tags-wg
14:02:30 <ttx> OK, so for this first meeting I'd like to discuss a bit on the long-term goals, and then on a few short-term targets
14:02:38 <sdague> sounds reasonable
14:02:39 <ttx> anything you would like to discuss ?
14:03:00 <ttx> Let's start with that and we can add more
14:03:14 <ttx> #topic Long-term goals
14:03:52 <ttx> I guess the main objective is to cover things that were covered before by integration requirements / integrated release meanings
14:04:05 <zaneb> +1
14:04:12 <russellb> ttx: o/
14:04:36 <ttx> doesn't mean we should not also address nice-to-communicate things, but we should at least cover most of the things there
14:04:50 <ttx> I tried to list those two sets on the etherpad, to varying degrees of success
14:05:15 <ttx> As far as "facets of the integrated release" go, we are not that bad:
14:05:37 <ttx> "Released together" and "managed release" is covered by release:* tags
14:05:43 <zaneb> I think some of the requirements on the checklist were sufficiently woolly that it would be ok for us to eliminate them from contention as tags quite quickly
14:05:54 <ttx> there was an expectation of co-gating... not sure we can qualify that
14:06:06 <ttx> sdague: ideas on this one ?
14:06:19 <zaneb> imho that one is out of date
14:06:21 <sdague> yeh, I don't think we need to bring forward everything, we can reevaluate what's useful in bigtent world
14:06:27 <russellb> hm ... we can certainly create "co-gating groups" and tag them ... but not sure that's useful anymore
14:06:33 <ttx> agreed
14:06:37 <zaneb> but sdague full_stack_testing idea might be an equivalent
14:06:40 <russellb> since the "single co-gate to rule the world" doesn't seem to be the thing anymore
14:06:50 <sdague> ttx: I think co-gating is not really useful, that's why I proposed the full stack testing bit
14:06:57 <ttx> ack
14:06:59 <russellb> yeah full-stack testing is interesting
14:07:23 <ttx> "Supported by OpenStack horizontal efforts" -> it's pretty much up for each team to come up with their *:suported variant
14:07:25 <sdague> zaneb: yeh, I tried to walk out the real meaning of what was wrapped up in gate, and tempest, and just say "we build a cloud with our component and test it for real on every commit"
14:07:26 <russellb> testcoverage:crap
14:07:27 <russellb> heh
14:07:35 <ttx> starter kit we covered
14:07:35 <zaneb> sdague: +1
14:07:51 <ttx> stability I have a few suggestions we'll talk abvout
14:07:59 <ttx> maturity is a bit harder
14:08:16 <zaneb> yeah, I don't think maturity can be a tag
14:08:17 <ttx> for that one I'd like to see what the ops team comes up with in their data
14:08:29 <sdague> yeh, maturity seems too nebulous
14:08:48 <ttx> any missing "meaning" of the integrated release you'd like to add to list ?
14:09:26 <ttx> if not we can skip to old graduation requirements
14:09:35 <sdague> I assume the supported python thing is just going to be expressed by trove categorization in setup.cfg
14:09:39 <ttx> which cover a few specific things
14:10:18 <ttx> Do we agree that "absence of scope duplication" is no longer applicable ?
14:10:24 <zaneb> yes
14:10:45 <ttx> next two are covered in the suggestions
14:10:45 <sdague> yep
14:10:54 <ttx> "diverse core reviewers team (more than 4 people)"
14:11:05 <ttx> that one is interesting, since no team: tag has been proposing that at all
14:11:29 <ttx> good to keep in mind that it was there, I don't think that's a top prio though
14:11:41 <russellb> re: scope, our new project requirements mention it, and we've used it before when discussing applications, so i'm ok with how that covers my concerns
14:11:48 <russellb> can't think of a tag there
14:11:51 <russellb> (sorry i'm behind)
14:12:22 <russellb> team tags are relatively low hanging fruit since we can script most of them against stackalytics
14:12:26 <ttx> "enforce a minimum of 2 +2s before accepting a change" -- is that a current project team requirement ?
14:12:26 <sdague> honestly, I think russellb's diverse team covers the basic points there, though I do think diverse danger needs to expose somewhere, as we've had a lot of 90%+ one org projects lately
14:12:48 <ttx> if not, is it something of value for our users ?
14:13:00 <sdague> I think our users probably don't care
14:13:16 <russellb> and i like to think of "2 +2s" as a guideline, not a rule anyway
14:13:24 <russellb> plenty of cases rubber stamping things in by 1 person is fine
14:13:24 <zaneb> ttx: that's _almost_ part of the 'are you one of us' test imho
14:13:26 <sdague> that's cultural expectations and we enforce there instead
14:13:29 <russellb> or cases where several +2s should be had
14:13:46 <russellb> culture handles it well enough, agree
14:13:54 <ttx> the rest are QA/Doc metrics imho and we'll likely redefine them, no need to go through them one by one...
14:13:59 <zaneb> (not disagreeing with russellb though, for the record)
14:14:06 <ttx> unless there is one you want to discuss...
14:14:47 <ttx> If not let's skip to short-term targets
14:14:55 <zaneb> history of triaging bugs/user support is probably not something we need tags for
14:15:03 <zaneb> might be better suited to the ops effort
14:15:10 <zaneb> whatever we're calling that
14:15:15 <ttx> zaneb: yes, feels moere like a rating
14:15:21 <zaneb> exactly
14:15:22 <ttx> "you suck at bug triaging"
14:15:44 <ttx> ok, next tags then
14:15:51 <ttx> #topic Short-term targets
14:16:15 <ttx> One that was mentioned by several people are the integration tags, starting with devstack
14:16:29 <ttx> sean / sdake proposed in_devstack and/or has_devstack_plugin
14:16:34 <russellb> i can take on the team tags
14:16:42 <ttx> I tend to be with zaneb, not sure the distinction is that valid
14:16:52 <russellb> size, and "diversity danger"
14:16:57 <sdake> sdague ttx you mean?
14:17:09 <sdake> rather ttx do you mean sdague?
14:17:14 <sdague> ttx: so the reason the distinction is valid, is that it actually is another thing the user would need to do
14:17:20 <zaneb> it was sdague and stevebaker iirc
14:17:27 <russellb> sdague: get the plugin you mean?
14:17:29 <sdake> ya not me, ok thanks bye guys :)
14:17:36 <zaneb> sdake: too many steves. as you were.
14:17:40 <sdague> russellb: right, specify "enable_plugin" for that component
14:17:43 <ttx> sdague: oh ETOOMANYSTEVES
14:17:48 <ttx> sdake: ^
14:17:52 <sdake> roger
14:17:53 <russellb> yeah, i guess so, not sure that's worth a tag
14:17:53 <sdague> so my lean was to be specific about it
14:17:54 <sdake> i'm off :)
14:18:02 <russellb> more like a tiny section in the project's docs
14:18:16 <russellb> but i don't have a strong opinion against it or anything
14:18:27 <sdague> sure, we can always break it out later if people are confused by it
14:18:45 <sdague> call it devstack_support
14:18:49 <sdague> or something
14:18:52 <ttx> yeah, trying to see if that piece of info is significant enough to justify learning another word
14:19:03 <russellb> "works with devstack" is good info though
14:19:15 <ttx> would have been a use case for attribute but I killed those last week :)
14:19:26 <zaneb> russellb++
14:19:29 <russellb> could also extend to "works with <other deployment thing in openstack>
14:19:39 <sdague> sure, there are a bunch of projects that have random directories and copy instructions, those projects would not get that tag
14:19:42 <russellb> "works with tripleo", "works with fuel",
14:19:52 <ttx> so the model we come up with there is likely to be reused for horizon
14:19:57 <sdague> because we really want everyone to do it in the documented way, so the user doesn't have to learn a massively manual thing
14:20:13 <russellb> yeah devstack plugin is pretty easy to do
14:20:17 <sdague> yep
14:20:21 <ttx> i.e. we wouldn't distinguish between "has horizon support" built-in / as-plugin
14:20:52 <ttx> I'm fine with that
14:20:58 <russellb> does it matter if a thing is supported directly by (devstack|horizon|whatever) or the team itself provides the support?
14:21:21 <zaneb> ttx: my understanding from david-lyle is that Horizon doesn't want there to be two kinds of plugins long-term anyway
14:21:24 <russellb> angle being about who provides the thing
14:21:48 <ttx> zaneb: agree in-tree / plugin / module is more of an implementation detail
14:22:07 <sdague> ttx: it is, until we figure out who supports what
14:22:21 <ttx> should we have a common prefix for all those "supported in", "works with", "integrated with"  things ?
14:22:37 <zaneb> my take on this is that I'd like all of the projects on that list to work toward eliminating that distinction over time, and separate tags just tends to reinforce that distinction
14:22:38 <sdague> honestly, I don't feel too strongly either way, but it is worth figuring out if we are going to confuse folks
14:22:56 <sdague> zaneb: eliminate what distinction?
14:23:00 <russellb> i guess this does get into the idea of project relationships
14:23:08 <zaneb> sdague: between in-tree and out-of-tree plugins
14:23:18 <russellb> which is actually interesting info
14:23:23 <sdague> zaneb: there is a distinction on support
14:23:52 <sdague> the reason for creating an out of tree plugin interface is the fact that we can't scale if every horiz effort has to own all the concept for the tent, so they provide a contract instead
14:24:20 <zaneb> sdague: oh, yeah, I'm not saying everyone should go to in-tree for everything
14:24:21 <sdague> magnum has a devstack plugin, I'm not going to support that
14:24:34 <sdague> I will support the contract that lets them do that
14:25:36 <sdague> and the question is whether that's useful for our user community to get here
14:25:46 <sdague> or if they figure that out via other means
14:25:47 <zaneb> sdague: I'm more saying that if e.g. Nova's DevStack plugin was also out-of-tree, you can be sure that somebody will make it super-easy to pull in out-of-tree plugins :)
14:26:02 <zaneb> so treat all plugins equal
14:26:06 <russellb> it's quite easy today
14:26:21 <russellb> but sort of an aside :)
14:26:23 <sdague> zaneb: yeh, look at the interface today, we didn't need that to make it easy :)
14:26:56 <zaneb> sdague: well, as you said before, it's an extra step for the user
14:27:05 <zaneb> if everything is the same, there's no extra step
14:27:06 <russellb> 1-liner in local.conf ... enable_plugin networking-ovn http://git.openstack.org/openstack/networking-ovn
14:27:08 <sdague> it's 1 line of config
14:27:11 <zaneb> that's just how you do it
14:27:38 <ttx> right, the two things the distinction would communicate are: "who supports the integration" and "it may require an extra install step"
14:27:54 <zaneb> and I'm not just talking about devstack, I'd like this for all projects on that list
14:28:06 * russellb nods
14:28:06 <zaneb> but anyway, we're getting a bit off-topic
14:28:11 <sdague> sure, though I guess we're wandering a bit
14:28:41 <sdague> I guess the 'todo later' is probably an expectation on projects about what we'd expect out of them providing a plugin interface
14:28:42 <russellb> we should ponder this a bit more ... not sure we've nailed an idea yet
14:28:52 <ttx> I won't fight strongly either way. We could let the color decision to whoever goes and draft that one
14:29:00 <ttx> I still think we need a common prefix those
14:29:03 <ttx> for those*
14:29:16 <ttx> but we can also bikeshed that common prefix name another day
14:29:27 <zaneb> yeah, I think it's a discussion for the TC
14:29:31 <zaneb> +1 for a common prefix
14:29:43 <zaneb> could we even propose all the tags in one review?
14:29:54 <zaneb> that would save a *lot* of time :)
14:30:05 <ttx> We could, but in practice the smaller the change, the faster it gets in
14:30:07 <sdague> I think coordinating the rest of the english would be a bit hard
14:30:24 <sdague> I'll write up the devstack plugin thing on the plane to MN on Monday
14:30:29 <ttx> ok
14:30:42 <sdague> and people can hate on terms until we find something that works for people
14:30:44 <ttx> #action sdague to draft *:*devstack* tag(s)
14:30:44 <zaneb> ok, so maybe start with a pilot and copy-paste once it has been wordsmithed to death?
14:31:24 <ttx> Next category, team tags
14:31:40 <ttx> We mentioned two in the brainstorming
14:31:55 <ttx> One is team size, projects that are >60% developed by just one person (or 95% developed by just 2) are a bus factor risk
14:32:13 <ttx> (your threshold may vary)
14:32:29 <zaneb> team:omnibus-proof
14:32:32 <ttx> the other is the diversity-danger one, or Team monoculture
14:32:38 <russellb> developed and/or reviewed by
14:32:56 <ttx> So while I agree those are negatiuve tags, I think they provide value to our users as such
14:33:07 <ttx> we are answering the "will the project be there tomorrow" question
14:33:11 <zaneb> I'd prefer we have tags for positive things
14:33:28 <zaneb> e.g. <nothing>, collaboration, community
14:33:39 <sdague> zaneb: sure, but I think the 100% one org thing is a challenge
14:33:46 <zaneb> vs. monoculture, <nothing>, community
14:33:47 <sdague> we're getting a lot of monoculture projects
14:33:52 <ttx> zaneb: I feel like a "decent-diversity" tag is less of an answer than "danger-will-robinson-is-alone-coding" one
14:33:52 <russellb> 100% one org thing doesn't sound like openstack
14:33:59 <russellb> :/
14:34:16 <russellb> lack of diversity in a young project is often expected
14:34:16 <sdague> well, I think the monoculture bit is bad enough we want to call people on it
14:34:19 <ttx> russellb: right, and I don't mind using a negative tag to call that long-term
14:34:20 <zaneb> sdague: totally agree there needs to be a separation between those first two levels
14:34:23 <russellb> but in large established one, huge concern
14:34:35 <sdague> russellb: yes, agree, so having the negative association with it is good
14:34:40 <zaneb> ok, here's my reasoning...
14:34:43 <sdague> some times you also need sticks, not just carrots
14:34:43 <ttx> it's something to fix
14:34:52 <russellb> i prefer carrots though :)
14:34:58 <ttx> *and* a useful bit of info for users
14:35:09 <sdague> russellb: agree, sticks are hard to make coleslaw out of
14:35:12 <zaneb> it's hard to distinguish between 'doesn't have this tag' and 'nobody bothered to apply this tag' for users
14:35:13 <russellb> lol
14:35:30 <russellb> but let's get specific ... consider the fuel case vs. a project that just got launched by a few devs at <company> 2 weeks ago
14:35:34 <ttx> russellb: I agree we shouldn't have sticks for the sake of it, but if they provide an answer to users questions, then they are good tags
14:35:41 <russellb> one of those deserves to be called out, the other maybe not
14:35:53 <zaneb> if there's no incentive for the team itself to come to the TC and ask for the tag to be applied, it could slip through the cracks
14:36:00 <ttx> russellb: the other needs to know it needs to work on it though
14:36:04 <zaneb> i.e. requires vigilance on the part of the TC
14:36:05 <russellb> ttx: true
14:36:16 <sdague> zaneb: stuff like this are pretty automatic though
14:36:29 <sdague> russellb already has a tool for the diverse team tag
14:36:30 <zaneb> positive tags offload the vigilance onto the teams that benefit
14:36:54 <ttx> zaneb: but I think an absent tag is less of an incentive than the presence of a negative one
14:37:14 <sdague> I also think it's fine that the TC has to be a bit vigilent in keeping an eye that projects are living up to what they said
14:37:31 <zaneb> sdague: fair
14:37:48 <zaneb> another option would be to just change the way we display them
14:38:06 <ttx> I think tags should convey meaning, not absence of tags. Here we care if a team is diverse, or if it's a monoculture. We don't care if it's "moderately diverse"
14:38:07 <zaneb> i.e. no team tag -> big 'monoculture' banner
14:38:25 <ttx> so we do a diverse and monoculture tag
14:38:35 <ttx> not a "diverse" and "almost diverse" one
14:39:04 <ttx> tags are affirmations. Trying to use combinations (AND / NOT / OR) wasn't a great success on the release:tags
14:39:10 <zaneb> "diverse" and "not-monoculture"? ;)
14:39:26 <zaneb> I'm relaxed, I don't think this is a big deal
14:39:30 <zaneb> just wanted to discuss it
14:39:30 <ttx> we had to refactor them to be clearer affirmations
14:39:58 <sdague> I feel on the team thing it's important enough to call it out as a bad thing, we really want all projects to end up diverse for long term health of our community.
14:40:03 <ttx> russellb: I take it you will work on those ?
14:40:42 <russellb> yep
14:40:45 <ttx> (small-team and monocultural-team)
14:40:54 <russellb> i'll start with team size, i think that's less controversial
14:41:02 <ttx> OK, so you should draft those and will re-debate
14:41:05 <ttx> we'll
14:41:05 <russellb> and then the anti-diversity one
14:41:07 <zaneb> sdague: totally agree we should call it out somehow
14:41:08 <russellb> yep
14:41:25 <ttx> #action russellb to draft small-team and monocultural-team tags
14:41:58 <ttx> Next category is a bit of a refactor
14:42:09 <ttx> It's things that answer expectations
14:42:22 <ttx> so timeline for deprecation of features / APIs
14:42:38 <russellb> good stuff
14:42:42 <ttx> forward-compatible config files
14:42:48 <ttx> rolling upgrades
14:42:56 <russellb> important technical bars we want projects to explicitly ACK that they meet
14:43:01 <ttx> right
14:43:15 <ttx> those are things projects opt to do
14:43:15 <zaneb> defining 'support' for rolling upgrades could be tricky?
14:43:20 <ttx> contracts that they sign
14:43:24 <russellb> zaneb: yep :)
14:43:31 <ttx> obligations that they put onto themselves
14:43:46 <ttx> so yeah, rolling upgrades is a slightly different duck there
14:44:03 <sdague> zaneb: yeh, so I think that for something like that, a team says they do it, and we expect them to have a prominent document describing what that means
14:44:04 <russellb> basically it gets into what kind of downtime is required for upgrades]
14:44:05 <zaneb> so we're saying that individual project teams will be responsible for assigning these tags to themselves (+1 btw)
14:44:08 <zaneb> ?
14:44:18 <russellb> zaneb: +1, with a sanity check
14:44:29 <russellb> hopefully with a pointer to a doc that explains it
14:44:38 <russellb> and we read it over and say "yep, seems sane"
14:44:49 <zaneb> that sounds perfect to me
14:44:59 <ttx> I think those will be the most useful things
14:45:00 <sdague> russellb: I think pointer to doc is required for stuff like this, and should be part of what is in the tag description document
14:45:04 <russellb> sdague: ++
14:45:27 <ttx> currently, good luck to tell what's the deprecation policy is for project Y
14:45:30 <sdague> stuff like this is going to take time to get right on the tag proposal, it was the kind of stuff that I want to see, but was punting on :)
14:45:54 <ttx> right, I think we'll do them one by one. I want to work on the deprecation policies, it's long overdue
14:45:59 <russellb> yep, one at a time ... we'll build up a nice set over time
14:46:20 <ttx> if someone wants to work in parallel on one of the others I'm cool with that
14:46:26 <russellb> ttx: yeah, you had a nice write-up on API deprecation at one point that would be a good basis
14:46:32 <russellb> in a thread a long time ago ..
14:46:36 <russellb> about keystone v3 iirc
14:46:56 <ttx> yeah, that one would likely be the middle policy
14:47:12 <ttx> (between "never ever" and "f*ck you")
14:47:15 <russellb> lol
14:47:22 <russellb> "reasonable middle ground"
14:48:01 <ttx> #action ttx to draft Deprecation policy contract tag
14:48:15 <zaneb> I can take the no-config-change one. that sounds simple enough
14:48:56 <russellb> sounds good :)
14:48:58 <ttx> zaneb: ideally it should describe how to do it right
14:49:12 <ttx> so that people don't get to guess :)
14:49:21 <ttx> OK, last but not least
14:49:22 <ttx> QA tags
14:49:35 <ttx> I'll let sdague detail fullstacktesting
14:49:36 <zaneb> I shall troll the ML for sdague's wisdom on that subject :)
14:49:43 <sdague> zaneb: heh
14:49:45 <zaneb> er, trawl
14:50:04 <ttx> My main question is whether we should bundle them or separate them
14:50:16 <sdague> ttx: bundle which?
14:50:30 <russellb> tag-per-testing-type vs. "well-tested" ?
14:50:33 <ttx> i.e. qa:awesome or a bunch of qa:upgrade-tested, qa:unit-tested
14:50:36 <ttx> right
14:50:54 <sdague> qa:awesome runs us into the subjective space we were trying to avoid, right?
14:51:01 <ttx> i.e. you could either describe a set of constraints or have a tag for each
14:51:22 <sdague> honestly, upgrade-testing is only done by about 25% of our projects
14:51:27 <russellb> qa:objective-gold-star
14:51:43 <sdague> so I think being a separate tag is good
14:51:46 <ttx> sdague: I don't think qa:awesome is more subjective
14:51:48 <zaneb> qa:upgrade-tested seems like a useful, objective tag
14:51:58 <sdague> because, honestly, some projects might not feel they need it
14:52:06 <sdague> their community is young, and people are fine without it
14:52:21 <sdague> full-stack-testing, same thing
14:52:23 <ttx> if QA:A means your QA does A and QA:B means your QA does B... qa:awesome would just mean your QA does A and B
14:52:34 <sdague> it could
14:52:40 <zaneb> sdague: and that's ok, as long as it is explicit to users
14:52:40 <sdague> but tags are cheap, right?
14:52:44 <ttx> i.e. you would describe what is needed to get the QA:awesome label
14:52:46 <sdague> zaneb: right, exactly
14:53:04 <ttx> sdague: sure. the question is more, what user question does it answer ?
14:53:08 <sdague> I think that was the biggest issue on the old integration requirements and the angst we saw
14:53:29 <sdague> because the requirements were one size fits all, but the project landscape is diverse
14:53:59 <ttx> sdague: ok, if you think there is no such thing as an overall "QA" state no point in bundling them
14:54:03 <sdague> ttx: it answers "can I expect a smooth upgrade without manual intervention"
14:54:03 <zaneb> I agree (I think) with sdague, create the individual tags and users can decide for themselves whether that is awesome or not
14:54:29 <ttx> (i.e. we are not answering "does this project have good QA". We answer more specific questions
14:55:06 <sdague> honestly, if people want to bundle later, I think that's fine, but lets start with specifics
14:55:24 <ttx> sdague: ok, you had me at "some projects might not feel they need it"
14:55:35 <ttx> means you can't define QA in one dimension
14:56:15 <sdague> yeh
14:56:16 <ttx> Do you plan to draft one of those ?
14:56:28 <sdague> not anytime soon
14:56:35 <ttx> ok, so up for grabs
14:56:42 <ttx> We already have at least one each on our plates
14:56:46 <sdague> yes, happy to review anyone that wants to run with it
14:57:14 <sdague> https://github.com/openstack-dev/grenade/blob/master/README.rst#theory-of-upgrade is some reasonable starter points for it
14:57:26 <ttx> #topic Open discussion
14:57:45 <russellb> ttx: thanks for organizing ttx :)
14:57:57 <sdague> so, my only open question, how do we get more folks contributing here :)
14:58:14 <ttx> I used to want "theme:" tags so that people using a project navigation website would find Manila once they found Cinder
14:58:16 <sdague> because it's currently tc members, + zaneb (who is in most tc meetings anyway), and I was hoping we'd fan out more
14:58:28 <russellb> hopefully the more work we do, the more apparent the value becomes, and the more people that will want to push forward
14:58:31 <ttx> but now I think that info should come from another source and be exposed on the same website
14:58:37 <zaneb> sdague: I think we had one more volunteer who couldn't make it this week
14:58:42 <sdague> zaneb: ok
14:59:05 <sdague> ttx: so, it's probably worth putting together a backlog of "things we'd find useful, no one working on them"
14:59:19 <sdague> so that if someone wanted to contribute, they'd have a pile to pick from
14:59:27 <jokke_> sdague: honestly I have been just reading through and just trying to catch up with the intentions
14:59:30 <zaneb> good idea
14:59:41 <zaneb> I guess the 'Next tags' list in the etherpad is that for now
14:59:42 <ttx> Maybe build on top of the "next tags" section of the etherpad ?
14:59:57 <sdague> yeh, with any relevant details
15:00:12 <ttx> maybe we can add a couple more
15:00:24 <sdague> ML posts, links to stuff that would be useful to define that thing, etc
15:00:42 <sdague> because if it's just a name, it will be too opaque
15:01:34 <ttx> OK, let's build from that
15:01:35 <jokke_> sdague: also "because it's currently tc members, + zaneb (who is in most tc meetings anyway)" might make it slightly intimidating for some to step out ;)
15:01:39 <ttx> Time is out
15:01:55 <sdague> thanks ttx et al
15:01:58 <sdague> jokke_: ++
15:02:03 <zaneb> thanks all, this has been productive I think
15:02:11 <ttx> I should post something about that meeting, early next week
15:02:27 <ttx> #endmeeting