[Openstack-operators] Developer Mailing List Digest March 3-9th

[Mike Perez]

HTML version: https://www.openstack.org/blog/?p=8361

Contribute to the Dev Digest by summarizing OpenStack Dev List threads:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/
* http://lists.openstack.org/pipermail/openstack-sigs


Success Bot Says

* kong: Qinling now supports Node.js runtime(experimental)
* AJaeger: Jenkins user and jenkins directory on images are gone.
  /usr/local/jenkins is only created for legacy jobs
* eumel8: Zanata 4 is now here [0]
* smcginnis: Queens has been released!!
* kong: welcome openstackstatus to #openstack-qinling channel!
* Tell us yours in OpenStack IRC channels using the command "#success "
* More: https://wiki.openstack.org/wiki/Successes

[0] - https://www.translate.openstack.org


Thanks Bot Says
===
* Thanks dhellmann for setting up community wide goals + good use of storyboard
  [0]
* Thanks ianw for kind help on upgrading to Zanata 4 which has much better UI
  and improved APIs!
* Tell us yours in OpenStack IRC channels using the command "#thanks "
* More: https://wiki.openstack.org/wiki/Thanks

[0] - https://storyboard.openstack.org/#!/project/923

Community Summaries
===
* Release countdown [0]
* TC report [1]
* Technical Committee status update [2]

[0] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128036.html
[1] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/127991.html
[2] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128098.html


PTG Summaries
=
Here's some summaries that people wrote for their project at the PTG:

* Documentation and i18n [0]
* First Contact SIG [1]
* Cinder [2]
* Mistral [3]
* Interop [4]
* QA [5]
* Release cycle versus downstream consuming models [6]
* Nova Placements [7]
* Kolla [8]
* Oslo [9]
* Ironic [10]
* Cyborg [11]

[0] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/127936.html
[1] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/127937.html
[2] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/127968.html
[3] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/127988.html
[4] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/127994.html
[5] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128002.html
[6] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128005.html
[7] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128041.html
[8] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128044.html
[9] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128055.html
[10] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128085.html
[11] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128094.html


OpenStack Queens is Officially Released!

Congratulations to all the teams who contributed to this release! Release notes
of different projects for Queens are available [0] and a list of projects [1]
that still need to approve their release note patches!

[0] - https://releases.openstack.org/queens/
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127813.html

Full message: 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127812.html


Release Cycles vs. Downstream consumers PTG Summary
===
Notes can be found on the original etherpad [0]. A TC resolution is in review
[1]

TLDR summary:
* No consensus on longer / shorter release cycles
* Focus on FFU to make upgrades less painful
* Longer stable branch maintenance time (18 months for Ocata)
* Bootstrap the "extended maintenance" concept with common policy
* Group most impacted by release cadence are packagers/distros/vendors
* Need for finer user survey questions on upgrade models
* Need more data and more discussion, next discussion at Vancouver forum
* Release Management team tracks it between events

[0] - https://etherpad.openstack.org/p/release-cycles-ptg-rocky
[1] - https://review.openstack.org/#/c/548916/

Full message: 
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128005.html


Pros and Cons of face-to-face Meetings
==
Some contributors might not be able to attend the PTG for various reasons:

* Health issues
* Privilege issues (like not getting visa or travel permits)
* Caretaking responsibilities (children, other family, animals, plants)
* Environmental concerns

There is a concern if this is preventing us from meeting our four opens [1] if
people are not able to attend the events. 

The PTG sessions are not recorded, but there is a super user article on how
teams can do this themselves [0]. At the PTG in Denver, the OpenStack
Foundation provided bluetooth speakers for teams to help with remote
participation.

Consensus is this may not be trivial for everyone and it could 

[openstack-dev] Developer Mailing List Digest March 3-9th

[Mike Perez]

HTML version: https://www.openstack.org/blog/?p=8361

Contribute to the Dev Digest by summarizing OpenStack Dev List threads:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/
* http://lists.openstack.org/pipermail/openstack-sigs


Success Bot Says

* kong: Qinling now supports Node.js runtime(experimental)
* AJaeger: Jenkins user and jenkins directory on images are gone.
  /usr/local/jenkins is only created for legacy jobs
* eumel8: Zanata 4 is now here [0]
* smcginnis: Queens has been released!!
* kong: welcome openstackstatus to #openstack-qinling channel!
* Tell us yours in OpenStack IRC channels using the command "#success "
* More: https://wiki.openstack.org/wiki/Successes

[0] - https://www.translate.openstack.org


Thanks Bot Says
===
* Thanks dhellmann for setting up community wide goals + good use of storyboard
  [0]
* Thanks ianw for kind help on upgrading to Zanata 4 which has much better UI
  and improved APIs!
* Tell us yours in OpenStack IRC channels using the command "#thanks "
* More: https://wiki.openstack.org/wiki/Thanks

[0] - https://storyboard.openstack.org/#!/project/923

Community Summaries
===
* Release countdown [0]
* TC report [1]
* Technical Committee status update [2]

[0] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128036.html
[1] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/127991.html
[2] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128098.html


PTG Summaries
=
Here's some summaries that people wrote for their project at the PTG:

* Documentation and i18n [0]
* First Contact SIG [1]
* Cinder [2]
* Mistral [3]
* Interop [4]
* QA [5]
* Release cycle versus downstream consuming models [6]
* Nova Placements [7]
* Kolla [8]
* Oslo [9]
* Ironic [10]
* Cyborg [11]

[0] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/127936.html
[1] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/127937.html
[2] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/127968.html
[3] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/127988.html
[4] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/127994.html
[5] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128002.html
[6] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128005.html
[7] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128041.html
[8] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128044.html
[9] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128055.html
[10] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128085.html
[11] - http://lists.openstack.org/pipermail/openstack-dev/2018-March/128094.html


OpenStack Queens is Officially Released!

Congratulations to all the teams who contributed to this release! Release notes
of different projects for Queens are available [0] and a list of projects [1]
that still need to approve their release note patches!

[0] - https://releases.openstack.org/queens/
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127813.html

Full message: 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127812.html


Release Cycles vs. Downstream consumers PTG Summary
===
Notes can be found on the original etherpad [0]. A TC resolution is in review
[1]

TLDR summary:
* No consensus on longer / shorter release cycles
* Focus on FFU to make upgrades less painful
* Longer stable branch maintenance time (18 months for Ocata)
* Bootstrap the "extended maintenance" concept with common policy
* Group most impacted by release cadence are packagers/distros/vendors
* Need for finer user survey questions on upgrade models
* Need more data and more discussion, next discussion at Vancouver forum
* Release Management team tracks it between events

[0] - https://etherpad.openstack.org/p/release-cycles-ptg-rocky
[1] - https://review.openstack.org/#/c/548916/

Full message: 
http://lists.openstack.org/pipermail/openstack-dev/2018-March/128005.html


Pros and Cons of face-to-face Meetings
==
Some contributors might not be able to attend the PTG for various reasons:

* Health issues
* Privilege issues (like not getting visa or travel permits)
* Caretaking responsibilities (children, other family, animals, plants)
* Environmental concerns

There is a concern if this is preventing us from meeting our four opens [1] if
people are not able to attend the events. 

The PTG sessions are not recorded, but there is a super user article on how
teams can do this themselves [0]. At the PTG in Denver, the OpenStack
Foundation provided bluetooth speakers for teams to help with remote
participation.

Consensus is this may not be trivial for everyone and it could 

[Openstack-operators] [forum] Brainstorming Topics for Vancouver 2018

[Mike Perez]

Hi all,

Welcome to the topic selection process for our Forum in Vancouver. Note that
this is not a classic conference track with speakers and presentations.
OpenStack community members (participants in development teams, SIGS, working
groups, and other interested individuals) discuss the topics they want to cover
and get alignment on and we welcome your participation.

The Forum is for the entire community to come together, to create a 
neutral space rather than having separate "ops" and "dev" days. Users should
should aim to come with ideas for for the next release, gather feedback on the
past version and have strategic discussions that go beyond just one release
cycle. We aim to ensure the broadest coverage of topics that will allow for
multiple parts of the community getting together to discuss key areas within
our community/projects.

There are two stages to the brainstorming:

1. Starting today, set up an etherpad with your team and start 
discussing ideas you'd like to talk about at the Forum and work out 
which ones to submit - just like you did prior to the design summit.

2. Then, in a couple of weeks, we will open up a more formal web-based 
tool for you to submit abstracts for the most popular sessions that came 
out of your brainstorming.

Make an etherpad and add it to the list at: 
https://wiki.openstack.org/wiki/Forum/Vancouver2018

One key thing we'd like to see (as always?) is cross-project 
collaboration, and discussion between every area of the community. Try 
to see if there is an interested working group on the user side to add 
to your ideas.

Examples of typical discussions that include multiple parts of the 
community getting together to discuss:

  * Strategic, whole-of-community discussions, to think about the big
picture, including beyond just one release cycle and new technologies
  o eg Making OpenStack One Platform for containers/VMs/Bare Metal
(Strategic session) the entire community congregates to share
opinions on how to make OpenStack achieve its integration engine
goal
  * Cross-project sessions, in a similar vein to what has happened at
past design summits, but with increased emphasis on issues that are
of relevant to all areas of the community
  o eg Rolling Upgrades at Scale (Cross-Project session) -- the
Large Deployments Team collaborates with Nova, Cinder and
Keystone to tackle issues that come up with rolling upgrades
when there's a large number of machines.
  * Project-specific sessions, where developers can ask users specific
questions about their experience, users can provide feedback from
the last release and cross-community collaboration on the priorities
and 'blue sky' ideas for the next release.
  o eg Neutron Pain Points (Project-Specific session) --
Co-organized by neutron developers and users. Neutron developers
bring some specific questions they want answered, Neutron users
bring feedback from the latest release and ideas about the future.

Think about what kind of session ideas might end up as: 
Project-specific, cross-project or strategic/whole-of-community 
discussions. There'll be more slots for the latter two, so do try and 
think outside the box!

This part of the process is where we gather broad community consensus - 
in theory the second part is just about fitting in as many of the good 
ideas into the schedule as we can.

Further details about the forum can be found at: 
https://wiki.openstack.org/wiki/Forum

-- 
Mike Perez (thingee)


pgpdTcV6ZoOex.pgp
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [forum] Brainstorming Topics for Vancouver 2018

[Mike Perez]

Hi all,

Welcome to the topic selection process for our Forum in Vancouver. Note that
this is not a classic conference track with speakers and presentations.
OpenStack community members (participants in development teams, SIGS, working
groups, and other interested individuals) discuss the topics they want to cover
and get alignment on and we welcome your participation.

The Forum is for the entire community to come together, to create a 
neutral space rather than having separate "ops" and "dev" days. Users should
should aim to come with ideas for for the next release, gather feedback on the
past version and have strategic discussions that go beyond just one release
cycle. We aim to ensure the broadest coverage of topics that will allow for
multiple parts of the community getting together to discuss key areas within
our community/projects.

There are two stages to the brainstorming:

1. Starting today, set up an etherpad with your team and start 
discussing ideas you'd like to talk about at the Forum and work out 
which ones to submit - just like you did prior to the design summit.

2. Then, in a couple of weeks, we will open up a more formal web-based 
tool for you to submit abstracts for the most popular sessions that came 
out of your brainstorming.

Make an etherpad and add it to the list at: 
https://wiki.openstack.org/wiki/Forum/Vancouver2018

One key thing we'd like to see (as always?) is cross-project 
collaboration, and discussion between every area of the community. Try 
to see if there is an interested working group on the user side to add 
to your ideas.

Examples of typical discussions that include multiple parts of the 
community getting together to discuss:

  * Strategic, whole-of-community discussions, to think about the big
picture, including beyond just one release cycle and new technologies
  o eg Making OpenStack One Platform for containers/VMs/Bare Metal
(Strategic session) the entire community congregates to share
opinions on how to make OpenStack achieve its integration engine
goal
  * Cross-project sessions, in a similar vein to what has happened at
past design summits, but with increased emphasis on issues that are
of relevant to all areas of the community
  o eg Rolling Upgrades at Scale (Cross-Project session) -- the
Large Deployments Team collaborates with Nova, Cinder and
Keystone to tackle issues that come up with rolling upgrades
when there's a large number of machines.
  * Project-specific sessions, where developers can ask users specific
questions about their experience, users can provide feedback from
the last release and cross-community collaboration on the priorities
and 'blue sky' ideas for the next release.
  o eg Neutron Pain Points (Project-Specific session) --
Co-organized by neutron developers and users. Neutron developers
bring some specific questions they want answered, Neutron users
bring feedback from the latest release and ideas about the future.

Think about what kind of session ideas might end up as: 
Project-specific, cross-project or strategic/whole-of-community 
discussions. There'll be more slots for the latter two, so do try and 
think outside the box!

This part of the process is where we gather broad community consensus - 
in theory the second part is just about fitting in as many of the good 
ideas into the schedule as we can.

Further details about the forum can be found at: 
https://wiki.openstack.org/wiki/Forum

-- 
Mike Perez (thingee)


pgpIwWCB79kzi.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [DriverLog] DriverLog future

[Mike Perez]

On 11:44 Mar 01, Ilya Shakhat wrote:
> Hi!
> 
> For those who do not know, DriverLog is a community registry of 3rd-party
> drivers for OpenStack hosted together with Stackalytics [1]. The project
> started 4 years ago and by now contains information about 220 drivers. The
> data from DriverLog is also consumed by official Marketplace [2].
> 
> Here I would like to discuss directions for DriverLog and 3rd-party driver
> registry as general.
> 
> 1) Being a single community-wide registry was good initially, it allowed to
> quickly collect description for most of drivers in a single place. But in a
> long term this approach stopped working - not many projects remember to
> update the information stored in some random place, right?
> 
> Mike already pointed to this problem a year ago [3] and the idea was to
> move driver list to projects (and thus move responsibility to them too) and
> have an aggregated list of drivers produced by infra. Do we have any
> progress in this direction? Is it a time to start deprecation of DriverLog
> and consider transition during Rocky release?
> 
> 2) As a project with 4 years history DriverLog's list only increased over
> the time with quite few removals. Now it still has drivers with the latest
> version Liberty or drivers for non-maintained projects (e.g. Fuel). While
> it maybe makes sense to keep all of them for operators who run older
> versions, it may produce a feeling that the majority of drivers are old.
> One of solutions for this is to show by default drivers for active releases
> only (Pike and ahead). If done this will apply to both DriverLog and
> Marketplace.
> 
> Any other ideas or suggestions?

Hey Ilya,

Yes there is progress. Thanks to others who have helped me, we have a project
called sphinx-feature-classification [0]. This allows a project to use a sphinx
directive to generate a support matrix based on drivers recorded in a INI file
[1] which lives in the project's repository.

I have also went through and found projects using the duplicate code this
library replaces and proposed changes to those projects [2].

Next steps in the library to account for:

* Releases
* Maintainers
* CI success/failure parsing patterns (do we still need this?)

Am I missing anything else? I noticed we have information in driver log and the
wiki [3] and I kind of don't know now what third-party CI's are dependent on to
work with gerrit. I'll check it out today and report back here, unless someone
knows and replies before I get a chance.


[0] - http://git.openstack.org/cgit/openstack/sphinx-feature-classification
[1] - https://docs.openstack.org/sphinx-feature-classification/latest/usage.html
[2] - https://review.openstack.org/#/q/status:+open+topic:support-matrix
[3] - https://wiki.openstack.org/wiki/ThirdPartySystems

-- 
Mike Perez (thingee)


pgpFI9A8f3PoE.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Developer Mailing List Digest February 17-23rd

[Mike Perez]

HTML version: https://www.openstack.org/blog/?p=8332

Contribute to the Dev Digest by summarizing OpenStack Dev List threads:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/
* http://lists.openstack.org/pipermail/openstack-sigs

Helpful PTG links
==
PTG is around the corner. Here are some helpful links:

* Main welcome email 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127611.html
* Quick links: http://ptg.openstack.org/
* PDF schedule: 
http://lists.openstack.org/pipermail/openstack-dev/attachments/20180221/5c279bb3/attachment-0002.pdf
* PDf map for PTG venue: 
http://lists.openstack.org/pipermail/openstack-dev/attachments/20180221/5c279bb3/attachment-0003.pdf


Success Bot Says

* mhayden: got centos OSA gate under 2h today
* thingee: we have an on-boarding page and documentation for new contributors! 
[0]
* Tell us yours in OpenStack IRC channels using the command "#success "
* More: https://wiki.openstack.org/wiki/Successes

[0] - https://www.openstack.org/community


Thanks Bot Says
===
* Thanks pkovar for keep the Documentation team going!
* Thanks pabelanger and infra for getting ubuntu mirrors repaired and backup 
quickly!
* Thanks lbragstad for helping troubleshoot an intermittent fernet token 
validation failure in puppet gates
* Thanks TheJulia for helping me with a problem last week, it was really a 
networking problem issue, like you said so :)
* Thanks tosky for backporting devstack ansible changes to pike!
* Thanks thingee for Thanks Bot
* Thanks openstackstatus for logging our things
* Thanks strigazi for the v1.9.3 image
* Thanks smcginnis for not stopping this.
* Tell us yours in OpenStack IRC channels using the command "#thanks "
* More: https://wiki.openstack.org/wiki/Thanks


Community Summaries
===
* TC report [0]
* POST /api-sig/news [1]
* Release countdown [2]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127584.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127651.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127465.html


Vancouver Community Contributor Awards
==
The Community contributor awards gives recognition to those that are
undervalued, don't know they're appreciated, bind the community together, keep
things fun, or challenge some norm. There are a lot of people out there that
could use a pat on the back and affirmation that they do good work in the
community.

Nomination period is open now [0] until May 14th. Winners will be announced in
feedback session at Vancouver.

[0] - https://openstackfoundation.formstack.com/forms/cca_nominations_vancouver

Full message: 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127634.html


Release Naming For S - time to suggest a name!
==
It's time to pick a name for our "S" release! Since the associated Summit will
be in Berlin, the Geographic location has been chosen as "Berlin" (state).
Nominations are now open [0]. Rules and processes can be seen on the Governance
site [1].

[0] - https://wiki.openstack.org/wiki/Release_Naming/S_Proposals
[1] - https://governance.openstack.org/tc/reference/release-naming.html

Full message: 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127592.html


Final Queens RC Deadline

Thursday 22nd of April is the deadline for any final Queens release candidates.
We'll enter a quiet period for a week in preparation of tagging the final
Queens release during the PTG week. Make sure if  you have patches merged to
stable/queens that you propose a new RC before the deadline. PTLs should watch
for a patch from the release management team tagging the final release. While
not required, an acknowledgement on the patch would be appreciated.

Full message: 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127540.html


Do Not Import oslo_db.tests.*
=
Deprecations were made on oslo_db.sqlalchemy.test_base package of DbFixture and
DbTestCase. In a patch [0], and assumption was made to that these should be
imported from oslo_db.tests.sqlalchemy. Cinder, Ironic and Glance have been
found with this issue [1].

Unfortunately these were not prefixed with underscores to comply with naming
conventions for people to recognize private code. The tests module was included
for consumers to run those tests on their own packages easily.

[0] - https://review.openstack.org/#/c/522290/
[1] - http://codesearch.openstack.org/?q=oslo_db.tests=nope==

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/thread.html#127531


Some New Zuul Features
==
Default timeout is 30 minutes for "post-run" phase of the job. A new attribute
"timeout" [0] can set this to something else, which could be useful for 

Re: [openstack-dev] [ptg] Lightning talks

[Mike Perez]

I would like to extend the deadline for Lightning Talks at the PTG to February
23rd 23:59 UTC to fill in the few more slots we have available. Details quoted
below, thanks!

-- 
Mike Perez (thingee)

On 02:36 Feb 13, Mike Perez wrote:
> On 11:25 Feb 08, Mike Perez wrote:
> > Hey all!
> > 
> > I'm looking for six 5-minute lightning talks for the PTG in Dublin. This 
> > will
> > be on Friday March 2nd at 13:00-13:30 local time.
> > 
> > Appropriate 5 minute talk examples:
> > * Neat features in libraries like oslo that we should consider adopting in 
> > our
> >   community wide goals.
> > * Features and tricks in your favorite editor that makes doing work easier.
> > * Infra tools that maybe not a lot of people know about yet. Zuul v3 
> > explained
> >   in five minutes anyone?
> > * Some potential API specification from the API SIG that we should adopt as
> >   a community wide goal.
> > 
> > Please email me DIRECTLY the following information:
> > 
> > Title:
> > Speaker(s) full name:
> > Abstract:
> > Link to presentation or attachment if you have it already. Laptop on stage 
> > will
> > be loaded with your presentation already. I'll have open office available so
> > odp, odg, otp, pdf, limited ppt format support.


pgpruIXfUoXrO.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] [all] Thanks Bot - For a happier open source community, give recognition

[Mike Perez]

Every open source community is made up of real people with real feelings. Many
open source contributors are working in their free time to provide essential
software that we use daily. Sometimes praise is lost in the feedback of bugs or
missing features. Focusing on too much negative feedback can lead contributors
to frustration and burnout.

However you end up contributing to OpenStack, or any open source project, I
believe that what gets people excited about working with a community is some
form of recognition.

My first answer to people coming into the OpenStack community is to join our
Project Team Gathering event. Significant changes are discussed here to
understand the technical details to carry out the work in the new release. You
should seek out people who are owners of these changes and volunteer to work on
a portion of the work. Not only are these people interested in your success by
having you take on some of the work they have invested in, but you will be
doing work that interests the entire team. You’ll finish the improvements and
be known as the person in the project with the expertise in that area. You’ll
receive some recognition from the team and the community using your software.
And just like that, you’re hooked because you know your work is making a
difference. Maybe you’ll improve that area of the project more, venture onto
other parts of the project, or even expand to other open source projects.

If you work in the OpenStack community, there’s also another way you can give
and get recognition. In OpenStack IRC channels, you can thank members of the
community publicly with the following command:

#thanks  for being a swell person in that heated discussion!

To be clear,   is replaced with the person you want to give thanks.

Where does this information go? Just like the Success Bot in which we can share
successes as a community, Thanks Bot will post them to the OpenStack wiki. They
will also be featured in the OpenStack Developer Digest.

https://wiki.openstack.org/wiki/Thanks

In developing this feature, I’ve had help and feedback from various members of
the community. You can see my history of thanking people along the way, too.

At the next OpenStack event, you’re still welcome to buy a tasty beverage for
someone to say thanks. But why not give them recognition now too and let them
know how much they’re appreciated in the community?

-- 
Mike Perez (thingee)


pgpX72OwhnVyD.pgp
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [all] Thanks Bot - For a happier open source community, give recognition

[Mike Perez]

Every open source community is made up of real people with real feelings. Many
open source contributors are working in their free time to provide essential
software that we use daily. Sometimes praise is lost in the feedback of bugs or
missing features. Focusing on too much negative feedback can lead contributors
to frustration and burnout.

However you end up contributing to OpenStack, or any open source project, I
believe that what gets people excited about working with a community is some
form of recognition.

My first answer to people coming into the OpenStack community is to join our
Project Team Gathering event. Significant changes are discussed here to
understand the technical details to carry out the work in the new release. You
should seek out people who are owners of these changes and volunteer to work on
a portion of the work. Not only are these people interested in your success by
having you take on some of the work they have invested in, but you will be
doing work that interests the entire team. You’ll finish the improvements and
be known as the person in the project with the expertise in that area. You’ll
receive some recognition from the team and the community using your software.
And just like that, you’re hooked because you know your work is making a
difference. Maybe you’ll improve that area of the project more, venture onto
other parts of the project, or even expand to other open source projects.

If you work in the OpenStack community, there’s also another way you can give
and get recognition. In OpenStack IRC channels, you can thank members of the
community publicly with the following command:

#thanks  for being a swell person in that heated discussion!

To be clear,   is replaced with the person you want to give thanks.

Where does this information go? Just like the Success Bot in which we can share
successes as a community, Thanks Bot will post them to the OpenStack wiki. They
will also be featured in the OpenStack Developer Digest.

https://wiki.openstack.org/wiki/Thanks

In developing this feature, I’ve had help and feedback from various members of
the community. You can see my history of thanking people along the way, too.

At the next OpenStack event, you’re still welcome to buy a tasty beverage for
someone to say thanks. But why not give them recognition now too and let them
know how much they’re appreciated in the community?

-- 
Mike Perez (thingee)


pgp31hDmM_C7G.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ptg] [contributor-guide] Contributor Guide Discussion and Hacking Sessions

[Mike Perez]

Hey all,

Our set of Contributor Guides [0] are making progress in providing our
community with content for on-boarding new contributors of different types of
work.

At the PTG we'll be sharing space with the Documentation and i18n teams [2]. On
Tuesday at 9:00-10:15 AM local time we'll be discussing next steps with the
Contributor Guide of what's left from our StoryBoard tasks [3] and the current
vision.

There will also be impromptu meetup/hacking sessions [4] happening Monday thru
Wednesday on the Contributor Guide with the OpenStack Upstream Institute team,
who are interested in using this content for future events. You can read about
contributing to the Contributor Guide for help [5].

I will be unable to physically attend the PTG this time, but Kendall Nelson
(diablo_rojo on IRC) will be around to help lead these sessions. I will however
be around on #openstack-doc to help with reviews or discussions in the
mentioned impromptu hack times.

Thanks everyone!

[1] - https://docs.openstack.org/contributors/
[2] - https://etherpad.openstack.org/p/docs-i18n-ptg-rocky
[3] - https://storyboard.openstack.org/#!/project/913
[4] - https://etherpad.openstack.org/p/OUI-Rocky-PTG
[5] - https://docs.openstack.org/contributors/contributing

-- 
Mike Perez (thingee)


