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