<div dir="ltr">Then it might fit the purpose to rename the technical committee to governance committee or other terms. If we have a technical committee not investing time to lead in technical evolvement of OpenStack, it just seems odd to me. <div><br></div><div>TC should be a place good developers aspired to, not retired to. BTW this is not a OpenStack-only issue but I see across multiple open source communities.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 4, 2019 at 4:51 AM Emmet Hikory <<a href="mailto:persia@shipstone.jp">persia@shipstone.jp</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">All,<br>
    I’ve spent the last few years watching the activities of the <br>
technical committee , and in recent cycles, I’m seeing a significant <br>
increase in both members of our community asking the TC to take action <br>
on things, and the TC volunteering to take action on things in the <br>
course of internal discussions (meetings, #openstack-tc, etc.).  In <br>
combination, these trends appear to have significantly increased the <br>
amount of time that members of the technical committee spend on “TC <br>
work”, and decreased the time that they spend on other activities in <br>
OpenStack.  As such, I suggest that the Technical Committee be <br>
restricted from actually doing anything beyond approval of merges to the <br>
governance repository.<br>
<br>
    Firstly, we select members of the technical committee from amongst <br>
those of us who have some of the deepest understanding of the entire <br>
project and frequently those actively involved in multiple projects and <br>
engaged in cross-project coordination on a regular basis.  Anything less <br>
than this fails to produce enough name recognition for election.  As <br>
such, when asking the TC to be responsible for activities, we should <br>
equally ask whether we wish the very people responsible for the <br>
efficiency of our collaboration to cease doing so in favor of whatever <br>
we may have assigned to the TC.<br>
<br>
    Secondly, in order to ensure continuity, we need to provide a means <br>
for rotation of the TC: this is both to allow folk on the TC to pursue <br>
other activities, and to allow folk not on the TC to join the TC and <br>
help with governance and coordination.  If we wish to increase the <br>
number of folk who might be eligible for the TC, we do this best by <br>
encouraging them to take on activities that involve many projects or <br>
affect activities over all of OpenStack.  These activities must <br>
necessarily be taken by those not current TC members in order to provide <br>
a platform for visibility to allow those doing them to later become TC <br>
members.<br>
<br>
    Solutions to both of these issues have been suggested involving <br>
changing the size of the TC.  If we decrease the size of the TC, it <br>
becomes less important to provide mechanisms for new people to develop <br>
reputation over the entire project, but this ends up concentrating the <br>
work of the TC to a smaller number of hands, and likely reduces the <br>
volume of work overall accomplished.  If we increase the size of the TC, <br>
it becomes less burdensome for the TC to take on these activities, but <br>
this ends up foundering against the question of who in our community has <br>
sufficient experience with all aspects of OpenStack to fill the <br>
remaining seats (and how to maintain a suitable set of folk to provide <br>
TC continuity).<br>
<br>
    If we instead simply assert that the TC is explicitly not <br>
responsible for any activities beyond governance approvals, we both <br>
reduce the impact that being elected to the TC has on the ability of our <br>
most prolific contributors to continue their activities and provide a <br>
means for folk who have expressed interest and initiative to broadly <br>
contribute and demonstrate their suitability for nomination in a future <br>
TC election<br>
<br>
    Feedback encouraged<br>
<br>
-- <br>
Emmet HIKORY<br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Zhipeng (Howard) Huang</div><div dir="ltr"><br></div><div dir="ltr">Principle Engineer</div><div>OpenStack, Kubernetes, CNCF, LF Edge, ONNX, Kubeflow, OpenSDS, Open Service Broker API, OCP, Hyperledger, ETSI, SNIA, DMTF, W3C</div><div dir="ltr"><br></div></div></div></div></div></div></div></div>