The content below is taken from the original (OpenStack Developer Mailing List Digest October 8-14), to continue reading please visit the site. Remember to respect the Author & Copyright.

SuccessBot Says

loquacities: Newton docs are live on docs.openstack.org! Way to go docs team \o/
dhellmann: OpenStack Newton is officially released!
tristanC: 6 TC members elected for Ocata [1].
dulek: Cinder gate is now voting on basic rolling upgrades support. One step closer to get assert:supports-rolling-upgrade tag.
More

Thoughts on the TC Election Process

When deciding to run, candidates write a long thoughtful essay on their reasons for wanting to serve on the TC.
- It is rare for anyone to ask follow-up question, or to challenge the candidates to explain their position more definitively.
- Some people pick by names they are most familiar with and don’t read those candidacy posts.
- It is believed that it’s rare for someone who hasn’t been a PTL of a large project to be elected.
- An example of implicit bias, blind auditions for musical orchestras radically changing the selection results [2].
Proposal: have candidates self-nominate, but instead of a long candidacy letter, just state their interests in serving.
- After nominations close, the election officials will assign each candidate with a non-identifying label (e.g. random number).
- Candidates will post their thoughts and positions and respond to questions from people.
- Candidacy essay would be posted in the campaign period, instead of the nomination period. This will exclude biographical information.
- Perhaps candidates can forward their responses to election officials, who will post them for the candidates and identify only by candidate number.
- The voting form will only list the candidates’ numbers.
Thoughts on the proposal:
- Not allowing people to judge peoples’ character introduces a fraud incentive. You can tell friends your number secretly. Their implicit bias will make them think this is morally ok, and make them more likely to vote for you.
- It can be important to identify candidates. For some people, there’s a difference in what they say, and what they end up doing when left calling the shots.
- Familiarity doesn’t necessarily equal bias. Trust is not bias.
- A good example [2] of needing to know the speaker and words came out of the thread. Also a reason why anonymous elections for leaders are a bad idea and favor native English speakers.
We need several things:
- Allow time between the nomination and the voting. Some candidates don’t announce until the last day or two. This doesn’t allow much time to get to know them.
- How to deal with timezone differences. One candidate may post an answer early and get more reaction.
- Reduce the effect of incumbency.
The comparison of orchestra auditions was brought up a couple of cycles ago as well, but could be a bad comparison. The job being asked of people was performing their instrument, and it turns out a lot of things not having to do with performing their instrument were biasing the results.
- The job of the TC is:
  - Putting the best interests of OpenStack at heart.
  - Be effective in working with a diverse set of folks in our community to get things done.
  - To find areas of friction and remove them.
  - Help set the overall direction for the project that community accepts.
- Writing a good candidacy email isn’t really good representation of those abilities. It’s the measure of writing a good candidacy email, in English.
Sean Dague hopes that when voters vote in the election that they are taking the reputation of individuals into account.
- Look at the work they did across all of OpenStack.
- How they got consensus on items.
- What efforts they are able to get folks to rally around and move forward.
- When they get stuck and get unstuck.
- When they ask for help and/or admit they’re out of their element.
- How they help new folks.
- How they work with long timers.
- It’s easy to dismiss it as a popularity contest, however, this is about evaluating the plausible promise that the individuals put forward. Not just ideas they have, but how likely they are to be able to bring them to fruition.
Full thread

API Workgroup News

API usability tests being conducted at the Barcelona summit [3].
Two lively discussions [4]:
- Collecting and improving error messages across OpenStack.
- Request semantics with regards to GET and body processing.
New guidelines:
- Add a warning about JSON expectations [5].
Guidelines currently under review:
- Specify time intervals based filtering queries [6].
Full thread

Project Teams Gathering from the Ops Perspective

The first PTG will be held February 20-24 in Atlanta, GA at the downtown Sheraton hotel.
Tickets are $100.
Group rate is $185/night.
Registration will go live in the next couple of weeks.
Horizontal/cross project teams will meet Monday and Tuesday.
Vertical projects will meet Wednesday through Friday.
There’s a lot of great planning happening around the PTG planning, however, it’s going take some time for operators to figure it out.
Tom Fifield gives some notes for the operators:
- Check out the diagram on the PTG site [7].
  - We’re finally acknowledging a release cycle starts with planning. Now we’ll be finalizing a release, while planning another.
  - This puts the summit at the right place to get feedback and decent ideas from users.
- The OpenStack summit is the place the entire community gets together.
  - The PTG doesn’t mean the summit becomes a marketing thing. The summit can also include:
    - Pre-spec brainstorming
    - Feedback with users
    - Be involved in strategic direction.
- Don’t expect Ops at the PTG
  - The PTG has been designed for space to get stuff done. Unless a user is deep in code, they won’t be there. If you want feedback from users, use the summit.
For ops-focused teams like Kolla, participating at OpenStack summits and Ops mid cycles are essential. Not everyone has to go to every event though. These teams should organize who is going to what events.
If you’re going to the summit in Barcelona, Thierry and Erin from the OpenStack Foundation will be hosting informational presentation on the PTG [8].
Full thread

Next PTL/TC Elections Timeframes

At the last TC meeting, TC members discussed future election period, with consideration of the OpenStack Summit and Project Teams Gathering.
The TC charter which uses “Design Summit” and “Summit” interchangeably is no longer valid and requires change.
- There was a focus on limiting the impact change to avoid the need to modify the Foundation bylaws [9].
- PTL elections would continue to be organized around development cycle boundaries.
- TC elections would continue to be organized relative to OpenStack Summit dates.
Full thread

Running Non-Devstack Jobs in Python Projects

Devstack is the common tool to deploy OpenStack in CI environments.
- However, it doesn’t deploy OpenStack in production versus tools like Kolla, Fuel, TripleO, etc.
Things might (and did) break when deploying OpenStack outside of Devstack:
- SSL was not tested. Some projects still don’t test with SSL enabled.
- IPv6 is not tested everywhere.
- Production scenarios with HA (HAproxy and/or Pacemaker) are not tested.
Proposal:
- This is not about removing Devstack. The idea is to add more coverage in an interactive way.
- Projects like TripleO and Heat have been added as CI jobs in the experimental pipeline.
- A draft document about increasing coverage in different projects [10].
Finding a balance between enough testing and overusing infra resources is tricky.
- Also anything that’s more complicated than unit tests has > 0% chance of failure.
Another proposal:
- Running periodic testing and moving forward reference hashes everyday if tests pass.
  - Allows deployment tools to move forward automatically.
  - Quite close to master, but not tightly coupled into every change.
  - This is pretty much what the OpenStack-Ansible project does for its “integrated build”.
Full thread