20:02:41 <ttx> #startmeeting tc
20:02:41 <openstack> Meeting started Tue May 20 20:02:41 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:44 <openstack> The meeting name has been set to 'tc'
20:02:52 <ttx> Here is our agenda for today:
20:03:02 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:03:07 <ttx> david-lyle: around?
20:03:14 <david-lyle> ttx: o/
20:03:19 <ttx> #topic Integrated projects and new requirements: Gap analysis for Horizon
20:03:31 <ttx> david-lyle prepared a gap analysis:
20:03:37 <ttx> #link https://etherpad.openstack.org/p/horizon-gap-analysis
20:03:57 <ttx> I picked Horizon on short notice, as i don't expect it to raise major issues
20:04:08 * mordred giggles
20:04:22 <vishy> o/
20:05:18 <ttx> but stil a few interesting things in there
20:05:34 <jeblair> so the note about "Split of repo planned into toolkit and django application." is nice because it's one of the things that makes horizon difficult to deal with from an infra pov (having 2 projects in 1 repo requires special one-off tooling)
20:05:34 <ttx> #info Scope needs to be documented
20:05:40 <annegentle_> Actually horizon still needs a mission statement right?
20:05:56 <david-lyle> annegentle_: yes
20:06:05 <ttx> #info Major architectural change planned: split of repo into toolkit and django app
20:06:45 <david-lyle> the repo essentially already contains two distinct pieces in one place
20:06:54 <sdague> for those of us less familiar with horizon code base, what's the toolkit contain roughly?
20:06:56 <david-lyle> this is more a formalization of that split
20:07:30 <jaypipes> david-lyle: timeframe around that split?
20:07:47 <david-lyle> the toolkit is the widgets and framework for the dashboards, panels, tables, etc
20:07:47 <ttx> #info Refresh of horizon-coresec needed
20:07:48 <jeblair> Also, django apparently necessitates non-standard translation tooling
20:08:09 <ttx> That's all I spotted from the doc... TC members, feel free to add more #info
20:08:14 <david-lyle> the openstack_dashboard component is the actual django application that implements the toolkit
20:08:42 <david-lyle> jeblair: I don't have admin on that, missed in transition
20:08:55 <annegentle_> #info Nice-to-have: listing of API calls not available in GUI per service
20:08:57 <david-lyle> jaypipes: juno-1 to juno-2
20:09:19 <david-lyle> we've been planning it since the icehouse summit, but got delayed
20:09:20 <ttx> david-lyle: is horizon tested in the gate, does that make even sense ? Or is selenium/unittesting considered enough due to the consumer position ?
20:09:26 <annegentle_> david-lyle: I'd also like to see a statement in your scope about the addition timing of integrated projects
20:09:50 <jaypipes> david-lyle: k, thx
20:10:06 <david-lyle> ttx: Horizon has one tempest job, that is a selenium test that tests login
20:10:15 <ttx> david-lyle: ok
20:10:23 <david-lyle> other than that it's purely unit test and selenium
20:10:41 <ttx> ack
20:10:50 <david-lyle> beyond that we have started building an integration test framework and can run against devstack
20:11:35 <david-lyle> we want to grow the test suite there and maybe eventually tie it into the gate, as we are uniquely positioned to insure non-breaking changes in the python-*clients
20:11:45 * mordred is in support of that
20:11:55 <jaypipes> ++
20:12:03 <mordred> that is - of "ensure non-breaking changes in python-*clients"
20:12:10 <ttx> mordred: but would you consider that a "gap" ?
20:12:22 <david-lyle> that obviously requires some work with infra once we have a better test suite
20:12:25 <devananda> ++ to integration test framework
20:12:47 <mordred> yes. the level to which we've tested horizon thusfar I think is less than any of us are happy about
20:12:55 <mordred> but it seems the plans moving forward are good ones
20:13:19 <zaneb> david-lyle: uniquely? ;)
20:13:22 <ttx> #info Integration test framework tied to gate
20:13:34 <mordred> david-lyle: while we're on testing - has anyone done any thinking about testr and horizon?
20:13:52 <ttx> OK, any other gap ?
20:13:53 <david-lyle> zaneb: maybe not as uniquely as we used to be, apologies
20:13:54 <mordred> last time I looked in to it, I gave up and deferred to later
20:14:14 <zaneb> david-lyle: no worries, I'm just kidding :)
20:14:18 <devananda> david-lyle: i see the call out for docs on the developer site. what about in openstack-manuals?
20:14:48 <david-lyle> mordred, we looked into it briefly, there was some issues with nose, but that was early last cycle, we could revisit
20:14:48 <zaneb> heat has it's own issues with tempest coverage
20:15:03 <ttx> zaneb: talking about which...
20:15:18 <ttx> Would you be up for next week ? :)
20:15:18 <mordred> david-lyle: it's not urgent yet - main thing is we _want_ to do some subunit processing in the gate itself, so want to make sure we don't have blocker projects if we get to that point
20:15:46 <annegentle_> devananda: david-lyle: for integration, those are the minimum docs... for a core project also install/config docs (which are in openstack-manuals)
20:16:02 <ttx> david-lyle: OK, I think we have all gaps documented in #info in the logs
20:16:09 <markmcclain> +1 to subunit
20:16:14 <david-lyle> mordred, we'll look again
20:16:18 <devananda> annegentle_: that's what I thought, but I dont see any mention of those in the etherpad
20:16:25 <ttx> david-lyle: would be good to have a coverage plan -- how you plan to address those in the future
20:16:33 <annegentle_> devananda: yep, because those docs aren't listed as a requirement in this gap analysis
20:16:39 <devananda> ah
20:16:43 <ttx> david-lyle: could you prepare one for next week ?
20:16:57 <zaneb> ttx: you might have to twist my arm ;)
20:17:29 <david-lyle> ttx: code coverage?
20:17:41 <ttx> david-lyle: no, gap coverage
20:17:49 <ttx> david-lyle: I listed gaps in #info in the meeting logs
20:17:54 <david-lyle> ttx: sure
20:18:01 <ttx> david-lyle: would be good to have a clear action plan on addressing those
20:18:13 <ttx> See https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage for an example
20:18:39 <ttx> TC members: any other remark on that topic ? Other gaps ?
20:18:41 <david-lyle> absolutely
20:19:06 <markmcclain> my favorite line "Dashboard would be circular and thus frowned upon."
20:19:41 <jeblair> ttx: did you note the non-standard tooling due to combined projects as a gap?
20:20:03 <ttx> jeblair: nope, be my guest :)
20:20:37 <jeblair> #info Non-standard test/packaging/translation tooling due to combined projects in one repo
20:20:50 <ttx> OK, if that is all, let's move to next topic
20:20:55 <ttx> david-lyle: thanks!
20:21:09 <annegentle_> thanks david-lyle!
20:21:23 <david-lyle> my pleasure
20:21:23 <mikal> Agreed, thanks for coming along
20:21:32 <zehicle_at_dell> o/
20:21:34 <ttx> on very short notice
20:21:39 <ttx> #topic Defcore update: Scoring the Havana capabilities
20:21:53 <ttx> zehicle_at_dell: floor is temporarily yours
20:21:56 <zehicle_at_dell> The board approved the 12 scoring critieria in the last meeting
20:22:08 <zehicle_at_dell> and that let us post the advisory Havana score card
20:22:19 <zehicle_at_dell> BUT it's got gaps and requests for TC input all over the place
20:22:31 <zehicle_at_dell> so I was hoping to work with you to fill in the gaps
20:22:47 <zehicle_at_dell> it's likely 2-4 hours of interactive work
20:22:48 <ttx> zehicle_at_dell: link?
20:23:06 <zehicle_at_dell> #link https://wiki.openstack.org/wiki/Governance/CoreCriteria
20:23:27 <annegentle_> zehicle_at_dell: what's the deadline?
20:23:32 <zehicle_at_dell> #link http://robhirschfeld.com/2014/05/08/defcore-scorecard/
20:23:37 <zehicle_at_dell> OSCON
20:23:51 <zehicle_at_dell> we'd like to have the board adopt the Havana sc ore card at OSCON
20:24:02 <zehicle_at_dell> it's ADVISORY for Havana
20:24:21 <zehicle_at_dell> but it's sets a trendline for the next I & J
20:24:33 <ttx> zehicle_at_dell: so you need input on all the 0.5 in TC direction @ https://wiki.openstack.org/w/images/e/e3/DefCore_Capabilities_Scoring.pdf ? Or more ?
20:24:34 <zehicle_at_dell> and we're still trying to complete those by Paris
20:24:42 <zehicle_at_dell> ttx, yes
20:24:51 <zehicle_at_dell> and also filling in the gaps
20:25:03 <ttx> gap = red lines ?
20:25:05 <zehicle_at_dell> which will then raise the question of % of designated code in Swift
20:25:08 <zehicle_at_dell> yes
20:25:14 <annegentle_> zehicle_at_dell: so July 20th or earlier than that to allow for formatting?
20:25:18 <zehicle_at_dell> ttx, the unscored ones in the center
20:25:26 <zehicle_at_dell> annegentle_, yes
20:25:34 <zehicle_at_dell> we could work on formatting earlier
20:25:34 <annegentle_> zehicle_at_dell: which?
20:25:40 <ttx> zehicle_at_dell: I think for the red lines it would be good to get the PTL input first
20:25:42 <annegentle_> zehicle_at_dell: July 15?
20:25:55 <ttx> TC can help with the 0.5 cells
20:26:00 <zehicle_at_dell> annegentle_, sorry.  yes 7/15.
20:26:07 <mikal> ttx: which PTL? The Havan PTL of the current one?
20:26:08 <zehicle_at_dell> annegentle_, we can get the formatting done in parallel
20:26:17 <ttx> PTLs affectd by red lines are notmyname, jgriffith and mikal
20:26:28 <ttx> I'd say current one
20:26:29 <annegentle_> #link https://wiki.openstack.org/w/images/e/e3/DefCore_Capabilities_Scoring.pdf
20:26:29 <zehicle_at_dell> ttx, yes.  would be good to ahve the relevant PTLs
20:26:47 <zehicle_at_dell> we are getting help from John D on Swift capabilities grouping too
20:26:52 <ttx> zehicle_at_dell: if they fail to provide input we can help fill, but that seems like the logical first step
20:27:01 <zehicle_at_dell> ideally, PTLs would also help on cabilities groups, but that's another topic
20:27:15 <annegentle_> #info Request from board for TC input on the red rows in https://wiki.openstack.org/w/images/e/e3/DefCore_Capabilities_Scoring.pdf by July 15th
20:27:15 <zehicle_at_dell> ttx, agree.  was hoping to have TC formalize the request
20:27:30 <ttx> zehicle_at_dell: so I suggest we take those 0.5 home as homework for the week, and come up with proposals for next week meeting
20:27:32 <annegentle_> zehicle_at_dell: how should the input come back?
20:27:40 <zehicle_at_dell> +1
20:27:42 <ttx> zehicle_at_dell: in the mean time I'll forward your request on red lines to affected PTLs
20:27:49 <zehicle_at_dell> thanks!
20:27:50 <annegentle_> ttx: I don't see 0.5? where is that?
20:27:57 <zehicle_at_dell> the yellow cells
20:28:03 <annegentle_> zehicle_at_dell: ah got it
20:28:05 <eglynn> zehicle_at_dell: is every project integrated in havana included in that matrix?
20:28:07 <ttx> annegentle_: 0.5 cells in Future Tc direction column
20:28:12 <zehicle_at_dell> #link http://robhirschfeld.com/2014/05/09/openstack-defcore-matrix-cheet-sheet/
20:28:21 <zehicle_at_dell> I made a cheat sheet to help understand the grid
20:28:22 <annegentle_> zehicle_at_dell: as in, you don't know if the 0.5 is accurate unless you ask more people?
20:28:29 <zehicle_at_dell> would accept help in formatting to make it easier to understand
20:28:36 <eglynn> zehicle_at_dell: (I see orch-stacks for heat, but nothing obvious for ceilometer)
20:28:39 <zehicle_at_dell> annegentle_, there should be no .5s.  those are place holders
20:28:48 <ttx> #action TC members to look at 0.5 cells in "future TC direction" column in http://robhirschfeld.com/2014/05/09/openstack-defcore-matrix-cheet-sheet/ and prepare proposed score for next meeting
20:28:52 <zehicle_at_dell> eglynn, we can only score items with tests
20:28:57 <annegentle_> zehicle_at_dell: ok
20:29:03 <zehicle_at_dell> so no tests = no capabililites
20:29:20 <ttx> #action ttx to reach to affected PTLs for red lines at https://wiki.openstack.org/w/images/e/e3/DefCore_Capabilities_Scoring.pdf
20:29:23 <zehicle_at_dell> annegentle_, would be good to have a new perspective to help explain it.  I'm way too close to the material
20:29:35 <zaneb> zehicle_at_dell: how old is the list of tests, just out of curiosity?
20:29:41 <annegentle_> zehicle_at_dell: I'm good at asking dumb questions :)
20:29:46 <ttx> #action ttx to schedule gap coverage plan approval for Horizon for next meeting
20:29:49 <eglynn> zehicle_at_dell: based on Tempest coverage?
20:29:55 * zaneb was pretty sure we had more than one ;)
20:29:59 <zehicle_at_dell> eglynn, yes
20:30:06 <sdague> zaneb: not in havana :)
20:30:07 <mordred> zehicle_at_dell: btw - have you guys been tracking branchless-tempest?
20:30:23 <zehicle_at_dell> mordred, yes!!! we are planning to move to that
20:30:36 <mordred> great. it's just a thing that would clearly affect you :)
20:30:40 <jeblair> there was lots of refstack<->tempest discussion on that topic at the summit
20:30:41 <zehicle_at_dell> mordred, even for Havana and just suck up that there's some slop
20:30:45 <ttx> hmm fixing action link
20:30:45 <zaneb> sdague: oh, Havana was not the one we just released :)
20:30:54 <zaneb> too many releases
20:31:00 <sdague> zehicle_at_dell: have you guys started looking at the differential with branchless at icehouse and havana tempest?
20:31:03 <ttx> #action TC members to look at 0.5 cells in "future TC direction" column in https://wiki.openstack.org/w/images/e/e3/DefCore_Capabilities_Scoring.pdf and prepare proposed score for next meeting
20:31:08 <sdague> because the overall test count did double
20:31:24 <sdague> and I'm curious how much of the analysis is going to need to rev after those new functional areas come in
20:31:32 <zehicle_at_dell> sdague, yes but I think thats OT for here
20:31:48 <eglynn> zehicle_at_dell: another dumb question, why concentrate on Havana as opposed to Icehouse?
20:32:20 <zehicle_at_dell> eglynn, so people can digest the impact
20:32:27 * eglynn asks as the first ceilometer tempest coverage dates from the Icehouse cycle
20:32:41 <annegentle_> eglynn: gives deployers some time to test and then act/iterate
20:32:45 <zehicle_at_dell> eglynn, this needs time to settle and get feedback - it will change commercial products
20:32:52 <zehicle_at_dell> annegentle_, +1
20:33:19 <zehicle_at_dell> eglynn, turning the ship...slowly
20:33:49 <ttx> zehicle_at_dell: OK, I think we have an action plan here
20:33:56 <ttx> zehicle_at_dell: anything else ?
20:33:59 <zehicle_at_dell> no
20:34:00 <eglynn> zehicle_at_dell: fair enough, though /me is eager for the lack of tempest coverage for ceilo in Havana not to exclude ceilo completely from the analysis
20:34:25 <eglynn> ... just sayin'
20:34:26 <annegentle_> eglynn: is your question aimed at whether ceilometer will be considered for core capability?
20:34:33 <eglynn> annegentle_: yep
20:34:41 <zehicle_at_dell> eglynn, putting pressure on community to add tests is part of the objective
20:34:57 <zehicle_at_dell> eglynn, pressure on the commercial interests that pay people
20:34:59 <zaneb> zehicle_at_dell: perhaps the question is how often do we expect this analysis to be revised?
20:35:07 <zehicle_at_dell> zaneb, every release
20:35:12 <zaneb> ok
20:35:16 <vishy> eglynn: is there a subset of ceilo api that is user facing?
20:35:20 <eglynn> zehicle_at_dell: k, got it ... we plan to expand this further over Juno
20:35:22 <zaneb> but with a 6 month lag?
20:35:28 <ttx> eglynn, zaneb: feel free to continue discussion with zehicle off-meeting
20:35:38 <zaneb> sure
20:35:41 <eglynn> vishy: the API is in a sense, consumed by the metering dashboard for example
20:35:46 <eglynn> ttx: roger that!
20:35:48 <zehicle_at_dell> zaneb, no.  we want to be zero day.  We are trying to get to 0.  will hopefully be there for K if not J
20:35:55 <zaneb> ok, cool :)
20:36:11 <ttx> #topic New requirements
20:36:19 <vishy> eglynn: seems like the surface is pretty small for users. Mostly used by admins operators
20:36:19 <ttx> * add upgrade expectations (https://review.openstack.org/87234)
20:36:30 <eglynn> vishy: fair point
20:36:32 <zehicle_at_dell> thanks everyone!'
20:36:39 <eglynn> zehicle_at_dell: thank you sir!
20:36:45 <ttx> This one could need another +1. There was a comment from lifeless tat was a -1 but he left the TC
20:36:53 <ttx> zehicle_at_dell: thx!
20:37:08 <sdague> ttx: I think lifeless and I are actually at violent agreement on the idea, it was a language clarity question
20:37:12 <ttx> so now it's a random comment, but his question should still be adressed
20:37:18 <ttx> ok
20:37:24 <sdague> so basically I'd see if people find his language or mine more clear
20:37:31 <sdague> and I'll propose with whatever people believe
20:37:47 <ttx> ok, so all make a last pass on this one, will approve if it gets 7 +1s
20:37:49 <sdague> I think mine wasn't legally sealed, but I think less confusing
20:37:53 <lifeless> sdague: agreed
20:38:02 <ttx> or more exactly..; if it still has 7 +1s by tomorrow :)
20:38:06 <annegentle_> For upgrade expectations, did anyone address the "from first integrated release" expectation?
20:38:37 <annegentle_> don't want to -1 unless I'm missing something
20:38:44 <mordred> sdague, lifeless: I actually think both of you are wrong
20:38:47 <sdague> annegentle_: good point
20:38:50 <ttx> yay!
20:38:59 <sdague> mordred: ok, alternate wording?
20:39:01 <lifeless> mordred: yay!.
20:39:24 <annegentle_> ok -1 from me
20:39:27 <devananda> on the "from any arbitrary point..." line, perhaps some wording that this doesn't imply a direct upgrade - which seems to be the point lifeless' comment is making
20:39:43 <mordred> sdague: will work on it - I thnk you're closest
20:40:07 <sdague> mordred: ok. I think the intent between all of us is clear, but would be best to make it easy to understand by new projects
20:40:08 <ttx> annegentle_: my reading is that "stable release" means integarted, but yes, more precision could help
20:40:15 <sdague> so they don't get surprised
20:40:29 <markmcclain> hmmm… technically the item has passed
20:40:31 <sdague> I do think calling out "after initial integrated release" is fair point to make clear
20:40:39 <ttx> OK, so this needs a few more iterations
20:40:43 <mordred> sdague: perhaps we should enumerate what we expect to be testable
20:40:43 <markmcclain> do we need folks to switch their +1s to 0/-1?
20:40:46 <devananda> sdague: +1
20:40:52 <ttx> markmcclain: well, sdague hasn't formally cast his vote :)
20:41:04 <sdague> ttx: I vote on my own proposals?
20:41:11 * markmcclain counts again
20:41:13 <ttx> sdague: it's a grey area.
20:41:17 <mordred> because we dont' do anything with 'arbitrary' points in time - and if it's not tested, it's broken
20:41:28 <ttx> i usually count the proposer in favor, yes
20:41:28 <markmcclain> 7 for -1 against
20:41:33 <sdague> mordred: fair, I was trying to capture the spirit of the CD case
20:41:36 <mordred> sdague: yah
20:41:39 * mordred may be wrong
20:41:40 <sdague> because we don't test it
20:41:49 <sdague> but we do call people out on it
20:41:55 <sdague> like when they reorder db migrations
20:42:01 <mordred> good point
20:42:04 <ttx> markmcclain: oh, someone just added a +1
20:42:16 <mordred> sdague: maybe we should figure out how to test for that ...
20:42:35 <markmcclain> I do think clarification is needed just wondering what the procedure is in this case… I assume voting it still open so folks can their positions
20:42:37 <mordred> maybe not in this meeting
20:42:40 <sdague> mordred: probably, though I doubt it will be this cycle
20:42:55 <ttx> markmcclain: anyway, I only fasttrack approvals when there are 7 +1s and no objection. Everything else requires a 'final vote' to be called after two meetings of non consensus
20:43:13 <markmcclain> ttx: ah good to know
20:43:16 <ttx> markmcclain: agree that proposer can vote on his own
20:43:30 <ttx> I usually count proposer as a +1, but we could be more formal
20:43:32 <sdague> so lets do this. annegentle_'s point is something we should fix, will do. I'm open to clearer language if someone proposes it.
20:43:52 <ttx> ok, let's give it another week then
20:43:55 <jeblair> ++
20:43:57 <ttx> * Add Ceilometer requirements (https://review.openstack.org/85978)
20:43:59 <annegentle_> sdague: so shall I patch this one with different wording?
20:44:00 <sdague> I can honestly go less "legally", and more example oriented
20:44:18 <sdague> annegentle_: sure, or leave a comment with the proposed wording
20:44:35 <ttx> This one is pretty stuck
20:44:59 <ttx> Not sure if we should ping proposer, vote -1 to remove it or just let it auto-abandon
20:45:13 <eglynn> yeah seems no prospect of agreement on current version, shall I punt it back to jd for another round of wordsmithing?
20:45:45 <ttx> eglynn: if it's still in same shape next week I'll probably cahse down -1s so that we kill it
20:45:46 <jeblair> ttx: oh we don't auto-abandon anymore; do you have an abandon button?
20:45:59 <eglynn> ttx: k, understood
20:46:05 <ttx> jeblair: we haven't set rules for such cases yet
20:46:14 <ttx> jeblair: I'm fine with the ultimatum I just gave
20:46:39 <ttx> i.e. give it another week, and kill it softly with a pack of -1s if it's still around
20:46:41 <jeblair> ttx: yeah, though i'm specifically asking if you personally have an abandon button in gerrit on the governance repo.  :)
20:46:45 <lifeless> mordred: +1 on enumerating things that should work.
20:46:49 <lifeless> mordred: and things that shouldn't.[6~
20:46:54 <ttx> jeblair: yes I do
20:46:57 <jeblair> cool
20:47:24 <ttx> #info If that one is not improved by next week, it will probably be abandoned
20:47:31 <ttx> #topic Minor governance changes
20:47:36 <ttx> * Render member list in HTML output (https://review.openstack.org/91450)
20:48:36 <ttx> I guess I can approve that one as non-policy
20:48:47 <mordred> ttx: ^^ do we need full TC vote on patches like that? non-policy patches seem like something that 2 positive votes should be good on
20:48:49 <ttx> unless someone complains rreally soon
20:49:01 <ttx> mordred; yep
20:49:06 <jeblair> do the docs build now?  if so, we should start gating
20:49:09 <ttx> #info will approve tomorrow unless someone -1s
20:49:17 <ttx> * Update sphinx doc formatting and toctrees (https://review.openstack.org/91422)
20:49:22 <ttx> Same for this one
20:49:27 <mordred> jeblair: ++
20:49:30 <annegentle_> I think two +2s should work for non-policy
20:49:43 <ttx> #info will approve tomorrow unless someone -1s
20:49:57 <ttx> * Add project mission statement for Ceilometer (https://review.openstack.org/87526)
20:50:08 <mordred> (should we pep8 the python in the governance repo?)
20:50:10 * mordred hides
20:50:20 <ttx> I think that one just needs a few more +1s
20:50:55 <ttx> I prefer to have one in and have people suggest better words afterwards
20:51:03 <jeblair> i think we gave ttx blanket non-policy rights (eg, i don't think he needs even 2 +2s, but can wait for them at his discretion)
20:51:21 <ttx> #info Will approve whenever it reaches 7 +1s
20:51:29 <ttx> jeblair: ok
20:52:00 <ttx> jeblair: for those one I wanted to make sure this use of the governance repo was ok with everyone
20:52:07 <ttx> but I think they are
20:52:19 <ttx> * Add oslo.db to the Oslo program (https://review.openstack.org/90127)
20:52:35 <ttx> This one depends on:
20:52:41 <ttx> * add oslo.i18n to Oslo program (https://review.openstack.org/92429)
20:53:12 <ttx> Both are approved by PTL
20:53:24 <ttx> no objection... OK if I approve them now ?
20:53:43 <annegentle_> ttx: yeah go ahead
20:53:59 <ttx> I may trigger a few rebasees but hey, that's life
20:54:18 <vishy> do it
20:54:21 <sdague> ttx: +1
20:55:17 <ttx> ok done
20:55:19 <ttx> for both
20:55:32 <ttx> #topic Open discussion
20:55:37 <anteaya> o/
20:55:44 <ttx> anteaya: go for it
20:55:47 <anteaya> thanks
20:56:05 <anteaya> so I just want folks to know that soon I want to talk about some election stuff
20:56:21 <anteaya> one item is do we have the right criteria for the electorate?
20:56:35 <anteaya> the ptl elections seem to be healthy with at least 43% voting
20:56:38 <annegentle_> ttx: I have a q next
20:56:45 <ttx> I hope I'll have my analysis of TC election ready soon, so that we can revisit the "proportional" option
20:56:47 <anteaya> the tc election needs some evaluation
20:56:59 <anteaya> we had 29.7% participation
20:57:13 <anteaya> I think we need a better % of participation
20:57:13 <mikal> Do we think that people had election fatigue at that point?
20:57:18 <anteaya> so that is coming up
20:57:23 <mikal> Many people had probably voted in several elections by then
20:57:24 <anteaya> no, I don't percieve fatigue
20:57:29 <anteaya> I percieve long tail
20:57:39 <sdague> anteaya: do we have comparisons to past TC elections?
20:57:39 <ttx> anteaya: I think it's a good topic. Ideally we would raise it on openstack-dev first to gather more input
20:57:40 <anteaya> 450 electorate for nova
20:57:47 <anteaya> 1500 electorate for tc
20:57:50 <ttx> like for all resolutions
20:58:08 <anteaya> yes, so just by way of heads up, I would like to have this discussion
20:58:12 <ttx> sdague: it was around 30% last time as well
20:58:20 <anteaya> I will get numbers and comparisons as they are requested
20:58:32 <ttx> anteaya: ok, thxc for heads-up
20:58:33 <ttx> annegentle_: go for your question
20:58:36 <anteaya> the second item dealing with elections is campagn messageing
20:58:44 * mordred has been thinking about revisiting the 1-vote==ATC criteria
20:58:46 <anteaya> we don't have any and I think we should ahve some
20:58:49 <anteaya> okay done
20:58:51 <ttx> anteaya: ack
20:58:52 <annegentle_> do we need to elect a tc chair? Or did we and I forgot it already?
20:59:05 <ttx> mordred: yes, we may want to revisit that, but I wonder if bylwas let us do that
20:59:06 <sdague> annegentle_: we did it already
20:59:16 <mordred> ttx: I think it's in our charter, no?
20:59:22 <annegentle_> sdague: ha I missed it
20:59:28 <sdague> annegentle_: https://review.openstack.org/#/c/92461/
20:59:35 <ttx> mordred: I'll have to check how much we are constrained by the ATC definition in the bylways
20:59:43 <mordred> ttx: we all think the foundation is crazy for having too-lax membership qualifications, so it seems like if we're having low voter turnout ...
20:59:49 <ttx> which lives in some appendix
20:59:59 <mordred> then perhaps we should address qualifications for being part of the electorate
21:00:03 <ttx> annegentle_: was last meeting
21:00:12 <mordred> since we have, you know, math at our disposal and are not afraid to use it
21:00:23 * jeblair is a little afraid of math
21:00:33 <ttx> behold the power of math
21:00:33 <zaneb> mordred: if the uninformed voters are self-selecting out anyway... is there a need?
21:00:52 <markmcclain> zaneb: quorum becomes a possible issue with low turnout
21:00:54 <ttx> ok, time is up
21:01:12 <ttx> thanks everyone!
21:01:18 <zaneb> markmcclain: for the foundation yes; I don't think there is a quorum for TC elections though
21:01:19 <mikal> :)
21:01:20 <mordred> zaneb: quoruum
21:01:44 <ttx> #action ttx to check how much control we have on electorate definition for the Technical Committee
21:01:44 <anteaya> zaneb: it plays a role in the effectiveness of any election
21:01:52 <ttx> #endmeeting