Open Stack

On 29 Sep 2016, at 16:00, gordon chung wrote:

>
> On 29/09/16 04:35 PM, John Dickinson wrote:
>>
>> I am concerned that there is a current focus on preserving the status
>> quo. There's focus on policies and rules instead of use cases; there's
>> focus on conformity instead of innovation; there's focus on forced
>> prioritization instead of inclusivity.
>
> i fully agree with this pov. there's a sentiment among certain members
> that if you choose a path different from the norm, you are not
> "following the OpenStack way".
>
> my question is (i guess this in theory could be ask to everyone), the
> the TC has historically been a reactive council that lets others ask for
> change and acts as the final approver (arguably, just my opinion). do
> you believe the TC should be a proactive committee that drives change?
> and if yes, to what scope? i realise the follow up is very open-end and
> vague and i apologise for this.

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.

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.

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.

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:

 * Every project installable in 10 minutes or less.
 * Most projects independently installable to solve a specific use case for a deployer.
 * 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?
 * How do we reduce the average time a patch spends in review?
 * Why are people adopting OpenStack? If people move away from OpenStack (in whole or in part), what was missing in OpenStack?
 * What improvements can we make to facilitate team communication across time zones and across cultural lines?
 * How do we provide our corporate sponsors with a reasonably-accurate view of future development work?
 * How do we support new languages and deployment tools in OpenStack projects?
 * What improvements can we make to integrate proprietary software and hardware into our projects?
 * How does OpenStack work in a world where "cloud" is dominated by AWS, Google, and Microsoft?

etc.



--John



>
>>
>> If I am elected to the TC, I will look at every decision in the light
>> of these two needs. I will not focus on codifying rules, and I will
>> not focus on keeping OpenStack small and homogeneous. I will do what I
>> can to help the OpenStack community increase adoption today and remain
>> relevant as the industry changes.
>>
>
> yay to less codifying rules!
>
> cheers,
> -- 
> gord
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160929/ae06b628/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160929/ae06b628/attachment.pgp>