confirmed On 04/20/2015 05:56 AM, Thierry Carrez wrote: > Hello list, > > I'm announcing my candidacy for the Technical Committee elections. > > I have been serving as the chair of the Technical Committee since its > inception, but I think we are at a critical point in the evolution of > the role of the Technical Committee, and if you allow it, I'd like to be > around to help drive us through this transition. > > In particular, I'd like the Technical Committee to push in 3 new > directions during the Liberty cycle: > > > 1. Step out of the way > > As I explained on [1], I think over the last cycles the TC pushed the > regulation and "ask for permission" cursor so far we actually start > preventing things from happening. I'd like us to come back to a point > where our community is more trusted by default, where it asks more for > forgiveness and less for permission. So I'd like the Technical Committee > to look into its processes and see where it can remove itself from the > action pipeline, and retreat back to being an appeals board should a > problem arise. > > [1] http://ttx.re/stepping-out-of-the-way.html > > > 2. Start addressing real issues > > I think it is part of the role of the Technical Committee members to > detect, investigate and help solving issues in our development > community. As we grow, we can't expect every member to know everything > about every project in OpenStack. But each member should be able to dive > into specific project(s) and report issues to the group. Subgroups of > members should be able to work together on proposing plans to solve > long-standing issues. That means spending more than one hour per week on > TC matters, which is why I'd like us to give preference in TC elections > to candidates who have enough time on their hands, as explained on [2]. > > [2] http://ttx.re/tech-committee-candidates.html > > > 3. Push toward both ends of the scale space > > Taking a step back on those last 5 years, I think the natural forces > behind OpenStack development made us cover the middle-tier of usage > quite well: reasonably large private IaaS systems (~10k VMs) with a need > for extra features and accepting the resulting complexity. They did not > make us cover the hyper-scale end (public clouds with millions of VMs in > a very active usage pattern) that well, because that end > is a specific use case that needs specific trade-offs, and not so many > users need/push those. And it did not make us cover the basic system > end, where people want to deploy a base IaaS compute system without > bells and whistles, and without a team of 100 admins, most of them SDN > specialists. > > Our development ecosystem won't naturally go and cover those use cases > (lack of business and/or market), but those are essential long-term. We > all need extremely-large OpenStack public clouds to burst hybrid > workloads to. And we all need people to be able to experiment with > OpenStack in POCs, labs and universities. This is the two directions I > want to encourage in the near future. > > > More generally, I think it is the role of the Technical Committee > members to provide a long-term vision. To influence where we are going, > beyond where the market forces push us. To inspire our developers to > work (or support work) to cover areas that their employer might not > immediately care about in the short term. To make OpenStack better and > more universal in the long run. > > Thanks for your consideration, >
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
