Hi all! I'd like to announce my candidacy to serve as a TC member.
About me: I'm a software engineer at Red Hat, and have been working full-time on OpenStack for the last two years. I've been heavily involved with the Heat project since before it was incubated, served as PTL for the Havana cycle, and remain one of the top contributors to the project. During Icehouse, I've been trying to improve my knowledge and involvement with other projects, in particular contributing fixes to keystone and working to improve Heat's functional testing via tempest. Platform: Working on orchestration provides a unique view of OpenStack - it's essential to learn at least a little bit about every other project, because orchestration integrates with everything. This is an exciting challenge, and provides a pretty broad perspective on issues such as API and client consistency. I am of the opinion that OpenStack should be inclusive by default and, trademark considerations aside, should not be limited to a "core" of components. Instead I see OpenStack developing into an increasingly powerful collection of abstractions, providing consistency for users and flexibility for deployers. If elected I would strive to work as an advocate for new and recently graduated projects, seeking to identify common problems and opportunities for improved integration. The issues I would consider priorities were I to be elected are detailed below, the common theme is basically better communication, efficiency and reuse: 1. API consistency and reuse I believe we're making great progress and improving API consistency but there are still challenges and opportunities, primarily around improving cross-project consistency, communication and reuse. I see the TC's role here as primarily one of facilitating and encouraging cross-project discussion, providing direction and monitoring progress. Closely related to this is encouraging projects to more pro-actively collaborate via cross-project initiatives such as oslo. Ultimately we all benefit if we can reduce duplication of effort and collaborate on shared solutions. I believe that the TC should be providing clear leadership and direction which encourages projects to avoid long term fragmentation as ultimately it harms the user community (users operators and deployers getting inconsistent experience) and developers (maintenance burden and lack of knowledge transfer between projects). Finally client API consistency should be improved, in particular working towards common solutions for version discovery and common version-agnositc interfaces which reduce the (IME considerable) pain users experience when API versions change. 2. Mentoring of new projects Having experienced the incubation process, and subsequent rapid growth of the Heat project, I've got first-hand experience of the challenges experienced by new projects seeking to become part of OpenStack. There is a lot of accumulated experience and knowledge in the community, and in many cases this "lore" is not documented for new projects and contributors. I think the TC should strive to encourage more active mentoring of new projects, by implementing a scheme where a representative from the incubated project is paired with a person experienced with the area related to a graduation requirement, over time this can lead to identifying areas of common confusion, improved documentation, and hopefully engage new contributors (and reviewers) to participate in components related to gate integration and testing. 3. Review of current PTL model After serving as the Heat PTL for Havana, I was left with the (apparently not that uncommon) impression that there are aspects of the PTL role and responsibilities which are sub-optimal for a diverse open-source project. As such, I would propose a review of the current model, where a PTL's primary function is release management and coordination, not really technical leadership in many cases. I would encourage consideration of a move to a "subsystem maintainer" structure, similar to that used for the Linux kernel, where individual projects and project sub-components are afforded more autonomy and less granular management, in exchange for an increased requirement for participation in automated gate integration testing. There may be other alternative solutions, but I believe it's time to initiate some discussion around what may be the most effective and appropriate strategy for project release management and leadership in an increasingly diverse and fast-moving environment. Thanks for your consideration! -- Steve Hardy Red Hat Engineering, Cloud _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev