confirmed On 04/15/2014 02:04 PM, Steven Hardy wrote: > 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 > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev