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