pgplJQTCgXrjL.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] Developer Mailing List Digest February 10-16th

[Mike Perez]

HTML version: https://www.openstack.org/blog/?p=8321

Please help shape the future of the Developer Mailing List Digest with this two
question survey:
https://openstackfoundation.formstack.com/forms/openstack_developer_digest_feedback

Contribute to the Dev Digest by summarizing OpenStack Dev and SIG List threads:
* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/
* http://lists.openstack.org/pipermail/openstack-sigs


Success Bot Says

None for this week. Tell us yours in OpenStack IRC channels using the command
"#success "

More: https://wiki.openstack.org/wiki/Successes


Thanks Bot Says
===
* diablo_rojo on #openstack-101 [0]: spotz for watching the #openstack-101
  channel and helping to point newcomers to good resources to get them started
  :)
* fungi on #openstack-infra [1]: dmsimard and mnaser for getting deep-linking
  in ara working for firefox
* fungi on #openstack-infra [2]: to Matt Van Winkle for volunteering to act as
  internal advocate at Rackspace for our control plane account there!
* AJaeger on #openstack-doc [3]: corvus for deleting /draft content
* AJaeger on #openstack-infra [4]: cmurphy for your investigation
* AJaeger on #openstack-infra [5]: to mordred for laying wonderful groundwork
  with the tox_siblings work.
* smcginnis on #openstack-infra [6]: fungi jeblair mordred AJaeger and other
  infra-team members for clearing up release job issues
* fungi on #openstack-infra [7]: zuul v3 for having such detailed configuration
  syntax error reporting.
* fungi on #openstack-dev [8]: diablo_rojo and persia for smooth but "rocky"
  ptl elections!
* Tell us yours in OpenStack IRC channels using the command "#thanks "
* More: https://wiki.openstack.org/wiki/Thanks

[0] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-101/%23openstack-101.2017-12-13.log.html
[1] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2017-12-20.log.html
[2] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-01-09.log.html
[3] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-doc/%23openstack-doc.2018-01-22.log.html
[4] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-01-30.log.html
[5] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-02-03.log.html
[6] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2017-12-11.log.html
[7] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-02-14.log.html
[8] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2018-02-15.log.html


Community Summaries
===
Nova Placement update [0]
Release Countdown [1]
TC Report [2]
Technical Committee Status update [3]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127473.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127465.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127324.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127467.html


PTG Bot HOWTO for Dublin

The third PTG is an event where topics of discussion are loosely scheduled in
tracks to maximize the attendee productivity. To keep track of what's happening
currently we have an event schedule page [0]. Below are some helpful
discussions in using PTG bot:

Track Leads
---
Track leads will be able issue various commands [1] in irc channel
#openstack-ptg:
* #TRACK now 
  - example: #swift now brainstorming improvements to the ring.

* Cross project interactions #TRACK now :
  - #nova now discussing #cinder interactions

* What's next #TRACK next :
  -  #api-sig next at 2pm we'll be discussing pagination woes

* Clear all now and next entries for a track #TRACK clean:
  - #ironic clean

Booking Reservable Rooms

Reservable rooms and what's being discussed works the same with it showing on
the event schedule page [0].

Different set of commands:
* Get the slot codes with the book command #TRACK book:
* Book a room with #TRACK book 
  - example: #relmgt book Coiste Bainisti-MonP2

Any track can book additional space. These slots are 1 hour and 45 minutes
long. You can ask ttx, diablo_rojo or #openstack-infra to add a track that's
missing. Keep in mind various teams will be soley relying on this for space at
the PTG.

Additional commands can be found in the PTG bot README [1].

[0] - http://ptg.openstack.org/ptg.html
[1] - https://git.openstack.org/cgit/openstack/ptgbot/tree/README.rst

Full messages:
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127413.html
and
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127414.html


PTL Election Results and Conclusions

[openstack-dev] Developer Mailing List Digest February 10-16th

[Mike Perez]

HTML version: https://www.openstack.org/blog/?p=8321

Please help shape the future of the Developer Mailing List Digest with this two
question survey:
https://openstackfoundation.formstack.com/forms/openstack_developer_digest_feedback

Contribute to the Dev Digest by summarizing OpenStack Dev and SIG List threads:
* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/
* http://lists.openstack.org/pipermail/openstack-sigs


Success Bot Says

None for this week. Tell us yours in OpenStack IRC channels using the command
"#success "

More: https://wiki.openstack.org/wiki/Successes


Thanks Bot Says
===
* diablo_rojo on #openstack-101 [0]: spotz for watching the #openstack-101
  channel and helping to point newcomers to good resources to get them started
  :)
* fungi on #openstack-infra [1]: dmsimard and mnaser for getting deep-linking
  in ara working for firefox
* fungi on #openstack-infra [2]: to Matt Van Winkle for volunteering to act as
  internal advocate at Rackspace for our control plane account there!
* AJaeger on #openstack-doc [3]: corvus for deleting /draft content
* AJaeger on #openstack-infra [4]: cmurphy for your investigation
* AJaeger on #openstack-infra [5]: to mordred for laying wonderful groundwork
  with the tox_siblings work.
* smcginnis on #openstack-infra [6]: fungi jeblair mordred AJaeger and other
  infra-team members for clearing up release job issues
* fungi on #openstack-infra [7]: zuul v3 for having such detailed configuration
  syntax error reporting.
* fungi on #openstack-dev [8]: diablo_rojo and persia for smooth but "rocky"
  ptl elections!
* Tell us yours in OpenStack IRC channels using the command "#thanks "
* More: https://wiki.openstack.org/wiki/Thanks

[0] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-101/%23openstack-101.2017-12-13.log.html
[1] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2017-12-20.log.html
[2] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-01-09.log.html
[3] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-doc/%23openstack-doc.2018-01-22.log.html
[4] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-01-30.log.html
[5] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-02-03.log.html
[6] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2017-12-11.log.html
[7] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-02-14.log.html
[8] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2018-02-15.log.html


Community Summaries
===
Nova Placement update [0]
Release Countdown [1]
TC Report [2]
Technical Committee Status update [3]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127473.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127465.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127324.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127467.html


PTG Bot HOWTO for Dublin

The third PTG is an event where topics of discussion are loosely scheduled in
tracks to maximize the attendee productivity. To keep track of what's happening
currently we have an event schedule page [0]. Below are some helpful
discussions in using PTG bot:

Track Leads
---
Track leads will be able issue various commands [1] in irc channel
#openstack-ptg:
* #TRACK now 
  - example: #swift now brainstorming improvements to the ring.

* Cross project interactions #TRACK now :
  - #nova now discussing #cinder interactions

* What's next #TRACK next :
  -  #api-sig next at 2pm we'll be discussing pagination woes

* Clear all now and next entries for a track #TRACK clean:
  - #ironic clean

Booking Reservable Rooms

Reservable rooms and what's being discussed works the same with it showing on
the event schedule page [0].

Different set of commands:
* Get the slot codes with the book command #TRACK book:
* Book a room with #TRACK book 
  - example: #relmgt book Coiste Bainisti-MonP2

Any track can book additional space. These slots are 1 hour and 45 minutes
long. You can ask ttx, diablo_rojo or #openstack-infra to add a track that's
missing. Keep in mind various teams will be soley relying on this for space at
the PTG.

Additional commands can be found in the PTG bot README [1].

[0] - http://ptg.openstack.org/ptg.html
[1] - https://git.openstack.org/cgit/openstack/ptgbot/tree/README.rst

Full messages:
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127413.html
and
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127414.html


PTL Election Results and Conclusions

[Openstack-operators] Feedback on the Dev Digest

[Mike Perez]

Hey all,

I setup a two question survey asking about your frequency with the Dev Digest,
and how it can be improved:

https://openstackfoundation.formstack.com/forms/openstack_developer_digest_feedback

In case you're not familiar, the Dev Digest tries to provide summaries of the
OpenStack Dev mailing list, for people who might not have time to read every
message and thread on the list. The hope is for people to be informed on
discussions they would've otherwise missed, and be able to get caught up to 
chime in if necessary. This is a community effort worked on via etherpad:

https://etherpad.openstack.org/p/devdigest

The content on Fridays is posted to the Dev list in plaintext, LWN, Twitter and
the OpenStack blog:

https://www.openstack.org/blog/

Thank you!

-- 
Mike Perez (thingee)


pgpQwBi0ozw0m.pgp
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] Feedback on the Dev Digest

[Mike Perez]

Hey all,

I setup a two question survey asking about your frequency with the Dev Digest,
and how it can be improved:

https://openstackfoundation.formstack.com/forms/openstack_developer_digest_feedback

In case you're not familiar, the Dev Digest tries to provide summaries of the
OpenStack Dev mailing list, for people who might not have time to read every
message and thread on the list. The hope is for people to be informed on
discussions they would've otherwise missed, and be able to get caught up to 
chime in if necessary. This is a community effort worked on via etherpad:

https://etherpad.openstack.org/p/devdigest

The content on Fridays is posted to the Dev list in plaintext, LWN, Twitter and
the OpenStack blog:

https://www.openstack.org/blog/

Thank you!

-- 
Mike Perez (thingee)


pgpfVEzvu3UKl.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptg] Lightning talks

[Mike Perez]

On 11:25 Feb 08, Mike Perez wrote:
> Hey all!
> 
> I'm looking for six 5-minute lightning talks for the PTG in Dublin. This will
> be on Friday March 2nd at 13:00-13:30 local time.
> 
> Appropriate 5 minute talk examples:
> * Neat features in libraries like oslo that we should consider adopting in our
>   community wide goals.
> * Features and tricks in your favorite editor that makes doing work easier.
> * Infra tools that maybe not a lot of people know about yet. Zuul v3 explained
>   in five minutes anyone?
> * Some potential API specification from the API SIG that we should adopt as
>   a community wide goal.
> 
> Please email me DIRECTLY the following information:
> 
> Title:
> Speaker(s) full name:
> Abstract:
> Link to presentation or attachment if you have it already. Laptop on stage 
> will
> be loaded with your presentation already. I'll have open office available so
> odp, odg, otp, pdf, limited ppt format support.
> 
> Submission deadline is February 16 00:00 UTC, and then I'll send confirmation
> emails to speakers requesting for slides. Thank you, looking forward to 
> hearing
> some great talks from our community!

Hey all,

Just a reminder that lightning talk proposals for the PTG in Dublin is due
February 16 at 00:00 utc. We're building up a nice line up already. Details
quoted above, Thanks!

-- 
Mike Perez (thingee)


pgp7ITUfTXQZX.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] Developer Mailing List Digest February 3-9th

[Mike Perez]

Please help shape the future of the Developer Mailing List Digest with this two
question survey:
https://openstackfoundation.formstack.com/forms/openstack_developer_digest_feedback

Contribute to the Dev Digest by summarizing OpenStack Dev List threads:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/
* http://lists.openstack.org/pipermail/openstack-sigs

HTML version: https://www.openstack.org/blog/?p=8287

Success Bot Says
* stephenfin on #openstack-nova [0]: After 3 years and 7 (?) releases,
  encryption between nova's consoleproxy service and compute nodes is finally
* possible ✌️
* AJaeger on #openstack-infra [1]: zuul and nodepool feature/zuulv3 branches
  have merged into master
* ildikov on #openstack-nova [2]: OpenStack now supports to attach a Cinder
  volume to multiple VM instances managed by Nova.
* mriedem on #openstack-nova [3]: osc-placement 1.0.0 released; you can now do
  things with resource providers/classes via OSC CLI now.
* AJaeger on #openstack-infra [4]: All tox jobs have been converted to Zuul v3
  native syntax, run-tox.sh is gone.
* ttx on #openstack-dev [5]: All teams have at least one candidate for PTL for
  the Rocky cycle! Might be the first time.
* Tell us yours in OpenStack IRC channels using the command "#success
  "
* More: https://wiki.openstack.org/wiki/Successes

[0] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-01-15.log.html
[1] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-01-18.log.html
[2] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-01-23.log.html
[3] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-01-24.log.html
[4] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-02-07.log.html
[5] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2018-02-08.log.html


Community Summaries
===
* Release countdown [0]
* Nova placement resource provider update [1]
* TC Report [2]
* POST /api-sig/news [3]
* Technical Committee Status Update [4]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127120.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127203.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127012.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127140.html
[4] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127192.html


Dublin PTG Schedule is Up
=
PTG schedule is available [0]. A lot of rooms are available Monday/Tuesday to
discuss additional topics that take half a day and can be requested [1]. For
small things (90 min discussions) we can book them dyncamically during the
event with the new PTG bot features. Follow the thread for updates to the
schedule [2].

[0] - https://www.openstack.org/ptg#tab_schedule
[1] - https://etherpad.openstack.org/p/PTG-Dublin-missing-topics
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/thread.html#126892

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/thread.html#126892


Last Chance for PTG Dublin Tickets
==
PTG tickets for Dublin were sold out this week, and the Foundation received
many requests for more tickets. Working with the venue to accommodate the extra
capacity, every additional attendee incrementally increases costs to $600. It's
understood the importance of this event and the need to have key team members
present, so the OpenStack Foundation has negotiated an additional 100 tickets
and will partially subsidize to be at sold at $400 [0].

[0] - 
https://www.eventbrite.com/e/project-teams-gathering-dublin-2018-tickets-39055825024

Full message: 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127129.html


New Zuul Depends-On Syntax

Recently introduced url-based syntax for Depends-On: footer in your commit 
message:

Depends-On: https://review.openstack.org/535851

Old syntax will continue to work for a while, but please begin using the new
syntax. Zuul has grown the ability to talk to multiple backend systems (Gerrit,
Git and plain Git so far).

From a change in gerrit you could have:
Depends-On: https://github.com/ikalnytskyi/sphinxcontrib-openapi/pull/17

Or from a Github pull request:
Depends-On: https://review.openstack.org/536159

Tips and certain cases contained further in the full message.

Full message: 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126535.html


Call For Mentors and Funding

The Outreachy program [0] helps people of underrepresented groups get involved
in free and open source software by matching interns with established mentors
in the upstream community.

OpenStack will be 

[openstack-dev] Developer Mailing List Digest February 3-9th

[Mike Perez]

Please help shape the future of the Developer Mailing List Digest with this two
question survey:
https://openstackfoundation.formstack.com/forms/openstack_developer_digest_feedback

Contribute to the Dev Digest by summarizing OpenStack Dev List threads:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/
* http://lists.openstack.org/pipermail/openstack-sigs

HTML version: https://www.openstack.org/blog/?p=8287

Success Bot Says
* stephenfin on #openstack-nova [0]: After 3 years and 7 (?) releases,
  encryption between nova's consoleproxy service and compute nodes is finally
* possible ✌️
* AJaeger on #openstack-infra [1]: zuul and nodepool feature/zuulv3 branches
  have merged into master
* ildikov on #openstack-nova [2]: OpenStack now supports to attach a Cinder
  volume to multiple VM instances managed by Nova.
* mriedem on #openstack-nova [3]: osc-placement 1.0.0 released; you can now do
  things with resource providers/classes via OSC CLI now.
* AJaeger on #openstack-infra [4]: All tox jobs have been converted to Zuul v3
  native syntax, run-tox.sh is gone.
* ttx on #openstack-dev [5]: All teams have at least one candidate for PTL for
  the Rocky cycle! Might be the first time.
* Tell us yours in OpenStack IRC channels using the command "#success
  "
* More: https://wiki.openstack.org/wiki/Successes

[0] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-01-15.log.html
[1] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-01-18.log.html
[2] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-01-23.log.html
[3] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-01-24.log.html
[4] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2018-02-07.log.html
[5] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2018-02-08.log.html


Community Summaries
===
* Release countdown [0]
* Nova placement resource provider update [1]
* TC Report [2]
* POST /api-sig/news [3]
* Technical Committee Status Update [4]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127120.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127203.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127012.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127140.html
[4] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127192.html


Dublin PTG Schedule is Up
=
PTG schedule is available [0]. A lot of rooms are available Monday/Tuesday to
discuss additional topics that take half a day and can be requested [1]. For
small things (90 min discussions) we can book them dyncamically during the
event with the new PTG bot features. Follow the thread for updates to the
schedule [2].

[0] - https://www.openstack.org/ptg#tab_schedule
[1] - https://etherpad.openstack.org/p/PTG-Dublin-missing-topics
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/thread.html#126892

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/thread.html#126892


Last Chance for PTG Dublin Tickets
==
PTG tickets for Dublin were sold out this week, and the Foundation received
many requests for more tickets. Working with the venue to accommodate the extra
capacity, every additional attendee incrementally increases costs to $600. It's
understood the importance of this event and the need to have key team members
present, so the OpenStack Foundation has negotiated an additional 100 tickets
and will partially subsidize to be at sold at $400 [0].

[0] - 
https://www.eventbrite.com/e/project-teams-gathering-dublin-2018-tickets-39055825024

Full message: 
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127129.html


New Zuul Depends-On Syntax

Recently introduced url-based syntax for Depends-On: footer in your commit 
message:

Depends-On: https://review.openstack.org/535851

Old syntax will continue to work for a while, but please begin using the new
syntax. Zuul has grown the ability to talk to multiple backend systems (Gerrit,
Git and plain Git so far).

From a change in gerrit you could have:
Depends-On: https://github.com/ikalnytskyi/sphinxcontrib-openapi/pull/17

Or from a Github pull request:
Depends-On: https://review.openstack.org/536159

Tips and certain cases contained further in the full message.

Full message: 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126535.html


Call For Mentors and Funding

The Outreachy program [0] helps people of underrepresented groups get involved
in free and open source software by matching interns with established mentors
in the upstream community.

OpenStack will be 

[openstack-dev] [ptg] Lightning talks

[Mike Perez]

Hey all!

I'm looking for six 5-minute lightning talks for the PTG in Dublin. This will
be on Friday March 2nd at 13:00-13:30 local time.

Appropriate 5 minute talk examples:
* Neat features in libraries like oslo that we should consider adopting in our
  community wide goals.
* Features and tricks in your favorite editor that makes doing work easier.
* Infra tools that maybe not a lot of people know about yet. Zuul v3 explained
  in five minutes anyone?
* Some potential API specification from the API SIG that we should adopt as
  a community wide goal.

Please email me DIRECTLY the following information:

Title:
Speaker(s) full name:
Abstract:
Link to presentation or attachment if you have it already. Laptop on stage will
be loaded with your presentation already. I'll have open office available so
odp, odg, otp, pdf, limited ppt format support.

Submission deadline is February 16 00:00 UTC, and then I'll send confirmation
emails to speakers requesting for slides. Thank you, looking forward to hearing
some great talks from our community!

-- 
Mike Perez (thingee)


pgppqFF0WWDDV.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] Developer Mailing List Digest January 5-12th

[Mike Perez]

Contribute to the Dev Digest by summarizing OpenStack Dev List thread:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/
* http://lists.openstack.org/pipermail/openstack-sigs

HTML version: 
https://www.openstack.org/blog/2018/01/developer-mailing-list-digest-january-5-12th/

Success Bot Says

* e0ne on #openstack-horizon [0]: amotoki runs horizon with django 2.0
* tristianC on #rdo [1]: review.rdoproject.org is now running sf-2.7
* mriedem on #openstack-nova [2]: nova merged alternate hosts support for
  server build
* mriedem on #openstack-nova [3]: After a week of problems, finally got
  a volume multiattach test run to actually attach a volume to two instances
  without melting the world. \o/
* zaneb [4]: 14% reduction in Heat memory use in the TripleO gate from fixing
  https://bugs.launchpad.net/heat/+bug/1731349
* Tell us yours in OpenStack IRC channels using the command "#success
  "
* More: https://wiki.openstack.org/wiki/Successes

[0] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-horizon/%23openstack-horizon.2017-12-18.log.html
[1] - http://eavesdrop.openstack.org/irclogs/%23rdo/%23rdo.2017-12-21.log.html
[2] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-12-22.log.html
[3] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-01-05.log.html
[4] - 
http://eavesdrop.openstack.org/irclogs/%23tripleo/%23tripleo.2018-01-09.log.html

Community Summaries
===
* Technical Committee Status update [0]
* POST /api-sig/news [1]
* Release countdown [2]
* Nova placement resource provider update [3]
* Keystone team update [4]
* Nova Notification Update [5]
* TC report [6]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126178.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126147.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/125996.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126179.html
[4] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126188.html
[5] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126025.html
[6] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126082.html


Community Goals for Rocky
=
So far one goal has been proposed by Kendall Nelson for migrating to
Storyboard. It was agreed to postpone the goal until the S cycle, as it could
take longer than six months to achieve. There is a good backlog of goals [0],
just no champions. It'll be bad for momentum if we have a cycle with no
community wide goal.

[0] - https://etherpad.openstack.org/p/community-goals

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126090.html

PTG Post-lunch Presentations

Feedback received from past PTG session(s) was the lack of situational
awareness and missed opportunity for "global" communication at the event. In
Dublin we'd used the end of the lunch break to for communications that could be
interesting to OpenStack upstream developers and project team members. The idea
is not to find a presentation for everyday, but if we find content that is
generally useful. Interesting topics include general guidance to make the most
of the PTG weeks (good Monday content), development tricks, code review
etiquette, new library features you should adopt, lightning talks (good Friday
content). We'd like to keep the slot under 20 minutes. If you have ideas please
fill out this etherpad [0] in a few weeks.

[0] - https://etherpad.openstack.org/p/dublin-PTG-postlunch

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126102.html


signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] Developer Mailing List Digest January 5-12th

[Mike Perez]

Contribute to the Dev Digest by summarizing OpenStack Dev List thread:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/
* http://lists.openstack.org/pipermail/openstack-sigs

HTML version: 
https://www.openstack.org/blog/2018/01/developer-mailing-list-digest-january-5-12th/

Success Bot Says

* e0ne on #openstack-horizon [0]: amotoki runs horizon with django 2.0
* tristianC on #rdo [1]: review.rdoproject.org is now running sf-2.7
* mriedem on #openstack-nova [2]: nova merged alternate hosts support for
  server build
* mriedem on #openstack-nova [3]: After a week of problems, finally got
  a volume multiattach test run to actually attach a volume to two instances
  without melting the world. \o/
* zaneb [4]: 14% reduction in Heat memory use in the TripleO gate from fixing
  https://bugs.launchpad.net/heat/+bug/1731349
* Tell us yours in OpenStack IRC channels using the command "#success
  "
* More: https://wiki.openstack.org/wiki/Successes

[0] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-horizon/%23openstack-horizon.2017-12-18.log.html
[1] - http://eavesdrop.openstack.org/irclogs/%23rdo/%23rdo.2017-12-21.log.html
[2] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-12-22.log.html
[3] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-01-05.log.html
[4] - 
http://eavesdrop.openstack.org/irclogs/%23tripleo/%23tripleo.2018-01-09.log.html

Community Summaries
===
* Technical Committee Status update [0]
* POST /api-sig/news [1]
* Release countdown [2]
* Nova placement resource provider update [3]
* Keystone team update [4]
* Nova Notification Update [5]
* TC report [6]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126178.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126147.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/125996.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126179.html
[4] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126188.html
[5] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126025.html
[6] - 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126082.html


Community Goals for Rocky
=
So far one goal has been proposed by Kendall Nelson for migrating to
Storyboard. It was agreed to postpone the goal until the S cycle, as it could
take longer than six months to achieve. There is a good backlog of goals [0],
just no champions. It'll be bad for momentum if we have a cycle with no
community wide goal.

[0] - https://etherpad.openstack.org/p/community-goals

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126090.html

PTG Post-lunch Presentations

Feedback received from past PTG session(s) was the lack of situational
awareness and missed opportunity for "global" communication at the event. In
Dublin we'd used the end of the lunch break to for communications that could be
interesting to OpenStack upstream developers and project team members. The idea
is not to find a presentation for everyday, but if we find content that is
generally useful. Interesting topics include general guidance to make the most
of the PTG weeks (good Monday content), development tricks, code review
etiquette, new library features you should adopt, lightning talks (good Friday
content). We'd like to keep the slot under 20 minutes. If you have ideas please
fill out this etherpad [0] in a few weeks.

[0] - https://etherpad.openstack.org/p/dublin-PTG-postlunch

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2018-January/126102.html


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] Developer Mailing List Digest November 25 to December 1st

[Mike Perez]

Contribute to the Dev Digest by summarizing OpenStack Dev List thread:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/
* http://lists.openstack.org/pipermail/openstack-sigs

HTML version: 
https://www.openstack.org/blog/2017/12/developer-mailing-list-digest-november-25-to-december-1st/


News

* Project Team Gather (PTG) in Dublin registration is live [0]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124978.html



Community Summaries
===
* TC report by Chris Dent [0]
* Release countdown [1]
* Technical Committee Status updated [2]
* POST /api-sig/news [3]
* Nova notification update [4]
* Nova placement resource providers update [5]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124964.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/125054.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125099.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/125071.html
[4] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125146.html
[5] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125117.html



Dublin PTG Format
=
We will continue themes as we did in Denver, but shorter times like half 
days.
Flexibility is added for other groups to book the remaining available 
rooms in

90-min slots on-demand driven by the PTG Bot. So far the split of having
Monday-Tuesday be dedicated to themes and Wednesday-Frday dedicated to 
teams as

we've done in previous PTG's is a winning decision.

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/thread.html#124898



First Contact SIG
=
A wiki has been created for the group [0]. The group is looking for 
intersted

people being points of contact for newcomers and what specified timezones.
Resource links like contributor portal, mentoring wiki, Upstream Institute,
outreachy are being collected on the wiki page. A representative from the
operators side to chair and represent would be good.

[0] - https://wiki.openstack.org/wiki/First_Contact_SIG

Policy Goal Queens-2 Update
===
Queens-2 coming to a close, we recap our community wide goal for 
policies [0].

If you want your status changed, contact Lance Bragstad. Use the topic
policy-and-docs-in-code for tracking related code changes.

Not Started
---
* ceilometer
* congress
* networking-bgpvpn
* networking-midonet
* networking-odl
* neutron-dynamic-routing
* neutron-fwaas
* neutron-lib
* solum
* swift


In Progress
---
* barbican
* cinder
* cloudkitty
* glance
* heat
* manila
* mistral
* neutron
* panko
* python-heatclient
* tacker
* tricircle
* trove
* vitrage
* watcher
* zaqar

Completed
-
* designate
* freezer
* ironic
* keystone
* magnum
* murano
* nova
* octavia
* sahara
* searchlight
* senlin
* zun


Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/thread.html#124966



Tempest Plugin Split Goal
=
A list of open reviews [0] is available for the Tempest plugin split 
goal [1].


Not Started
---
* Congress
* ec2-api
* freezer
* mistral
* monasca
* senlin
* tacker
* Telemetry
* Trove
* Vitrage

In Progress
---
* Cinder
* Heat
* Ironic
* magnum
* manila
* Neutron
* murano
* networking-l2gw
* octavia

Completed
-
* Barbican
* CloudKitty
* Designate
* Horizon
* Keystone
* Kuryr
* Sahara
* Solum
* Tripleo
* Watcher
* Winstackers
* Zaqar
* Zun

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125131.html



[0] - 
https://review.openstack.org/#/q/topic:goal-split-tempest-plugins+status:open
[1] - 
https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html



___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] Developer Mailing List Digest November 25 to December 1st

[Mike Perez]

Contribute to the Dev Digest by summarizing OpenStack Dev List thread:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/
* http://lists.openstack.org/pipermail/openstack-sigs

HTML version: 
https://www.openstack.org/blog/2017/12/developer-mailing-list-digest-november-25-to-december-1st/


News

* Project Team Gather (PTG) in Dublin registration is live [0]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124978.html



Community Summaries
===
* TC report by Chris Dent [0]
* Release countdown [1]
* Technical Committee Status updated [2]
* POST /api-sig/news [3]
* Nova notification update [4]
* Nova placement resource providers update [5]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124964.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/125054.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125099.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/125071.html
[4] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125146.html
[5] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125117.html



Dublin PTG Format
=
We will continue themes as we did in Denver, but shorter times like half 
days.
Flexibility is added for other groups to book the remaining available 
rooms in

90-min slots on-demand driven by the PTG Bot. So far the split of having
Monday-Tuesday be dedicated to themes and Wednesday-Frday dedicated to 
teams as

we've done in previous PTG's is a winning decision.

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/thread.html#124898



First Contact SIG
=
A wiki has been created for the group [0]. The group is looking for 
intersted

people being points of contact for newcomers and what specified timezones.
Resource links like contributor portal, mentoring wiki, Upstream Institute,
outreachy are being collected on the wiki page. A representative from the
operators side to chair and represent would be good.

[0] - https://wiki.openstack.org/wiki/First_Contact_SIG

Policy Goal Queens-2 Update
===
Queens-2 coming to a close, we recap our community wide goal for 
policies [0].

If you want your status changed, contact Lance Bragstad. Use the topic
policy-and-docs-in-code for tracking related code changes.

Not Started
---
* ceilometer
* congress
* networking-bgpvpn
* networking-midonet
* networking-odl
* neutron-dynamic-routing
* neutron-fwaas
* neutron-lib
* solum
* swift


In Progress
---
* barbican
* cinder
* cloudkitty
* glance
* heat
* manila
* mistral
* neutron
* panko
* python-heatclient
* tacker
* tricircle
* trove
* vitrage
* watcher
* zaqar

Completed
-
* designate
* freezer
* ironic
* keystone
* magnum
* murano
* nova
* octavia
* sahara
* searchlight
* senlin
* zun


Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/thread.html#124966



Tempest Plugin Split Goal
=
A list of open reviews [0] is available for the Tempest plugin split 
goal [1].


Not Started
---
* Congress
* ec2-api
* freezer
* mistral
* monasca
* senlin
* tacker
* Telemetry
* Trove
* Vitrage

In Progress
---
* Cinder
* Heat
* Ironic
* magnum
* manila
* Neutron
* murano
* networking-l2gw
* octavia

Completed
-
* Barbican
* CloudKitty
* Designate
* Horizon
* Keystone
* Kuryr
* Sahara
* Solum
* Tripleo
* Watcher
* Winstackers
* Zaqar
* Zun

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125131.html



[0] - 
https://review.openstack.org/#/q/topic:goal-split-tempest-plugins+status:open
[1] - 
https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Community managed tech/dev blog: Call for opinions and ideas

[Mike Perez]

On 10:45 Nov 28, Jimmy McArthur wrote:
> Thierry Carrez wrote:
> >
> >What Josh wants is a curated technical blog, so if we reused blog.o.o
> >for this (and I think it's a good idea), we'd likely want to have a bit
> >more rules on what's appropriate.
> 
> Agreed. It's almost solely used for developer digest now and isn't
> frequently updated. Most of the promotion of sponsors and news goes into
> o.o/News, SuperUser, or one of our other marketing channels. It's a good
> time for the community to repurpose it :)

+1 from me to bring more life to the blog than just the dev digest!

-- 
Mike Perez (thingee)


pgpdODcUhXcyI.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Developer Mailing List Digest November 18-27

[Mike Perez]

Contribute to the Dev Digest by summarizing OpenStack Dev List thread:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/

HTML version: 
https://www.openstack.org/blog/2017/11/developer-mailing-list-digest-november-18-27/


Community Summaries
===
* Glance priorities [0]
* Nova placement resource provider update [1]
* Keystone Upcoming Deadlines [2]
* Ironic priorities and subteam reports [3]
* Keystone office hours [4]
* Nova notification update [5]
* Release countdown [6]
* Technical committee status update [7]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124678.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124429.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124727.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124731.html
[4] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124820.html
[5] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124900.html
[6] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124882.html
[7] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124875.html


Self-healing SIG created


Adam Spiers announced the formation of a SIG around self-healing. Its scope is 
to coordinate the use and development of several OpenStack projects which can 
be combined in various ways to manage OpenStack infrastructure in a 
policy-driven fashion, reacting to failures and other events by automatically 
healing and optimising services.

Full thread: 
http://lists.openstack.org/pipermail/openstack-sigs/2017-November/000170.html


Proposal for a QA SIG
=

A proposal to to have a co-existing QA special interest group (SIG) that would
be a place for downstream efforts to have a common place in collaborating and
sharing tests. Example today the OPNFV performs QA on OpenStack releases today
and are actively looking for opportunieis to share tools and test cases. While
a SIG can exist to do some code, the QA team will remain for now since there
are around 15 QA projects existing like Tempest and Grenade.

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/thread.html#124662


Improving the Process for Release Marketing
===

Collecting and summarizing "top features" during release time is difficult for
both PTL's and Foundation marketing. A system is now in place for PTL's to
highlight release notes [0]. Foundation marketing will work with the various
teams if needed to understand and make things more press friendly.

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/thread.html#124726

[0] - http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n466

-- 
Mike Perez (thingee)


pgp4aZbH06Cqz.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] Developer Mailing List Digest November 11-17

[Mike Perez]

Contribute to the Dev Digest by summarizing OpenStack Dev List thread:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/

HTML version: 
https://www.openstack.org/blog/2017/11/developer-mailing-list-digest-november-11-17

Summaries
=
* POST /api-sig/news [0]
* Release countdown for week R-14, November 18-24 [1]
[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124633.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124631.html


Upstream Long Term Support Releases
===
The Sydney Summit had a very well attended and productive session [0] about to
go about keeping a selection of past releases available and maintained for long
term support (LTS).

In the past the community has asked for people who are interested in old
branches being maintained for a long time to join the Stable Maintenance team
with the premise that if the stable team grew, it could support more branches
for longer periods. This has been repeated for about years and is not working.

This discussion is about allowing collaboration on patches beyond end of life
(EOL) and enable whoever steps up to maintain longer lived branches to come up
with a set of tests that actually match their needs with tests that would be
less likely to bitrot due to changing OS/PYPI substrate. We need to lower
expectations of what we're likely to produce will get more brittle the older
the branch gets. Any burden created by taking on more work is absorbed by
people doing the work, as does not unduly impact the folks not interested in
doing the work.

The idea is to continue the current stable policy more or less as it is.
Development teams take responsibility of a couple of stable branches. At some
point what we now call an EOL branch, instead of deleting it we would leave it
open and establish a new team of people who want to continue to main that
branch. It's anticipated the members of those new teams are coming mostly from
users and distributors. Not all branches are going to attract teams to maintain
them, and that's OK.

We will stop tagging these branches so the level of support they provide are
understood. Backports and other fixes can be shared, but to consume them, a
user will have to build their own packages.

Test jobs will run as they are, and the team that maintain the branch could
decide how to deal with them. Fixing the jobs upstream where possible is
preferred, but depending on who is maintaining the branch, the level of support
they are actually providing and the nature of the breakage, removing individual
tests or whole jobs is another option. Using third-party testing came up but is
not required.

Policies for the new team being formed to maintain these older branches is
being discussed in an etherpad [2].

Some feedback in the room expressed they to start one release a year who's
branch isn't deleted after a year. Do one release a year and still keep N-2
stable releases around. We still do backports to all open stable branches.
Basically do what we're doing now, but once a year.

Discussion on this suggestion extended to the OpenStack SIG mailing list [1]
suggesting that skip-release upgrades are a much better way to deal with
upgrade pain than extending cycles. Releasing every year instead of a 6 months
means our releases will contain more changes, and the upgrade could become more
painful. We should be release often as we can and makes the upgrades less
painful so versions can be skipped.

We have so far been able to find people to maintain stable branches for 12-18
months. Keep N-2 branches for annual releases open would mean extending that
support period to 2+ years. If we're going to do that, we need to address how
we are going to retain contributors.

When you don't release often enough, the pressure to get a patch "in"
increases. Missing the boat and waiting for another year is not bearable.


[0] - https://etherpad.openstack.org/p/SYD-forum-upstream-lts-releases
[1] - 
http://lists.openstack.org/pipermail/openstack-sigs/2017-November/000149.html
[2] - https://etherpad.openstack.org/p/LTS-proposal

-- 
Mike Perez (thingee)


pgpkzYmrOdcD3.pgp
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] Developer Mailing List Digest November 11-17

[Mike Perez]

Contribute to the Dev Digest by summarizing OpenStack Dev List thread:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/

HTML version: 
https://www.openstack.org/blog/2017/11/developer-mailing-list-digest-november-11-17

Summaries
=
* POST /api-sig/news [0]
* Release countdown for week R-14, November 18-24 [1]
[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124633.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124631.html


Upstream Long Term Support Releases
===
The Sydney Summit had a very well attended and productive session [0] about to
go about keeping a selection of past releases available and maintained for long
term support (LTS).

In the past the community has asked for people who are interested in old
branches being maintained for a long time to join the Stable Maintenance team
with the premise that if the stable team grew, it could support more branches
for longer periods. This has been repeated for about years and is not working.

This discussion is about allowing collaboration on patches beyond end of life
(EOL) and enable whoever steps up to maintain longer lived branches to come up
with a set of tests that actually match their needs with tests that would be
less likely to bitrot due to changing OS/PYPI substrate. We need to lower
expectations of what we're likely to produce will get more brittle the older
the branch gets. Any burden created by taking on more work is absorbed by
people doing the work, as does not unduly impact the folks not interested in
doing the work.

The idea is to continue the current stable policy more or less as it is.
Development teams take responsibility of a couple of stable branches. At some
point what we now call an EOL branch, instead of deleting it we would leave it
open and establish a new team of people who want to continue to main that
branch. It's anticipated the members of those new teams are coming mostly from
users and distributors. Not all branches are going to attract teams to maintain
them, and that's OK.

We will stop tagging these branches so the level of support they provide are
understood. Backports and other fixes can be shared, but to consume them, a
user will have to build their own packages.

Test jobs will run as they are, and the team that maintain the branch could
decide how to deal with them. Fixing the jobs upstream where possible is
preferred, but depending on who is maintaining the branch, the level of support
they are actually providing and the nature of the breakage, removing individual
tests or whole jobs is another option. Using third-party testing came up but is
not required.

Policies for the new team being formed to maintain these older branches is
being discussed in an etherpad [2].

Some feedback in the room expressed they to start one release a year who's
branch isn't deleted after a year. Do one release a year and still keep N-2
stable releases around. We still do backports to all open stable branches.
Basically do what we're doing now, but once a year.

Discussion on this suggestion extended to the OpenStack SIG mailing list [1]
suggesting that skip-release upgrades are a much better way to deal with
upgrade pain than extending cycles. Releasing every year instead of a 6 months
means our releases will contain more changes, and the upgrade could become more
painful. We should be release often as we can and makes the upgrades less
painful so versions can be skipped.

We have so far been able to find people to maintain stable branches for 12-18
months. Keep N-2 branches for annual releases open would mean extending that
support period to 2+ years. If we're going to do that, we need to address how
we are going to retain contributors.

When you don't release often enough, the pressure to get a patch "in"
increases. Missing the boat and waiting for another year is not bearable.


[0] - https://etherpad.openstack.org/p/SYD-forum-upstream-lts-releases
[1] - 
http://lists.openstack.org/pipermail/openstack-sigs/2017-November/000149.html
[2] - https://etherpad.openstack.org/p/LTS-proposal

-- 
Mike Perez (thingee)


pgpQn5z3KGpek.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Developer Mailing List Digest October 28th - November 3rd

[Mike Perez]

Contribute to the Dev Digest by summarizing OpenStack Dev List thread:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/

HTML version: 
https://www.openstack.org/blog/2017/11/developer-mailing-list-digest-october-28th-november-3rd/

News

* Sydney Summit Etherpads [0]

[0] - https://wiki.openstack.org/wiki/Forum/Sydney2017


Community Summaries
===
Nova Placements Resource Provider Update by Eric Fried [0]
Nova Notification Update by Balazs Gibizer [1]
Technical Committee Status update by Thierry Carrez [2]
Technical Committee Report by Chris Dent [3]
Release Countdown by Sean McGinnis [4]
POST /api-sig/news by Chris Dent [5]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-November/124233.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/124079.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/124049.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/124134.html
[4] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123799.html
[5] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/124023.html


TC Election Results (continued)
===
Congrats to our 6 newly elected Technical Committee members:
Colleen Murphy (cmurphy)
Doug Hellmann (dhellmann)
Emilien Macchi (emilienm)
Jeremy Stanley (fungi)
Julia Kreger (TheJulia)
Paul Belanger (pabelanger)

Full results are available [0]. The process and results are also available [1].
420 voted out of 2430 electorate, giving us a 17.28% turn out with a delta of
29.16% [2].

Reasons for the low turnout is hard to tell without knowing who is voting and
what their activity is in the community. More people are beginning to
understand the point of the TC activities, being more around duties than rights
(e.g. stewardship and leadership). People could care a bit less about specific
individuals and are less motivated by the vote itself. If the activity of the
TC was a lot more conflict and a lot less consensus, people might care about it
more.

[0] - http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ce86063991ef8aae
[1] - https://governance.openstack.org/election/
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123848.html

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/thread.html#124004


Security SIG

Our governance used to only have project teams to recognize activity in
OpenStack, so we created a security team. Introduction of sigs provide a new
construct for recognizing activity around a group that share interest around
a topic or practice that are not mainly around software bits.

Security is a great example of a topic that could benefit from this construct
to gather all security-conscious people in our community. SIGs can have
software by-products and own git repositories, and the software is more about
security in general than a piece of OpenStack itself.

It's important to consider the Vulnerability Management Team (VMT) under the
new model, which acts as an independent task force.

The Security team discussed the idea of a SIG in their meeting, and overall
think it's worth exploring by having the SIG and team exist in parallel to see
if there is traction.

Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/thread.html#124053

-- 
Mike Perez (thingee)


pgpVF01hhDNf9.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptls] MOAR UPDATES: Sydney Project Onboarding

[Mike Perez]

On 02:34 Oct 24, Dave McCowan (dmccowan) wrote:
> We're working on the Barbican Onboarding session now.  I don't think our 
> Boston session went very well, and the results borne out; we were unable to 
> convert any attendee to active contributor.  It was a much bigger group than 
> I was expecting and everyone was at a different starting point .  I was 
> unprepared for both of those situations.
> 
> I'd like to hear some success stories from Boston to learn from.
> 
> For projects that were successful, what topics did you cover?
> For prospective Sydney Onboarders, what do you want to learn at these 
> sessions?

An effort we talked about at the last PTG and finally surfaced is the
contributor portal [1] and contributor guide [2].

The portal is a good landing page to explore different projects and their
contributor guides listed in the project yaml [3].

The contributor guide is included on the portal and the hope is people go
through that first which includes general topics like irc setup, account setup
and git setup. More people can contribute general topics so all projects
benefit.

The contributor guide should at least cover those topics for you to have groups
break off and do. Then you can spend your preparing time on other topics like
team specific topics and tools.

If anyone has time and wants to help all projects choosing to use this guide,
read my previous post [3] announcing this project and asking for help.

[1] - https://www.openstack.org/community/
[2] - https://docs.openstack.org/contributors/
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123740.html

-- 
Mike Perez


pgpECvMlJObHd.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] [requirements] moving driver dependencies to global-requirements?

[Mike Perez]

On 17:51 Oct 30, Dmitry Tantsur wrote:
> Hi all,
> 
> So far driver requirements [1] have been managed outside of
> global-requirements. This was mostly necessary because some dependencies
> were not on PyPI. This is no longer the case, and I'd like to consider
> managing them just like any other dependencies. Pros:
> 1. making these dependencies (and their versions) more visible for packagers
> 2. following the same policies for regular and driver dependencies
> 3. ensuring co-installability of these dependencies with each other and with
> the remaining openstack
> 4. potentially using upper-constraints in 3rd party CI to test what
> packagers will probably package
> 5. we'll be able to finally create a tox job running unit tests with all
> these dependencies installed (FYI these often breaks in RDO CI)

I noticed Cinder is doing this with drivers, but in a different file:

http://git.openstack.org/cgit/openstack/cinder/tree/driver-requirements.txt

-- 
Mike Perez


pgpjj5AdeWm9b.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack] Developer Mailing List Digest September 30 – October 6

[Mike Perez]

Thanks to Thierry Carrez and Jeremy Stanley for summarizing this issue of the
Dev Digest!

Contribute to the Dev Digest by summarizing OpenStack Dev List thread:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/

HTML Version: 
https://www.openstack.org/blog/2017/10/developer-mailing-list-digest-october-21-27-2017/



News

* TC election results [0]
* Next PTG will be in Dublin, the week of February 26, 2018. More details will
  be posted on openstack.org/ptg as soon as we have them. [1]

[0] http://lists.openstack.org/pipermail/openstack-dev/2017-October/123845.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2017-October/124021.html

 
SuccessBot Says
===
* gothamr_  [0]:changes to the manila driverfixes branches can finally be
  merged xD Thanks infra folks for ZuulV3!
* andreaf [1]: Tempest test base class is now a stable API for plugins
* More [2]

[0] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-manila/%23openstack-manila.2017-10-17.log.html
[1] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2017-10-24.log.html
[2] - https://wiki.openstack.org/wiki/Successes

 
Community Summaries
===
* TC Report 43 by Chris Dent [0]
* Nova Notification Update Week 43 by Balazs Gibizer [1]
* POST /api-sig/news by Chris Dent [2]
* Technical Committee Status Update by Thierry Carrez [3]
* Nova Placements Resource Provider Update [4]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123944.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123990.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/124023.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123818.html
[4] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/124052.html

 
Time to Remove the Ceilometer API?
==
Summarized by Jeremy Stanley
 
The Ceilometer REST API was deprecated in Ocata, a year ago, and the User
Survey indicates more than half its users have switched to the non-OpenStack
Gnocchi service's API instead (using Ceilometer as a backend). The Ceilometer
install guide has also been recommending Gnocchi at least as long ago as
Newton. The old API has become an attractive nuisance from the Telemetry team's
perspective, and they'd like to go ahead and drop it altogether in Queens.
 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123593.html
 
 
Keystone v2.0 API Removal
=
Summarized by Thierry Carrez
 
Keystone Queen's PTL Lance Bragstad gives notice that the Queen's release will
not be included v2.0, except the ec2-api. This is being done after a lengthy
given deprecation period.
 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123783.html


pgpzXzQfguKqq.pgp
Description: PGP signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] Developer Mailing List Digest September 30 – October 6

[Mike Perez]

Thanks to Thierry Carrez and Jeremy Stanley for summarizing this issue of the
Dev Digest!

Contribute to the Dev Digest by summarizing OpenStack Dev List thread:

* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/

HTML Version: 
https://www.openstack.org/blog/2017/10/developer-mailing-list-digest-october-21-27-2017/



News

* TC election results [0]
* Next PTG will be in Dublin, the week of February 26, 2018. More details will
  be posted on openstack.org/ptg as soon as we have them. [1]

[0] http://lists.openstack.org/pipermail/openstack-dev/2017-October/123845.html
[1] http://lists.openstack.org/pipermail/openstack-dev/2017-October/124021.html

 
SuccessBot Says
===
* gothamr_  [0]:changes to the manila driverfixes branches can finally be
  merged xD Thanks infra folks for ZuulV3!
* andreaf [1]: Tempest test base class is now a stable API for plugins
* More [2]

[0] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-manila/%23openstack-manila.2017-10-17.log.html
[1] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2017-10-24.log.html
[2] - https://wiki.openstack.org/wiki/Successes

 
Community Summaries
===
* TC Report 43 by Chris Dent [0]
* Nova Notification Update Week 43 by Balazs Gibizer [1]
* POST /api-sig/news by Chris Dent [2]
* Technical Committee Status Update by Thierry Carrez [3]
* Nova Placements Resource Provider Update [4]

[0] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123944.html
[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123990.html
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/124023.html
[3] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123818.html
[4] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/124052.html

 
Time to Remove the Ceilometer API?
==
Summarized by Jeremy Stanley
 
The Ceilometer REST API was deprecated in Ocata, a year ago, and the User
Survey indicates more than half its users have switched to the non-OpenStack
Gnocchi service's API instead (using Ceilometer as a backend). The Ceilometer
install guide has also been recommending Gnocchi at least as long ago as
Newton. The old API has become an attractive nuisance from the Telemetry team's
perspective, and they'd like to go ahead and drop it altogether in Queens.
 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123593.html
 
 
Keystone v2.0 API Removal
=
Summarized by Thierry Carrez
 
Keystone Queen's PTL Lance Bragstad gives notice that the Queen's release will
not be included v2.0, except the ec2-api. This is being done after a lengthy
given deprecation period.
 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123783.html


pgpB2eZcqVoRU.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] [all] TC Report 43

[Mike Perez]

On 11:17 Oct 25, Flavio Percoco wrote:
> On 24/10/17 19:26 +0100, Chris Dent wrote:
> >It's clear that anyone and everyone _could_ write their own blogs and
> >syndicate to the [OpenStack planet](http://planet.openstack.org/) but
> >this doesn't have the same panache and potential cadence as an
> >official thing _might_. It comes down to people having the time. Eking
> >out the time for this blog, for example, can be challenging.
> >
> >Since this is the second [week in a
> >row](https://anticdent.org/tc-report-42.html) that Josh showed up with
> >an idea, I wonder what next week will bring?
> 
> I might not be exactly the same but, I think the superuser's blog could be a
> good place to do some of this writing. There are posts of various kinds in 
> that
> blog: technical, community, news, etc. I wonder how many folks from the
> community are aware of it and how many would be willing to contribute to it 
> too.
> Contributing to the superuser's blog is quite simple, really.

Anne used to do TC updates and they were posted to the OpenStack Blog:

https://www.openstack.org/blog/category/technical-committee-updates/

-- 
Mike Perez


pgpHJDadMERqZ.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] OpenStack Dev Digest is Open to Volunteers!

[Mike Perez]

On 19:06 Oct 17, Mike Perez wrote:
> Hey all,
> 
> The OpenStack Dev Digest has been receiving great feedback from various 
> members
> of our community as being a good resource to get important summaries of 
> threads
> they might be interested in responding back to and/or being informed on.
> 
> Currently the Dev Digest gets posted by me on the OpenStack blog [1] weekly
> when I can, gets posted on the dev list, the operators lists, OpenStack
> twitter, and LWN [2].
> 
> Summarizing everything can be a lot of work. I recently read the User Group
> Newsletter [3] by Sonia Ramza and noticed the content is created by the
> community via an etherpad.
> 
> I would like to do the same with the Dev Digest and have started a new 
> etherpad
> [4]. I will still be writing the Dev Digest and acting editor, but hoping to
> lean more on the community for content I might've missed and getting
> corrections.
> 
> The cut off each week for now we'll say is every Friday at 19:00 UTC. Thank
> you!
> 
> [1] - https://www.openstack.org/blog
> [2] - https://lwn.net
> [3] - 
> https://www.openstack.org/blog/2017/10/user-group-newsletter-september-2017/
> [4] - https://etherpad.openstack.org/p/devdigest

Reminder the cut off is tomorrow at 19:00 UTC. Thanks Fungi for writing on
"Time To Remove the Ceilometer API"!

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack] OpenStack Dev Digest is Open to Volunteers!

[Mike Perez]

Hey all,

The OpenStack Dev Digest has been receiving great feedback from various members
of our community as being a good resource to get important summaries of threads
they might be interested in responding back to and/or being informed on.

Currently the Dev Digest gets posted by me on the OpenStack blog [1] weekly
when I can, gets posted on the dev list, the operators lists, OpenStack
twitter, and LWN [2].

Summarizing everything can be a lot of work. I recently read the User Group
Newsletter [3] by Sonia Ramza and noticed the content is created by the
community via an etherpad.

I would like to do the same with the Dev Digest and have started a new etherpad
[4]. I will still be writing the Dev Digest and acting editor, but hoping to
lean more on the community for content I might've missed and getting
corrections.

The cut off each week for now we'll say is every Friday at 19:00 UTC. Thank
you!

[1] - https://www.openstack.org/blog
[2] - https://lwn.net
[3] - 
https://www.openstack.org/blog/2017/10/user-group-newsletter-september-2017/
[4] - https://etherpad.openstack.org/p/devdigest

-- 
Mike Perez


signature.asc
Description: PGP signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack-operators] OpenStack Dev Digest is Open to Volunteers!

[Mike Perez]

Hey all,

The OpenStack Dev Digest has been receiving great feedback from various members
of our community as being a good resource to get important summaries of threads
they might be interested in responding back to and/or being informed on.

Currently the Dev Digest gets posted by me on the OpenStack blog [1] weekly
when I can, gets posted on the dev list, the operators lists, OpenStack
twitter, and LWN [2].

Summarizing everything can be a lot of work. I recently read the User Group
Newsletter [3] by Sonia Ramza and noticed the content is created by the
community via an etherpad.

I would like to do the same with the Dev Digest and have started a new etherpad
[4]. I will still be writing the Dev Digest and acting editor, but hoping to
lean more on the community for content I might've missed and getting
corrections.

The cut off each week for now we'll say is every Friday at 19:00 UTC. Thank
you!

[1] - https://www.openstack.org/blog
[2] - https://lwn.net
[3] - 
https://www.openstack.org/blog/2017/10/user-group-newsletter-september-2017/
[4] - https://etherpad.openstack.org/p/devdigest

-- 
Mike Perez


signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] OpenStack Dev Digest is Open to Volunteers!

[Mike Perez]

Hey all,

The OpenStack Dev Digest has been receiving great feedback from various members
of our community as being a good resource to get important summaries of threads
they might be interested in responding back to and/or being informed on.

Currently the Dev Digest gets posted by me on the OpenStack blog [1] weekly
when I can, gets posted on the dev list, the operators lists, OpenStack
twitter, and LWN [2].

Summarizing everything can be a lot of work. I recently read the User Group
Newsletter [3] by Sonia Ramza and noticed the content is created by the
community via an etherpad.

I would like to do the same with the Dev Digest and have started a new etherpad
[4]. I will still be writing the Dev Digest and acting editor, but hoping to
lean more on the community for content I might've missed and getting
corrections.

The cut off each week for now we'll say is every Friday at 19:00 UTC. Thank
you!

[1] - https://www.openstack.org/blog
[2] - https://lwn.net
[3] - 
https://www.openstack.org/blog/2017/10/user-group-newsletter-september-2017/
[4] - https://etherpad.openstack.org/p/devdigest

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all][docs][contributor-guide] Onboarding Contributor Content Help Wanted

[Mike Perez]

Hey all,

tldr; There's an effort to collect general documentation for new OpenStack
contributors. The content that qualifies as general so far is Git, IRC, account
setup. We are looking for help to write new content at the git repo
openstack/contributor-guide.

No that subject tag is not a mistake. There are two projects recently that I've
been active with that have the word "Contributor" in it.

1) Contributor Portal - The openstack.org/community page update that focuses
   more on guiding potential contributors to areas of interest. This will link
   people to the general documentation set for that category (The Contributor
   Guide)and the project team's specific documentation if any. Everyone gets
   general onboarding contributor documentation for free! In addition it serves
   as a great landing page of resources for existing contributors. [1]

2) Contributor Guide - A sphinx project of where the general documentation
   is stored. [2] I'm waiting on a couple of patches to merge [3][4], but this
   will be published at https://docs.openstack.org/contributors

My goal is to make the Contributor Guide and Contributor Portal available to
all projects for their Onboarding rooms in Sydney [5].

If you're not familiar with this effort, we're creating general documentation
(e.g. IRC, git, account setup, and more) in an effort to keep them up-to-date
and not have outdated silos of this type of documentation. From the PTG
discussion [4] it was agreed that general documentation can live in a separate
repository (i.e. Contributor Guide), but project specific documentation will
continue to live in the development documentation of the respected project.

I'm looking for volunteers to help build our Contributor guide. I think
a good starting point is to look at how we can help keep some content fresh for
things like the Upstream Institute [6]. They have a great layout that we can
build off of from their content page [7].

If anyone is interested in helping with making our onboarding experience
better, please checkout the git repository [8] and lets collaborate on this
content. I'm thingee on freenode and in the #openstack-doc room for these
related discussions.

Shout out to Kendall Nelson, Anne Bertucio, Frank Kloeker, Ildiko Vancsa, Amy
Marrich, Thierry Carrez, Lauren Sell, Jimmy McArthur, Wes Wilson, the
Documentation Core team, and Infra core team for getting this project going!

Thanks!

[1] - http://lists.openstack.org/pipermail/openstack-dev/2017-June/118877.html
[2] - https://review.openstack.org/#/c/511033/
[3] - https://review.openstack.org/#/c/512865/
[4] - https://review.openstack.org/#/c/512871/
[5] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-October/123206.html
[6] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122534.html
[7] - https://docs.openstack.org/upstream-training/
[8] - 
https://docs.openstack.org/upstream-training/upstream-training-content.html
[9] - https://git.openstack.org/contributor-guide

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [forum] Schedule Is Available

[Mike Perez]

On 16:43 Oct 16, Mike Perez wrote:
> Hey all,
> 
> Thanks to Jimmy McArthur for getting the schedule posted so quickly! Here's 
> the
> schedule posted on the Summit site filtering by forum related sessions:
> 
> https://www.openstack.org/summit/sydney-2017/summit-schedule/#day=2017-11-06_groups=63
> 
> Please reply to give corrections.
> 
> I will be sending emails to listed moderators to verify there will be someone
> physically present at the Forum to moderate the session. Thank you!

Hey all,

I was infomed that making changes to the schedule can cause a cascade of
conflicts at this point. If you are scheduled however at multiple places at
once, please let us know at speakersupp...@openstack.org

Thanks everyone!

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] [thin...@gmail.com: [forum] Schedule Is Available]

[Mike Perez]

- Forwarded message from Mike Perez <thin...@gmail.com> -

From: Mike Perez <thin...@gmail.com>
To: openstack-...@lists.openstack.org
Date: Mon, 16 Oct 2017 16:43:28 -0700
Subject: [forum] Schedule Is Available

Hey all,

Thanks to Jimmy McArthur for getting the schedule posted so quickly! Here's the
schedule posted on the Summit site filtering by forum related sessions:

https://www.openstack.org/summit/sydney-2017/summit-schedule/#day=2017-11-06_groups=63

Please reply to give corrections.

I will be sending emails to listed moderators to verify there will be someone
physically present at the Forum to moderate the session. Thank you!

-- 
Mike Perez



- End forwarded message -----

-- 
Mike Perez


signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [forum] Schedule Is Available

[Mike Perez]

Hey all,

Thanks to Jimmy McArthur for getting the schedule posted so quickly! Here's the
schedule posted on the Summit site filtering by forum related sessions:

https://www.openstack.org/summit/sydney-2017/summit-schedule/#day=2017-11-06_groups=63

Please reply to give corrections.

I will be sending emails to listed moderators to verify there will be someone
physically present at the Forum to moderate the session. Thank you!

-- 
Mike Perez


pgp9j7R_QsGGu.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] Developer Mailing List Digest September 30 - October 6

[Mike Perez]

HTML version: 
https://www.openstack.org/blog/2017/10/developer-mailing-list-digest-september-30-6-2017/

## Summaries
* OpenStack Technical Committee
*  [TC report 
40](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123063.html)
 by Chris Dent
* [TC report 
41](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123397.html)
 by Chris Dent
* [Technical Committee Status update, October 
6th](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123236.html)
 by Thierry Carrez
* [Technical Committee Status update, October 
13th](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123573.html)
 by Thierry Carrez
* Zuul
* [Zuul v3 Status - and Rollback 
Information](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123049.html)
  by Monty Taylor
* [Important information for people with in-repo Zuul v3 
config](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123064.html)
 by Monty Taylor
* [Zuul v3 rollout, the 
sequel](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123337.html)
 by Jeremy Stanley
* [Zuul v3 Rollout Update - devstack-gate issues 
edition](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123464.html)
 by Monty Taylor
* [Zuul v3 rollout, the sequel 
returns](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123618.html)
 by Jeremy Stanley
* [POST 
/api-sig/news](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123208.html)
* [Release countdown for week R-19, October 
13-20](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123516.html)
 by Sean McGinnis
* [QA Office Hours 
Report](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123520.html)
 by Andrea Frittoli
* [Keystone Office Hours 
Report](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123271.html)
 by Lance Bragstad
* Nova
* [Placement resource providers update 
36](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123244.html)
 by Chris Dent
* [Placement resource providers update 
38](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123581.html)
 by Chris Dent

