Tag: Governance


OpenStack Technical Committee Update (July 1)

July 2nd, 2014 — 2:02pm

The last TC update discussed the DefCore effort being led by the OpenStack Foundation Board. The DefCore subcommittee had made some requests for input from the TC. This week we held a special meeting entirely focused on clarifying some points around DefCore and providing some responses to the questions given to us.

It’s also worth noting that prior to the meeting, Jonathan Bryce posted a very comprehensive review of the existing framework that governs OpenStack trademark usage. This thread is absolutely worth reading for a good understanding of this topic.

Scope of DefCore

The first point on the agenda was to clarify the scope of DefCore. Specifically, we wanted to clarify which uses of the trademark this effort was applicable to. There were some important points of clarification reached during the meeting on this topic. DefCore is only about the commercial uses of the trademark. Currently, this only includes the “Powered by OpenStack” trademark license program. We also understand that the board has left open the option of an “OpenStack Compatible” trademark program in the future that may have a different set of requirements than what we are discussing right now.

Jonathan clarified this very well during the meeting (at 20:25:56):

The license agreement in question is called OpenStack Powered and is intended for use with products and services that are built using OpenStack software. for instance a public cloud “FooTron Compute Powered By OpenStack”, an appliance “FooTron Appliance Powered by OpenStack”, a distribution “FooTron OpenStack”. All of those different products would be held to the same standard. in other words, they would all be required to expose the same capabilities (testable over the APIs) and include the same actual community-developed software bits (designated sections).

DefCore Capabilities

The DefCore subcommittee has been working to define a set of capabilities with associated tests that would be used as a part of the process to determine if a given OpenStack product or service was allowed to use the OpenStack mark under the “Powered by OpenStack” trademark program. They have been using a scoring system to determine which capabilities should be required. Part of the input into this scoring is “technical direction”. They do not want to include a required capability that the technical community does not view as something we want to keep around long term. The TC was asked to provide input on some capabilities where the future was unclear. We have been working on clarifying all of these points in two reviews to the OpenStack technical governance repository. We are close to reaching a final conclusion on these points.

DefCore capabilities are currently defined in a JSON file as a mapping to a set of tests. One recommendation that the TC provided was that a 1 or 2 sentence description for each capability would help provide easier understanding of the intended coverage of a capability. Otherwise, interested parties must go read each test to understand exactly what it’s attempting to verify. While this would be helpful, we all agreed that this does not actually block progress. It would just make things easier.

The final point discussed in this section of the meeting was the intersection of capabilities and designated sections of code. Generally you have to implement designated section code and deliver core capabilities, but it was clarified that designated sections of code would only be required if there is a corresponding capability that is deemed required. If a project has no required capabilities, then the use or distribution of that project is not required.

Designated Sections

This was the most controversial part of the meeting. The DefCore committee had requested that the TC provide a proposed set of designated sections of code. This input would then be used as the basis for what code is required under the “Powered by OpenStack” trademark license program. After much discussion, the TC was able to reach consensus on this topic and a response was provided in this meeting.

One of the primary responsibilities of the TC is to define the OpenStack integrated release which is released every 6 months. This is the set of things that we vouch for. We have a defined process with a set of requirements projects must satisfy to apply for incubation and potentially eventually graduate to be a part of this integrated release. Defining a subset of the integrated release would make the TC appear to endorse or encourage replacing part of their work with proprietary alternatives. The TC is an elected representation of the contributors to the project and as such it does not feel it should declare a subset of the integrated release less important than the rest.

We do value that the Apache license provides the option of replacing part of the code with alternative solutions, and we respect that it’s the board prerogatives to determine trademark use policy. So we would like to clearly recognize that it’s the board’s right to define the subset of the integrated release required by commercial trademark license agreements (such as the “OpenStack Powered” trademark program), and therefore they should have final say on “designated sections”. A process to achieve that was suggested by Mark McLoughlin on the Defcore list, where the Board would propose designated sections and ask the wider community for comments on it, then make the final calls based on that feedback.

Comment » | Governance

OpenStack Technical Committee Update

June 11th, 2014 — 4:29pm

