<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 29 Sep 2016, at 16:00, gordon chung wrote:</p>
<p dir="auto"></p></div>
<div style="white-space:pre-wrap"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><div dir="auto">
</div><div dir="auto">On 29/09/16 04:35 PM, John Dickinson wrote:
</div><blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><div dir="auto">
</div><div dir="auto">I am concerned that there is a current focus on preserving the status
</div><div dir="auto">quo. There's focus on policies and rules instead of use cases; there's
</div><div dir="auto">focus on conformity instead of innovation; there's focus on forced
</div><div dir="auto">prioritization instead of inclusivity.
</div></blockquote><div dir="auto">
</div><div dir="auto">i fully agree with this pov. there's a sentiment among certain members
</div><div dir="auto">that if you choose a path different from the norm, you are not
</div><div dir="auto">"following the OpenStack way".
</div><div dir="auto">
</div><div dir="auto">my question is (i guess this in theory could be ask to everyone), the
</div><div dir="auto">the TC has historically been a reactive council that lets others ask for
</div><div dir="auto">change and acts as the final approver (arguably, just my opinion). do
</div><div dir="auto">you believe the TC should be a proactive committee that drives change?
</div><div dir="auto">and if yes, to what scope? i realise the follow up is very open-end and
</div><div dir="auto">vague and i apologise for this.
</div></blockquote></div>
<div style="white-space:normal">
<p dir="auto">The TC is not small enough, and OpenStack is too big, for the TC to proactively drive and manage change across all OpenStack projects. In fact, I think OpenStack is too big for any one group to try to manage a task for all projects. I like how the docs team has been pushing docs into each project repository. That distributes the load and solves a scaling problem.</p>
<p dir="auto">In my experience as a PTL for a single OpenStack project, I've learned that I can influence by suggestion, but I cannot mandate anything. In a large part, my role has been to respond to what the community is doing by removing any barriers that exist, monitoring the status of the team, connecting people working on similar tasks, and providing a general vision of where we're going as a project.</p>
<p dir="auto">I see the role of the TC in much the same way. The TC should not be the high-priesthood of OpenStack where we go to present our supplications before we're allowed to do something. Individual projects should default to "doing" and the TC's role there is to make sure barriers for "doing" are removed. The individual projects are what initial and drive change in OpenStack, based on the needs of their specific users, and the TC aggregates those changes across projects to facilitate communication with the broader ecosystem about OpenStack in general.</p>
<p dir="auto">I'm sure I could go on for quite a while about specifics I'd like to see. Here's a short list of bullets of things I'd love to see the TC take on:</p>
<ul>
<li>Every project installable in 10 minutes or less.</li>
<li>Most projects independently installable to solve a specific use case for a deployer.</li>
<li>Track contributor activity to identify when and why people contribute. Is there some pattern that can be used to identify when someone might leave the community? Is there a pattern of how long-term contributors start? What are the major barriers for new contributors?</li>
<li>How do we reduce the average time a patch spends in review?</li>
<li>Why are people adopting OpenStack? If people move away from OpenStack (in whole or in part), what was missing in OpenStack?</li>
<li>What improvements can we make to facilitate team communication across time zones and across cultural lines?</li>
<li>How do we provide our corporate sponsors with a reasonably-accurate view of future development work?</li>
<li>How do we support new languages and deployment tools in OpenStack projects?</li>
<li>What improvements can we make to integrate proprietary software and hardware into our projects?</li>
<li>How does OpenStack work in a world where "cloud" is dominated by AWS, Google, and Microsoft?</li>
</ul>
<p dir="auto">etc.</p>
<p dir="auto">--John</p>
<p dir="auto"></p></div>
<div style="white-space:pre-wrap"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><div dir="auto">
</div><blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><div dir="auto">
</div><div dir="auto">If I am elected to the TC, I will look at every decision in the light
</div><div dir="auto">of these two needs. I will not focus on codifying rules, and I will
</div><div dir="auto">not focus on keeping OpenStack small and homogeneous. I will do what I
</div><div dir="auto">can to help the OpenStack community increase adoption today and remain
</div><div dir="auto">relevant as the industry changes.
</div><div dir="auto">
</div></blockquote><div dir="auto">
</div><div dir="auto">yay to less codifying rules!
</div><div dir="auto">
</div><div dir="auto">cheers,
</div><div dir="auto">--
</div><div dir="auto">gord
</div><div dir="auto">
</div><div dir="auto">__________________________________________________________________________
</div><div dir="auto">OpenStack Development Mailing List (not for usage questions)
</div><div dir="auto">Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
</div><div dir="auto"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" style="color:#777">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</div></blockquote></div>
<div style="white-space:normal">
</div>
</div>
</body>
</html>