## Sydney Forum Schedule Available
* [View it 
now!](https://www.openstack.org/summit/sydney-2017/summit-schedule/#day=2017-11-06_groups=63)

## TC Nomination Period Is Now Over
* Kendall Nelson has announced the [official candidate 
list](https://governance.openstack.org/election/#pike-tc-candidates).

## Prepping for the Stable/Newton EOL
* The [published timeline](https://releases.openstack.org/queens/schedule.html) 
is:
* Sep 29 : Final newton library releases
* Oct 09 : stable/newton branches enter Phase III
* Oct 11 : stable/newton branches get tagged EOL
* Given that those key dates were a little disrupted, Tony Breeds is proposing
  adding a week to each so the new timeline looks like:
* Oct 08 : Final newton library releases
* Oct 16 : stable/newton branches enter Phase III
* Oct 18 : stable/newton branches get tagged EOL
* 
[Thread](http://lists.openstack.org/pipermail/openstack-dev/2017-October/thread.html#123088)

## Policy Community Wide Goal Progress
* [The 
goal](https://governance.openstack.org/tc/goals/queens/policy-in-code.html)
* [Burn down chart](https://www.lbragstad.com/policy-burndown/)
* Over half the projects attempted the goal.
* 
[Message](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123040.html)

## Tempest Plugin Split Community Wide Goal Progress
* [The 
goal](https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html)
* [The 
reviews](https://review.openstack.org/#/q/topic:goal-split-tempest-plugins+status:open)
* List of projects which have already completed the goal:
- Barbican
- Designate
- Horizon
- Keystone
- Kuryr
- Os-win
- Sahara
- Solum
- Watcher
* List of projects which are working on the goal:
- Aodh
- Cinder
- Magnum
- Manila
- Murano
- Neutron
- Neutron L2GW
- Octavia
- Senlin
- Zaqar
- Zun
- 
[Message](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123268.html)


signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] Developer Mailing List Digest September 30 - October 6

[Mike Perez]

HTML version: 
https://www.openstack.org/blog/2017/10/developer-mailing-list-digest-september-30-6-2017/

## Summaries
* OpenStack Technical Committee
*  [TC report 
40](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123063.html)
 by Chris Dent
* [TC report 
41](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123397.html)
 by Chris Dent
* [Technical Committee Status update, October 
6th](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123236.html)
 by Thierry Carrez
* [Technical Committee Status update, October 
13th](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123573.html)
 by Thierry Carrez
* Zuul
* [Zuul v3 Status - and Rollback 
Information](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123049.html)
  by Monty Taylor
* [Important information for people with in-repo Zuul v3 
config](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123064.html)
 by Monty Taylor
* [Zuul v3 rollout, the 
sequel](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123337.html)
 by Jeremy Stanley
* [Zuul v3 Rollout Update - devstack-gate issues 
edition](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123464.html)
 by Monty Taylor
* [Zuul v3 rollout, the sequel 
returns](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123618.html)
 by Jeremy Stanley
* [POST 
/api-sig/news](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123208.html)
* [Release countdown for week R-19, October 
13-20](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123516.html)
 by Sean McGinnis
* [QA Office Hours 
Report](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123520.html)
 by Andrea Frittoli
* [Keystone Office Hours 
Report](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123271.html)
 by Lance Bragstad
* Nova
* [Placement resource providers update 
36](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123244.html)
 by Chris Dent
* [Placement resource providers update 
38](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123581.html)
 by Chris Dent

## Sydney Forum Schedule Available
* [View it 
now!](https://www.openstack.org/summit/sydney-2017/summit-schedule/#day=2017-11-06_groups=63)

## TC Nomination Period Is Now Over
* Kendall Nelson has announced the [official candidate 
list](https://governance.openstack.org/election/#pike-tc-candidates).

## Prepping for the Stable/Newton EOL
* The [published timeline](https://releases.openstack.org/queens/schedule.html) 
is:
* Sep 29 : Final newton library releases
* Oct 09 : stable/newton branches enter Phase III
* Oct 11 : stable/newton branches get tagged EOL
* Given that those key dates were a little disrupted, Tony Breeds is proposing
  adding a week to each so the new timeline looks like:
* Oct 08 : Final newton library releases
* Oct 16 : stable/newton branches enter Phase III
* Oct 18 : stable/newton branches get tagged EOL
* 
[Thread](http://lists.openstack.org/pipermail/openstack-dev/2017-October/thread.html#123088)

## Policy Community Wide Goal Progress
* [The 
goal](https://governance.openstack.org/tc/goals/queens/policy-in-code.html)
* [Burn down chart](https://www.lbragstad.com/policy-burndown/)
* Over half the projects attempted the goal.
* 
[Message](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123040.html)

## Tempest Plugin Split Community Wide Goal Progress
* [The 
goal](https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html)
* [The 
reviews](https://review.openstack.org/#/q/topic:goal-split-tempest-plugins+status:open)
* List of projects which have already completed the goal:
- Barbican
- Designate
- Horizon
- Keystone
- Kuryr
- Os-win
- Sahara
- Solum
- Watcher
* List of projects which are working on the goal:
- Aodh
- Cinder
- Magnum
- Manila
- Murano
- Neutron
- Neutron L2GW
- Octavia
- Senlin
- Zaqar
- Zun
- 
[Message](http://lists.openstack.org/pipermail/openstack-dev/2017-October/123268.html)


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] [forum] Draft Schedule - Deadline Oct 13 Friday 20:00 UTC

[Mike Perez]

nder Block Storage Office Hour  Jay Bryant
11/7 5:00-5:40
Keystone Operator & User Feedback Lance Bragstad
11/7 5:50-6:30
Cells v2 update and direction Matt Riedemann
11/7 5:50-6:30
Trove user feedback   Manoj Kumar   
11/7 5:50-6:30
Java SDKs David F Flanders  
11/7 9:00-9:40
Self-healing and optimization SIG Adam Spiers   
11/7 9:00-9:40
Interop Test Library for OpenStack SDKs   megan 
11/7 9:00-9:40
Users / Operators adoption of QA tools / plugins  Andrea Frittoli   
11/7 9:50-10:30
OpenStack Charms user feedback sessionJames Page
11/7 9:50-10:30
Zuulv3 Feedback Session   Clark Boylan  
11/7 9:50-10:30
Placement update and directionMatt Riedemann
11/8 1:50-2:30
Designate Ops / End User feedback Graham Hayes  
11/8 1:50-2:30
Baremetal Scheduling  Julia Kreger  
11/8 1:50-2:30
Bare metal as a service: Ironic vs. Mogan vs. NovaZhenguo Niu   
11/8 11:00-11:40
First Contact SIG Formation DiscussionZhipeng   
11/8 11:00-11:40
"NFV meets cloud   virtio   
 sr-iov
User Committee - Planning activities for next cycle   Edgar Magana  
11/8 11:50-12:30
Features missing in OpenStack core for Public Cloud provider  Tobias Rydberg
11/8 11:50-12:30
Watcher users feedbackHidekazu Nakamura 
11/8 11:50-12:30
Neutron pain points   Miguel Lavalle
11/8 2:40-3:20
Heat ops and users feedback   Rico Lin  
11/8 2:40-3:20
Nova: Queens roadmap and checkpoint   Matt Riedemann
11/8 2:40-3:20
Neutron Quality-Of-Service Discussion Reedip
11/8 3:30-4:10
"Refstack: OpenStack to OPNFV Vertical Integrated   
 Interop"
Upstream LTS Releases Erik McCormick
11/8 9:00-9:40
Roadmap: User Feedback Gathering  Anne Bertucio 
11/8 9:00-9:40
Hardware in the cloud Stephen Finucane  
11/8 9:00-9:40
ETSI NFV Specs’ Requirements vs OpenStack Reality forum   Gergely Csatari   
11/8 9:50-10:30
OpenStack Public Cloud Passport Program   Tobias Rydberg
11/8 9:50-10:30
Multi-cloud management projectMatt McEuen   
11/8 9:50-10:30

-- 
Mike Perez


SYD-OpenStack-Forum.pdf
Description: Adobe PDF document


signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [forum] Draft Schedule - Deadline Oct 13 Friday 20:00 UTC

[Mike Perez]

nder Block Storage Office Hour  Jay Bryant
11/7 5:00-5:40
Keystone Operator & User Feedback Lance Bragstad
11/7 5:50-6:30
Cells v2 update and direction Matt Riedemann
11/7 5:50-6:30
Trove user feedback   Manoj Kumar   
11/7 5:50-6:30
Java SDKs David F Flanders  
11/7 9:00-9:40
Self-healing and optimization SIG Adam Spiers   
11/7 9:00-9:40
Interop Test Library for OpenStack SDKs   megan 
11/7 9:00-9:40
Users / Operators adoption of QA tools / plugins  Andrea Frittoli   
11/7 9:50-10:30
OpenStack Charms user feedback sessionJames Page
11/7 9:50-10:30
Zuulv3 Feedback Session   Clark Boylan  
11/7 9:50-10:30
Placement update and directionMatt Riedemann
11/8 1:50-2:30
Designate Ops / End User feedback Graham Hayes  
11/8 1:50-2:30
Baremetal Scheduling  Julia Kreger  
11/8 1:50-2:30
Bare metal as a service: Ironic vs. Mogan vs. NovaZhenguo Niu   
11/8 11:00-11:40
First Contact SIG Formation DiscussionZhipeng   
11/8 11:00-11:40
"NFV meets cloud   virtio   
 sr-iov
User Committee - Planning activities for next cycle   Edgar Magana  
11/8 11:50-12:30
Features missing in OpenStack core for Public Cloud provider  Tobias Rydberg
11/8 11:50-12:30
Watcher users feedbackHidekazu Nakamura 
11/8 11:50-12:30
Neutron pain points   Miguel Lavalle
11/8 2:40-3:20
Heat ops and users feedback   Rico Lin  
11/8 2:40-3:20
Nova: Queens roadmap and checkpoint   Matt Riedemann
11/8 2:40-3:20
Neutron Quality-Of-Service Discussion Reedip
11/8 3:30-4:10
"Refstack: OpenStack to OPNFV Vertical Integrated   
 Interop"
Upstream LTS Releases Erik McCormick
11/8 9:00-9:40
Roadmap: User Feedback Gathering  Anne Bertucio 
11/8 9:00-9:40
Hardware in the cloud Stephen Finucane  
11/8 9:00-9:40
ETSI NFV Specs’ Requirements vs OpenStack Reality forum   Gergely Csatari   
11/8 9:50-10:30
OpenStack Public Cloud Passport Program   Tobias Rydberg
11/8 9:50-10:30
Multi-cloud management projectMatt McEuen   
11/8 9:50-10:30

-- 
Mike Perez


SYD-OpenStack-Forum.pdf
Description: Adobe PDF document


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack-operators] [openstack-dev] Sydney Forum Topic Submission

[Mike Perez]

On 16:15 Sep 21, Shamail Tahir wrote:
> Hi,
> 
> We have made it to the next stage of the topic selection process for the
> Forum in Sydney!
> 
> At the Forum the entire OpenStack community (users and developers) gathers
> to brainstorm the requirements for the next release, gather feedback on the
> past version and have strategic discussions that go beyond just one release
> cycle. The Sydney Forum is the start of the Rocky release cycle. Please
> prepare session ideas with feedback from the Pike release in mind.
> 
> Our submission tool is now open for you to submit abstracts for the most
> popular sessions that came out of your brainstorming.
> 
> Ask all session leaders to submit their abstracts at:
> http://forumtopics.openstack.org/
> 
> before *11:59PM UTC on Friday September 29th*!
> 
> We are looking for a good mix of project-specific, cross-project or
> strategic/whole-of-community discussions, and sessions that emphasize
> collaboration between users and developers are most welcome!
> 
> We assume that anything submitted to the Forum Topics Tool has achieved a
> good amount of discussion and consensus that it's a worthwhile topic. After
> submissions close, a team of representatives from the User Committee, the
> Technical Committee, and Foundation staff will take the sessions proposed
> by the community and fill out the schedule.
> 
> You can expect the draft schedule to be released on October 9th, 2017.
> 
> Further details about the Forum can be found at:
> https://wiki.openstack.org/wiki/Forum

Hi all!

We're a bit delayed in having that draft available for you all. The committee
has voted on the submitted forum topics and is currently waiting to hold
a discussion on Wednesday October 11th to finalize the selection.

You can now expect a draft available October 12th. Thank you.

-- 
Mike Perez


signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] Sydney Forum Topic Submission

[Mike Perez]

On 16:15 Sep 21, Shamail Tahir wrote:
> Hi,
> 
> We have made it to the next stage of the topic selection process for the
> Forum in Sydney!
> 
> At the Forum the entire OpenStack community (users and developers) gathers
> to brainstorm the requirements for the next release, gather feedback on the
> past version and have strategic discussions that go beyond just one release
> cycle. The Sydney Forum is the start of the Rocky release cycle. Please
> prepare session ideas with feedback from the Pike release in mind.
> 
> Our submission tool is now open for you to submit abstracts for the most
> popular sessions that came out of your brainstorming.
> 
> Ask all session leaders to submit their abstracts at:
> http://forumtopics.openstack.org/
> 
> before *11:59PM UTC on Friday September 29th*!
> 
> We are looking for a good mix of project-specific, cross-project or
> strategic/whole-of-community discussions, and sessions that emphasize
> collaboration between users and developers are most welcome!
> 
> We assume that anything submitted to the Forum Topics Tool has achieved a
> good amount of discussion and consensus that it's a worthwhile topic. After
> submissions close, a team of representatives from the User Committee, the
> Technical Committee, and Foundation staff will take the sessions proposed
> by the community and fill out the schedule.
> 
> You can expect the draft schedule to be released on October 9th, 2017.
> 
> Further details about the Forum can be found at:
> https://wiki.openstack.org/wiki/Forum

Hi all!

We're a bit delayed in having that draft available for you all. The committee
has voted on the submitted forum topics and is currently waiting to hold
a discussion on Wednesday October 11th to finalize the selection.

You can now expect a draft available October 12th. Thank you.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Project Ideas for Graduate Student

[Mike Perez]

On 15:27 Oct 05, Mike Perez wrote:
> On 02:59 Oct 05, Puneet Jain wrote:
> > Hello all,
> > 
> > I am a graduate student and have intermediate knowledge and huge in cloud
> > computing. I am looking for a project idea, particularly any new feature I
> > can implement in OpenStack.
> > 
> > I thought of implementing multi-factor authentication but happened to know
> > that it has already been implemented.
> > https://docs.openstack.org/security-guide/identity/authentication.html
> > 
> > I would prefer to do something in security. Any ideas?
> > 
> > Looking forward to hearing from you guys. Thanks in advance!
> 
> Welcome to the community Puneet! We have various Security group related
> projects listed here:
> 
> https://wiki.openstack.org/wiki/Security
> 
> You can also find various Security/Identity/Compliance OpenStack project
> services listed in our project navigator:
> 
> https://www.openstack.org/software/project-navigator/
> 
> Also on freenode irc we have #openstack-security. You can see more channels:
> 
> https://wiki.openstack.org/wiki/IRC
> 
> Here are some helpful documents in setting up IRC, git, and the various
> accounts you'll be using in our community:
> 
> https://docs.openstack.org/upstream-training/irc.html
> https://docs.openstack.org/upstream-training/git.html
> https://docs.openstack.org/upstream-training/accounts.html
> 
> -- 
> Mike Perez

Actually this account setup documentation is more up-to-date and better:

https://docs.openstack.org/infra/manual/developers.html#account-setup

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Project Ideas for Graduate Student

[Mike Perez]

On 02:59 Oct 05, Puneet Jain wrote:
> Hello all,
> 
> I am a graduate student and have intermediate knowledge and huge in cloud
> computing. I am looking for a project idea, particularly any new feature I
> can implement in OpenStack.
> 
> I thought of implementing multi-factor authentication but happened to know
> that it has already been implemented.
> https://docs.openstack.org/security-guide/identity/authentication.html
> 
> I would prefer to do something in security. Any ideas?
> 
> Looking forward to hearing from you guys. Thanks in advance!

Welcome to the community Puneet! We have various Security group related
projects listed here:

https://wiki.openstack.org/wiki/Security

You can also find various Security/Identity/Compliance OpenStack project
services listed in our project navigator:

https://www.openstack.org/software/project-navigator/

Also on freenode irc we have #openstack-security. You can see more channels:

https://wiki.openstack.org/wiki/IRC

Here are some helpful documents in setting up IRC, git, and the various
accounts you'll be using in our community:

https://docs.openstack.org/upstream-training/irc.html
https://docs.openstack.org/upstream-training/git.html
https://docs.openstack.org/upstream-training/accounts.html

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] policy community goal progress

[Mike Perez]

On 09:37 Oct 03, Lance Bragstad wrote:
> Hey all,
> 
> According to our burndown chart [0], just over half the projects have
> started implementing the goal [1]. I've been proposing patches for some
> of the projects in the not-started column. Most patches I've been
> working on would benefit from a review from someone more experienced
> with the project. Some projects have policies aren't documented in their
> respective API reference, so providing useful descriptions is going to
> have to come from project developers. Other patches are tripping over
> fake policies that are inconsistent with the packaged policy file. Those
> could require additional testing logic to ensure the tests are actually
> testing the defaults and not just empty policies ("").
> 
> As always, if you have questions about how to get started, please feel
> free to come find me. If I've proposed an implementation for a your
> project [2], don't hesitate to pick it up and run with it. This will
> free me up to continue helping other projects that have yet to get started.
> 
> Thanks!
> 
> Lance
> 
> [0] https://www.lbragstad.com/policy-burndown/
> [1] https://governance.openstack.org/tc/goals/queens/policy-in-code.html
> [2]
> https://review.openstack.org/#/q/topic:policy-and-docs-in-code+status:open

Happy to see openstack-dev/sandbox has come onboard with this effort. I will
definitely start pitching in on the Cinder reviews and promoting in whatever
ways I can with the Dev Digest and resources I have.

Lance, thank you for setting a great example of someone championing
a community-wide goal. 

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptg] Simplification in OpenStack

[Mike Perez]

On 10:45 Sep 12, Mike Perez wrote:
> Hey all,
> 
> Back in a joint meeting with the TC, UC, Foundation and The Board it was
> decided as an area of OpenStack to focus was Simplifying OpenStack. This
> intentionally was very broad so the community can kick start the conversation
> and help tackle some broad feedback we get.
> 
> Unfortunately yesterday there was a low turn out in the Simplification room.
> A group of people from the Swift team, Kevin Fox and Swimingly were nice
> enough to start the conversation and give some feedback. You can see our
> initial ether pad work here:
> 
> https://etherpad.openstack.org/p/simplifying-os
> 
> There are efforts happening everyday helping with this goal, and our team has
> made some documented improvements that can be found in our report to the
> board within the ether pad. I would like to take a step back with this
> opportunity to have in person discussions for us to identify what are the
> area of simplifying that are worthwhile. I’m taking a break from the room at
> the moment for lunch, but I encourage people at 13:30 local time to meet at
> the simplification room level b in the big thompson room. Thank you!

Sorry for the late reply all. Decompression from burning man and ptg :).

Thanks for the discussions everyone has brought to this thread. I think we did
a good job brainstorming and identifying what we have more information on.

I would like to move this discussion to a different thread that focuses on
those more identified areas, with relation to the recent user survey:

http://lists.openstack.org/pipermail/openstack-dev/2017-October/123086.html

Lets keep this momentum going!

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] [simplification] PTG Recap

[Mike Perez]

th all of these releases. Only do a release once every two 
years

[1] - https://etherpad.openstack.org/p/queens-PTG-skip-level-upgrades
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-May/thread.html#116677
[3] - 
https://www.openstack.org/blog/2017/05/openstack-developer-mailing-list-digest-20170526/
 

## Operations
### Etherpad Summary

 Confusion with OpenStack Client and Project Clients
* OpenStack client doesn’t entirely support micro versions on some nova
  functionality.
* Functions that work in OpenStack Client, but not in the project clients
  themselves (e.g., Kerberos)
* Given that OpenStack Client is now available and widely used, I still see new
  projects being created with their project clients which is strange.

 OpenStack Client Needs to Be Better
* The documentation needs to be better, possibly its interface.
* A couple of examples from the current documentation [1]. 
  * get_rdp_console doesn't even tell me what it returns (many calls there have
this issue).
  * The first object on the page, novaclient.v2.servers.NetworkInterface,
refers to a 'manager' - what's a manager? (The answer is probably that this
isn't user callable, but I'd be fine with it saying that.)
  * If people are expected to use these in the right way, let alone use the
right versions, we need to offer them more help than this.
 
 More Documentation
* Scaling the infrastructure. How to do this? When? How to detect?
* Recommendations?
* Ensure high availability. Recommendations?
* Networking: production vs. testing
* Integration with LDAP. Scarcely documented.
* Quotas

[1] - 
https://docs.openstack.org/python-novaclient/pike/reference/api/v2/servers.html

-- 
Mike Perez


signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [simplification] PTG Recap

[Mike Perez]

th all of these releases. Only do a release once every two 
years

[1] - https://etherpad.openstack.org/p/queens-PTG-skip-level-upgrades
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-May/thread.html#116677
[3] - 
https://www.openstack.org/blog/2017/05/openstack-developer-mailing-list-digest-20170526/
 

## Operations
### Etherpad Summary

 Confusion with OpenStack Client and Project Clients
* OpenStack client doesn’t entirely support micro versions on some nova
  functionality.
* Functions that work in OpenStack Client, but not in the project clients
  themselves (e.g., Kerberos)
* Given that OpenStack Client is now available and widely used, I still see new
  projects being created with their project clients which is strange.

 OpenStack Client Needs to Be Better
* The documentation needs to be better, possibly its interface.
* A couple of examples from the current documentation [1]. 
  * get_rdp_console doesn't even tell me what it returns (many calls there have
this issue).
  * The first object on the page, novaclient.v2.servers.NetworkInterface,
refers to a 'manager' - what's a manager? (The answer is probably that this
isn't user callable, but I'd be fine with it saying that.)
  * If people are expected to use these in the right way, let alone use the
right versions, we need to offer them more help than this.
 
 More Documentation
* Scaling the infrastructure. How to do this? When? How to detect?
* Recommendations?
* Ensure high availability. Recommendations?
* Networking: production vs. testing
* Integration with LDAP. Scarcely documented.
* Quotas

[1] - 
https://docs.openstack.org/python-novaclient/pike/reference/api/v2/servers.html

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][zuul] A Sad Farewell

[Mike Perez]

On 11:17 Oct 03, Dean Troyer wrote:
> On Mon, Oct 2, 2017 at 9:13 PM, Jamie Lennox <jamielen...@gmail.com> wrote:
> > I'm really sad to announce that I'll be leaving the OpenStack community (at
> > least for a while), I've accepted a new position unrelated to OpenStack
> > that'll begin in a few weeks, and am going to be mostly on holiday until
> > then.
> 
> No, this just will not do. -2
> 
> Seriously, it has been a great pleasure to 'try to take over the
> world' with you, at least that is what I recall as the goal we set in
> Hong Kong.  The entire interaction of Python-based clients with
> OpenStack has been made so much better with your contributions and
> OpenStackClient would not have gotten as far as it has without them.
> Thank You.
> 
> dt
> 
> /me looking for one more post-Summit beer-debrief in the hotel lobby
> next month...

Yes add me for some bourbon. Thank you Jamie for helping me with various things
in the keystone api's. It has been a pleasure working with you.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Zuul v3 Status - and Rollback Information

[Mike Perez]

On 19:38 Oct 03, Jean-Philippe Evrard wrote:
> On Tue, Oct 3, 2017 at 5:40 PM, Monty Taylor <mord...@inaugust.com> wrote:
> > Hey everybody!


 
> Hello,
> 
> I'd like to first thank everyone involved, doing this hard work.

Yes thank you all very much for your hardwork. I think we can all agree
"computers happen."

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [storyboard] Should New Projects Be Using Storyboard?

[Mike Perez]

I noticed that the project creator [1] and cookiecutter [2] promote using
launchpad. If we're migrating projects to storyboard today, should we stop
promoting launchpad for new projects?

[1] - https://docs.openstack.org/infra/manual/creators.html
[2] - 
https://git.openstack.org/cgit/openstack-dev/cookiecutter/tree/cookiecutter.json#n6

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] Developer Mailing List Digest September 23-29

[Mike Perez]

 the marketing community and projects 
work together to make the release communications happen.
* Having multiple, repetitive demands to summarize" top features" during 
release time can be a pester, and having to re-collect the information each 
time isn't an effective use of time.
* Being asked to make a polished, "Press–Friendly" message out of release 
can feel too far outside of the PTL’s Focus areas or skills.
* Technical content marketers, attempting to find the key features from 
release notes, mailing lists, specifications, roadmaps, whatever means 
interesting features are sometimes overlooked.
* To address this gap, the release team and foundation marketing team proposed 
collecting information as part of the release tagging process.
* We will collect from deliverable files to provide highlights for the 
series (about three items).
* The text will be used to build a landing page on release.openstack.org 
that shows the"Key features" flagged by PTL’s that the marketing teams should 
be looking at during release communication times.
* This page will link to the [release 
notes](https://release.openstack.org) so marketers can gather additional 
information.
* 
[Message](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122678.html)


## Simplification in OpenStack
* Two camps appear: people that want to see OpenStack as a product with a way 
of doing deployments and the people who want to focus on configuration 
management tools.
* One person gives an example of using both Ubuntu MAAS and Puppet. The 
puppet solution allowed for using existing deployment methodologies unlike the 
former.
* We should start promoting and using a single solution for the bulk of the 
community efforts. Right now we do that with Devstack as a reference 
implementation that nobody should use for anything but dev/test.
* This sort of idea could make other deployment efforts relevant.
* Kolla came up at the PTG: scenario-based testing and documentation based on 
different  “constellations" or use cases.
* Puppet has been doing 
[this](https://github.com/openstack/puppet-openstack-integration) and Triple-o 
has been doing 
[this](https://docs.openstack.org/tripleo-quickstart/latest/feature-configuration.html).
* If you break down actual use cases, most people want nova (qemu+KVM), 
neutron (vxlan, potentially VLAN), Cinder (ceph).
* If we agreed to cover 90% of users, that'll boil down to 4 to 5 
different “constellations.”
* Someone has been working on a local testing environment, and it boils 
down to [this](https://github.com/test-kitchen/test-kitchen/issues/873).
* 
[Thread](http://lists.openstack.org/pipermail/openstack-dev/2017-September/thread.html#122075)


-- 
Mike Perez


signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] Developer Mailing List Digest September 23-29

[Mike Perez]

 the marketing community and projects 
work together to make the release communications happen.
* Having multiple, repetitive demands to summarize" top features" during 
release time can be a pester, and having to re-collect the information each 
time isn't an effective use of time.
* Being asked to make a polished, "Press–Friendly" message out of release 
can feel too far outside of the PTL’s Focus areas or skills.
* Technical content marketers, attempting to find the key features from 
release notes, mailing lists, specifications, roadmaps, whatever means 
interesting features are sometimes overlooked.
* To address this gap, the release team and foundation marketing team proposed 
collecting information as part of the release tagging process.
* We will collect from deliverable files to provide highlights for the 
series (about three items).
* The text will be used to build a landing page on release.openstack.org 
that shows the"Key features" flagged by PTL’s that the marketing teams should 
be looking at during release communication times.
* This page will link to the [release 
notes](https://release.openstack.org) so marketers can gather additional 
information.
* 
[Message](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122678.html)


## Simplification in OpenStack
* Two camps appear: people that want to see OpenStack as a product with a way 
of doing deployments and the people who want to focus on configuration 
management tools.
* One person gives an example of using both Ubuntu MAAS and Puppet. The 
puppet solution allowed for using existing deployment methodologies unlike the 
former.
* We should start promoting and using a single solution for the bulk of the 
community efforts. Right now we do that with Devstack as a reference 
implementation that nobody should use for anything but dev/test.
* This sort of idea could make other deployment efforts relevant.
* Kolla came up at the PTG: scenario-based testing and documentation based on 
different  “constellations" or use cases.
* Puppet has been doing 
[this](https://github.com/openstack/puppet-openstack-integration) and Triple-o 
has been doing 
[this](https://docs.openstack.org/tripleo-quickstart/latest/feature-configuration.html).
* If you break down actual use cases, most people want nova (qemu+KVM), 
neutron (vxlan, potentially VLAN), Cinder (ceph).
* If we agreed to cover 90% of users, that'll boil down to 4 to 5 
different “constellations.”
* Someone has been working on a local testing environment, and it boils 
down to [this](https://github.com/test-kitchen/test-kitchen/issues/873).
* 
[Thread](http://lists.openstack.org/pipermail/openstack-dev/2017-September/thread.html#122075)


-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release][ptl] Improving the process for release marketing

[Mike Perez]

On 14:33 Sep 26, Anne Bertucio wrote:
> Release marketing is a critical part of sharing what’s new in each release,
> and we want to rework how the marketing community and projects work together
> to make the release communications happen. 
> 
> Having multiple, repetetive demands to summarize "top features" during
> release time can be pestering and having to recollect the information each
> time isn't an effective use of time. Being asked to make polished,
> "press-friendly" messages out of release notes can feel too far outside of
> the PTL's focus areas or skills. At the same time, for technical content
> marketers, attempting to find the key features from release notes, ML posts,
> specs, Roadmap, etc., means interesting features are sometimes overlooked.
> Marketing teams don't have the latest on what features landed and with what
> caveats.
> 
> To address this gap, the Release team and Foundation marketing team propose
> collecting information as part of the release tagging process. Similar to the
> existing (unused) "highlights" field for an individual tag, we will collect
> some text in the deliverable file to provide highlights for the series (about
> 3 items). That text will then be used to build a landing page on
> release.openstack.org that shows the "key features" flagged by PTLs that
> marketing teams should be looking at during release communication times. The
> page will link to the release notes, so marketers can start there to gather
> additional information, eliminating repetitive asks of PTLs. The "pre
> selection" of features means marketers can spend more time diving into
> release note details and less sifting through them.
> 
> To supplement the written information, the marketing community is also going
> to work together to consolidate follow up questions and deliver them in
> "press corps" style (i.e. a single phone call to be asked questions from
> multiple parties vs. multiple phone calls from individuals).
> 
> We will provide more details about the implementation for the highlights page
> when that is ready, but want to gather feedback about both aspects of the
> plan early.

As being someone who participates in building out that page, I  welcome this to
represent highlights from the community itself better.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] OpenStack Developer Mailing List Digest September 16-22

[Mike Perez]

know where the community needs the most identified help.
* This is a social issue, not a technical issue. Arguing about what is useful 
and what isn’t is probably not worth the effort here.
* Communication and education is probably the best solution here. For repeated 
offenders, off-list email could be fine to make sure the communication is 
clear. Communicating this in the new [contributor 
portal](http://lists.openstack.org/pipermail/openstack-dev/2017-September/122534.html)
 and Upstream Institute would be helpful.
* 
[Thread](http://lists.openstack.org/pipermail/openstack-dev/2017-September/thread.html#122472)

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes

[Mike Perez]

On 08:50 Sep 22, Doug Hellmann wrote:
> Excerpts from Tom Barron's message of 2017-09-22 08:10:35 -0400:
> > 
> > On 09/21/2017 10:21 PM, Matt Riedemann wrote:
> > > I just wanted to highlight to people that there seems to be a series of
> > > garbage patches in various projects [1] which are basically doing things
> > > like fixing a single typo in a code comment, or very narrowly changing
> > > http to https in links within docs.
> > > 
> > > Also +1ing ones own changes.
> > > 
> > > I've been trying to snuff these out in nova, but I see it's basically a
> > > pattern widespread across several projects.
> > > 
> > > This is the boilerplate comment I give with my -1, feel free to employ
> > > it yourself.
> > > 
> > > "Sorry but this isn't really a useful change. Fixing typos in code
> > > comments when the context is still clear doesn't really help us, and
> > > mostly seems like looking for padding stats on stackalytics. It's also a
> > > drain on our CI environment.
> > > 
> > > If you fixed all of the typos in a single module, or in user-facing
> > > documentation, or error messages, or something in the logs, or something
> > > that actually doesn't make sense in code comments, then maybe, but this
> > > isn't one of those things."
> > > 
> > > I'm not trying to be a jerk here, but this is annoying to the point I
> > > felt the need to say something publicly.
> > > 
> > > [1] https://review.openstack.org/#/q/author:%255E.*inspur.*
> > > 
> > 
> > The boilerplate is helpful but have we considered putting something
> > along these lines in official documentation so that reviewers can just
> > point to it? It should then be clear to all that negative reviews on
> > these grounds are not simply a function of the individual reviewer's
> > judgment or personality.
> 
> That's a good idea. How about adding a "Contribution Guidelines" section
> to https://docs.openstack.org/project-team-guide/open-development.html
> with this and other tips?

We can make sure this is linked somehow with the contributor portal when
applicable.

http://lists.openstack.org/pipermail/openstack-dev/2017-September/122534.html

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes

[Mike Perez]

On 15:04 Sep 22, Jeremy Stanley wrote:
> On 2017-09-22 14:50:55 + (+), Rajath Agasthya (rajagast) wrote:
> > On 9/21/17, 10:19 PM, "Jeremy Freudberg" <jeremyfreudb...@gmail.com> wrote:
> > > 3) Delay spin-up of resource-intensive/long-running CI jobs
> > > until after some initial review has been added or time has
> > > passed. Authorized contributors, not necessarily synonymous with
> > > cores, can override the delay if there's a critical patch which
> > > needs to get through the queue quickly.
> >
> > +1. This is done in Go code review process, where CI is run by an
> > explicit Run-TryBot+1 review only after a core developer
> > ascertains that the patch looks okay and most code review comments
> > are addressed. This means no CI resource usage for every change
> > and every single patchset. We could adopt a similar approach so
> > that CI resources aren’t wasted for useless patches. This doesn’t
> > take a whole lot of work for the reviewers than the current review
> > process.
> > 
> > https://github.com/golang/go/wiki/GerritAccess#trybot-access-may-start-trybots
> 
> I'm wary of potential overengineering like this, particularly
> without at least some analysis showing the percentage of CI
> resources we'll save by asking our already overworked (on most teams
> anyway) core reviewers to also take on the task of authorizing basic
> CI jobs. The more likely outcome I foresee is that, much like
> contributions going unreviewed sometimes for weeks or months, the
> change authors won't even know whether their changes are suitable
> for review for some similar period of delay.
> 
> The CI system is there to serve reviewers and contributors, not the
> other way around. The CI resource shortages we see from time to time
> should not be used as an excuse to go on witch hunts so we can find
> ways to save what probably accounts for <1% of our overall
> utilization. That's classic premature optimization. What's important
> in this situation is the time wasted by reviewers having to respond
> to or find ways to ignore these patches, so let's focus on that
> rather than getting bogged down with attractive non-problems for
> which we can more easily engineer technical solutions.

+1

Can you imagine the number of jobs that would be delayed. At least today with
things not be delayed we can see if a patch ever worked when it was rebased in
the CI comments.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs][ptls][install] Install guide vs. tutorial

[Mike Perez]

On 11:33 Sep 21, Alexandra Settle wrote:
> > For me, a tutorial is something that teaches. So after I've gone through a
> > tutorial I would expect to have learned how installs work and would
> > just know
> > these things (with an occasional need to reference a few points) going
> > forward.
> >
> > A guide to me is something that I know I will use whenever I need to do
> > something. So for me, having an installation guide is what I would
> > expect
> > from this as every time I need to do a package based install, I am
> > going to pull
> > up the guide to go through it.
> >
>Interesting.
> 
> So Sean has the opposite impression from Eric and I.  Yeah, that does 
> make it seem like reaching a consensus will be difficult.
> 
> At that point I think consistency becomes the most important thing.
> 
> 
> I completely agree consistency is more important, than bike shedding over the
> name :)
> To be honest, it would be easier to change everything to ‘guide’ – seeing as
> all our URLs are ‘install-guide’.
> But that’s the lazy in me speaking.
> 
> Industry wise – there does seem to be more of a trend towards ‘guide’ rather
> than ‘tutorial’. Although, that is at a cursory glance.
> 
> I am happy to investigate further, if this matter is of some contention to
> people?

This is the first time I'm hearing about "Install Tutorial". I'm also lazy, +1
with sticking to install guide.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes

[Mike Perez]

On 21:21 Sep 21, Matt Riedemann wrote:
> I just wanted to highlight to people that there seems to be a series of
> garbage patches in various projects [1] which are basically doing things
> like fixing a single typo in a code comment, or very narrowly changing http
> to https in links within docs.
> 
> Also +1ing ones own changes.
> 
> I've been trying to snuff these out in nova, but I see it's basically a
> pattern widespread across several projects.
> 
> This is the boilerplate comment I give with my -1, feel free to employ it
> yourself.
> 
> "Sorry but this isn't really a useful change. Fixing typos in code comments
> when the context is still clear doesn't really help us, and mostly seems
> like looking for padding stats on stackalytics. It's also a drain on our CI
> environment.
> 
> If you fixed all of the typos in a single module, or in user-facing
> documentation, or error messages, or something in the logs, or something
> that actually doesn't make sense in code comments, then maybe, but this
> isn't one of those things."
> 
> I'm not trying to be a jerk here, but this is annoying to the point I felt
> the need to say something publicly.
> 
> [1] https://review.openstack.org/#/q/author:%255E.*inspur.*

I agree with the frustration here. It was mentioned earlier in the thread the
top 5 wanted [1] is a good step in the right direction. I think also the
efforts on the contributor portal [2] are going to be a helpful link to send
people when they make mistakes.

I'm sure some of the people who haven't had this communicated to them yet
aren't aware, so we should all be aware as demonstrated in Matt's boilerplate
comment to be nice when communicating.

[1] - http://governance.openstack.org/tc/reference/top-5-help-wanted.html 
[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122534.html

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] Contributor Portal PTG Recap

[Mike Perez]

# Contributor Portal Next Steps

## Landing Page Mock ups
* Current mock up:
https://drive.google.com/file/d/0BxMh9oiou2xMLVRvRWRFVklHa2c/view
* Limited click through mock up:
https://invis.io/CSDEZTBDJ#/252645774_Landing

## Todo
- [ ] thingee: A proposal for the *second level* of what the landing page
shows.
- [ ] thingee: Follow up with the Wes and Jimmy at the OpenStack Foundation
for design assistance.

## Communication To The Community
* [Initial
email](http://lists.openstack.org/pipermail/openstack-dev/2017-June/118877.html)
* [Initial full
thread](http://lists.openstack.org/pipermail/openstack-dev/2017-June/thread.html#118877)

## Highlights from PTG session
[OpenStack Etherpad](https://etherpad.openstack.org/p/contributor-portal)

### TLDR (big changes from discussion)
* Instead of all team on-boarding documentation living in a central
repository, it will still remain with the individual teams to maintain in
their own repository. General documentation (e.g. git, creating accounts,
gerrit setup, etc) will still live in this central repo. If you choose to
contribute by code for example and you pick a project, it will take you
through our general documentation, then the project’s specific documentation.
* This could lead to inconsistencies in documentation design? Confusion
for the reader being sent to different pages?

### General
* We can’t go based off services. Not everything people are contributing
to is a service, so they won't have anything corresponding in the
[service type authority
repo](http://git.openstack.org/cgit/openstack/service-types-authority/tree/service-types.yaml).
There might be a field in projects.yaml that can help with this.
* Remind Thierry on the service type authority repo for
grouping/mapping project.
* Videos were considered, but they’re hard to keep up-to-date.
Previous Documentation PTL Alexandra Settle expressed that even
screenshots can get out of date real fast. 
* Generate some kind of crash-course / cheatsheet content for people
who are used to GitHub but not familiar with Gerrit. Aspiers
volunteered for this and made this first pass [ethercalc
sheet](https://ethercalc.openstack.org/github-gerrit).
* Translation team needs to be included
* Provide documentation with how to edit the landing page, since the
source is being hosted on github (there are transition discussions in
place with the infra team and Jimmy)
* Help projects with creating their own contributor guides if they
need to. Think of something like Cookie cutter for setting up the
scaffolding for a new OpenStack project, but getting projects
contributor guides going.

### Upstream Institute
Attendees of the session we’re more in favor of projects keeping
their specific documentation owned in their repositories. As learned
from the centralize documentation problem
[1](http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html)
[2](https://doughellmann.com/blog/2017/08/24/stop-working-so-hard-scaling-open-source-community-practices/)
[3](https://governance.openstack.org/tc/reference/top-5-help-wanted.html#documentation-owners),
this is a good move. Upstream institute would then use whatever
general documentation is provided. If people get past that, we could
even suggest on-boarding to one of the [top 5 most wanted
help](https://governance.openstack.org/tc/reference/top-5-help-wanted.html)!

### User Committee
Lauren Sell worked with Melvin and others from the user committee to get their
requirements and perspective on the project. Here's an ether pad:
https://etherpad.openstack.org/p/contributor-portal-user-section

### Mock Up Feedback
* Having the service types is great, but on the next level it would
be good to express the code name with a description of what the
project does.
* Combine in events OpenStack day, meetups, forum, ptg, etc.
(emphasize on in person thing)

### Bikeshed
* A word that combines code and documentation ("team(s)" was already
rejected)

-- 
Mike Perez


signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] Contributor Portal PTG Recap

[Mike Perez]

# Contributor Portal Next Steps

## Landing Page Mock ups
* Current mock up:
https://drive.google.com/file/d/0BxMh9oiou2xMLVRvRWRFVklHa2c/view
* Limited click through mock up:
https://invis.io/CSDEZTBDJ#/252645774_Landing

## Todo
- [ ] thingee: A proposal for the *second level* of what the landing page
shows.
- [ ] thingee: Follow up with the Wes and Jimmy at the OpenStack Foundation
for design assistance.

## Communication To The Community
* [Initial
email](http://lists.openstack.org/pipermail/openstack-dev/2017-June/118877.html)
* [Initial full
thread](http://lists.openstack.org/pipermail/openstack-dev/2017-June/thread.html#118877)

## Highlights from PTG session
[OpenStack Etherpad](https://etherpad.openstack.org/p/contributor-portal)

### TLDR (big changes from discussion)
* Instead of all team on-boarding documentation living in a central
repository, it will still remain with the individual teams to maintain in
their own repository. General documentation (e.g. git, creating accounts,
gerrit setup, etc) will still live in this central repo. If you choose to
contribute by code for example and you pick a project, it will take you
through our general documentation, then the project’s specific documentation.
* This could lead to inconsistencies in documentation design? Confusion
for the reader being sent to different pages?

### General
* We can’t go based off services. Not everything people are contributing
to is a service, so they won't have anything corresponding in the
[service type authority
repo](http://git.openstack.org/cgit/openstack/service-types-authority/tree/service-types.yaml).
There might be a field in projects.yaml that can help with this.
* Remind Thierry on the service type authority repo for
grouping/mapping project.
* Videos were considered, but they’re hard to keep up-to-date.
Previous Documentation PTL Alexandra Settle expressed that even
screenshots can get out of date real fast. 
* Generate some kind of crash-course / cheatsheet content for people
who are used to GitHub but not familiar with Gerrit. Aspiers
volunteered for this and made this first pass [ethercalc
sheet](https://ethercalc.openstack.org/github-gerrit).
* Translation team needs to be included
* Provide documentation with how to edit the landing page, since the
source is being hosted on github (there are transition discussions in
place with the infra team and Jimmy)
* Help projects with creating their own contributor guides if they
need to. Think of something like Cookie cutter for setting up the
scaffolding for a new OpenStack project, but getting projects
contributor guides going.

### Upstream Institute
Attendees of the session we’re more in favor of projects keeping
their specific documentation owned in their repositories. As learned
from the centralize documentation problem
[1](http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html)
[2](https://doughellmann.com/blog/2017/08/24/stop-working-so-hard-scaling-open-source-community-practices/)
[3](https://governance.openstack.org/tc/reference/top-5-help-wanted.html#documentation-owners),
this is a good move. Upstream institute would then use whatever
general documentation is provided. If people get past that, we could
even suggest on-boarding to one of the [top 5 most wanted
help](https://governance.openstack.org/tc/reference/top-5-help-wanted.html)!

### User Committee
Lauren Sell worked with Melvin and others from the user committee to get their
requirements and perspective on the project. Here's an ether pad:
https://etherpad.openstack.org/p/contributor-portal-user-section

### Mock Up Feedback
* Having the service types is great, but on the next level it would
be good to express the code name with a description of what the
project does.
* Combine in events OpenStack day, meetups, forum, ptg, etc.
(emphasize on in person thing)

### Bikeshed
* A word that combines code and documentation ("team(s)" was already
rejected)

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][nova][mogan] How to show respect to the original authors?

[Mike Perez]

On 15:56 Sep 20, Flavio Percoco wrote:
> On 20/09/17 12:21 +, Jeremy Stanley wrote:
> > On 2017-09-20 07:51:29 -0400 (-0400), Davanum Srinivas wrote:
> > [...]
> > > please indicate which file from Nova, so if anyone wanted to cross
> > > check for fixes etc can go look in Nova
> > [...]
> > 
> > While the opportunity has probably passed in this case, the ideal
> > method is to start with a Git fork of the original as your seed
> > project (perhaps with history pruned to just the files you're
> > reusing via git filter-branch or similar). This way the complete
> > change history of the files in question is preserved for future
> > inspection.
> 
> If it's not too late, I would definitely recommend going with a fork, fwiw.
> 
> Flavio
> 
> --
> @flaper87
> Flavio Percoco

+1 please fork instead.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptg] Simplification in OpenStack

[Mike Perez]

On 15:53 Sep 12, Boris Pavlovic wrote:
> Mike,
> 
> Great intiative, unfortunately I wasn't able to attend it, however I have
> some thoughts...
> You can't simplify OpenStack just by fixing few issues that are described
> in the etherpad mostly..



Definitely agree that it's not going to be a few issues to fix. I purposely was
leading this effort being broad so we can take the comments of OpenStack being
complex, and have a conversation on what that actually means to people. 

The feedback from people on the etherpad, as well as the in person discussions
have been valuable in getting those different perspectives. Unfortunately
participation was low, but I'm interested in seeing if we can identify some
themes to have some actual doable objectives.

I appreciate you taking the time in writing up your feedback on this Boris.
I will make sure it's included in the more polished summary I'll be giving the
TC and the Board to act on. Thank you!

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptg] Simplification in OpenStack

[Mike Perez]

Hey all,

I would like to encourage people from different teams to add items of
things they learned at the PTG about simplifying their own projects.
Maybe we can see some themes that can contribute to community wide
goals?

https://etherpad.openstack.org/p/simplifying-os

—
Mike Perez

On September 12, 2017 at 15:33:14, Mike Perez (thin...@gmail.com) wrote:
> Hey all,
>
> The session is over. I’m hanging near registration if anyone wants to discuss 
> things.
> Shout out to John for coming by on discussions with simplifying dependencies. 
> I welcome
> more packagers to join the discussion.
>
> https://etherpad.openstack.org/p/simplifying-os
>
> —
> Mike Perez
>
>
> On September 12, 2017 at 11:45:05, Mike Perez (thin...@gmail.com) wrote:
> > Hey all,
> >
> > Back in a joint meeting with the TC, UC, Foundation and The Board it was 
> > decided as an area
> > of OpenStack to focus was Simplifying OpenStack. This intentionally was 
> > very broad
> > so the community can kick start the conversation and help tackle some broad 
> > feedback
> > we get.
> >
> > Unfortunately yesterday there was a low turn out in the Simplification 
> > room. A group
> > of people from the Swift team, Kevin Fox and Swimingly were nice enough to 
> > start the conversation
> > and give some feedback. You can see our initial ether pad work here:
> >
> > https://etherpad.openstack.org/p/simplifying-os
> >
> > There are efforts happening everyday helping with this goal, and our team 
> > has made some
> > documented improvements that can be found in our report to the board within 
> > the ether
> > pad. I would like to take a step back with this opportunity to have in 
> > person discussions
> > for us to identify what are the area of simplifying that are worthwhile. 
> > I’m taking a
> break
> > from the room at the moment for lunch, but I encourage people at 13:30 
> > local time to meet
> > at the simplification room level b in the big thompson room. Thank you!
> >
> > —
> > Mike Perez
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

We now have an ether pad

https://etherpad.openstack.org/p/contributor-portal

—
Mike Perez

On September 13, 2017 at 11:47:16, Mike Perez (thin...@gmail.com) wrote:
> Hey all,
>
> We’ll be meeting with the Documentation team at the ptg in ballroom c today 
> at 14:30 local
> time to discuss progress. Join us and lets help make our on-boarding 
> experience better
> for new contributors!
>
> —
> Mike Perez
>
> On June 23, 2017 at 14:17:07, Mike Perez (thin...@gmail.com) wrote:
> >
> >
> > Hello all,
> >
> > Every month we have people asking on IRC or the dev mailing list having 
> > interest in working
> > on OpenStack, and sometimes they're given different answers from people, or 
> > worse,
> > no answer at all.
> >
> > Suggestion: lets work our efforts together to create some common 
> > documentation so
> that
> > all teams in OpenStack can benefit.
> >
> > First it’s important to note that we’re not just talking about code 
> > projects here. OpenStack
> > contributions come in many forms such as running meet ups, identifying use 
> > cases (product
> > working group), documentation, testing, etc. We want to make sure those 
> > potential
> contributors
> > feel welcomed too!
> >
> > What is common documentation? Things like setting up Git, the many accounts 
> > you need
> > to setup to contribute (gerrit, launchpad, OpenStack foundation account). 
> > Not all
> > teams will use some common documentation, but the point is one or more 
> > projects will
> use
> > them. Having the common documentation worked on by various projects will 
> > better help
> > prevent duplicated efforts, inconsistent documentation, and hopefully just 
> > more
> > accurate information.
> >
> > A team might use special tools to do their work. These can also be 
> > integrated in this idea
> > as well.
> >
> > Once we have common documentation we can have something like:
> > 1. Choose your own adventure: I want to contribute by code
> > 2. What service type are you interested in? (Database, Block storage, 
> > compute)
> > 3. Here’s step-by-step common documentation to setting up Git, IRC, Mailing 
> > Lists,
> > Accounts, etc.
> > 4. A service type project might choose to also include additional 
> > documentation in
> that
> > flow for special tools, etc.
> >
> > Important things to note in this flow:
> > * How do you want to contribute?
> > * Here are **clear** names that identify the team. Not code names like 
> > Cloud Kitty, Cinder,
> > etc.
> > * The documentation should really aim to not be daunting:
> > * Someone should be able to glance at it and feel like they can finish 
> > things in five minutes.
> > Not be yet another tab left in their browser that they’ll eventually forget 
> > about
> > * No wall of text!
> > * Use screen shots
> > * Avoid covering every issue you could hit along the way.
> >
> > ## Examples of More Simple Documentation
> > I worked on some documentation for the Upstream University preparation that 
> > has received
> > excellent feedback meet close to these suggestions:
> > * IRC [1]
> > * Git [2]
> > * Account Setup [3]
> >
> > ## 500 Feet Birds Eye view
> > There will be a Contributor landing page on the openstack.org website. 
> > Existing contributors
> > will find reference links to quickly jump to things. New contributors will 
> > find a banner
> > at the top of the page to direct them to the choose your own adventure to 
> > contributing
> to
> > OpenStack, with ordered documentation flow that reuses existing 
> > documentation when
> > necessary. Picture also a progress bar somewhere to show how close you are 
> > to being ready
> > to contribute to whatever team. Of course there are a lot of other fancy 
> > things we can
> come
> > up with, but I think getting something up as an initial pass would be 
> > better than what
> we
> > have today.
> >
> > Here's an example of what the sections/chapters could look like:
> >
> > - Code
> > * Volumes (Cinder)
> > * IRC
> > * Git
> > * Account Setup
> > * Generating Configs
> > * Compute (Nova)
> > * IRC
> > * Git
> > * Account Setup
> > * Something about hypervisors (matrix?)
> > - Use Cases
> > * Products (Product working group)
> > * IRC
> > * Git
> > * Use Case format
> >
> > There are some rough mock up ideas [4]. Probably Sphinx will be fin

Re: [openstack-dev] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

Hey all,

We’ll be meeting with the Documentation team at the ptg in ballroom c
today at 14:30 local time to discuss progress. Join us and lets help
make our on-boarding experience better for new contributors!

—
Mike Perez

On June 23, 2017 at 14:17:07, Mike Perez (thin...@gmail.com) wrote:
>
>
> Hello all,
>
> Every month we have people asking on IRC or the dev mailing list having 
> interest in working
> on OpenStack, and sometimes they're given different answers from people, or 
> worse,
> no answer at all.
>
> Suggestion: lets work our efforts together to create some common 
> documentation so that
> all teams in OpenStack can benefit.
>
> First it’s important to note that we’re not just talking about code projects 
> here. OpenStack
> contributions come in many forms such as running meet ups, identifying use 
> cases (product
> working group), documentation, testing, etc. We want to make sure those 
> potential contributors
> feel welcomed too!
>
> What is common documentation? Things like setting up Git, the many accounts 
> you need
> to setup to contribute (gerrit, launchpad, OpenStack foundation account). Not 
> all
> teams will use some common documentation, but the point is one or more 
> projects will use
> them. Having the common documentation worked on by various projects will 
> better help
> prevent duplicated efforts, inconsistent documentation, and hopefully just 
> more
> accurate information.
>
> A team might use special tools to do their work. These can also be integrated 
> in this idea
> as well.
>
> Once we have common documentation we can have something like:
> 1. Choose your own adventure: I want to contribute by code
> 2. What service type are you interested in? (Database, Block storage, compute)
> 3. Here’s step-by-step common documentation to setting up Git, IRC, Mailing 
> Lists,
> Accounts, etc.
> 4. A service type project might choose to also include additional 
> documentation in that
> flow for special tools, etc.
>
> Important things to note in this flow:
> * How do you want to contribute?
> * Here are **clear** names that identify the team. Not code names like Cloud 
> Kitty, Cinder,
> etc.
> * The documentation should really aim to not be daunting:
> * Someone should be able to glance at it and feel like they can finish things 
> in five minutes.
> Not be yet another tab left in their browser that they’ll eventually forget 
> about
> * No wall of text!
> * Use screen shots
> * Avoid covering every issue you could hit along the way.
>
> ## Examples of More Simple Documentation
> I worked on some documentation for the Upstream University preparation that 
> has received
> excellent feedback meet close to these suggestions:
> * IRC [1]
> * Git [2]
> * Account Setup [3]
>
> ## 500 Feet Birds Eye view
> There will be a Contributor landing page on the openstack.org website. 
> Existing contributors
> will find reference links to quickly jump to things. New contributors will 
> find a banner
> at the top of the page to direct them to the choose your own adventure to 
> contributing to
> OpenStack, with ordered documentation flow that reuses existing documentation 
> when
> necessary. Picture also a progress bar somewhere to show how close you are to 
> being ready
> to contribute to whatever team. Of course there are a lot of other fancy 
> things we can come
> up with, but I think getting something up as an initial pass would be better 
> than what we
> have today.
>
> Here's an example of what the sections/chapters could look like:
>
> - Code
> * Volumes (Cinder)
> * IRC
> * Git
> * Account Setup
> * Generating Configs
> * Compute (Nova)
> * IRC
> * Git
> * Account Setup
> * Something about hypervisors (matrix?)
> - Use Cases
> * Products (Product working group)
> * IRC
> * Git
> * Use Case format
>
> There are some rough mock up ideas [4]. Probably Sphinx will be fine for 
> this. Potentially
> we could use this content for conference lunch and learns, upstream 
> university, and
> the on-boarding events at the Forum. What do you all think?
>
> [1] - http://docs.openstack.org/upstream-training/irc.html
> [2] - http://docs.openstack.org/upstream-training/git.html
> [3] - http://docs.openstack.org/upstream-training/accounts.html
> [4] - 
> https://www.dropbox.com/s/o46xh1cp0sv0045/OpenStack%20contributor%20portal.pdf?dl=0
>
> —
>
> Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptg] Simplification in OpenStack

[Mike Perez]

Hey all,

The session is over. I’m hanging near registration if anyone wants to
discuss things. Shout out to John for coming by on discussions with
simplifying dependencies. I welcome more packagers to join the
discussion.

https://etherpad.openstack.org/p/simplifying-os

—
Mike Perez


On September 12, 2017 at 11:45:05, Mike Perez (thin...@gmail.com) wrote:
> Hey all,
>
> Back in a joint meeting with the TC, UC, Foundation and The Board it was 
> decided as an area
> of OpenStack to focus was Simplifying OpenStack. This intentionally was very 
> broad
> so the community can kick start the conversation and help tackle some broad 
> feedback
> we get.
>
> Unfortunately yesterday there was a low turn out in the Simplification room. 
> A group
> of people from the Swift team, Kevin Fox and Swimingly were nice enough to 
> start the conversation
> and give some feedback. You can see our initial ether pad work here:
>
> https://etherpad.openstack.org/p/simplifying-os
>
> There are efforts happening everyday helping with this goal, and our team has 
> made some
> documented improvements that can be found in our report to the board within 
> the ether
> pad. I would like to take a step back with this opportunity to have in person 
> discussions
> for us to identify what are the area of simplifying that are worthwhile. I’m 
> taking a break
> from the room at the moment for lunch, but I encourage people at 13:30 local 
> time to meet
> at the simplification room level b in the big thompson room. Thank you!
>
> —
> Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ptg] Simplification in OpenStack

[Mike Perez]

Hey all,

Back in a joint meeting with the TC, UC, Foundation and The Board it
was decided as an area of OpenStack to focus was Simplifying
OpenStack. This intentionally was very broad so the community can kick
start the conversation and help tackle some broad feedback we get.

Unfortunately yesterday there was a low turn out in the Simplification
room. A group of people from the Swift team, Kevin Fox and Swimingly
were nice enough to start the conversation and give some feedback. You
can see our initial ether pad work here:

https://etherpad.openstack.org/p/simplifying-os

There are efforts happening everyday helping with this goal, and our
team has made some documented improvements that can be found in our
report to the board within the ether pad. I would like to take a step
back with this opportunity to have in person discussions for us to
identify what are the area of simplifying that are worthwhile. I’m
taking a break from the room at the moment for lunch, but I encourage
people at 13:30 local time to meet at the simplification room level b
in the big thompson room. Thank you!

—
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] OpenStack Developer Mailing List Digest July 22-28

[Mike Perez]

HTML version: 
https://www.openstack.org/blog/2017/08/openstack-developer-mailing-list-digest-20170728/

Summaries
=
* Nova placement/resource providers update 30 [1]
* TC Report 30 [2]
* POST /api-wg/news [3]
* Release countdown for week R-4, July 28 - Aug 4 [4]
* Technical Committee Status update, July 28 [5]

Project Team Gathering Planning
===
* Nova [6]
* Keystone [7]
* Sahara [8]
* Cinder [9]
* Oslo [10]
* Neutron [11]
* Documentation [12]

Oslo DB Network Database Base namespace throughout OpenStack Projects
=
* Mike Bayer has been working with Octave Oregon on adding the network database
  storage engine for mysql to oslo.db module so other projects can take
  advantage of it. Mike Bayer notes:
  - The code review [13]
  - Support in Nova [14]
  - Support in Neutron [15]
* New data types that map to types from the NDB namespace.
  - oslo_db.sqlalchemy.types.SmallString
  - oslo_db.sqlalchemy.types.String
* Full thread: [16]

1. http://lists.openstack.org/pipermail/openstack-dev/2017-July/120290.html
2. http://lists.openstack.org/pipermail/openstack-dev/2017-July/120112.html
3. http://lists.openstack.org/pipermail/openstack-dev/2017-July/120245.html
4. http://lists.openstack.org/pipermail/openstack-dev/2017-July/120304.html
5. http://lists.openstack.org/pipermail/openstack-dev/2017-July/120280.html
6. http://lists.openstack.org/pipermail/openstack-dev/2017-July/120020.html
7. http://lists.openstack.org/pipermail/openstack-dev/2017-July/119299.html
8. http://lists.openstack.org/pipermail/openstack-dev/2017-July/119352.html
9. http://lists.openstack.org/pipermail/openstack-dev/2017-July/119358.html
10. http://lists.openstack.org/pipermail/openstack-dev/2017-July/119462.html
11. http://lists.openstack.org/pipermail/openstack-dev/2017-July/120270.html
12. http://lists.openstack.org/pipermail/openstack-dev/2017-July/119990.html
13. https://review.openstack.org/#/c/427970/
14. https://review.openstack.org/#/c/446643
15. https://review.openstack.org/#/c/446136/
16. 
http://lists.openstack.org/pipermail/openstack-dev/2017-July/thread.html#120037


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] Proposing TommyLikeHu for Cinder core

[Mike Perez]

On 03:07 Jul 25, Sean McGinnis wrote:
> I am proposing we add TommyLike as a Cinder core.
> 
> DISCLAIMER: We work for the same company.
> 
> I have held back on proposing him for some time because of this conflict. But
> I think from his number of reviews [1] and code contributions [2] it's
> hopefully clear that my motivation does not have anything to do with this.
> 
> TommyLike has consistently done quality code reviews. He has contributed a
> lot of bug fixes and features. And he has been available in the IRC channel
> answering questions and helping out, despite some serious timezone
> challenges.
> 
> I think it would be great to add someone from this region so we can get more
> perspective from the APAC area, as well as having someone around that may
> help as more developers get involved in non-US and non-EU timezones.
> 
> Cinder cores, please respond with your opinion. If no reason is given to do
> otherwise, I will add TommyLike to the core group in one week.
> 
> And absolutely call me out if you see any in bias in my proposal.

+1

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][all] Improving Vendor Driver Discoverability

[Mike Perez]

On 20:29 Jan 13, Mike Perez wrote:
> Hello all,
> 
> In the spirit of recent Technical Committee discussions I would like to bring
> focus on how we're doing vendor driver discoverability. Today we're doing this
> with the OpenStack Foundation marketplace [1] which is powered by the 
> driverlog
> project. In a nutshell, it is a big JSON file [2] that has information on 
> which
> vendor solutions are supported by which projects in which releases. This
> information is then parsed to generate the marketplace so that users can
> discover them. As discussed in previous TC meetings [3] we need to recognize
> vendors that are trying to make great products work in OpenStack so that they
> can be successful, which allows our community to be successful and healthy.
> 
> In the feedback I have received from various people in the community, some
> didn’t know how it worked, and were unhappy that the projects themselves
> weren’t owning this. I totally agree that project teams should own this and
> should be encouraged to be involved in the reviews. Today that’s not 
> happening.
> I’d like to propose we come up with a way for the marketplace to be more
> community-driven by the projects that are validating these solutions.
> 
> At the Barcelona Summit [4] we discussed ways to improve driverlog. Projects
> like Nova have a support matrix of hypervisors in their in-tree documentation.
> Various members of the Cinder project also expressed interest in using this
> solution. It was suggested in the session that the marketplace should just 
> link
> to the projects' appropriate documentation. The problem with this solution is
> the information is not presented in a consistent way across projects, as
> driverlog does it today. We could accomplish this instead by using a parsable
> format that is stored in each appropriate project's git repository. I'm
> thinking of pretty much how driverlog works today, but broken up into
> individual projects.
> 
> The marketplace can parse this information and present it in one place
> consistently. Projects may also continue to parse this information in their 
> own
> documentation, and we can even write a common tool to do this. The way a 
> vendor
> is listed here is based on being validated by the project team itself. Keeping
> things in the marketplace would also address the suggestions that came out of
> the recent feedback we received from various driver maintainers [4].
> 
> The way validation works is completely up to the project team. In my research
> as shown in the Summit etherpad [5] there's a clear trend in projects doing
> continuous integration for validation. If we wanted to we could also have the
> marketplace give the current CI results, which was also requested in the
> feedback from driver maintainers.
> 
> I would like to volunteer in creating the initial files for each project with
> what the marketplace says today.
> 
> [1] - https://www.openstack.org/marketplace/drivers/
> [2] - 
> http://git.openstack.org/cgit/openstack/driverlog/tree/etc/default_data.json
> [3] - 
> http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-01-10-20.01.log.html#l-106
> [4] - 
> http://lists.openstack.org/pipermail/openstack-dev/2017-January/109855.html
> [5] - https://etherpad.openstack.org/p/driverlog-validation

Hey all,

Continuing things, posted for review is the initial project [1][2], add it to
test-requirements [3] and changes for Nova [4] and Neutron [5].

Review love appreciated!

[1] - https://review.openstack.org/472260
[2] - https://review.openstack.org/472488
[3] - https://review.openstack.org/481294
[4] - https://review.openstack.org/481304
[5] - https://review.openstack.org/481307 

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack-operators] [User-committee] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

Hey Melvin,

Ah yes, I should’ve mentioned earlier that this is totally a POC.
There are lots missing, don’t worry! :)

—
Mike Perez

On June 29, 2017 at 13:47:14, Melvin Hillsman (mrhills...@gmail.com) wrote:
> +1
>
> Did not have a chance to draft a message but thanks for ops mention.
>
> On Jun 29, 2017 3:02 PM, "Amy Marrich" wrote:
>
> > First off it looks really sleek and I love the look! A few thoughts though
> > and I do realize it's just a mock up:
> >
> > 1) We have Sponsor just to pick one but don't have
> > Operators/Administrators and their feedback is a major contribution so
> > please don't leave them out.
> > 2) I would list the contributor types in alphabetical order that way no
> > group feels slighted, you can't help it if Use Cases are last it's just
> > that they start with a U vs Code which is a C.
> > 3) What if you would like to contribute in multiple ways?
> >
> > Resources are definitely still underdevelopment there but are they meant
> > to be broad applicable to all resources with more specialized one's visible
> > when you click on how you'd like to contribute?
> >
> > Amy (spotz)
> >
> > On Thu, Jun 29, 2017 at 2:03 PM, Mike Perez wrote:
> >
> >> Hello all,
> >>
> >> Wes has just took my ugly mock up of the contributor portal idea and
> >> came up with this [1].
> >>
> >> Here’s what he said:
> >>
> >> "The idea is to help get potential contributors to the right place,
> >> using the outline Mike put together. Rather than sending people to a
> >> different page for each contribution type, users would be able to see
> >> what options are available all on this page. We’d send them to any
> >> necessary page(s) once they’ve gone through this quasi-wizard. Is this
> >> along the lines of what you were thinking? page 2 shows the view once
> >> you’ve clicked “Code” on page 1 (just in case that wasn’t super
> >> obvious) Thanks!”
> >>
> >> What do you all think? This does change things a bit of instead of the
> >> landing page being more obvious of a resource of links, it’s both for
> >> new and current contributors. Current contributors would hopefully be
> >> able to see the resource links below.
> >>
> >> Keep in mind that we will be working in the “Top 5 requested help” and
> >> as suggested by Clark, an option of “I don’t know where I want to
> >> start, but I want to help” kind of option. This would direct people to
> >> resources such as Upstream University, mentor program, low hanging
> >> fruit, that release priority idea I talked about earlier, etc.
> >>
> >> Personally I like it!
> >>
> >>
> >> [1] - https://www.dropbox.com/s/3q172qwfkik1ysd/contributor-port
> >> al.pdf?dl=0
> >>
> >> —
> >> Mike Perez
> >>
> >> On June 27, 2017 at 13:48:36, Mike Perez (thin...@gmail.com) wrote:
> >> > Hello all,
> >> >
> >> > Every month we have people asking on IRC or the dev mailing list having
> >> interest in working
> >> > on OpenStack, and sometimes they're given different answers from
> >> people, or worse,
> >> > no answer at all.
> >> >
> >> > Suggestion: lets work our efforts together to create some common
> >> documentation so that
> >> > all teams in OpenStack can benefit.
> >> >
> >> > First it’s important to note that we’re not just talking about code
> >> projects here. OpenStack
> >> > contributions come in many forms such as running meet ups, identifying
> >> use cases (product
> >> > working group), documentation, testing, etc. We want to make sure those
> >> potential contributors
> >> > feel welcomed too!
> >> >
> >> > What is common documentation? Things like setting up Git, the many
> >> accounts you need
> >> > to setup to contribute (gerrit, launchpad, OpenStack foundation
> >> account). Not all
> >> > teams will use some common documentation, but the point is one or more
> >> projects will use
> >> > them. Having the common documentation worked on by various projects
> >> will better help
> >> > prevent duplicated efforts, inconsistent documentation, and hopefully
> >> just more
> >> > accurate information.
> >> >
> >> > A team might use special tools to do their work. These can also be
> >> integrated in this idea
&

Re: [Openstack] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

+ OpenStack dev list

On June 29, 2017 at 13:01:09, Amy Marrich (a...@demarco.com) wrote:
> First off it looks really sleek and I love the look! A few thoughts though
> and I do realize it's just a mock up:
>
> 1) We have Sponsor just to pick one but don't have Operators/Administrators
> and their feedback is a major contribution so please don't leave them out.

Ah yes, I should’ve mentioned earlier that this is totally a POC.
There are lots missing, don’t worry! :)

> 2) I would list the contributor types in alphabetical order that way no
> group feels slighted, you can't help it if Use Cases are last it's just
> that they start with a U vs Code which is a C.

Sure!

> 3) What if you would like to contribute in multiple ways?

You would come back to the main contributor portal and click on a
different contribution. How about at the end of each lesson it gives
them the option to go back to main contributor portal to pick another
way to contribute?

>
> Resources are definitely still underdevelopment there but are they meant to
> be broad applicable to all resources with more specialized one's visible
> when you click on how you'd like to contribute?

That’s a good question. I think it should probably on top contain the
more general stuff, then in alphabetical order we can list resources
for all contribution types? It can be like the “I want to contribute
to OpenStack by…” top piece, but instead lists resource links to pick
through based on your contribution type(s). Maybe we keep them as
separate pages as originally given in the mock up so it’s not overly
crowded?

Thanks for the help Amy!

—
Mike Perez

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [User-committee] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

On June 29, 2017 at 13:01:09, Amy Marrich (a...@demarco.com) wrote:
> First off it looks really sleek and I love the look! A few thoughts though
> and I do realize it's just a mock up:
>
> 1) We have Sponsor just to pick one but don't have Operators/Administrators
> and their feedback is a major contribution so please don't leave them out.

Ah yes, I should’ve mentioned earlier that this is totally a POC.
There are lots missing, don’t worry! :)

> 2) I would list the contributor types in alphabetical order that way no
> group feels slighted, you can't help it if Use Cases are last it's just
> that they start with a U vs Code which is a C.

Sure!

> 3) What if you would like to contribute in multiple ways?