The OpenStack Technical Committee (TC) meets weekly. During the meeting on 2014-06-03, one of the topics we discussed was the relatively low turnout for the TC election as compared to the PTL elections. The most productive thing to come out of that discussion was that we needed to do a better job of communicating what the TC is working on and why it is important. As a result, we will be posting regular updates about the TC to the OpenStack blog. This first post will likely be a bit longer as it’s important to set up some of the context for the things we are currently discussing.

How the TC was formed is described in the history of OpenStack open source project governance  by the current chair of the TC, Thierry Carrez.

Openness

Open governance is an important value held by OpenStack and the TC wants to be as open as possible. In addition to these regular updates, you can find the details of everything we do in a few other places. The archives of the openstack-tc mailing list are open. Our weekly IRC meetings are public and logged.

All project governance work is managed in a git repository and changes are reviewed in gerrit in the same way that we review code. Everyone that is interested is invited to comment on proposed governance changes. You can find a list of changes under review here. You can find a list of previously approved changes and the discussions that happened on their reviews here.

Project Incubation and Graduation Requirements

One of the responsibilities of the TC is to manage the set of projects that are included in the OpenStack integrated release. New projects may apply to be incubated. Incubated projects will later be reviewed for graduation from incubation. A graduated project is a part of the integrated release.

As OpenStack has grown, it became clear that we needed to be much more clear around our expectations of projects for incubation and graduation. Over the last year we worked to formalize these expectations in a document in the governance repository. We approved the first version of this document on December 2, 2013. We have been updating it ever since as more issues need to be clarified. You can find the latest version of that document in the Governance git repository.

Toward the end of the Icehouse development cycle, we started a process of going through all projects already in the integrated release and evaluating them against this criteria. For any project that has gaps against these expectations, we require that the PTL present a plan for addressing these gaps during the Juno cycle.

Glance

The latest project review was for Glance, during the TC meeting on 2014-06-10. The only gap found for Glance was around tempest test coverage. Specifically, Tempest does not cover uploading a real binary image to Glance. The Glance PTL will now come up with a plan to address this gap and the TC will review progress against this plan throughout the Juno cycle.

We actually spent quite a bit of this meeting talking about Glance. The most controversial topic is around the proposal to increase its scope. Glance is currently focused on disk images. There is a proposal against the governance repository to expand its scope to cover a more general definition of artifacts. The particular use cases that inspired this direction for Glance is the desire to store things like Heat or Murano templates. In the end, there seems to be broad support for the general direction proposed. We still have some work to do to get the wording of the mission statement in a form that everyone is comfortable with.

Finally, the Glance project brought an important cross-project API consistency question to the TC. Specifically, they have an alternative method for how they would like to expose actions through their API which is different from how Nova does it currently, for example. There was support for the specific proposal. However, it raises the larger question about how we go about best working toward cross project API consistency. We would love to have someone lead an effort to create a cross-project API style guide for OpenStack, but it’s unclear who will do it and exactly who would review and approve the content. I expect this to be an ongoing discussion.

You can find the full mailing list thread that spawned this API discussion in the archives starting in May and continuing in June.

Designate

Another project that has received a lot of attention recently is Designate, which provides DNS as a Service for OpenStack. This is a sorely needed feature for OpenStack deployments so I’m very happy to see the progress made in this area.

The project recently applied for incubation. This is actually the second time that Designate has applied for incubation. The first time was one year ago, in June of 2013. After the first application, the TC concluded that it was a bit too early to incubate the project. There were various concerns, but the primary one was the level of involvement in the project, in terms of individuals and separate companies.

Designate has matured a good bit over the last year and I’m proud to announce that the application has been approved. Designate is now an incubated project!

The earliest Designate will be included in the integrated release would be the K release. Given that we’re already well into the Juno cycle, the L release seems more realistic. This is a topic that the TC would revisit at the end of the Juno development cycle.

Future Updates

We want to make these updates from the TC as useful as possible. If you have any comments or suggestions, please let us know!

Comment » | Communication, community, Governance

OpenStack Blog Authors Code Of Conduct

June 7th, 2012 — 12:09pm

