<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div class=""><br class="">
</div>
Are there some stats on the active electorate sizes ?
<div class=""><br class="">
</div>
<div class="">I have the impression that the voting AUCs were a smaller number of people than the contributors so a single election may result in less total representation compared to today’s UC & TC.
<div class="">
<div class=""><br class="">
</div>
<div class="">Tim<br class="">
<div class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 25 Feb 2020, at 17:00, Amy Marrich <<a href="mailto:amy@demarco.com" class="">amy@demarco.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">Option 1 is definitely the fastest though I do wish we could have a more unified name for the group. It's not just a UC issue of not having enough people to run, the last TC election I believe did not have an actual vote after nominations.
<div class=""><br class="">
</div>
<div class="">Either we have a unified group that oversees the direction of the community or keep them separate as they are now. </div>
<div class=""><br class="">
</div>
<div class="">OPS Meetup reports to the UC in a sense and is not a totally different group.</div>
<div class=""><br class="">
</div>
<div class="">Amy (spotz)</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Feb 25, 2020 at 9:23 AM Ghanshyam Mann <<a href="mailto:gmann@ghanshyammann.com" class="">gmann@ghanshyammann.com</a>> wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
---- On Tue, 25 Feb 2020 04:23:56 -0600 Thierry Carrez <<a href="mailto:thierry@openstack.org" target="_blank" class="">thierry@openstack.org</a>> wrote ----<br class="">
> Hi all,<br class="">
> <br class="">
> When our current project governance was established in 2012, we defined <br class="">
> two separate bodies. The Technical Committee represented developers / <br class="">
> code contributors to the open source project(s), while the User <br class="">
> Committee represented the operators running the resulting software, as <br class="">
> well as users of the APIs.<br class="">
> <br class="">
> That setup served us well in those early days. The focus on the upstream <br class="">
> side was strongly around *development* of code, we did not have that <br class="">
> many users, and even less users directly involved in upstream <br class="">
> development. A separate User Committee resulted in the formation of an <br class="">
> engaged community of users, and ensured that our community in general <br class="">
> (and our events in particular) took the needs of operators into account.<br class="">
> <br class="">
> Fast-forward to 2020: the upstream focus is more on maintenance. We now <br class="">
> have a lot of users, and thanks to the efforts of the UC they are <br class="">
> increasingly directly involved in the open source project development, <br class="">
> with several operators leading upstream project teams directly. There is <br class="">
> now limited UC-specific activity, and as such it is struggling to get <br class="">
> volunteers to step up for it: nobody nominated themselves for the last <br class="">
> round of election.<br class="">
> <br class="">
> Keeping two separate bodies to represent them maintains the illusion <br class="">
> that devs and ops are different breeds, and sometimes discourages <br class="">
> operators from running for the TC and more directly influence the shape <br class="">
> of the software. If anything, we need more ops representation at the TC, <br class="">
> and seeing people like mnaser being elected at (and chairing) the TC was <br class="">
> a great experience. I discussed the situation with the current UC <br class="">
> members, and we decided it's time to consider having a single <br class="">
> "community" and a single body to represent it.<br class="">
> <br class="">
> That body would tackle the traditional TC tasks (open source project <br class="">
> governance and stewardship) but also the UC tasks (user survey, <br class="">
> ambassador program...). That body would be elected by contributors, in a <br class="">
> large sense that includes the AUC definition. I feel like that would <br class="">
> help remove the artificial barriers discouraging users to get more <br class="">
> directly involved with software development and maintenance.<br class="">
> <br class="">
> There are multiple ways to achieve that, in increasing order of <br class="">
> complexity and bylaws changes needed:<br class="">
> <br class="">
> 1- No bylaws change<br class="">
> As bylaws changes take a lot of time and energy, the simplest approach <br class="">
> would be to merge the TC and UC without changing the bylaws at all. The <br class="">
> single body (called TC) would incorporate the AUC criteria by adding all <br class="">
> AUC members as extra-ATC. It would tackle all aspects of our community. <br class="">
> To respect the letter of the bylaws, the TC would formally designate 5 <br class="">
> of its members to be the 'UC' and those would select a 'UC chair'. But <br class="">
> all tasks would be handled together.<br class="">
<br class="">
Thanks a lot, ttx for starting this thread.<br class="">
<br class="">
option 1 looks more feasible way but few question/feedback:<br class="">
- How we will execute the "designate 5 members from TC and select UC chair"?<br class="">
<br class="">
If by volunteer call from TC?<br class="">
I think this can lead to the current situation where very few members are interested to<br class="">
serve as UC. I am afraid that we will get 5 volunteers and a chair.<br class="">
<br class="">
If by force?<br class="">
I do not think this is or should be an option :). But if then how we make sure the TC<br class="">
members are ok/good to handle the UC tasks on the non-technical side for example<br class="">
ambassador program.<br class="">
<br class="">
- Will there be any change in TC elections, votes weightage and nomination? by this change<br class="">
of a new subteam under TC? <br class="">
<br class="">
- I think along with the merging proposal, we should distribute the current tasks handled by UC<br class="">
among TC, Ops group, foundation etc. For example, the ambassador program, local user group<br class="">
interaction or any other managerial tasks should be excluded from TC scope. <br class="">
If we would like to merge all then I think we should rename TC to Steering Committee or<br class="">
something which is option 3.<br class="">
<br class="">
- What about merging UC into Ops team, they are more close to users/operators and active<br class="">
in terms of the meetup and providing feedback etc.<br class="">
<br class="">
-gmann<br class="">
<br class="">
> <br class="">
> 2- Minimal bylaws change<br class="">
> Same, but all mentions of the UC would be removed from the bylaws <br class="">
> (affecting sections 4.12, 4.14, and Appendix 10). This would require a <br class="">
> simple vote by the Board of Directors, and would avoid some confusion <br class="">
> and having to formally designate a subset of the TC to respect the <br class="">
> letter of the bylaws.<br class="">
> <br class="">
> 3- Maximal bylaws change<br class="">
> Create a new body ("steering committee" for example) replacing the TC <br class="">
> and the UC. This would require changing sections 4.1, 4.12, 4.13, 4.14, <br class="">
> 4.20, 7.1.b, 7.4, 9.1, 9.2.d, and Appendixes 4 and 10. Section 4.13, 7.1 <br class="">
> and 7.4 being heavily protected in the bylaws, they require special <br class="">
> votes by each class of Foundation members, probably a multi-year effort. <br class="">
> A lot of documentation would also need to be changed in case the TC is <br class="">
> renamed.<br class="">
> <br class="">
> I personally don't think the benefit of the change offsets the large <br class="">
> cost of option (3). Given the current vacancy in the UC makeup I would <br class="">
> recommend we pursue option 1 immediately (starting at the next TC <br class="">
> election in April), and propose minimal bylaws change to the board in <br class="">
> parallel (option 2).<br class="">
> <br class="">
> Thoughts ?<br class="">
> <br class="">
> -- <br class="">
> Thierry Carrez<br class="">
> <br class="">
> <br class="">
<br class="">
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</div>
</body>
</html>