confirmed
On 10/10/2014 01:52 AM, David Lyle wrote:
> I would like to announce my candidacy for the Technical Committee.
>
> I have been working on OpenStack since the beginning of the Grizzly cycle.
> I started working on OpenStack as part of HP's Public Cloud effort. I spent
> two years working to make Horizon work in that scale of environment and
> making Horizon the user facing interface of HP's Public Cloud. I have
> served as a Horizon core reviewer since the Havana cycle and I am starting
> my third release as Horizon PTL. Currently, I am employed by Intel in their
> Open Source Technology Center.
>
> I have been a regular observer of the Technical Committee during my time as
> PTL. The role of the TC is large and difficult. I appreciate the efforts of
> all those that have served during that time and I would like to thank them
> for their dedication. One takeaway from those observations in the very
> heavy representation on the TC by infrastructure and core services. I think
> the TC would be benefit from more representation higher up the stack. I
> think Heat, Horizon, Solum, TripleO have a unique perspective into
> cross-project issues and the TC would benefit from such representation.
>
> In my opinion, the fundamental problems the TC needs to address in the Kilo
> cycle are handling growth and cross-project alignment. I'll be honest, I
> don't have a master plan to address these, but I think I'm well equipped
> and motivated to help develop that plan with other members of the TC.
>
> Thanks for your consideration,
> David Lyle
>
>
> Topic: OpenStack Mission: How do you feel the technical community is doing
> in meeting the OpenStack Mission?
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> "To produce the ubiquitous OpenSource Cloud Computing platform that will
> meet the needs of public and private clouds regardless of size, by being
> simple to implement and massively scalable."
>
> I think this is a very broad mission. Breadth is not a problem, but there
> are a few implications in here. One OpenStack needs to be inclusive, to
> accomplish ubiquity we need to strive to allow deployers to meet their
> widely varied needs. So we need to support a large ecosystem. The ecosystem
> around OpenStack is certainly large, but there is a fairly sharp dichotomy
> between OpenStack and not OpenStack, recognizing larger parts of the
> ecosystem is important for ecosystem health. As to public vs private and
> massively scalable aspects, I think we have room for growth. Running a
> public cloud on OpenStack requires not insignificant changes, and OpenStack
> has room for improvement on the scalability front. We need greater feedback
> from the very large deployers to make sure we meet those scalability needs.
>
> Topic: Technical Committee Mission: How do you feel the technical committee
> is doing in meeting the technical committee mission?
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> "The Technical Committee ("TC") is tasked with providing the technical
> leadership for OpenStack as a whole (all official programs, as defined
> below). It enforces OpenStack ideals (Openness, Transparency, Commonality,
> Integration, Quality...), decides on issues affecting multiple programs,
> forms an ultimate appeals board for technical decisions, and generally has
> oversight over all the OpenStack project."
>
> The technical committee has spent much of the last cycle acting as gate
> keeper. I would like to see it take a larger role in overall architectural
> direction in OpenStack. I believe one of the greatest challenges we face is
> coherency of vision and direction. I think this should be the province of
> the technical committee to act as an arbitrar and architectural board. I
> don't hold that overall technical direction is to be dictated by the TC,
> rather the TC merely helps unify that direction and insures consistency.
> Obviously this is a herculean task, but I believe OpenStack needs more
> clearness in direction.
>
> Topic: Contributor Motivation: How would you characterize the various
> facets of contributor motivation?
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Contributors are motivated to contribute for various reasons. People
> contribute for personal interest, corporate interest, academic interest,
> and any mix of all three. Corporate interest covers a lot, from users to
> operators, vendors to consumers. Many ideas from our great community of
> diverse contributors helps drive us forward and keeps us honest and
> progressing.
>
> At the end of the day, OpenStack is cloud software that should be usable.
> We do need to temper the wouldn't it be neat if, with how will this work in
> real world application ranging from small test clouds to large public
> clouds. Services should strive to work across this spectrum. The difficulty
> is focusing these disparate motivations into a cohesive effort.
>
> Topic: Rate of Growth: There is no argument the OpenStack technical
> community has a substantial rate of growth. What are some of the
> consequences of this rate?
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> The phenomenal growth rate is our greatest asset. It's also our largest
> pain point. We need to reevaluate our processes to cope with this increased
> strain. I think we need to remain inclusive, but temper how much the
> ecosystem taxes the cross-project resources of OpenStack.
>
> Topic: New Contributor Experience: How would you characterize the
> experience new contributors have currently?
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> There are several things OpenStack has right for new contributors. The
> documentation on how to contribute is easy to discover and very thorough.
> Requisite information for submitting a patch is well presented. The
> OpenStack developer is also a very open and inclusive community. New
> contributors are treated with civility, respect, and appreciation. This is
> something I am very proud of and strive to maintain. From there, the
> contributor experience becomes a more daunting. Although the documentation
> for getting started is very good, there is still a great deal of process
> and configuration required to apply that documentation toward contributing
> your first patch. Hopefully a new contributor's patch is a bug fix. Once
> that hurdle is crossed, the experience is much better. Patch review
> turn-around time is a large concern as well, and again comes back to
> dealing with the scale of OpenStack.
>
> I know there has been numerous discussion regarding the CLA requirement.
> For most contributors this is not much of an impediment. However, I
> understand some employers are not willing to let employees contribute based
> on the CLA requirement. I'd like to strive to include those contributors as
> well.
>
> Topic: Communication: How would you describe our current state of
> communication in the OpenStack community?
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> For a global community of developers, I think communication is very good.
> However, from the feedback I receive, the burden for communication is too
> high. With 19+ recognized projects and 20+ other satellite projects vying
> for developer eyeballs, it is very overwhelming for contributors to filter
> and find the important items to them. I think this is primarily another
> symptom of community growth.
>
> Topic: Relationship with the Foundation Board: The technical committee
> interacts with the foundation board on several different fronts. How would
> you describe these interactions?
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> As an observer of the technical committee the past couple of years, the
> open interaction I've witnessed has primarily focused on Def Core. There is
> a fundamental disconnect between the objectives of the Technical Committee
> and the Foundation Board on this issue. This is expected as the two bodies
> have very different end goals. The board's role is to protect the OpenStack
> trademark in which many companies have heavily invested. Allowing the
> trademark to carry a very broad definition potentially lessens the return
> on this investment. The technical committee is made of the builders of
> OpenStack, believers in an open process of development. To restrict the way
> operators can use OpenStack to satisfy how the trademark can be applied
> runs counter to the open process. An impasse is the result. My position is
> that the components of OpenStack are replaceable, the burden for the
> trademark should allow for API compatibility, but I fall on the developer
> side of the fence.
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