With the current number of authors on the community blog I think it’s a good idea to make sure we all have a clear understanding of what it means to have an account on such visible community asset. I think it would be good for the whole community to have a brief, clear, understandable code of conduct for all existing authors and for the future ones. We discussed on our community team and we came up with the OpenStack Blog Authors Code Of Conduct below.  We’ll publish this together with other community policies (like the OpenStack Event policy) in the next days: add your comments below or send them to the community team.

OpenStack.org Blog is the asset owned by the community and a platform where to share thoughts, ideas, reports and news about OpenStack. All the authors of blog posts have the responsibility to respect this common space while being grateful for the opportunity it represents. As a writer you should write articles respecting other’s opinions, even if you disagree. The OpenStack Community will benefit from sharing, debating and reflecting rather than discounting and disparaging others’ thoughts. Remember that as an author of OpenStack.org blog, the community trusts you to give voice to the community as a whole.

Writers accept these simple principles:

  • Prefer facts to opinions: be always aware that what you publish will be read by thousands of people and that your opinion is not necessarily that of the whole community. Try to stick to facts, like reporting the result of a meeting, announcing upcoming community events, describing technical achievements.
  • Disclose, don’t promote: it’s good to let people know that a company is contributing to OpenStack, sponsoring an event and such but the OpenStack.org Blog is not the place to publish a company’s press release or other type of commercial offering message.
  • Contribute to the commons: our blog is licensed under the terms of Creative Commons Attribution Share-alike version 3 unported. Pay attention to the license of any material you add to the blog, make sure it’s released under compatible terms.

Comment » | Communication, community, Governance

OpenStack Governance Elections Spring 2012 Results

March 3rd, 2012 — 3:31pm

The OpenStack community has elected the Project Technical Leads and two members of the Project Policy Board. Here are the winners:

NOVA Project Technical Lead (1 position)

Winner:

KEYSTONE Project Technical Lead (1 position)

Winner:

HORIZON Project Technical Lead (1 position)

Winner:

SWIFT Project Technical Lead (1 position)

  • Only one candidate

Winner:

GLANCE Project Technical Lead (1 position)

Winner:

PROJECT POLICY BOARD (2 positions)

Winners:

Congratulations to you all! Good work everybody.

1 comment » | Communication, community, Governance

OpenStack Governance Elections Spring 2012: Time to vote!

February 27th, 2012 — 7:41pm

UPDATE: PPB election update: we need to reboot the voting process. Please accept our apology. Read more on http://ow.ly/9lNGf

The OpenStack community is called to elect the Project Technical Leads and two seats of the Project Policy Board. The nominations process is now officially closed and voting can start: all entitled to vote will receive a personal message via email on February 28 and have time until March 3 11:59 PST to vote. The email message will go to the email address included in the Authors file and the one provided during the registration for PPB votes.

The official list of nominees (in random order) is the following:

NOVA Project Technical Lead (1 position)

KEYSTONE Project Technical Lead (1 position)

HORIZON Project Technical Lead (1 position)

SWIFT Project Technical Lead (1 position)

GLANCE Project Technical Lead (1 position)

PROJECT POLICY BOARD (2 positions)

Voting process

Like previous OpenStack Governance Elections, we will use the Condorcet Internet Voting Service from Cornell University, http://www.cs.cornell.edu/andru/civs.html.  This tool uses the Condorcet method of voting which invokes ranking the  nominees instead of just selecting one choice. More information on this  methodology is at http://www.cs.cornell.edu/w8/~andru/civs/rp.html. All registered voters will receive an email with a unique link allowing them to privately vote.

Please note that the voting system is run using private polls with  restricted access to ensure voter authenticity; however all results will  be made public once the election ends. Voter anonymity is guaranteed.  The result’s ranking will be evaluated using Schulze (also known as Beatpath or CSSD) completion rule. If an individual should happen to be elected as both a PTL and General  Member of the PPB, then they will take their PTL seat only and the  elected General Member seat will go to the next highest vote getter in  the most recent election.  Thanks for participating in this essential process.

The election committee is made of Stefano Maffulli, Lloyd Dewolf and Dave Nielsen.

Comment » | community, Governance

OpenStack Governance Elections Spring 2012: Action Item For All Candidates

