The content below is taken from the original (Technical Committee Highlights September 25, 2015), to continue reading please visit the site. Remember to respect the Author & Copyright.
Tagging efforts for diversity and deprecation policies
Since tagging projects for a percentage of diverse affiliations, we are also discussing the idea of an inverse tag to indicate non-diversity. Some of us on the TC are unsure that a lack of diversity is an indicator that the project isn’t useful or successful, especially in the early days of a project’s maturation. Others would like to indicate that a lack of diversity could mean support would be easy to pull.
We’ve passed a “follows-standard-deprecation” tag that projects can apply to in order to indicate their deprecation policies follow the standard for all OpenStack projects. No projects are asserting following it yet, but we want to make sure the community knows we’ve written the policies for configuration option and potential feature deprecation.
Code of Conduct (CoC)
Cindy Pallares reached out to the Technical Committee with a proposal to improve OpenStack’s current CoC. After reviewing CoCs from other communities and listening to the feedback provided by Cindy and other members, the OpenStack’s CoC will be updated and improved to make it organized by context, such as online or in events. Please, do stay in touch and follow this discussion closely as it’ll have an impact on the whole community. We do have Code of Conducts in place for both contexts, but we actively review these as the community grows, diversifies, and matures to ensure it meets the needs of all members.
Considering additional programming languages
There’s a new resolution defining how projects written in other programming languages should be evaluated. The resolution talks about how we mostly contain and plan for Python projects with JavaScript (Dashboard) and bash (DevStack) also enabled in time. The discussion started a few meetings ago where things like big tent, community impact, infrastructure impact, technology impact were highlighted and discussed at a high level. Since this topic impacts the whole community, we appreciated the input we got and welcome all to read and understand the resolution. We came to a conclusion that we do consider additional languages but need to ensure common process and tooling for infrastructure, testing, and documentation as part of the larger picture especially for OpenStack services.
Handling project teams with no candidate PTLs
We got “our garumphs out” over time zone confusion with the recent candidacy round and approved PTLs for these projects:
- Security: Robert Clark
- Key Manager (barbican): Douglas Mendizabal
- Application Catalog (murano): Serg Melikyan
For the Containers (magnum) project, the two candidates Hongbin Lu and Adrian Otto agreed to an election to resolve a timing problem with the candidate submissions. The election officials agreed they could run another PTL election just for magnum, so look for that ballot in your inbox if you worked on the magnum codebase in the last six months.
MagnetoDB didn’t receive any candidacies. Unfortunately, this project hasn’t received contributions in a while and it’s being considered for removal from the Big Tent. Read more about the current discussion on the review itself.
As a reminder, our charter currently states, “Voters for a given project’s PTL election are the active project contributors (“APC”), which are a subset of the Foundation Individual Members. Individual Members who committed a change to a repository of a project over the last two 6-month release cycles are considered APC for that project team.” The names of repositories of projects are kept in the projects.yaml file in the openstack/governance repository.
Applications incoming and welcoming
As always we are busy reviewing incoming applications to OpenStack governance.
The Monasca project has been asked to keep working on their open processes and keep their application alive in the queue. Three items of feedback for their consideration are: 1) Integration tests should be running as a gate job with OpenStack CI tools, using devstack as a bootstrap. 2) Host the source in gerrit (review.openstack.org) so that all components and tests are well-understood. 3) Better integration with the rest of the community, using more patterns of communication and doing cross-project liaison work.
We discussed the Kosmos project application, a very new project, formed initially from members of Designate and Neutron LBaaS, to provide global server load balancing for OpenStack clouds. A few of the TC members would prefer to see more evidence of their work, others think that the new definition of working like OpenStack should enable them to apply and be accepted.
We are thinking about the CloudKitty application and Juji Charms for Ubuntu application to OpenStack governance and will consider at the next TC meeting. As guidance for timing, we add motions presented before Friday 0800 UTC to the next Tuesday meeting agenda for discussion.
Cross-project Track
At the upcoming Mitaka summit, the community will have a dedicated track for cross-project discussion. The period for proposals is now open and it’ll be until October 9th. It’s possible to propose sessions on ODSREG. More info can be found on this thread.