20:00:48 <jbryce> #startmeeting
20:00:49 <openstack> Meeting started Tue Jun 19 20:00:48 2012 UTC.  The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:55 <johnpur> o/
20:01:03 <jaypipes> o/
20:01:07 <mtaylor> o/
20:01:35 <jbryce> so we've got 5 so far?
20:01:36 <vishy> o/
20:01:37 <jbryce> need 2 more
20:01:40 <jbryce> need 1 more
20:01:46 <jbryce> step right up
20:01:49 <danwent_> o/
20:01:55 <jbryce> sweet
20:01:55 <vishy> anotherjesse_zz: is popping in too
20:01:55 <mtaylor> still need one more - I don't count
20:01:58 <jbryce> http://wiki.openstack.org/Governance/PPB
20:02:01 <anotherjesse> o/
20:02:03 <jbryce> mtaylor: i didn't count you this time
20:02:03 <mtaylor> w00t
20:02:06 <mtaylor> jbryce: :)
20:02:14 <jbryce> http://wiki.openstack.org/Governance/PPB
20:02:23 <jbryce> #topic Library/Gating Projects
20:02:29 <johnpur> monty: you always count to us :)
20:02:38 <jbryce> mtaylor: do you want to explain where you've ended up with the discussion on the mailing list?
20:03:10 <jaypipes> should markmc join us?
20:03:15 <ttx> jbryce: I think the sticking point is on a different release scheme than associated server projects
20:03:19 <bcwaldon> back!
20:03:24 <anotherjesse> how many errors on the that page can you spot ;)
20:03:25 <notmyname> here
20:03:53 <mtaylor> jbryce: so, I'm not sure I've sold markmc on anything - but I believe bcwaldon is more on board with the new version of things
20:04:04 <bcwaldon> mtaylor: yep
20:04:06 <jbryce> anotherjesse: = )  it's a wiki page so people should feel free to update their affiliations
20:04:12 <ttx> jbryce: our point is that libs require PyPI, and PyPI makes your life miserable if you want to do a complex scheme
20:04:17 <mtaylor> short story: client versions should be there own thing and tied to neither server releases or api versions
20:04:19 <bcwaldon> mtaylor: or you're on board with my version of things ;)
20:04:23 <mtaylor> yup
20:04:30 * mtaylor bows to bcwaldon
20:04:35 <bcwaldon> like a boss
20:04:49 <heckj> o/
20:05:10 <mtaylor> and other than that, I think as long as we tag all releases, we can defer discussion of stable branches until we come up with a situatoin where we're actually in trouble?
20:05:12 <jbryce> is markmc in the other room?
20:05:28 <ttx> for the record, I was thinking like markmc initially, but couldn't find a solution that would work... so I accepted mtaylor's solution.
20:05:34 <jaypipes> nope
20:05:39 <mtaylor> ttx: which is bcwaldon's :)
20:05:40 <jaypipes> jbryce: nope
20:06:07 <mtaylor> I don't know if anyone read my latest novel in that thread...
20:06:08 <heckj> mtaylor: I'm fine with that - I mostly needed a tag
20:06:15 <mtaylor> heckj: awesome. you shall have one
20:06:18 <jbryce> well the current state makes sense to me as well with tags
20:06:42 <jaypipes> ++ me as well, after reading the various posts I concur with bcwaldon (much as it pains me)
20:06:50 <jbryce> ok. sounds like we're ready for a vote
20:06:56 <mtaylor> whee!
20:07:02 <ttx> So in summary, I think the drawbacks of doing simple versioning / release scheme are far outweighed by the convenience of using PyPI in a straightfoward manner.
20:07:02 <bcwaldon> jaypipes: what that mouth
20:07:02 <notmyname> wait
20:07:06 <bcwaldon> jaypipes: gah, watch*
20:07:08 <jbryce> mtaylor: could you propose what we're voting on?
20:07:11 * mtaylor is scared of days when mtaylor and jaypipes both agree with bcwaldon
20:07:15 <jbryce> notmyname: waiting...
20:07:16 <jaypipes> :)
20:07:42 <notmyname> jbryce: for what you just said. an actual proposal or link to what we're voting on. not "what so-and-so said on the mailing list"
20:08:10 <johnpur> notmyname: good point
20:08:14 <mtaylor> let me try to make a quick summarization for voting purposes:
20:08:16 <jbryce> notmyname: that's why i asked mtaylor to propose it in its current form
20:09:17 <mtaylor> we will decouple client releases from server release, we will release client libs to pypi as they are ready and their version scheme will be standard library versioning (major version bump on incompatible api changes)
20:09:21 <mtaylor> ttx: yeah? ^^
20:10:02 <ttx> mtaylor: ..and there will be no stable version point releases
20:10:29 <mtaylor> oh, and there will only ever be one "stable" release of client libs, and it will be expected to support all currently supported versions of the relevant api
20:10:36 <mtaylor> which is the longer way of saying what ttx just said
20:11:17 <johnpur> are we making a statement about what "currently supported" means?
20:11:23 <jbryce> ok. give me a minute to do the votebot
20:11:29 <anotherjesse> johnpur: was just going to ask that
20:11:34 <mtaylor> johnpur: I don't think so
20:11:45 <mtaylor> I think we have not made decisions on deprecating old api versions overall
20:12:06 <mtaylor> but when we do make the decision to do that, I would not expect the client libs to need to support things we declare are now crap
20:12:23 <johnpur> We should queue this up for discussion
20:12:31 <mtaylor> ++
20:12:43 <jbryce> #startvote Should we decouple client releases from server releases, release client libs to pypi as they are ready, version them with a standard library scheme (major version bump on incompatible API changes), and have a single stable release of client libs expected to support all currently supported versions of the relevant API?  Yes, No, Abstain
20:12:44 <openstack> Begin voting on: Should we decouple client releases from server releases, release client libs to pypi as they are ready, version them with a standard library scheme (major version bump on incompatible API changes), and have a single stable release of client libs expected to support all currently supported versions of the relevant API? Valid vote options are Yes, No, Abstain.
20:12:45 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:13:10 <bcwaldon> #vote Yes
20:13:12 <johnpur> #vote Yes
20:13:23 <jbryce> #vote Yes
20:13:26 <heckj> #vote yes
20:13:27 <openstack> heckj: yes is not a valid option. Valid options are Yes, No, Abstain.
20:13:35 <heckj> #vote Yes
20:13:36 <danwent_> #vote Yes
20:13:37 <notmyname> #vote Yes
20:13:37 <johnpur> lol
20:13:42 <heckj> picky thing...
20:13:43 <ttx> #vote Abstain
20:13:44 <mtaylor> haha.
20:13:48 <jbryce> does vote have a -i option?
20:13:49 <johnpur> computers are awesome!
20:13:55 * ttx really wishes there was another solution.
20:13:57 <mtaylor> clarkb: feature request - case insensitive voting
20:14:00 <bcwaldon> vishy, anotherjesse ?
20:14:05 <clarkb> roger
20:14:37 <anotherjesse> #vote Yes
20:15:01 <jbryce> vishy: last chance
20:15:13 <vishy> Yes
20:15:15 <vishy> sorry :)
20:15:20 <vishy> #vote Yes
20:15:22 <ttx> Sidenote #1: it also makes more sense to separate from parent project in case we do a common single library for all openstack stuff
20:15:25 <jbryce> #endvote
20:15:26 <openstack> Voted on "Should we decouple client releases from server releases, release client libs to pypi as they are ready, version them with a standard library scheme (major version bump on incompatible API changes), and have a single stable release of client libs expected to support all currently supported versions of the relevant API?" Results are
20:15:27 <openstack> Yes (8): anotherjesse, bcwaldon, johnpur, jbryce, vishy, heckj, danwent_, notmyname
20:15:28 <openstack> Abstain (1): ttx
20:15:46 <mtaylor> baller. we shall work on getting the bits in place to do the above. thanks all!
20:15:47 <ttx> Sidenote #2: That means we'll revive the python-*client projects in Launchpad
20:16:28 <jbryce> #topic PPB to Technical Committee transition
20:16:31 <jbryce> http://wiki.openstack.org/Governance/Foundation/TechnicalCommittee
20:16:40 <jbryce> that link is ttx's current proposal
20:17:08 <jbryce> i think the most unsettled portion of it is the status of PTLs as it relates to the Technical Committee
20:17:27 <jbryce> which we discussed a little previously but never really reached a consensus
20:17:34 <ttx> I can explain my position again
20:17:48 <bcwaldon> I think PTLs should have a seat guaranteed, they ARE technical leadership
20:17:53 <johnpur> what is unclear to me is whether TC == PPB? or is TC + BoD == PPB?
20:18:15 <heckj> bcwaldon:++
20:18:30 <ttx> bcwaldon, heckj: that's unfair and doesn't scale, let me explain
20:18:41 <jbryce> johnpur: there isn't an exact equivalent, but TC is closer to PPB
20:18:59 <ttx> As we split Nova into smaller bits, we can expect more than 10 PTLs, erach representing a tiny bit of code
20:19:19 <ttx> A vote should represent an equal force
20:19:29 <jbryce> johnpur: the core project additions/removals (not incubation) will also require board approval as it affects what the trademark represents
20:19:32 <bcwaldon> ttx: I wouldnt call a person in control of a section of Nova a PTL
20:19:34 <ttx> The only way to esnure that fairness is to have everybody elected, and PTLs running for a positio,n
20:19:46 <bcwaldon> ttx: I would propose a new title for those positions
20:19:54 <ttx> bcwaldon: where does the bucket stop ? Cinder ? Glance ?
20:20:02 <bcwaldon> ttx: I dont follow
20:20:15 <jbryce> bcwaldon: do glance and cinder have PTLs?
20:20:22 <bcwaldon> jbryce: currently, yes
20:20:30 <jbryce> bcwaldon: or should they i suppose is the more appropriate question
20:20:35 <ttx> bcwaldon: Cinder is a split of Nova. It's a full-fledged core project. I don't want to have small and bug core projects
20:20:40 <ttx> I want to have core projects
20:20:44 <ttx> big*
20:20:49 <jbryce> ttx is referring to all of the things that we've been breaking out of nova
20:21:02 <ttx> There will be no correlation between the size of a core project and the fact that it is core
20:21:08 <jbryce> quantum too
20:21:10 <ttx> so you will end up with 10+ PTLs
20:21:11 <bcwaldon> I understand, but doesnt there have to be someone in control of Nova to coordinate all the goings on?
20:21:30 <ttx> PTLs for large projects will get elected to the TC anyway
20:21:35 <jbryce> yes, nova would continue to have a PTL
20:21:47 <ttx> and PTLS for very small projects, well..; why should they get an appointed seat ?
20:21:54 <jbryce> ttx: what about representation for the smaller projects? especially if there are more of them?
20:22:02 <bcwaldon> I think we're talking past each other here
20:22:12 <ttx> A PTL is still in charge of its project...
20:22:19 <heckj> ttx: i think it's stilly to have a system that supports implicitly the idea that their *could* be another group other than the PTLs who are deciding technical decisions about those projects.
20:22:29 <bcwaldon> heckj: yes, thats my main point
20:22:36 <ttx> He can participate to the meeting. I don't see why he would necessarily need to have a vote.
20:22:41 <bcwaldon> ttx: really, the TC should be PTLs + some more smart people
20:22:47 * mtaylor proposes a bi-cameral solution, with one side having proportional representation, and the other side having equal
20:22:48 <bcwaldon> ttx: because voting makes things happen!
20:23:02 <jbryce> bcwaldon: that's actually my preferred make up as well
20:23:11 <jbryce> similar to what we have now, just removing the appointed seats
20:23:21 * anotherjesse kicks me
20:23:25 <bcwaldon> jbryce: but you're missing the part about PTLs having guaranteed membership
20:23:27 <ttx> OK, then I'll say that I don't thin kit's fair that vishy's voice is as important as John Griffith's.
20:23:27 <johnpur> :(
20:23:36 <jbryce> bcwaldon: no i wasn't. i agreed with you
20:23:43 <ttx> it should be more important. He represents a larger project
20:23:51 <bcwaldon> jbryce: ok, I must have missed it in the three convos happening here :)
20:24:13 <danwent_> ttx: vish will have authority because we trust his judgement and he can sway people.
20:24:14 <ttx> I understand why THIS group would prefer to keep PTLS appointed, but a bloated workgroup won't work
20:24:15 <bcwaldon> ttx: but you just said nova is going to continue to be split...
20:24:18 <jbryce> bcwaldon: earlier i was just trying to explain that ttx was actually talking about real PTLs and projects not sub-components of nova or any project
20:24:34 <bcwaldon> okie
20:24:43 <ttx> bcwaldon: the projects will never be of equal size. Fairness is to get everyone elected
20:24:57 <jbryce> so if we remove the appointed seats, we now have 4 additional slots before we're back to current size
20:25:08 <jbryce> i don't know that we've had too much of a problem with bloat to date
20:25:11 <bcwaldon> ttx: so what happens when we get a bunch of random people elected to TC dictating what the PTLs have to do
20:25:13 <jbryce> one other important point
20:25:21 <bcwaldon> ttx: a new company could join tomorrow with enough voting power to install people
20:25:35 <jgriffith> ttx: The only thing I would ask about is some sort of requirement to even run for election?
20:25:36 <jbryce> according to the Bylaws, the technical committee has the ability to change its make up and processes down the road
20:25:40 <ttx> bcwaldon: they would elect PTLs as well
20:25:57 <bcwaldon> ttx: fair
20:26:00 <ttx> The trick is to get the technical membership right, so that the same people vote for PTLs and vote for TC
20:26:03 <jbryce> i would trust the group to recognize if the current structure is getting so bloated as to prevent problems and make some changes
20:26:17 <ttx> bcwaldon: then in the end, the TC ends up being the 9 most representative PTLs.
20:26:38 <bcwaldon> ttx: ok, I guess I'm not thinking about how many PTLs there will be down the road
20:27:09 <jbryce> how many more pieces do we anticipate splitting out?
20:27:10 <johnpur> jbryce: this is why i asked about ppb and tc equivalence, i agree with what ttx just said
20:27:12 <ttx> jbryce: we have the opportunity to do it right, why not take it now ?
20:27:23 <anotherjesse> if we end up with 20 projects we are probably doing something wrong, that shouldn't be solved by not allowing PTLs in, but not allowing projects in
20:27:36 <heckj> jbryce: I don't see a whole lot more splitting out than already has for core projects. I think this is a non issue
20:27:38 <johnpur> however, this doesn't cover the policy and global view that ppb is suppoed to own
20:27:44 <jbryce> ttx: depends on the definition of "doing it right"
20:27:49 <notmyname> jbryce: but you don't want to trust the future TC to voluntarily "limit" its reach (by limiting who is in it, it implies that current members of it vote themselves off of it)
20:27:51 * mtaylor thinks anotherjesse isn't going to accept his coffee-as-a-service project into core. cries. :(
20:27:53 <ttx> Also note that PTLs are still very much in charge of their project. The TC just solves issues that are cross-project
20:28:00 <bcwaldon> mtaylor: go back to your corner!
20:28:20 <notmyname> anotherjesse: +1
20:28:21 <ttx> TC controls "openstack", PTls control each project
20:28:21 <bcwaldon> ttx: ok, well I feel like theres already a lot of mandating that happens even though I'm Glance PTL
20:28:30 <bcwaldon> ttx: so be careful with what you say :)
20:28:39 <notmyname> bcwaldon: +1
20:29:04 <heckj> ttx: false division - the projects are interrelated and getting more so, not less.
20:29:08 <johnpur> ttx: today we have an implied (maybe explicit) assumption that PTL's are solving cross project technical issues outside of "governance", right?
20:29:27 <bcwaldon> johnpur: definitely is happening
20:29:40 <heckj> johnpur: yes, absolutely occuring
20:29:50 <johnpur> TC should add value above this level of interaction
20:30:00 <ttx> how about that: the PTLs are all members of the TC, but only elected members get a vote
20:30:13 <bcwaldon> ttx: then what does membership even mean?
20:30:13 <ttx> so they can participate in the discussion and influence the vote
20:30:20 <anotherjesse> johnpur: shouldn't the TC/PBB/whatever only come into play if there is a roadblock?
20:30:39 <bcwaldon> ttx: I would assume *anybody* can participate
20:30:43 <bcwaldon> ttx: open community, no?
20:30:43 <anotherjesse> thus far the discussions between projects have gone well
20:30:44 <jbryce> mtaylor has been participating in the discussion all day today!
20:30:51 * mtaylor does his best
20:30:52 <bcwaldon> anotherjesse: indeedly doodly
20:31:18 <jaypipes> anotherjesse: ++
20:31:34 <johnpur> anotherjesse: right. and to raise issues that individual projects/owners might not consider
20:32:01 <jbryce> i actually think that either model could work, but i do feel like having the PTLs involved in all of these decisions has been better for us over the past year and a half that the POC/PPB has existed
20:32:04 <johnpur> to guide openstack as a whole
20:32:15 <ttx> What would be the alternative ? A TC entirely made of, and only consisting of, PTLs ?
20:32:22 <anotherjesse> I'm leaning towards PTLs being on the TC until a time where it is unmanagable
20:32:26 * ttx doesn't want bloat
20:32:26 <anotherjesse> and then fix it
20:32:34 <jbryce> PTLs plus X number of generally elected seats (4-5)
20:32:41 <bcwaldon> ttx: how many ptls will we have for the next 9 months?
20:32:52 <jbryce> 7
20:33:00 <anotherjesse> nova,glance,swift,keystone,cinder,quantum,dash
20:33:00 <jbryce> if cinder makes it in
20:33:02 <bcwaldon> ttx: nova, glance, swift, keystone, quantum, horizon
20:33:08 <bcwaldon> so 6 or 7
20:33:16 <bcwaldon> I think we will be fine for the next 9 months :)
20:33:24 <ttx> cinder, at least two other projects filing in incubation...
20:33:26 * heckj agrees
20:33:36 <bcwaldon> whats the time frame on forming this TC?
20:33:37 <anotherjesse> ttx: which two other projects/
20:33:59 <ttx> anotherjesse: unified cli, ceilometer, heat...
20:34:05 <heckj> ttx: I understand your point, but I think you're making a mountain out of a mole hill here
20:34:27 <anotherjesse> I would argue that those aren't core
20:34:34 <ttx> heckj: I would prefer that everyone is on the TC for the same reason. That sounded fair. You would get elected anyway :)
20:34:38 <bcwaldon> ttx: anotherjesse they wont be for at least 9 months
20:34:50 <anotherjesse> bcwaldon: even then, are they essential iaas
20:34:52 <jbryce> the current structure is 5 generally elected seats, all core PTLs, plus 4 appointed. if we remove the 4 appointed seats, we have 4 spots before we even get back to the size we are right now
20:34:56 <bcwaldon> anotherjesse: thats another discussion
20:35:04 <bcwaldon> anotherjesse: (I agree with you)
20:35:30 <jbryce> bcwaldon: we need to decide on the structure within the next few weeks and be ready for a transition in august to september timeframe
20:35:30 <bcwaldon> jbryce: I like that plan
20:35:44 <heckj> ttx: kind of you to say, but not exactly the point
20:35:46 <ttx> jbryce: If that's what everyone wants, I'll fold. I'd prefer to design a long-lasting solution rather than something we need to revisit soon
20:35:49 <jbryce> bcwaldon: it may slip past that by a month or so, but that's the timeline we're shooting for
20:35:50 <bcwaldon> jbryce: ok, so once we actually form this thing we've still got 6 months
20:36:27 <ttx> let's ask it the other way around: what's the problem with all-elected members ?
20:36:58 <ttx> some project PTL might not be in ? so what. It's not as if decisions were unanimous
20:37:00 <bcwaldon> ttx: I feel like the PTLs have already been identified as critical leadership, and their inherently *technical* skills are necessary
20:37:15 <bcwaldon> ttx: but I might just be talking myself up, here :)
20:37:30 <ttx> bcwaldon: if the TC is elected by project contributors, you'll get PTL-like people on the TC
20:37:42 <ttx> note that we only let contributors vote
20:38:13 <bcwaldon> ttx: that is true
20:38:14 <ttx> think of it as a super-PTL vote. All contributors choose the 9 best people.
20:38:25 <ttx> Instead of half of them being selecetd by subgroups
20:38:36 <bcwaldon> ttx: I'd also like to look at this more like the electoral college than the popular vote
20:38:46 <bcwaldon> ttx: I dont want a super project (nova) to have all the representation on cross-project matters
20:38:51 <jbryce> ttx: i think the issue is underrepresentation of smaller projects
20:39:23 <ttx> jbryce: smaller projects will have to be underrepresented. If we create a project for each core plugin, there will be a lot of them
20:39:34 <ttx> and it would be unfair to consider them less important than others
20:39:53 <bcwaldon> ttx: I *really* want to make sure we agree on what a PTL is
20:40:07 <jbryce> what is a core plugin? how is that different from a core project?
20:40:40 <jbryce> we have a definition and process for determining that something becomes part of "core OpenStack"...is that the same thing you're referring to?
20:41:09 <ttx> jbryce: if we continue to split Nova into smaller bits (like for Cinder)... there will be a lot of new core projects. Not counting those that will file for inclusion
20:41:33 <ttx> I'd hate it if we decided to reject a core project just because the TC feels crowded
20:41:50 <bcwaldon> ttx: I would too, and if we got to that point we would have to fix the TC
20:41:55 <jbryce> when i asked earlier what else might get split from nova besides networking and block storage, it didn't seem like people had a really long list
20:41:59 <ttx> That's why I recommended a fixed number and get them all elected
20:42:10 <ttx> That's fair and it scales.
20:42:18 <bcwaldon> ttx: I still dont agree that its fair
20:42:36 <bcwaldon> ttx: well, its "fair" but it may not give the best representation
20:42:36 <jbryce> can we take a straw poll to see where people are standing on the idea of having PTLs plus generally elected seats for the makeup of the TC?
20:42:56 <bcwaldon> I'm sure many people have alt+tabbed away by this point :)
20:43:02 <ttx> bcwaldon: I don't think it's fair that memebrs of smaller projects, or members of multiple projects, get multiple attempts to select their TC member
20:43:12 <jbryce> e.g. the Technical Committee would consist of all PTLs plus 5 generally elected seats
20:43:24 <jbryce> bcwaldon: no joke
20:43:35 <mtaylor> nah. this is where the action is
20:43:37 <anotherjesse> ttx: that's an odd way of looking at PTL to TC relation
20:43:41 <bcwaldon> mtaylor: you dont count!
20:43:49 <anotherjesse> ttx: the PTL position is more important than the TC imho
20:43:57 <ttx> bcwaldon: fairness: basically, the vote of a strong contributor to Nova has less weight than the vote of a small contributor to cinder and glance
20:44:07 <johnpur> anotherjesse: +1
20:44:08 <anotherjesse> PTL is about leading a project, people don't become active in many of them to try to get TC or PBB or whatever
20:44:53 <bcwaldon> ttx: but if we segment up Nova, the weights will even out
20:45:26 <ttx> bcwaldon: you still get more power if you're a small contributor to all projects rather than a big contributor to all of them
20:45:40 <ttx> err...
20:45:40 <anotherjesse> ttx: the weight should be about how wise/practical/... the person is, not the value of their project.  If vishy was a total asshole and didn't try to work with the other projects he wouldn't have the same position
20:45:52 <ttx> bcwaldon: you still get more voting power if you're a small contributor to all projects rather than a big contributor to only one of them
20:46:10 <bcwaldon> ttx: ok, well I'm at the point where I'm going to #agree to #disagree
20:46:57 <ttx> bcwaldon: I think all-elected is the only way to have fair representation. That said, we can bend the rule if we thing something else is more important
20:46:57 <jbryce> so....
20:47:09 <anotherjesse> the PTLs are elected
20:47:12 <bcwaldon> ttx: I know, I've been listening to you
20:47:12 <ttx> like making sure all PTLs as leaders of this community will be at TC
20:47:39 <jbryce> heckj, notmyname, vishy: do you have an opinion on this?
20:47:43 <johnpur> ttx: the ptl's are all elected now.
20:47:50 <danwent> ttx: so all elected means getting rid of appointed as well?
20:48:16 <ttx> danwent: sure
20:48:19 <jbryce> danwent: appointed seats are going away in either scenario
20:48:23 <heckj> jbryce: All PTLs + 5 generally elected seats
20:48:24 <johnpur> it sounds like the tc is simply aggregating the ptl's and giving them (as a group) a wider charter
20:48:34 <danwent> ttx: k, wasn't sure
20:48:40 <jbryce> options are a) 9 seats, all elected generally or b) PTLs plus 5 generally elected seats
20:49:05 <notmyname> jbryce: PTLs should have a seat. voters should have a commit in the past 2 release cycles. no proxy votes
20:49:15 <johnpur> do we think that the non-ptl members of the PPB are adding value?
20:49:16 <bcwaldon> jbryce: you're proposing two different sizes of TC, yes?
20:49:27 <anotherjesse> johnpur: speaking as one ;)
20:49:30 <jbryce> bcwaldon: yes. one is fixed and one is variable with the number of projects
20:49:31 <bcwaldon> johnpur: yes
20:49:42 <danwent> do we have a proof-point how "how large is too large"?   Or just guessing?
20:49:47 <notmyname> johnpur: when they attend... :-)
20:49:48 <johnpur> this may help in the decision
20:50:03 <bcwaldon> jbryce: kk, just pointing out that the latter will be 11-12 for the G-whiz time frame
20:50:14 <jbryce> bcwaldon: correct
20:50:21 <notmyname> danwent: generally about 10-12 is the max effective size of a group
20:50:37 <danwent> notmyname: seems reasonable
20:50:47 <bcwaldon> notmyname: citation needed
20:50:51 <jbryce> danwent: we've been 14-15 for around a year
20:51:07 <notmyname> bcwaldon: http://en.wikipedia.org/wiki/Dunbar%27s_number
20:51:17 <danwent> jbryce: yet we struggle for qourum at the start of meetings?
20:51:24 <danwent> didn't realize we were that big.
20:51:30 <bcwaldon> notmyname: well done
20:51:51 <jbryce> danwent: we haven't had that problem for a while. i think that was more process failure on my part than our size
20:52:00 <johnpur> dunbar's number is 100-200 :)
20:52:02 <notmyname> bcwaldon: actually, I think that's the wrong reference, but the principle is there :-)
20:52:13 <johnpur> that's a lot of ptls!
20:52:18 <bcwaldon> notmyname: wait
20:52:23 <bcwaldon> notmyname: yes, just read into it
20:52:26 <bcwaldon> notmyname: 150!
20:52:54 <ttx> Last remark: should the "gating projects" that we just decided would exist as official projects have leaders ? Would they be considered "PTLs" and get a seat to the TC ?
20:53:22 <ttx> sigh. I'd prefer if we didn't have to artifically limit the number of projects and leaders just to avoid committee bloat
20:53:25 <anotherjesse> ttx: I hope not
20:53:26 <bcwaldon> ttx: did I miss some context for that first question?
20:53:48 <anotherjesse> ttx: are they official core projects?
20:53:55 * anotherjesse missed somethign
20:54:01 <johnpur> ttx: agree. we need a system that scales to the natural size of the openstack project
20:54:02 <ttx> bcwaldon: previous topic. Proposal created "library projects" and "gating projects" as official openstack projects
20:54:03 <jbryce> i thought they were getting a non-core designation
20:54:13 <mtaylor> ++
20:54:15 <ttx> so PTLs = core only ?
20:54:24 <ttx> other projects don't get to have a leader ?
20:54:37 <ttx> or they are not 'important enough' to have a seat ?
20:54:40 <mtaylor> anybody can have any leader they want
20:54:51 <bcwaldon> ttx: maybe not a PTL in the governance we set up
20:55:08 <mtaylor> otherwise we'd just call them core projects
20:55:21 <ttx> ok, so your governance is also about deciding which kind of leaders actually should have a reserved seat on the TC
20:55:42 <bcwaldon> ttx: I'd call that a side-effect, but yes
20:55:50 <danwent> one way to look at this is as a representative democracy… with PTLs having a spot on TC, each developer is guaranteed to have a representative on the TC that they work closely with.  Albiet with skewed voting power, as ttx notes.  Seems new approach makes it easy for a dev not to really know anyone on the TC, especially if they contribute to a smaller project.   Not sure if that is a goal we consider important though.
20:55:51 <ttx> so only PTLs-as-in-core-project
20:56:12 <ttx> danwent: good summary
20:56:28 <ttx> Like I said, I'm ready to accept some skew... I just want to do it for good reasons
20:56:34 <jbryce> ttx: that was my thought. that's why i keep tying it back to the core project designation
20:56:57 <jbryce> the purpose of the community and development process is to produce the core software projects
20:57:08 <bcwaldon> 2 minutes, turkish
20:57:11 <ttx> not because some people are afraid to lose their seat, but because we actually want that kind of representation
20:57:12 <jbryce> lots of other activities and projects related to that and that make that work
20:57:54 <ttx> jbryce: what size would be the limit at which you would reconsider that PTL+5 model ?
20:58:31 <jbryce> ttx: dunbar's number? = )
20:58:36 <ttx> haha
20:58:37 <jbryce> i don't have a specific number in mind
20:58:38 <johnpur> lol
20:58:54 <notmyname> lol
20:59:08 <ttx> frankly, I would expect the PTLs would get elected anyway, as proved by last election (where some PTLs were also running for the free seats)
20:59:09 <jbryce> we've moved to having an average of about a meeting a month and with proper notice have been able to reach quorum and have good discussions
20:59:23 <jbryce> so i don't think even 15 is too many
20:59:28 <ttx> the benefit of the "pure 9" model is that it has bloat-containment built-in
20:59:33 <jbryce> true
20:59:39 <jbryce> well...we're out of time
20:59:55 <jbryce> i'll send something to the list to follow up
20:59:56 <jbryce> thanks everyone
20:59:59 <jbryce> #endmeeting