February 22nd, 2012 — 11:52pm

The OpenStack community is electing its Project Technical Leads and two members of the Project Policy Board. Details are at http://www.openstack.org/blog/2012/02/openstack-governance-elections-spring-2012/. On February 26 the nominations will close and the voting process will start on February 28 and finish on March 3rd.

The list of nominees is at http://etherpad.openstack.org/Spring2012-Nominees. It’s still open. You must register to vote for PPB on http://ppbelectionsregistration.openstack.org/

Before the voting process starts the election committee asks all nominees to create a page on OpenStack wiki and answer three simple questions:

1a. [for PPB] Since the last elections, what areas have you focused on and what contributions have you made in order to improve OpenStack as a whole?

1b. [for PTL] Since the last elections, what areas have you focused on and what contributions have you made in order to improve your project?

2a. [for PPB] What are the most pressing/important issues facing OpenStack as a whole?

2b. [for PTL] What are the most pressing/important issues facing your project?

3. What is your relationship to OpenStack & why is its success important to you and/or your company?

If you’re a candidate, create a wiki page using the template http://wiki.openstack.org/Governance/ElectionsSpring2012/[Firstname_Lastname] and answer those questions there. Feel free to add more content, too. Those pages will be included in the link sent to all voters.

The election committee is made of Stefano Maffulli, Lloyd Dewolf and Dave Nielsen.

Comment » | Communication, community, Governance

OpenStack Governance Elections Spring 2012

February 13th, 2012 — 1:00am

The time is once again upon us for our OpenStack Governance Elections. The OpenStack community is called to elect the Project Technical Leads and two seats of the Project Policy Board. The election committee is made of Stefano Maffulli, Lloyd Dewolf and Dave Nielsen.

  • February 16 – 26 11:59 PST: Nominations open.
  • February 28 – March 3 11:59 PST: Online voting open.
  • March 3 11:59 PST: Voting closed.

Final results will be posted immediately upon election close.

What seats are up for election

  • NOVA Project Team Lead (1 Position)
  • SWIFT Project Team Lead (1 Position)
  • GLANCE Project Team Lead (1 Position)
  • HORIZON Project Team Lead (1 Position)
  • KEYSTONE Project Team Lead (1 Position)
  • Project Policy Board (2 Open Positions)

How to nominate yourself or others as Project Technical Lead

Only OpenStack community members who have code in the respective OpenStack subproject are eligible to be elected as that subproject’s Project Team Lead. Please nominate someone from the developer community or yourself at http://etherpad.openstack.org/Spring2012-Nominees under the Nominees heading.  Please provide the name and email address of the nominee. The election committee will then confirm with the nominee that they are willing to run for the position.The list of Approved Candidates will be announced with a new blog post on openstack.org/blog when online voting opens (Feb 28).

How to nominate yourself or others as member of the Project Policy Board

Any registered member of the OpenStack Launchpad group is eligible to run or be nominated for a position on the Project Policy Board. If you want to vote and/or run for a seat you need to register on Launchpad and add yourself to the public OpenStack group on https://launchpad.net/~openstack. Please nominate someone from the community or yourself at http://etherpad.openstack.org/Spring2012-Nominees under the Nominees heading. Please give the name and email address of the nominee. The election committee will then confirm with the nominee that they are willing to run for the position. The list of Approved Candidates will be announced with a new blog post on openstack.org/blog right before the election starts.

How to register to vote for PTL

Only OpenStack community members who have code in the respective OpenStack subproject are eligible to vote for that subproject’s Project Team Lead.  The authoritative list of eligible voters and nominees is the Authors file in each repository. For example, the list of Nova authors is https://github.com/openstack/nova/blob/master/Authors.
Make sure your name and correct email address is there or you won’t be able to vote.

How to register to vote for Project Policy Board

Any registered member of the OpenStack Launchpad group is eligible to vote for the Project Policy Board. If you want to vote you need to register to Launchpad and add yourself to the public OpenStack group on https://launchpad.net/~openstack before registering as a voter using the form at http://ppbelectionsregistration.openstack.org/. Company affiliation is only collected as an interesting statistic; it has no effect on the outcome of the election.