You would come back to the main contributor portal and click on a
different contribution. How about at the end of each lesson it gives
them the option to go back to main contributor portal to pick another
way to contribute?

>
> Resources are definitely still underdevelopment there but are they meant to
> be broad applicable to all resources with more specialized one's visible
> when you click on how you'd like to contribute?

That’s a good question. I think it should probably on top contain the
more general stuff, then in alphabetical order we can list resources
for all contribution types? It can be like the “I want to contribute
to OpenStack by…” top piece, but instead lists resource links to pick
through based on your contribution type(s). Maybe we keep them as
separate pages as originally given in the mock up so it’s not overly
crowded?

Thanks for the help Amy!

—
Mike Perez

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack-operators] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

+ OpenStack dev list

On June 29, 2017 at 13:01:09, Amy Marrich (a...@demarco.com) wrote:
> First off it looks really sleek and I love the look! A few thoughts though
> and I do realize it's just a mock up:
>
> 1) We have Sponsor just to pick one but don't have Operators/Administrators
> and their feedback is a major contribution so please don't leave them out.

Ah yes, I should’ve mentioned earlier that this is totally a POC.
There are lots missing, don’t worry! :)

> 2) I would list the contributor types in alphabetical order that way no
> group feels slighted, you can't help it if Use Cases are last it's just
> that they start with a U vs Code which is a C.

