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]
> 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]
> 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,

Attachment: signature.asc
Description: OpenPGP digital signature

OpenStack Development Mailing List (not for usage questions)

Reply via email to