Voting process

Like previous OpenStack Governance Elections, we will use the Condorcet Internet Voting Service from Cornell University, http://www.cs.cornell.edu/andru/civs.html. This tool uses the Condorcet method of voting which invokes ranking the nominees instead of just selecting one choice. More information on this methodology is at http://www.cs.cornell.edu/w8/~andru/civs/rp.html.

All registered voters will receive an email with a unique link allowing them to privately vote.

Please note that the voting system is run using private polls with restricted access to ensure voter authenticity; however all results will be made public once the election ends. Voter anonymity is guaranteed. The result’s ranking will be evaluated using Schulze (also known as Beatpath or CSSD) completion rule.

Thanks for participating in this essential process. Please remind your friends and colleagues to get involved, register and vote!

Comment » | Communication, community, Governance

OpenStack Governance Elections Fall 2011 – Results

September 5th, 2011 — 11:26am

The polls  for OpenStack Governance Elections closed. Congratulations to the winners and thank you all for participating in this election.

PROJECT POLICY BOARD (3 positions + 1 to replace resigning member)

Winners:

  1. Ewan Mellor
  2. Paul Voccio
  3. Monty Taylor
  4. Josh Kearney

Details of the poll results are visible.

The Project Technical Leads have not changed.

NOVA Project Technical Lead (1 position)

Winner: Vishvananda Ishaya

SWIFT Project Technical Lead (1 position)

Winner: John Dickinson

GLANCE Project Technical Lead (1 position)

Winner: Jay Pipes

1 comment » | Communication, Governance

OpenStack Governance Elections – Voting started

August 25th, 2011 — 4:21pm

Today at 12:00pm CDT the election process for the OpenStack has started.  The approved candidates for the Project Policy Board are:

  • Joe Heck
  • Soren Hansen
  • Rick Clark
  • Jason Cannavale
  • Christopher MacGown
  • Paul Voccio
  • Joe Arnold
  • Blake Yeager
  • Ewan Mellor
  • Brian Lamar
  • Monty Taylor
  • Josh Kearney
  • Chuck Thier
  • Rob Hirschfeld

The poll is currently running to elect the three new members and the replacement for Eric Day. If you are eligible to vote and have requested to be added to the official list of voters you should have received an email with instructions to cast your vote for the Project Policy Board (PPB). Poll will close on September 4th, 12pm CDT.

For the Team Lead positions in Nova, Swift and Glance projects no poll was necessary since we had only one candidate for each position. The Team Leads therefore are:

  • NOVA Project Technical Lead:  Vishvananda Ishaya
  • SWIFT Project Technical Lead:  John Dickinson
  • GLANCE Project Technical Lead: Jay Pipes

3 comments » | Communication, Governance

OpenStack Governance Elections – Voting Process

August 22nd, 2011 — 9:19am

This Wednesday at Noon CST, the OpenStack Governance Elections Nominations process will close and all approved candidates will be entered into the Election Tool.  Elections will run from August 25 – September 4 at Noon CST.

Elections

The following four separate votes will be conducted during this election cycle:

  • NOVA Project Team Lead (1 Position)
  • SWIFT Project Team Lead (1 Position)
  • GLANCE Project Team Lead (1 Position)
  • Project Policy Board (3 Open Seats)

In addition, Eric Day has resigned his seat on the PPB with a term ending Spring 2012. To fill his seat for the next 6 months, the 4th place vote getter in the Project Policy Board election will replace Eric and complete his term. This process change simplifies having to run a special election for his seat. Please contact me if you have any questions on this process for replacing Eric on the board.

Voter Eligibility

Each election has a separate policy for who can vote in the election. A complete review of this process can be found at http://www.openstack.org/blog/2011/08/openstack-governance-elections-coming-soon/. To be eligible to vote, please ensure that you meet these requirements by Noon CST on Wednesday August 25th.

Candidates

The current list of nominees is available at http://etherpad.openstack.org/Fall2011-Nominees.  If you are interested in being a nominee, please add yourself by Wednesday August 25th by Noon CST at which time nominations will close.

2 comments » | Communication, Governance

Back to top