Sure!

> 3) What if you would like to contribute in multiple ways?

You would come back to the main contributor portal and click on a
different contribution. How about at the end of each lesson it gives
them the option to go back to main contributor portal to pick another
way to contribute?

>
> Resources are definitely still underdevelopment there but are they meant to
> be broad applicable to all resources with more specialized one's visible
> when you click on how you'd like to contribute?

That’s a good question. I think it should probably on top contain the
more general stuff, then in alphabetical order we can list resources
for all contribution types? It can be like the “I want to contribute
to OpenStack by…” top piece, but instead lists resource links to pick
through based on your contribution type(s). Maybe we keep them as
separate pages as originally given in the mock up so it’s not overly
crowded?

Thanks for the help Amy!

—
Mike Perez

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

+ OpenStack dev list

On June 29, 2017 at 13:01:09, Amy Marrich (a...@demarco.com) wrote:
> First off it looks really sleek and I love the look! A few thoughts though
> and I do realize it's just a mock up:
>
> 1) We have Sponsor just to pick one but don't have Operators/Administrators
> and their feedback is a major contribution so please don't leave them out.

Ah yes, I should’ve mentioned earlier that this is totally a POC.
There are lots missing, don’t worry! :)

> 2) I would list the contributor types in alphabetical order that way no
> group feels slighted, you can't help it if Use Cases are last it's just
> that they start with a U vs Code which is a C.

Sure!

> 3) What if you would like to contribute in multiple ways?

You would come back to the main contributor portal and click on a
different contribution. How about at the end of each lesson it gives
them the option to go back to main contributor portal to pick another
way to contribute?

>
> Resources are definitely still underdevelopment there but are they meant to
> be broad applicable to all resources with more specialized one's visible
> when you click on how you'd like to contribute?

That’s a good question. I think it should probably on top contain the
more general stuff, then in alphabetical order we can list resources
for all contribution types? It can be like the “I want to contribute
to OpenStack by…” top piece, but instead lists resource links to pick
through based on your contribution type(s). Maybe we keep them as
separate pages as originally given in the mock up so it’s not overly
crowded?

Thanks for the help Amy!

—
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack-operators] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

+ OpenStack dev list

Hello all,

Wes has just took my ugly mock up of the contributor portal idea and
came up with this [1].

Here’s what he said:

"The idea is to help get potential contributors to the right place,
using the outline Mike put together. Rather than sending people to a
different page for each contribution type, users would be able to see
what options are available all on this page. We’d send them to any
necessary page(s) once they’ve gone through this quasi-wizard. Is this
along the lines of what you were thinking? page 2 shows the view once
you’ve clicked “Code” on page 1 (just in case that wasn’t super
obvious) Thanks!”

What do you all think? This does change things a bit of instead of the
landing page being more obvious of a resource of links, it’s both for
new and current contributors. Current contributors would hopefully be
able to see the resource links below.

Keep in mind that we will be working in the “Top 5 requested help” and
as suggested by Clark, an option of “I don’t know where I want to
start, but I want to help” kind of option. This would direct people to
resources such as Upstream University, mentor program, low hanging
fruit, that release priority idea I talked about earlier, etc.

Personally I like it!


[1] - https://www.dropbox.com/s/3q172qwfkik1ysd/contributor-portal.pdf?dl=0

—
Mike Perez

> On June 27, 2017 at 13:48:36, Mike Perez (thin...@gmail.com) wrote:
> > Hello all,
> >
> > Every month we have people asking on IRC or the dev mailing list having 
> > interest in working
> > on OpenStack, and sometimes they're given different answers from people, or 
> > worse,
> > no answer at all.
> >
> > Suggestion: lets work our efforts together to create some common 
> > documentation so
> that
> > all teams in OpenStack can benefit.
> >
> > First it’s important to note that we’re not just talking about code 
> > projects here. OpenStack
> > contributions come in many forms such as running meet ups, identifying use 
> > cases (product
> > working group), documentation, testing, etc. We want to make sure those 
> > potential
> contributors
> > feel welcomed too!
> >
> > What is common documentation? Things like setting up Git, the many accounts 
> > you need
> > to setup to contribute (gerrit, launchpad, OpenStack foundation account). 
> > Not all
> > teams will use some common documentation, but the point is one or more 
> > projects will
> use
> > them. Having the common documentation worked on by various projects will 
> > better help
> > prevent duplicated efforts, inconsistent documentation, and hopefully just 
> > more
> > accurate information.
> >
> > A team might use special tools to do their work. These can also be 
> > integrated in this idea
> > as well.
> >
> > Once we have common documentation we can have something like:
> > 1. Choose your own adventure: I want to contribute by code
> > 2. What service type are you interested in? (Database, Block storage, 
> > compute)
> > 3. Here’s step-by-step common documentation to setting up Git, IRC, Mailing 
> > Lists,
> > Accounts, etc.
> > 4. A service type project might choose to also include additional 
> > documentation in
> that
> > flow for special tools, etc.
> >
> > Important things to note in this flow:
> > * How do you want to contribute?
> > * Here are **clear** names that identify the team. Not code names like 
> > Cloud Kitty, Cinder,
> > etc.
> > * The documentation should really aim to not be daunting:
> > * Someone should be able to glance at it and feel like they can finish 
> > things in five minutes.
> > Not be yet another tab left in their browser that they’ll eventually forget 
> > about
> > * No wall of text!
> > * Use screen shots
> > * Avoid covering every issue you could hit along the way.
> >
> > ## Examples of More Simple Documentation
> > I worked on some documentation for the Upstream University preparation that 
> > has received
> > excellent feedback meet close to these suggestions:
> > * IRC [1]
> > * Git [2]
> > * Account Setup [3]
> >
> > ## 500 Feet Birds Eye view
> > There will be a Contributor landing page on the openstack.org website. 
> > Existing contributors
> > will find reference links to quickly jump to things. New contributors will 
> > find a banner
> > at the top of the page to direct them to the choose your own adventure to 
> > contributing
> to
> > OpenStack, with ordered documentation flow that reuses existing 
> > documentation when
> > necessary. Picture also a progress

Re: [openstack-dev] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

+ OpenStack dev list

Hello all,

Wes has just took my ugly mock up of the contributor portal idea and
came up with this [1].

Here’s what he said:

"The idea is to help get potential contributors to the right place,
using the outline Mike put together. Rather than sending people to a
different page for each contribution type, users would be able to see
what options are available all on this page. We’d send them to any
necessary page(s) once they’ve gone through this quasi-wizard. Is this
along the lines of what you were thinking? page 2 shows the view once
you’ve clicked “Code” on page 1 (just in case that wasn’t super
obvious) Thanks!”

What do you all think? This does change things a bit of instead of the
landing page being more obvious of a resource of links, it’s both for
new and current contributors. Current contributors would hopefully be
able to see the resource links below.

Keep in mind that we will be working in the “Top 5 requested help” and
as suggested by Clark, an option of “I don’t know where I want to
start, but I want to help” kind of option. This would direct people to
resources such as Upstream University, mentor program, low hanging
fruit, that release priority idea I talked about earlier, etc.

Personally I like it!


[1] - https://www.dropbox.com/s/3q172qwfkik1ysd/contributor-portal.pdf?dl=0

—
Mike Perez

> On June 27, 2017 at 13:48:36, Mike Perez (thin...@gmail.com) wrote:
> > Hello all,
> >
> > Every month we have people asking on IRC or the dev mailing list having 
> > interest in working
> > on OpenStack, and sometimes they're given different answers from people, or 
> > worse,
> > no answer at all.
> >
> > Suggestion: lets work our efforts together to create some common 
> > documentation so
> that
> > all teams in OpenStack can benefit.
> >
> > First it’s important to note that we’re not just talking about code 
> > projects here. OpenStack
> > contributions come in many forms such as running meet ups, identifying use 
> > cases (product
> > working group), documentation, testing, etc. We want to make sure those 
> > potential
> contributors
> > feel welcomed too!
> >
> > What is common documentation? Things like setting up Git, the many accounts 
> > you need
> > to setup to contribute (gerrit, launchpad, OpenStack foundation account). 
> > Not all
> > teams will use some common documentation, but the point is one or more 
> > projects will
> use
> > them. Having the common documentation worked on by various projects will 
> > better help
> > prevent duplicated efforts, inconsistent documentation, and hopefully just 
> > more
> > accurate information.
> >
> > A team might use special tools to do their work. These can also be 
> > integrated in this idea
> > as well.
> >
> > Once we have common documentation we can have something like:
> > 1. Choose your own adventure: I want to contribute by code
> > 2. What service type are you interested in? (Database, Block storage, 
> > compute)
> > 3. Here’s step-by-step common documentation to setting up Git, IRC, Mailing 
> > Lists,
> > Accounts, etc.
> > 4. A service type project might choose to also include additional 
> > documentation in
> that
> > flow for special tools, etc.
> >
> > Important things to note in this flow:
> > * How do you want to contribute?
> > * Here are **clear** names that identify the team. Not code names like 
> > Cloud Kitty, Cinder,
> > etc.
> > * The documentation should really aim to not be daunting:
> > * Someone should be able to glance at it and feel like they can finish 
> > things in five minutes.
> > Not be yet another tab left in their browser that they’ll eventually forget 
> > about
> > * No wall of text!
> > * Use screen shots
> > * Avoid covering every issue you could hit along the way.
> >
> > ## Examples of More Simple Documentation
> > I worked on some documentation for the Upstream University preparation that 
> > has received
> > excellent feedback meet close to these suggestions:
> > * IRC [1]
> > * Git [2]
> > * Account Setup [3]
> >
> > ## 500 Feet Birds Eye view
> > There will be a Contributor landing page on the openstack.org website. 
> > Existing contributors
> > will find reference links to quickly jump to things. New contributors will 
> > find a banner
> > at the top of the page to direct them to the choose your own adventure to 
> > contributing
> to
> > OpenStack, with ordered documentation flow that reuses existing 
> > documentation when
> > necessary. Picture also a progress

Re: [Openstack-operators] [User-committee] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

On June 29, 2017 at 13:01:09, Amy Marrich (a...@demarco.com) wrote:
> First off it looks really sleek and I love the look! A few thoughts though
> and I do realize it's just a mock up:
>
> 1) We have Sponsor just to pick one but don't have Operators/Administrators
> and their feedback is a major contribution so please don't leave them out.

Ah yes, I should’ve mentioned earlier that this is totally a POC.
There are lots missing, don’t worry! :)

> 2) I would list the contributor types in alphabetical order that way no
> group feels slighted, you can't help it if Use Cases are last it's just
> that they start with a U vs Code which is a C.

Sure!

> 3) What if you would like to contribute in multiple ways?

You would come back to the main contributor portal and click on a
different contribution. How about at the end of each lesson it gives
them the option to go back to main contributor portal to pick another
way to contribute?

>
> Resources are definitely still underdevelopment there but are they meant to
> be broad applicable to all resources with more specialized one's visible
> when you click on how you'd like to contribute?

That’s a good question. I think it should probably on top contain the
more general stuff, then in alphabetical order we can list resources
for all contribution types? It can be like the “I want to contribute
to OpenStack by…” top piece, but instead lists resource links to pick
through based on your contribution type(s). Maybe we keep them as
separate pages as originally given in the mock up so it’s not overly
crowded?

Thanks for the help Amy!

—
Mike Perez

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

+ OpenStack dev list

Hello all,

Wes has just took my ugly mock up of the contributor portal idea and
came up with this [1].

Here’s what he said:

"The idea is to help get potential contributors to the right place,
using the outline Mike put together. Rather than sending people to a
different page for each contribution type, users would be able to see
what options are available all on this page. We’d send them to any
necessary page(s) once they’ve gone through this quasi-wizard. Is this
along the lines of what you were thinking? page 2 shows the view once
you’ve clicked “Code” on page 1 (just in case that wasn’t super
obvious) Thanks!”

What do you all think? This does change things a bit of instead of the
landing page being more obvious of a resource of links, it’s both for
new and current contributors. Current contributors would hopefully be
able to see the resource links below.

Keep in mind that we will be working in the “Top 5 requested help” and
as suggested by Clark, an option of “I don’t know where I want to
start, but I want to help” kind of option. This would direct people to
resources such as Upstream University, mentor program, low hanging
fruit, that release priority idea I talked about earlier, etc.

Personally I like it!


[1] - https://www.dropbox.com/s/3q172qwfkik1ysd/contributor-portal.pdf?dl=0

—
Mike Perez

> On June 27, 2017 at 13:48:36, Mike Perez (thin...@gmail.com) wrote:
> > Hello all,
> >
> > Every month we have people asking on IRC or the dev mailing list having 
> > interest in working
> > on OpenStack, and sometimes they're given different answers from people, or 
> > worse,
> > no answer at all.
> >
> > Suggestion: lets work our efforts together to create some common 
> > documentation so
> that
> > all teams in OpenStack can benefit.
> >
> > First it’s important to note that we’re not just talking about code 
> > projects here. OpenStack
> > contributions come in many forms such as running meet ups, identifying use 
> > cases (product
> > working group), documentation, testing, etc. We want to make sure those 
> > potential
> contributors
> > feel welcomed too!
> >
> > What is common documentation? Things like setting up Git, the many accounts 
> > you need
> > to setup to contribute (gerrit, launchpad, OpenStack foundation account). 
> > Not all
> > teams will use some common documentation, but the point is one or more 
> > projects will
> use
> > them. Having the common documentation worked on by various projects will 
> > better help
> > prevent duplicated efforts, inconsistent documentation, and hopefully just 
> > more
> > accurate information.
> >
> > A team might use special tools to do their work. These can also be 
> > integrated in this idea
> > as well.
> >
> > Once we have common documentation we can have something like:
> > 1. Choose your own adventure: I want to contribute by code
> > 2. What service type are you interested in? (Database, Block storage, 
> > compute)
> > 3. Here’s step-by-step common documentation to setting up Git, IRC, Mailing 
> > Lists,
> > Accounts, etc.
> > 4. A service type project might choose to also include additional 
> > documentation in
> that
> > flow for special tools, etc.
> >
> > Important things to note in this flow:
> > * How do you want to contribute?
> > * Here are **clear** names that identify the team. Not code names like 
> > Cloud Kitty, Cinder,
> > etc.
> > * The documentation should really aim to not be daunting:
> > * Someone should be able to glance at it and feel like they can finish 
> > things in five minutes.
> > Not be yet another tab left in their browser that they’ll eventually forget 
> > about
> > * No wall of text!
> > * Use screen shots
> > * Avoid covering every issue you could hit along the way.
> >
> > ## Examples of More Simple Documentation
> > I worked on some documentation for the Upstream University preparation that 
> > has received
> > excellent feedback meet close to these suggestions:
> > * IRC [1]
> > * Git [2]
> > * Account Setup [3]
> >
> > ## 500 Feet Birds Eye view
> > There will be a Contributor landing page on the openstack.org website. 
> > Existing contributors
> > will find reference links to quickly jump to things. New contributors will 
> > find a banner
> > at the top of the page to direct them to the choose your own adventure to 
> > contributing
> to
> > OpenStack, with ordered documentation flow that reuses existing 
> > documentation when
> > necessary. Picture also a progress

Re: [Openstack] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

Hello all,

Wes has just took my ugly mock up of the contributor portal idea and
came up with this [1].

Here’s what he said:

"The idea is to help get potential contributors to the right place,
using the outline Mike put together. Rather than sending people to a
different page for each contribution type, users would be able to see
what options are available all on this page. We’d send them to any
necessary page(s) once they’ve gone through this quasi-wizard. Is this
along the lines of what you were thinking? page 2 shows the view once
you’ve clicked “Code” on page 1 (just in case that wasn’t super
obvious) Thanks!”

What do you all think? This does change things a bit of instead of the
landing page being more obvious of a resource of links, it’s both for
new and current contributors. Current contributors would hopefully be
able to see the resource links below.

Keep in mind that we will be working in the “Top 5 requested help” and
as suggested by Clark, an option of “I don’t know where I want to
start, but I want to help” kind of option. This would direct people to
resources such as Upstream University, mentor program, low hanging
fruit, that release priority idea I talked about earlier, etc.

Personally I like it!


[1] - https://www.dropbox.com/s/3q172qwfkik1ysd/contributor-portal.pdf?dl=0

—
Mike Perez

On June 27, 2017 at 13:48:36, Mike Perez (thin...@gmail.com) wrote:
> Hello all,
>
> Every month we have people asking on IRC or the dev mailing list having 
> interest in working
> on OpenStack, and sometimes they're given different answers from people, or 
> worse,
> no answer at all.
>
> Suggestion: lets work our efforts together to create some common 
> documentation so that
> all teams in OpenStack can benefit.
>
> First it’s important to note that we’re not just talking about code projects 
> here. OpenStack
> contributions come in many forms such as running meet ups, identifying use 
> cases (product
> working group), documentation, testing, etc. We want to make sure those 
> potential contributors
> feel welcomed too!
>
> What is common documentation? Things like setting up Git, the many accounts 
> you need
> to setup to contribute (gerrit, launchpad, OpenStack foundation account). Not 
> all
> teams will use some common documentation, but the point is one or more 
> projects will use
> them. Having the common documentation worked on by various projects will 
> better help
> prevent duplicated efforts, inconsistent documentation, and hopefully just 
> more
> accurate information.
>
> A team might use special tools to do their work. These can also be integrated 
> in this idea
> as well.
>
> Once we have common documentation we can have something like:
> 1. Choose your own adventure: I want to contribute by code
> 2. What service type are you interested in? (Database, Block storage, compute)
> 3. Here’s step-by-step common documentation to setting up Git, IRC, Mailing 
> Lists,
> Accounts, etc.
> 4. A service type project might choose to also include additional 
> documentation in that
> flow for special tools, etc.
>
> Important things to note in this flow:
> * How do you want to contribute?
> * Here are **clear** names that identify the team. Not code names like Cloud 
> Kitty, Cinder,
> etc.
> * The documentation should really aim to not be daunting:
> * Someone should be able to glance at it and feel like they can finish things 
> in five minutes.
> Not be yet another tab left in their browser that they’ll eventually forget 
> about
> * No wall of text!
> * Use screen shots
> * Avoid covering every issue you could hit along the way.
>
> ## Examples of More Simple Documentation
> I worked on some documentation for the Upstream University preparation that 
> has received
> excellent feedback meet close to these suggestions:
> * IRC [1]
> * Git [2]
> * Account Setup [3]
>
> ## 500 Feet Birds Eye view
> There will be a Contributor landing page on the openstack.org website. 
> Existing contributors
> will find reference links to quickly jump to things. New contributors will 
> find a banner
> at the top of the page to direct them to the choose your own adventure to 
> contributing to
> OpenStack, with ordered documentation flow that reuses existing documentation 
> when
> necessary. Picture also a progress bar somewhere to show how close you are to 
> being ready
> to contribute to whatever team. Of course there are a lot of other fancy 
> things we can come
> up with, but I think getting something up as an initial pass would be better 
> than what we
> have today.
>
> Here's an example of what the sections/chapters could look like:
>
> - Code
> * Volumes (Cinder)
> * IRC
> * Git
> * Account Setup
> * Generating Con

Re: [Openstack-operators] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

Hello all,

Wes has just took my ugly mock up of the contributor portal idea and
came up with this [1].

Here’s what he said:

"The idea is to help get potential contributors to the right place,
using the outline Mike put together. Rather than sending people to a
different page for each contribution type, users would be able to see
what options are available all on this page. We’d send them to any
necessary page(s) once they’ve gone through this quasi-wizard. Is this
along the lines of what you were thinking? page 2 shows the view once
you’ve clicked “Code” on page 1 (just in case that wasn’t super
obvious) Thanks!”

What do you all think? This does change things a bit of instead of the
landing page being more obvious of a resource of links, it’s both for
new and current contributors. Current contributors would hopefully be
able to see the resource links below.

Keep in mind that we will be working in the “Top 5 requested help” and
as suggested by Clark, an option of “I don’t know where I want to
start, but I want to help” kind of option. This would direct people to
resources such as Upstream University, mentor program, low hanging
fruit, that release priority idea I talked about earlier, etc.

Personally I like it!


[1] - https://www.dropbox.com/s/3q172qwfkik1ysd/contributor-portal.pdf?dl=0

—
Mike Perez

On June 27, 2017 at 13:48:36, Mike Perez (thin...@gmail.com) wrote:
> Hello all,
>
> Every month we have people asking on IRC or the dev mailing list having 
> interest in working
> on OpenStack, and sometimes they're given different answers from people, or 
> worse,
> no answer at all.
>
> Suggestion: lets work our efforts together to create some common 
> documentation so that
> all teams in OpenStack can benefit.
>
> First it’s important to note that we’re not just talking about code projects 
> here. OpenStack
> contributions come in many forms such as running meet ups, identifying use 
> cases (product
> working group), documentation, testing, etc. We want to make sure those 
> potential contributors
> feel welcomed too!
>
> What is common documentation? Things like setting up Git, the many accounts 
> you need
> to setup to contribute (gerrit, launchpad, OpenStack foundation account). Not 
> all
> teams will use some common documentation, but the point is one or more 
> projects will use
> them. Having the common documentation worked on by various projects will 
> better help
> prevent duplicated efforts, inconsistent documentation, and hopefully just 
> more
> accurate information.
>
> A team might use special tools to do their work. These can also be integrated 
> in this idea
> as well.
>
> Once we have common documentation we can have something like:
> 1. Choose your own adventure: I want to contribute by code
> 2. What service type are you interested in? (Database, Block storage, compute)
> 3. Here’s step-by-step common documentation to setting up Git, IRC, Mailing 
> Lists,
> Accounts, etc.
> 4. A service type project might choose to also include additional 
> documentation in that
> flow for special tools, etc.
>
> Important things to note in this flow:
> * How do you want to contribute?
> * Here are **clear** names that identify the team. Not code names like Cloud 
> Kitty, Cinder,
> etc.
> * The documentation should really aim to not be daunting:
> * Someone should be able to glance at it and feel like they can finish things 
> in five minutes.
> Not be yet another tab left in their browser that they’ll eventually forget 
> about
> * No wall of text!
> * Use screen shots
> * Avoid covering every issue you could hit along the way.
>
> ## Examples of More Simple Documentation
> I worked on some documentation for the Upstream University preparation that 
> has received
> excellent feedback meet close to these suggestions:
> * IRC [1]
> * Git [2]
> * Account Setup [3]
>
> ## 500 Feet Birds Eye view
> There will be a Contributor landing page on the openstack.org website. 
> Existing contributors
> will find reference links to quickly jump to things. New contributors will 
> find a banner
> at the top of the page to direct them to the choose your own adventure to 
> contributing to
> OpenStack, with ordered documentation flow that reuses existing documentation 
> when
> necessary. Picture also a progress bar somewhere to show how close you are to 
> being ready
> to contribute to whatever team. Of course there are a lot of other fancy 
> things we can come
> up with, but I think getting something up as an initial pass would be better 
> than what we
> have today.
>
> Here's an example of what the sections/chapters could look like:
>
> - Code
> * Volumes (Cinder)
> * IRC
> * Git
> * Account Setup
> * Generating Con

Re: [openstack-dev] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

On 22:18 Jun 27, Jeremy Stanley wrote:
> On 2017-06-27 14:34:46 -0700 (-0700), Mike Perez wrote:
> [...]
> > ## PTG
> > 
> > New contributors should be participating in the sessions for a
> > project and get to know who are the people leading those efforts.
> > People leading efforts want help. Whether it be documentation for
> > the thing, implementation, testing, etc. Working with the people
> > involved is a good way to get to know that feature or change. The
> > people leading the effort are now invested in YOU succeeding
> > because if you don't succeed, they don't either. Once you succeed
> > in the feature or change with someone, you have recognition in
> > people knowing you are responsible for it in some way. This is an
> > awesome feeling and will lead you to either improving it more or
> > going onto other things. While you're only understanding of a
> > project is that thing, you may get curious and move onto other
> > parts of the code. This leads to someone in the future leading
> > efforts for new contributors!
> [...]
> 
> If you mean "junior" contributors who have maybe gotten a small
> change merged or fixed a minor bug (but have at least figured out
> what team they probably want to spend a lot of their time helping
> on) then I agree. To me "new" contributors are the ones who still
> need the basics of how to submit a patch, where to find bug reports,
> or whatever and those are being catered to at the Forum (via
> OpenStack 101, Upstream Institute, project onboarding), not the PTG.

Yes I'm talking about both junior and new contributors in the way you're
defining them. If they're new, they can still participate in discussions and
meet the people leading an effort. Processes with launchpad/gerrit etc is all
just tools that can be learned later. Learning these processes should just be
followed up later with the looking at the new contributor portal with the
project they selected to work with and follow instructions and ask for help on
their IRC channel when needed.  

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

On 00:07 Jun 28, Ildiko Vancsa wrote:


 
> > On 2017. Jun 27., at 23:34, Mike Perez <thin...@gmail.com> wrote:
> > 
> > On 13:52 Jun 23, Michał Jastrzębski wrote:
> >> Great idea!
> >> 
> >> I would also throw another issue new people often have (I had it too).
> >> Namely what to contribute. Lot's of people wants to do something but
> >> not quite know where to start.
> >> So few ideas for start:
> >> * List of triaged bugs
> >> * List of work items of large blueprits
> > 
> > IMO the triaged bugs/low hanging fruit thing seems to be still daunting for 
> > new
> > contributors. There's also not really much gratification or recognition for
> > what you did by the wider community sometimes. This is something I feel that
> > helps in having people come back to contribute.
> 
> From maintenance perspective I would ensure new comers are aware how to find
> those, but don’t give an exact list.
> 
> By having the Project On-boarding sessions, etc. and a bit more focus on
> coaching and mentoring we might be able to get some attention from projects
> regarding maintaining the list of low hanging fruit bugs. Sometimes that tag
> is not really verified and there are also cases when it does not get marked
> as fixed or obsolete. From earlier experience they are not always
> encouraging...
> 
> > This is going on a tangent of something else I have coming in the future but
> > I think there are a few ways a new contributor would come in:
> > 
> > ## PTG
> > 
> > New contributors should be participating in the sessions for a project and
> > get to know who are the people leading those efforts. People leading efforts
> > want help. Whether it be documentation for the thing, implementation, 
> > testing,
> > etc. Working with the people involved is a good way to get to know that 
> > feature
> > or change. The people leading the effort are now invested in YOU succeeding
> > because if you don't succeed, they don't either. Once you succeed in the
> > feature or change with someone, you have recognition in people knowing you 
> > are
> > responsible for it in some way. This is an awesome feeling and will lead 
> > you to
> > either improving it more or going onto other things. While you're only
> > understanding of a project is that thing, you may get curious and move onto
> > other parts of the code. This leads to someone in the future leading efforts
> > for new contributors!
> 
> I think for this we need to encourage people to attend the Summit first and
> come to an On-boarding session if their target project has one. From my
> experience when I attended my first Design Summit I had no clue what’s going
> on and that can be very discouraging and I saw people for whom it was. And in
> my opinion we also cannot expect the project teams to baby sit new people on
> the PTG.
> 
> With that said, I agree we should have new people on this event, but I think
> we need to be more careful with describing and clarifying prerequisites and
> expectations, like basic knowledge of the area and experience or just to do
> their research before they come and they should know this event is not
> focusing on them.
> 
> The portal should be a great place to describe all this and give a list of
> best practices!

I agree. I just know people are going to come regardless of no matter how many
warning signs you throw in front of them. A quick intro into each session that
this going to move fast/has been discussed and not exactly new contributor
friendly but if you are interested in the effort being discussed find . This is just an answer for those people that
miss all those warnings.

> > ## Forum
> > 
> > I would like to see our on-boarding rooms having time to introduce
> > current/future efforts happening in the project. Introduce the people behind
> > those efforts. Give a little time to break out into meet and greet to 
> > remember
> > friendly faces and do as mentioned above.
> 
> +1
> 
> > 
> > ## Internet
> > 
> > People may not be able to attend our events, but want to participate. Using
> > your idea of listing work items of large blueprints is an excellent! It 
> > would
> > be good if we could list those cleanly and who is leading it. Maybe 
> > Storyboard
> > will be able to help with this in the future Kendall?
> 
> Do we/can we have a tag for large blueprints? So we could teach people how to
> find this and give them a search link, etc.?

Either storyboard allows us to filter on the stuff the project teams have set
for a release, or we just use its API and build our own clean listing.


-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

On 13:52 Jun 23, Michał Jastrzębski wrote:
> Great idea!
> 
> I would also throw another issue new people often have (I had it too).
> Namely what to contribute. Lot's of people wants to do something but
> not quite know where to start.
> So few ideas for start:
> * List of triaged bugs
> * List of work items of large blueprits

IMO the triaged bugs/low hanging fruit thing seems to be still daunting for new
contributors. There's also not really much gratification or recognition for
what you did by the wider community sometimes. This is something I feel that
helps in having people come back to contribute.

This is going on a tangent of something else I have coming in the future but
I think there are a few ways a new contributor would come in:

## PTG

New contributors should be participating in the sessions for a project and
get to know who are the people leading those efforts. People leading efforts
want help. Whether it be documentation for the thing, implementation, testing,
etc. Working with the people involved is a good way to get to know that feature
or change. The people leading the effort are now invested in YOU succeeding
because if you don't succeed, they don't either. Once you succeed in the
feature or change with someone, you have recognition in people knowing you are
responsible for it in some way. This is an awesome feeling and will lead you to
either improving it more or going onto other things. While you're only
understanding of a project is that thing, you may get curious and move onto
other parts of the code. This leads to someone in the future leading efforts
for new contributors!

## Forum

I would like to see our on-boarding rooms having time to introduce
current/future efforts happening in the project. Introduce the people behind
those efforts. Give a little time to break out into meet and greet to remember
friendly faces and do as mentioned above.

## Internet

People may not be able to attend our events, but want to participate. Using
your idea of listing work items of large blueprints is an excellent! It would
be good if we could list those cleanly and who is leading it. Maybe Storyboard
will be able to help with this in the future Kendall?

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

On 09:45 Jun 26, Alexandra Settle wrote:
> I think this is a good idea :) thanks Mike. We get a lot of people coming to
> the docs chan or ML asking for help/where to start and sometimes it’s
> difficult to point them in the right direction.
> 
> Just from experience working with contributor documentation, I’d avoid all
> screen shots if you can – updating them whenever the process changes
> (surprisingly often) is a lot of unnecessary technical debt.

I understand and agree. This was a big selling point to contributors I've spoke
to about this though in avoid walls of text so it's actually something seeming
doable. Perhaps having a small number of steps to a page can still give the
reader a feeling they can finish it in five minutes or less?

> The docs team put a significant amount of effort in a few releases back
> writing a pretty comprehensive Contributor Guide. For the purposes you
> describe below, I imagine a lot of the content here could be adapted. The
> process of setting up for code and docs is exactly the same:
> http://docs.openstack.org/contributor-guide/index.html

Yes I've seen this content and do plan to adapt stuff over!

> 
> I also wonder if we could include a ‘what is openstack’ 101 for new
> contributors. I find that there is a *lot* of material out there, but it is
> often very hard to explain to people what each project does, how they all
> interact, why we install from different sources, why do we have official and
> unofficial projects etc. It doesn’t have to be seriously in-depth, but an
> overview that points people who are interested in the right directions. Often
> this will help people decide on what project they’d like to undertake.

Wonderful idea. I cc'd Anne from the Openstack Foundation who is helping with
this effort. We will be discussing soon on incorporating 101 content over.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

Hello all,

Every month we have people asking on IRC or the dev mailing list
having interest in working on OpenStack, and sometimes they're given
different answers from people, or worse, no answer at all.

Suggestion: lets work our efforts together to create some common
documentation so that all teams in OpenStack can benefit.

First it’s important to note that we’re not just talking about code
projects here. OpenStack contributions come in many forms such as
running meet ups, identifying use cases (product working group),
documentation, testing, etc. We want to make sure those potential
contributors feel welcomed too!

What is common documentation? Things like setting up Git, the many
accounts you need to setup to contribute (gerrit, launchpad, OpenStack
foundation account). Not all teams will use some common documentation,
but the point is one or more projects will use them. Having the common
documentation worked on by various projects will better help prevent
duplicated efforts, inconsistent documentation, and hopefully just
more accurate information.

A team might use special tools to do their work. These can also be
integrated in this idea as well.

Once we have common documentation we can have something like:
    1. Choose your own adventure: I want to contribute by code
    2. What service type are you interested in? (Database, Block
storage, compute)
    3. Here’s step-by-step common documentation to setting up Git,
IRC, Mailing Lists, Accounts, etc.
    4. A service type project might choose to also include additional
documentation in that flow for special tools, etc.

Important things to note in this flow:
    * How do you want to contribute?
    * Here are **clear** names that identify the team. Not code names
like Cloud Kitty, Cinder, etc.
    * The documentation should really aim to not be daunting:
    * Someone should be able to glance at it and feel like they can
finish things in five minutes. Not be yet another tab left in their
browser that they’ll eventually forget about
    * No wall of text!
    * Use screen shots
    * Avoid covering every issue you could hit along the way.

## Examples of More Simple Documentation
I worked on some documentation for the Upstream University preparation
that has received excellent feedback meet close to these suggestions:
    * IRC [1]
    * Git [2]
    * Account Setup [3]

## 500 Feet Birds Eye view
There will be a Contributor landing page on the openstack.org website.
Existing contributors will find reference links to quickly jump to
things. New contributors will find a banner at the top of the page to
direct them to the choose your own adventure to contributing to
OpenStack, with ordered documentation flow that reuses existing
documentation when necessary. Picture also a progress bar somewhere to
show how close you are to being ready to contribute to whatever team.
Of course there are a lot of other fancy things we can come up with,
but I think getting something up as an initial pass would be better
than what we have today.

Here's an example of what the sections/chapters could look like:

- Code
        * Volumes (Cinder)
             * IRC
             * Git
             * Account Setup
             * Generating Configs
        * Compute (Nova)
             * IRC
             * Git
             * Account Setup
        * Something about hypervisors (matrix?)
-  Use Cases
* Products (Product working group)
* IRC
    * Git
* Use Case format

There are some rough mock up ideas [4]. Probably Sphinx will be fine
for this. Potentially we could use this content for conference lunch
and learns, upstream university, and the on-boarding events at the
Forum. What do you all think?

[1] - http://docs.openstack.org/upstream-training/irc.html
[2] - http://docs.openstack.org/upstream-training/git.html
[3] - http://docs.openstack.org/upstream-training/accounts.html
[4] - 
https://www.dropbox.com/s/o46xh1cp0sv0045/OpenStack%20contributor%20portal.pdf?dl=0

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack-operators] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

Hello all,

Every month we have people asking on IRC or the dev mailing list
having interest in working on OpenStack, and sometimes they're given
different answers from people, or worse, no answer at all.

Suggestion: lets work our efforts together to create some common
documentation so that all teams in OpenStack can benefit.

First it’s important to note that we’re not just talking about code
projects here. OpenStack contributions come in many forms such as
running meet ups, identifying use cases (product working group),
documentation, testing, etc. We want to make sure those potential
contributors feel welcomed too!

What is common documentation? Things like setting up Git, the many
accounts you need to setup to contribute (gerrit, launchpad, OpenStack
foundation account). Not all teams will use some common documentation,
but the point is one or more projects will use them. Having the common
documentation worked on by various projects will better help prevent
duplicated efforts, inconsistent documentation, and hopefully just
more accurate information.

A team might use special tools to do their work. These can also be
integrated in this idea as well.

Once we have common documentation we can have something like:
    1. Choose your own adventure: I want to contribute by code
    2. What service type are you interested in? (Database, Block
storage, compute)
    3. Here’s step-by-step common documentation to setting up Git,
IRC, Mailing Lists, Accounts, etc.
    4. A service type project might choose to also include additional
documentation in that flow for special tools, etc.

Important things to note in this flow:
    * How do you want to contribute?
    * Here are **clear** names that identify the team. Not code names
like Cloud Kitty, Cinder, etc.
    * The documentation should really aim to not be daunting:
    * Someone should be able to glance at it and feel like they can
finish things in five minutes. Not be yet another tab left in their
browser that they’ll eventually forget about
    * No wall of text!
    * Use screen shots
    * Avoid covering every issue you could hit along the way.

## Examples of More Simple Documentation
I worked on some documentation for the Upstream University preparation
that has received excellent feedback meet close to these suggestions:
    * IRC [1]
    * Git [2]
    * Account Setup [3]

## 500 Feet Birds Eye view
There will be a Contributor landing page on the openstack.org website.
Existing contributors will find reference links to quickly jump to
things. New contributors will find a banner at the top of the page to
direct them to the choose your own adventure to contributing to
OpenStack, with ordered documentation flow that reuses existing
documentation when necessary. Picture also a progress bar somewhere to
show how close you are to being ready to contribute to whatever team.
Of course there are a lot of other fancy things we can come up with,
but I think getting something up as an initial pass would be better
than what we have today.

Here's an example of what the sections/chapters could look like:

- Code
        * Volumes (Cinder)
             * IRC
             * Git
             * Account Setup
             * Generating Configs
        * Compute (Nova)
             * IRC
             * Git
             * Account Setup
        * Something about hypervisors (matrix?)
-  Use Cases
* Products (Product working group)
* IRC
    * Git
* Use Case format

There are some rough mock up ideas [4]. Probably Sphinx will be fine
for this. Potentially we could use this content for conference lunch
and learns, upstream university, and the on-boarding events at the
Forum. What do you all think?

[1] - http://docs.openstack.org/upstream-training/irc.html
[2] - http://docs.openstack.org/upstream-training/git.html
[3] - http://docs.openstack.org/upstream-training/accounts.html
[4] - 
https://www.dropbox.com/s/o46xh1cp0sv0045/OpenStack%20contributor%20portal.pdf?dl=0

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [docs][all][ptl] Contributor Portal and Better New Contributor On-boarding

[Mike Perez]

Hello all,

Every month we have people asking on IRC or the dev mailing list having
interest in working on OpenStack, and sometimes they're given different
answers from people, or worse, no answer at all.

Suggestion: lets work our efforts together to create some common
documentation so that all teams in OpenStack can benefit.

First it’s important to note that we’re not just talking about code
projects here. OpenStack contributions come in many forms such as running
meet ups, identifying use cases (product working group), documentation,
testing, etc. We want to make sure those potential contributors feel
welcomed too!

What is common documentation? Things like setting up Git, the many accounts
you need to setup to contribute (gerrit, launchpad, OpenStack foundation
account). Not all teams will use some common documentation, but the point
is one or more projects will use them. Having the common documentation
worked on by various projects will better help prevent duplicated efforts,
inconsistent documentation, and hopefully just more accurate information.

A team might use special tools to do their work. These can also be
integrated in this idea as well.

Once we have common documentation we can have something like:
1. Choose your own adventure: I want to contribute by code
2. What service type are you interested in? (Database, Block storage,
compute)
3. Here’s step-by-step common documentation to setting up Git, IRC,
Mailing Lists, Accounts, etc.
4. A service type project might choose to also include additional
documentation in that flow for special tools, etc.

Important things to note in this flow:
* How do you want to contribute?
* Here are **clear** names that identify the team. Not code names like
Cloud Kitty, Cinder, etc.
* The documentation should really aim to not be daunting:
* Someone should be able to glance at it and feel like they can finish
things in five minutes. Not be yet another tab left in their browser that
they’ll eventually forget about
* No wall of text!
* Use screen shots
* Avoid covering every issue you could hit along the way.

## Examples of More Simple Documentation
I worked on some documentation for the Upstream University preparation that
has received excellent feedback meet close to these suggestions:
* IRC [1]
* Git [2]
* Account Setup [3]

## 500 Feet Birds Eye view
There will be a Contributor landing page on the openstack.org website.
Existing contributors will find reference links to quickly jump to things.
New contributors will find a banner at the top of the page to direct them
to the choose your own adventure to contributing to OpenStack, with ordered
documentation flow that reuses existing documentation when necessary.
Picture also a progress bar somewhere to show how close you are to being
ready to contribute to whatever team. Of course there are a lot of other
fancy things we can come up with, but I think getting something up as an
initial pass would be better than what we have today.

Here's an example of what the sections/chapters could look like:

- Code
* Volumes (Cinder)
 * IRC
 * Git
 * Account Setup
 * Generating Configs
* Compute (Nova)
 * IRC
 * Git
 * Account Setup
* Something about hypervisors (matrix?)
-  Use Cases
* Products (Product working group)
* IRC
* Git
* Use Case format

There are some rough mock up ideas [4]. Probably Sphinx will be fine for
this. Potentially we could use this content for conference lunch and
learns, upstream university, and the on-boarding events at the Forum. What
do you all think?

[1] - http://docs.openstack.org/upstream-training/irc.html
[2] - http://docs.openstack.org/upstream-training/git.html
[3] - http://docs.openstack.org/upstream-training/accounts.html
[4] -
https://www.dropbox.com/s/o46xh1cp0sv0045/OpenStack%20contributor%20portal.pdf?dl=0

—

Mike Perez
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tc][all][ptl] Most Supported Queens Goals and Improving Goal Completion

[Mike Perez]

Hey all,

In the community wide goals, we started as a group discussing goals at the
OpenStack Forum. Then we brought those ideas to the mailing list to
continue the discussion and include those that were not able to be at the
forum. The discussions help the TC decide on what goals we will do for the
Queens release. The goals that have the most support so far are:

1) Split Tempest plugins into separate repos/projects [1]
2) Move policy and policy docs into code [2]

In the recent TC meeting [3] it was recognized that goals in Pike haven't
been going as smoothly and not being completed. There will be a follow up
thread to cover gathering feedback in an etherpad later, but for now the TC
has discussed potential actions to improve completing goals in Queens.

An idea that came from the meeting was creating a role of "Champions", who
are the drum beaters to get a goal done by helping projects with tracking
status and sometimes doing code patches. These would be interested
volunteers who have a good understanding of their selected goal and its
implementation to be a trusted person.

What do people think before we bikeshed on the name? Would having a
champion volunteer to each goal to help? Are there ideas that weren't
mentioned in the TC meeting [3]?

[1] -
https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html
[2] -
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg106392.html
[3] -
http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-06-20-20.01.log.html#l-10

—
Mike Perez
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] Status update, Jun 16

[Mike Perez]

On 11:17 Jun 16, Thierry Carrez wrote:
 


> == Need for a TC meeting next Tuesday ==
> 
> In order to make progress on the Pike goal selection, I think a
> dedicated IRC meeting will be necessary. We have a set of valid goals
> proposed already: we need to decide how many we should have, and which
> ones. Gerrit is not great to have that ranking discussion, so I think we
> should meet to come up with a set, and propose it on the mailing-list
> for discussion. We could use the regular meeting slot on Tuesday,
> 20:00utc. How does that sound ?

I will be there since I started facilitating this back at the forum.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc][glance] Glance needs help, it's getting critical

[Mike Perez]

On 16:01 Jun 12, Flavio Percoco wrote:
> On 12/06/17 23:20 +0300, Mikhail Fedosin wrote:
> > My opinion is that Glance stagnates and it's really hard to implement new
> > features there. In two years, only one major improvement was developed
> > (Image Import Refactoring), and no one has tested it in production yet. And
> > this is in the heyday of the community, as you said!
> 
> You're skipping 2 important things here:
> 
> The first one is that focusing on the image import refactor (IIR) was a
> community choice. It's fixing a bigger problem that requires more focus. The
> design of the feature took a couple of cycles too, not the implementation. The
> second thing is that the slow pace may also be caused by the lack of
> contributors.

+1 image import refactor work. That's great that the image import refactor work
is done! 

Mikhail,

I'm pretty thorough on reading this list for the dev digest, so even I missed
that news. Which release was that done in? Are people not using it in
production right away because of having to upgrade to a new release?

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic][nova] Goodbye^W See you later

[Mike Perez]

On 08:45 Jun 08, Jim Rollenhagen wrote:
> Hey friends,
> 
> I've been mostly missing for the past six weeks while looking for a new
> job, so maybe you've forgotten me already, maybe not. I'm happy to tell you
> I've found one that I think is a great opportunity for me. But, I'm sad to
> tell you that it's totally outside of the OpenStack community.
> 
> The last 3.5 years have been amazing. I'm extremely grateful that I've been
> able to work in this community - I've learned so much and met so many
> awesome people. I'm going to miss the insane(ly awesome) level of
> collaboration, the summits, the PTGs, and even some of the bikeshedding.
> We've built amazing things together, and I'm sure y'all will continue to do
> so without me.
> 
> I'll still be lurking in #openstack-dev and #openstack-ironic for a while,
> if people need me to drop a -2 or dictate old knowledge or whatever, feel
> free to ping me. Or if you just want to chat. :)

Really appreciated your time as PTL, and congrats on the future.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo.db] Stepping down from core

[Mike Perez]

On 17:32 Jun 11, Roman Podoliaka wrote:
> Hi all,
> 
> I recently changed job and hasn't been able to devote as much time to
> oslo.db as it is expected from a core reviewer. I'm no longer working
> on OpenStack, so you won't see me around much.
> 
> Anyway, it's been an amazing experience to work with all of you! Best
> of luck! And see ya at various PyCon's around the world! ;)

Thanks for all your contributions, and congrats with the new job.

-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [forum] Future of Stackalytics

[Mike Perez]

On June 8, 2017 at 07:20:23, Jeremy Stanley (fu...@yuggoth.org) wrote:
> > On 2017-06-07 16:36:45 
> > -0700(http://airmail.calendar/2017-06-07%2016:36:45%20PDT)
> (-0700), Ken'ichi Ohmichi wrote:
> [...]
> > one of config files is 30KL due to much user information and that
> > makes the maintenance hard now. I am trying to separate user
> part
> > from the existing file but I cannot find the way to make a
> > consensus for such thing.
>
> There is a foundation member directory API now which provides
> affiliation details and history, so if it were my project (it's
> not
> though) I'd switch to querying that and delete all the static
> affiliation mapping out of that config instead. Not only would
> it
> significantly reduce the reviewer load for Stackalytics, but
> it
> would also provide a greater incentive for contributors to keep
> their affiliation data updated in the foundation member directory.

+1. This would really help me when generating the stats for our yearly
reports/keynote/etc stats instead of having to query multiple sources
and figure out which one is more current.

—
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] OpenStack Developer Mailing List Digest April 29 - May 5

[Mike Perez]

nstack-dev/2017-May/116401.html
[8] - https://www.openstack.org/assets/survey/April2017SurveyReport.pdf
[9] - 
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18694/infraqarelease-mgmtregsstable-project-onboarding
[10] - 
https://www.openstack.org/videos/video/openstack-stable-what-it-actually-means-to-maintain-stable-branches
[11] - https://etherpad.openstack.org/p/stable-branch-eol-policy-newton
[12] - 
https://docs.google.com/presentation/d/1k0mCHwRZ3_Z8zJw_WilsuTYYqnUDlY2PkgVJLz_xVQc/edit?usp=sharing
[13] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-May/thread.html#116298


-- 
Mike Perez


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev