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

[Alexandra Settle]

 
> 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.

Just to clarify: https://docs.openstack.org/install-guide/ The link is 
“install-guide” but the actual title on the page is “OpenStack Installation 
Tutorial”.

Apologies if I haven’t been clear enough in this thread! Context always helps :P

__
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

[Alexandra Settle]

> 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?

__
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] [doc][meeting] Doc team meeting cancelled today

[Alexandra Settle]

Hi everyone,

The documentation team meeting is cancelled today as I am unable to host this 
afternoon due to a conflict,
and Petr is travelling home from the PTG.

The next documentation team meeting will be scheduled in #openstack-meeting at 
16:00 UTC, 5 October 2017.

Petr has asked me to mention that he is most likely unable to attend the 
OpenStack Summit in Sydney.
This means we are looking for volunteers to help present our project update. Is 
anyone able to help?

Cheers,

Alex
__
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] [docs][ptls][install] Install guide vs. tutorial

[Alexandra Settle]

Hi everyone,

I hope everyone had a safe trip home after the PTG!

Since the doc-migration, quite a number or individuals have had questions 
regarding the usage of “Install Tutorial” vs. “Install Guide” in our 
documentation in the openstack-manuals repo and in the project-specific repos. 
We (the doc team) agree there should be consistency across all repos and would 
like to bring this to the table to discuss.

Previously, we have used the phrase ‘tutorial’ as the literal translation of a 
tutorial is that of a ‘paper, book, film, or computer program that provides 
practical information about a specific subject.’

Thoughts?

Alex
__
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][neutron] checking link integrity in the gate

[Alexandra Settle]

On 9/6/17, 12:10 PM, "Doug Hellmann"  wrote:

Excerpts from Doug Hellmann's message of 2017-09-05 13:53:40 -0400:
> Excerpts from Boden Russell's message of 2017-09-05 11:25:34 -0600:
> > 
> > On 9/5/17 11:03 AM, Doug Hellmann wrote:
> > > Is eventlet being initialized (or partially initialized) when a module
> > > from the application is imported for the auto-generated API
> > > documentation?
> > More than likely :)
> > But even if they are, what's the fix/workaround?
> > 
> 
> Ensure that it is fully initialized, or not initialized at all, I would
> think. I'm sure Sphinx does not expect to be running under eventlet.
> 
> I see a comment in neutron's doc/source/conf.py about another issue with
> eventlet and some of the test code. I would start by configuring pbr to
> ignore the test code when generating class documentation and see if that
> eliminates both problems. See "autodoc_tree_excludes" in
> https://docs.openstack.org/pbr/latest/user/using.html#pbr for details.
> 
> If that doesn't help, then I would try to find a way to avoid
> initializing eventlet at all. For example, set an environment variable
> in doc/source/conf.py and then look for it in
> neutron/common/eventlet_utils.py and skip the call to
> eventlet.monkey_patch().
> 
> If neither of those options work, we can continue thinking of other
> ideas.
> 
> Doug
> 

Something to watch out for when using link check in CI: It's a path for
someone outside of your team to break your gate, just by renaming a web
page. It might be more useful to schedule regular manual runs and
updates.

The docs team may have suggestions for how they handle that on the main
docs.o.o site and the guides they manage.

Previously we have run a spider over our repo. Specifically, I know Andreas has 
successfully used https://github.com/alecxe/broken-links-checker.git 

Hopefully this helps. I was thinking we needed to do the same thing over the 
manuals repo now we have finalized most of the migration.


__
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] Updating the docs team mission statement

[Alexandra Settle]

I have updated the mission statement as per Thierry’s suggestion (thank you, I 
liked that a lot!)

See the review here: https://review.openstack.org/#/c/499556/ 

It is currently in WIP. Petr and I agree that the best place to discuss this 
will be at the PTG.

On 8/22/17, 5:34 PM, "Doug Hellmann"  wrote:

Excerpts from Jay S Bryant's message of 2017-08-22 11:06:37 -0500:
> 
> On 8/22/2017 7:30 AM, Doug Hellmann wrote:
> > Excerpts from Doug Hellmann's message of 2017-08-08 08:11:25 -0400:
> >> Excerpts from Thierry Carrez's message of 2017-08-08 12:28:58 +0200:
> >>> Petr Kovar wrote:
>  Hi all,
> 
>  With the core docs suite moving from openstack-manuals to individual
>  project repos as per
>  
http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html,
>  it's also time to update the docs team mission statement from
>  
https://governance.openstack.org/tc/reference/projects/documentation.html.
> 
>  What are everybody's thoughts on what should the new mission 
statement
>  say now that most OpenStack docs maintenance is in the hands of 
project
>  teams?
> 
>  One idea is for the docs team to act as a focused group of editors 
and
>  maintain a common set of guidelines, recommended practices (style
>  guidelines come to mind, for instance), and requirements (such as a 
common
>  docs and publishing structure shared across projects).
> >>> I would say something like:
> >>>
> >>> The docs team provides guidance, assistance, tooling, and style guides
> >>> enabling OpenStack project teams to produce consistent, accurate, and
> >>> high-quality documentation.
> >>>
> >> Thanks for starting this thread, Petr.
> >>
> >> To make it easier to compare, here's the current mission statement:
> >>
> >>Provide documentation for core OpenStack projects to promote
> >>OpenStack.  Develop and maintain tools and processes to ensure
> >>quality, accurate documentation. Treat documentation like OpenStack
> >>code.
> >>
> >> Thierry's suggestion highlights some of the changes I see coming
> >> for the docs team. I would like to hear from some of the other team
> >> members about what they think about that.
> >>
> >> Doug
> > This thread died out, but I think it's important that we make some
> > progress on the discussion before the PTG because the outcome is
> > going to influence the work we do there.
> >
> > One way we could approach it is to make a list of all of the things
> > that the team is currently doing (or has been doing, up to Pike)
> > and then review that list to consider which of those things, if the
> > team was not already doing them, you would be willing to start doing
> > today.  That should establish a pattern for the types of tasks and
> > initiatives the team thinks it can manage, and help us focus the
> > mission statement.
> >
> > So, what does the docs team "do" or "make" today?
> >
> > Doug
> >
> > 
__
> > 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
> Doug,
> 
> I think this is a good idea.  Rather than writing a mission statement 
> and try to get what we do to fit it, we should look at what everyone is 
> doing and can do and then work to craft the statement from that.
> 
> One important part in the process, however, would be to look at how that 
> compares to what was previously being done and make sure that there 
> aren't gaps.  It is an opportunity to make sure we don't let anything 
> slip through the cracks.
> 
> Jay
> 

It's also an opportunity to identify things that should be dropped, or
moved to another team. But yes, let's start by understanding what's
actually happening today.

Doug

__
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 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] [docs] [ptls] Install guide testing

[Alexandra Settle]

Hi everyone,

The documentation team is searching for volunteers to help test and verify the 
OpenStack installation instructions here: 
https://docs.openstack.org/install-guide/

Previously this action has been undertaken by a series of volunteers, mostly 
from the documentation team. However due to the migration, and a significant 
drop in contributors, we are now seeking new individuals to help us complete 
this task.

We will be tracking any work here: 
https://wiki.openstack.org/wiki/Documentation/PikeDocTesting You can see what 
we have previously done for testing here: 
https://wiki.openstack.org/wiki/Documentation/OcataDocTesting

PTLs of cinder/keystone/horizon/neutron/nova/glance – Previously the 
documentation team performed the testing tasks for your respective projects as 
they lived within the openstack-manuals repo. We appreciate that you may or may 
not have the resources to continue this effort, but it would be great if your 
teams are able. Please let me know if you are able to so we can verify the 
instructions of these projects :)

Thanks,

Alex
__
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][docs] I see, you see, we all see red*

[Alexandra Settle]

Hey Ruby!

Good point – thanks for bringing it up :)

I was brought up to think that red was one of those colours that people had 
different (and sometimes really negative) associations with. When I look at our 
latest and greatest! ironic documentation (e.g. [1]), I see red. Not only do I 
see red, but the term has a different background colour and is bordered (or 
whatever it is called). Are we using the wrong .rst syntax, should we be 
highlighting terms differently? And/or is there some way to change the 
appearance of highlighted terms? I much prefer something simple, like bold 
black text in some uniform font. On the other hand, perhaps lots of others like 
this and I'm in the minority.

Andreas is right – the red definitely correct, and this is how we have always 
done it in manuals. But that doesn’t mean we have to continue. We just need to 
come up with another strong, inoffensive colour that matches; I believe the red 
was chosen to simply contrast the blue. A compromise, and complementary 
colour[0], would be orange. How would you feel about this?

I hesitated about sending this due to the wonderful bike shedding that could 
happen, don't disappoint me, cuz I'm sure we all have opinions about colour. :)

Not going to lie, also afraid of all the bike shedding! But you bring up a good 
point – and I don’t want others to also feel negatively about our 
documentation. We should be as inclusive as we can.

Also, this email thread isn't about discussing the green and orange colours 
used for the code blocks; feel free to start your own thread about that if you 
want!

No thanks, if I can avoid it :P

Cheers,

Alex

[0] https://en.wikipedia.org/wiki/Complementary_colors
__
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] [docs][ptg] Doc team attendance

[Alexandra Settle]

Hi everyone,

I’ve updated the docs PTG etherpad with a few details: 
https://etherpad.openstack.org/p/denver-doc-PTG

All those attending, could you please put your names/availability on the 
etherpad.

Also – to those interested who cannot attend on the Mon-Tues for Queens 
planning sessions, please note that I have booked Wednesday morning in Colorado 
Ballroom C for migration-specific discussions. See: 
https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms

If you wish to attend *these* sessions, please put your name in the Wednesday 
slot in the etherpad.

Cheers,

Alex
__
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-docs] [all][elections] Project Team Lead Election Conclusion and Results

[Alexandra Settle]

Sigh. The Queen release deliverables*, not the Pike release deliverables.

One day I will send out an email without something incorrect.


From: Alexandra Settle <a.set...@outlook.com>
Date: Thursday, August 17, 2017 at 10:22 AM
To: openstack-docs <openstack-d...@lists.openstack.org>, "OpenStack Development 
Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Subject: Re: [OpenStack-docs] [openstack-dev] [all][elections] Project Team 
Lead Election Conclusion and Results

Hi everyone,

The PTL nomination period is now over, so I'm pleased to be able to confirm 
that Petr Kovar is our new PTL for Queens.

Congratulations, Petr! I am excited to be working with you on the doc team 
future, and I can't wait to see what the docs team can achieve under your 
stewardship.

I would also like to thank Chason Chan for stepping up to represent our team.

On immediate practical matters: I will continue to handle the Pike release, 
along with our release team, while Petr will be organising the PTG in Denver, 
and the Pike release deliverables. I will be working closely with Petr over the 
next couple of weeks to ensure he has all the tools he needs to serve as your 
PTL.

Congratulations :)

Alex

From: Kendall Nelson <kennelso...@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Thursday, August 17, 2017 at 1:25 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [all][elections] Project Team Lead Election Conclusion 
and Results


Hello Everyone!

Thank you to the electorate, to all those who voted and to all candidates who 
put their name forward for Project Team Lead (PTL) in this election. A healthy, 
open process breeds trust in our decision making capability thank you to all 
those who make this process possible.



Now for the results of the PTL election process, please join me in extending 
congratulations to the following PTLs:



 * Barbican  : Dave McCowan

 * Chef OpenStack: Samuel Cassiba

 * Cinder: Jay Bryant

 * Cloudkitty: Christophe Sauthier

 * Congress  : Eric Kao

 * Designate : Graham Hayes

 * Documentation : Petr Kovar

 * Dragonflow: Omer Anson

 * Ec2 Api   : Andrey Pavlov

 * Freezer   : Saad Zaher

 * Glance: Brian Rosmaita

 * Heat  : Rico Lin

 * Horizon   : Ying Zuo

 * I18n  : Frank Kloeker

 * Infrastructure: Clark Boylan

 * Ironic: Dmitry Tantsur

 * Karbor: Chenying Chenying

 * Keystone  : Lance Bragstad

 * Kolla : Michal Jastrzebski

 * Kuryr : Antoni Segura Puimedon

 * Magnum: Spyros Trigazis

 * Manila: Ben Swartzlander

 * Mistral   : Renat Renat

 * Monasca   : Witold Bedyk

 * Murano: Zhurong Zhurong

 * Neutron   : Kevin Benton

 * Nova  : Matt Riedemann

 * Octavia   : Michael Johnson

 * OpenStackAnsible  : Jean-Philippe Evrard

 * OpenStackClient   : Dean Troyer

 * OpenStack Charms  : James Page

 * Oslo  : ChangBo Guo

 * Packaging Rpm : Thomas Bechtold

 * Puppet OpenStack  : Mohammed Naser

 * Quality Assurance : Andrea Frittoli

 * Rally : Andrey Kurilin

 * RefStack  : Chris Hoge

 * Release Management: Sean McGinnis

 * Requirements  : Matthew Thode

 * Sahara: Telles Mota Vidal Nóbrega

 * Searchlight   : Steve McLellan

 * Security  : Luke Hinds

 * Senlin: RUIJIE YUAN

 * Shade : Monty Taylor

 * Solum : Zhurong Zhurong

 * Stable Branch Maintenance : Tony Breeds

 * Storlets  : Kota Tsuyuzaki

 * Swift : John Dickinson

 * Tacker: Gongysh Gongysh

 * Telemetry : Gordon Chung

 * Tricircle : Zhiyuan Cai

 * Tripleo   : Alex Schultz

 * Trove : Amrith Kumar

 * Vitrage   : Ifat Afek

 * Watcher   : Alexander Chadin

 * Winstackers   : Claudiu Belu

 * Zaqar : Feilong Wang

 * Zun   : Hongbin Lu



Elections:

* Documentation: 
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_d5d9fb5a2354e2a0

* Ironic: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_0fb06bb4edfd3d08



Election process details and 

Re: [openstack-dev] [all][elections] Project Team Lead Election Conclusion and Results

[Alexandra Settle]

Hi everyone,

The PTL nomination period is now over, so I'm pleased to be able to confirm 
that Petr Kovar is our new PTL for Queens.

Congratulations, Petr! I am excited to be working with you on the doc team 
future, and I can't wait to see what the docs team can achieve under your 
stewardship.

I would also like to thank Chason Chan for stepping up to represent our team.

On immediate practical matters: I will continue to handle the Pike release, 
along with our release team, while Petr will be organising the PTG in Denver, 
and the Pike release deliverables. I will be working closely with Petr over the 
next couple of weeks to ensure he has all the tools he needs to serve as your 
PTL.

Congratulations :)

Alex

From: Kendall Nelson 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, August 17, 2017 at 1:25 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [all][elections] Project Team Lead Election Conclusion 
and Results


Hello Everyone!

Thank you to the electorate, to all those who voted and to all candidates who 
put their name forward for Project Team Lead (PTL) in this election. A healthy, 
open process breeds trust in our decision making capability thank you to all 
those who make this process possible.



Now for the results of the PTL election process, please join me in extending 
congratulations to the following PTLs:



 * Barbican  : Dave McCowan

 * Chef OpenStack: Samuel Cassiba

 * Cinder: Jay Bryant

 * Cloudkitty: Christophe Sauthier

 * Congress  : Eric Kao

 * Designate : Graham Hayes

 * Documentation : Petr Kovar

 * Dragonflow: Omer Anson

 * Ec2 Api   : Andrey Pavlov

 * Freezer   : Saad Zaher

 * Glance: Brian Rosmaita

 * Heat  : Rico Lin

 * Horizon   : Ying Zuo

 * I18n  : Frank Kloeker

 * Infrastructure: Clark Boylan

 * Ironic: Dmitry Tantsur

 * Karbor: Chenying Chenying

 * Keystone  : Lance Bragstad

 * Kolla : Michal Jastrzebski

 * Kuryr : Antoni Segura Puimedon

 * Magnum: Spyros Trigazis

 * Manila: Ben Swartzlander

 * Mistral   : Renat Renat

 * Monasca   : Witold Bedyk

 * Murano: Zhurong Zhurong

 * Neutron   : Kevin Benton

 * Nova  : Matt Riedemann

 * Octavia   : Michael Johnson

 * OpenStackAnsible  : Jean-Philippe Evrard

 * OpenStackClient   : Dean Troyer

 * OpenStack Charms  : James Page

 * Oslo  : ChangBo Guo

 * Packaging Rpm : Thomas Bechtold

 * Puppet OpenStack  : Mohammed Naser

 * Quality Assurance : Andrea Frittoli

 * Rally : Andrey Kurilin

 * RefStack  : Chris Hoge

 * Release Management: Sean McGinnis

 * Requirements  : Matthew Thode

 * Sahara: Telles Mota Vidal Nóbrega

 * Searchlight   : Steve McLellan

 * Security  : Luke Hinds

 * Senlin: RUIJIE YUAN

 * Shade : Monty Taylor

 * Solum : Zhurong Zhurong

 * Stable Branch Maintenance : Tony Breeds

 * Storlets  : Kota Tsuyuzaki

 * Swift : John Dickinson

 * Tacker: Gongysh Gongysh

 * Telemetry : Gordon Chung

 * Tricircle : Zhiyuan Cai

 * Tripleo   : Alex Schultz

 * Trove : Amrith Kumar

 * Vitrage   : Ifat Afek

 * Watcher   : Alexander Chadin

 * Winstackers   : Claudiu Belu

 * Zaqar : Feilong Wang

 * Zun   : Hongbin Lu



Elections:

* Documentation: 
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_d5d9fb5a2354e2a0

* Ironic: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_0fb06bb4edfd3d08



Election process details and results are also available here: 
https://governance.openstack.org/election/



Thank you to all involved in the PTL election process,

- Kendall Nelson(diablo_rojo)
__
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] Doc meeting Thursday

[Alexandra Settle]

Reminder: Docs meeting as normally scheduled in #openstack-meeting today at 
16:00UTC.

Agenda: https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting

Thanks,

Alex

From: Alexandra Settle <a.set...@outlook.com>
Date: Tuesday, August 8, 2017 at 11:13 AM
To: openstack-docs <openstack-d...@lists.openstack.org>, "OpenStack Development 
Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Subject: [docs] Doc meeting Thursday

Hi everyone,

With the upcoming PTG and all of the big changes with the migration, I will be 
hosting the docs meeting as normally scheduled in #openstack-meeting on 
Thursday, 10th of August at 16:00UTC.

I will send out the agenda closer to the day. I *strongly* urge all to attend. 
I know it’s not the best time in the world, but we’re closing in on the first 
release for the doc team with the new release format.

The meeting chair will be me – although I’ll be juggling my regular conflict at 
the same time! Hope you can all make it :)

Thanks,

Alex

__
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] [docs] Doc meeting Thursday

[Alexandra Settle]

Hi everyone,

With the upcoming PTG and all of the big changes with the migration, I will be 
hosting the docs meeting as normally scheduled in #openstack-meeting on 
Thursday, 10th of August at 16:00UTC.

I will send out the agenda closer to the day. I *strongly* urge all to attend. 
I know it’s not the best time in the world, but we’re closing in on the first 
release for the doc team with the new release format.

The meeting chair will be me – although I’ll be juggling my regular conflict at 
the same time! Hope you can all make it :)

Thanks,

Alex

__
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-doc] Attending PTG?

[Alexandra Settle]

Hey everyone,

Put your hand in the air* if you’re attending the PTG!

Myself and the potential PTL will need to start planning shortly, and it would 
be good to get an idea of numbers, and who we are planning for.

I will be looking at hosting a working bee or hack session for migration 
related issues throughout the week.

Cheers,

Alex

*reply to this ML thread
__
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] [doc][api] need new reviewers for the api-site and developer.openstack.org

[Alexandra Settle]

Hi everyone,

As you all know, we have been changing the way the documentation team operates. 
Chief among those
changes are reducing the workload on the shrinking team. The migration to move 
installation, admin, and
configuration documentation to project-team repositories is the first phase of 
that transition. Another component on
the documentation team's list of responsibilities is developer.openstack.org, 
the site for consumers of
OpenStack services to find resources to help them build their applications. 
Finding a new team of people
to manage that site is the next phase of shrinking the documentation team's 
duties.

We are setting up a new review team [0] in gerrit for the openstack/api-site 
repository and removing
the api-site and the faafo (First App Application for OpenStack) repositories 
from the set listed as owned by the docs
team in governance [1].  This opens up an opportunity for a new SIG or WG that 
is able to tackle the requirements
of the api-site repo.

Any concerns or questions, please do not hesitate to reach out.

Cheers,

Alex

[0] https://review.openstack.org/#/c/485179/
[1] https://review.openstack.org/#/c/485249/
__
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-docs] [doc] Operations Guide removal

[Alexandra Settle]

Hey Blair!

Thanks for looking into this… Adding Mario and Erik who both also volunteered 
their time :)

1. I can say confidently that the content that lives at 
https://wiki.openstack.org/wiki/Documentation/OpsGuide can be removed. I am 
happy to do this if you would like to use this URL?
2. We (very successfully) used pandoc during our conversion from XML to RST. I 
would recommend it. I admit I haven’t tried converting to a mediaWiki format. 
But hey, worth trying… I guess the other option is manually copying across and 
editing. (Unless someone has a script lying around?)
3. It’s a good question, one I’m not really sure how to answer. The idea of 
pushing back to the wiki was so that the operators can own. Having the guide 
linked from docs.o.o will still ensure there is traffic, and people are able to 
edit. Perhaps the best idea for this is to use the documentation liaison for 
Ops as a first point of call? What do you think about that? Currently Robert 
Starmer is our liaison 
(https://wiki.openstack.org/wiki/CrossProjectLiaisons#Documentation ) but 
seeing as we’re now making this more of an official ownership thing, we should 
be revisiting the responsibilities of the ops docs liaison?

Cheers,

Alex

On 7/19/17, 11:40 AM, "Blair Bethwaite" <blair.bethwa...@gmail.com> wrote:

Hi Alex,

I just managed to take a half hour to look at this and have a few
questions/comments towards making a plan for how to proceed with
moving the Ops Guide content to the wiki...

1) Need to define wiki location and structure. Curiously at the moment
there is already meta content at
https://wiki.openstack.org/wiki/Documentation/OpsGuide, Maybe the
content could live at https://wiki.openstack.org/wiki/OpsGuide? I
think it makes sense to follow the existing structure with possible
exception of culling wrong / very-out-of-date content (but perhaps
anything like that should be done as a later step and keep it simple
aiming for a "like-for-like" migration to start with)...?

2) Getting the content into the wiki. Looks like there is no obvious
up-to-date RST import functionality for MediaWiki. Pandoc seems as
though it might support some useful conversions but I didn't try this
yet and don't have any experience with it - can anyone say with
authority whether it is worth pursuing?

3) Future management - obvious can of worms given this is much better
addressed by all the tooling and scaffolding the docs team already
provides around the repos... but nonetheless some expectations may
need to be set upfront to avoid future pain.

Cheers,

On 15 July 2017 at 01:48, Alexandra Settle <a.set...@outlook.com> wrote:
> Hi operators,
>
> Please be aware that I have proposed the following patch:
> https://review.openstack.org/#/c/483937/
>
>
>
> This removes the Operations Guide from the openstack-manuals repo and will
> no longer be accessible via docs.openstack.org after the patch merges.
>
> The documentation team does not have the resources to move the ops guide 
to
> the wiki ourselves. If you are able to work on the migration, please check
> out the ‘before-migration’ tag in the repo to access the deleted content.
> [0]
>
> Once the ops guide is migrated to the wiki, we will help you add a 
redirect
> so that the old link on docs.openstack.org will allow users to find the
> content in the new location.
>
> Thanks,
>
> Alex
>
>
>
> [0] https://github.com/openstack/openstack-manuals/tree/before-migration
>
>
> ___
> OpenStack-docs mailing list
> openstack-d...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>



-- 
Cheers,
~Blairo


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

[Openstack-operators] [doc] Operations Guide removal

[Alexandra Settle]

Hi operators,
Please be aware that I have proposed the following patch: 
https://review.openstack.org/#/c/483937/

This removes the Operations Guide from the openstack-manuals repo and will no 
longer be accessible via docs.openstack.org after the patch merges.
The documentation team does not have the resources to move the ops guide to the 
wiki ourselves. If you are able to work on the migration, please check out the 
‘before-migration’ tag in the repo to access the deleted content. [0]
Once the ops guide is migrated to the wiki, we will help you add a redirect so 
that the old link on docs.openstack.org will allow users to find the content in 
the new location.
Thanks,
Alex

[0] https://github.com/openstack/openstack-manuals/tree/before-migration
___
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] doc-migration status

[Alexandra Settle]

Just to add to this, today I have spent some time going through and abandoning 
patches that were against the master branch for openstack-manuals and I have 
backported those applicable to Ocata.

If anyone has patches against the master branch that are addressing a 
bug/fix/enhancement in the install, networking, config ref, CLI ref, or admin 
guides – please abandon and move to relevant repo.

Thanks everyone for all your hard work! This has been a massive success (so 
far) as a result of everyone pooling together (

On 7/3/17, 3:34 PM, "Doug Hellmann"  wrote:

After a busy week last week, we made some good progress with the
documentation migration project. We still have quite a few repositories
that haven't been started, though, so please keep working. If you
need assistance preparing or reviewing the patches, let us know
with a follow-up email to this thread or by asking in #openstack-docs.

Because we still have a lot of work to do in the openstack-manuals
repo, the documentation team has started landing patches to remove
the content that is being migrated into project repositories. If
you have not yet started your migration, check out the commit tagged
"before-migration" in openstack-manuals to find the content to be
migrated.

As part of this work today we have also prepared a patch to move
all remaining projects to the new documentation build jobs. This
will cause any content from doc/source to be published to
docs.o.o/$project/latest instead of docs.o.o/developer/$project.
Project teams still need to reorganize this content as described
in the spec to ensure the automatically generated landing pages
point to the correct URLs.

We need to complete this migration work before creating stable
branches, to avoid having to backport the documentation changes.

Over the course of last week, we had a few questions about the
directions and about reviews.

1. Please use the gerrit topic "doc-migration" for all of the patches
related to this work. We are monitoring the available changes by
using that topic in queries, and we won't see your patches to help
with reviews if you use another topic. Tying your patch to the
blueprint using "Blueprint: doc-migration" will set the topic of
the patch to "bp/doc-migration", and the patches will not appear
in the query results.

2. Please work on the steps in the order given. We have had quite
a few patches that only apply the new theme, without reorganizing
the content for the projects. These projects will not be linked
properly from the templated landing pages, so your users will have
trouble finding your documentation.

3. Only official OpenStack projects, under TC governance, should
use the openstackdocs theme. Projects publishing their documentation
to readthedocs.org or other sites should not use the theme, and do
not need to take any of the other migration steps.

4. Reviewers, please prioritize landing the intiial content import
and ask for follow-up patches to fix issues, unless the content is
just absolutely wrong. Whitespace issues, typos, etc. should all
be fixed after the initial import of the content created by the
documentation team is complete.

5. Projects with a "deployment guide" instead of "install guide"
need to make sure they are using the openstackdocs theme and to
update the organization of the rest of their content. The deployment
guide should stay where it is, for now.

6. We've had a couple of cases where multiple people did the same
work because neither put their name next to the repository in the
list on https://etherpad.openstack.org/p/doc-migration-tracking.
We have plenty of this work to go around! Please use the etherpad
to sign up for the repo you are going to work on *before* starting
to write patches, so that we can avoid duplicating effort!

If you run into trouble or have other questions, please follow-up
here or ping us in the #openstack-doc IRC channel on Freenode.

Doug

__
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 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] Retiring clouddocs-maven-plugin

[Alexandra Settle]

Sound proposal. +1 

Thanks Andreas

On 6/30/17, 2:16 PM, "Andreas Jaeger"  wrote:

It's IMHO time to retire
http://git.openstack.org/cgit/openstack/clouddocs-maven-plugin/ - this
was used to build documents from XML.

We converted all documents to RST, have released the last version in
April 2015, and not merged anything since May 2016.

Current openstack-manuals got fully converted to RST with Mitaka, so we
have no current branches that need this.

Thus I propose to retire the repo and will propose patches for it. Once
those are submitted, I'll reply here with references to them,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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 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][doc[ptls] Doc meeting

[Alexandra Settle]

Hi everyone,

If you have any questions/concerns/comments/feelings you have about the doc 
migration, bring ‘em to #openstack-meeting at 1600UTC today :)

I’ll be there to chat instead of our regularly scheduled meeting :)

Cheers,

Alex

From: Alexandra Settle <a.set...@outlook.com>
Date: Wednesday, June 28, 2017 at 6:45 PM
To: "'openstack-d...@lists.openstack.org'" 
<openstack-d...@lists.openstack.org>, "OpenStack Development Mailing List (not 
for usage questions)" <openstack-...@lists.openstack.org>
Cc: "openstack-operators@lists.openstack.org" 
<openstack-operators@lists.openstack.org>
Subject: [Openstack-operators] [openstack-dev][doc[ptls] Doc meeting

Hey everyone,

The docs meeting will continue in #openstack-meeting as scheduled (Thursday, 
29th of June at 16:00 UTC).

There will be no official agenda, I am opening up this meeting for any docs 
liaisons and PTLs to come and chat about the docs migration and any questions 
they may have.

The meeting chair will be me! Hope you can all make it ☺

Thanks,

Alex

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

Re: [openstack-dev] [Openstack-operators] [doc[ptls] Doc meeting

[Alexandra Settle]

Hi everyone,

If you have any questions/concerns/comments/feelings you have about the doc 
migration, bring ‘em to #openstack-meeting at 1600UTC today :)

I’ll be there to chat instead of our regularly scheduled meeting :)

Cheers,

Alex

From: Alexandra Settle <a.set...@outlook.com>
Date: Wednesday, June 28, 2017 at 6:45 PM
To: "'openstack-d...@lists.openstack.org'" 
<openstack-d...@lists.openstack.org>, "OpenStack Development Mailing List (not 
for usage questions)" <openstack-dev@lists.openstack.org>
Cc: "openstack-operat...@lists.openstack.org" 
<openstack-operat...@lists.openstack.org>
Subject: [Openstack-operators] [openstack-dev][doc[ptls] Doc meeting

Hey everyone,

The docs meeting will continue in #openstack-meeting as scheduled (Thursday, 
29th of June at 16:00 UTC).

There will be no official agenda, I am opening up this meeting for any docs 
liaisons and PTLs to come and chat about the docs migration and any questions 
they may have.

The meeting chair will be me! Hope you can all make it ☺

Thanks,

Alex

__
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] [openstack-dev][doc[ptls] Doc meeting

[Alexandra Settle]

Hey everyone,

The docs meeting will continue in #openstack-meeting as scheduled (Thursday, 
29th of June at 16:00 UTC).

There will be no official agenda, I am opening up this meeting for any docs 
liaisons and PTLs to come and chat about the docs migration and any questions 
they may have.

The meeting chair will be me! Hope you can all make it ☺

Thanks,

Alex

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

[openstack-dev] [doc[ptls] Doc meeting

[Alexandra Settle]

Hey everyone,

The docs meeting will continue in #openstack-meeting as scheduled (Thursday, 
29th of June at 16:00 UTC).

There will be no official agenda, I am opening up this meeting for any docs 
liaisons and PTLs to come and chat about the docs migration and any questions 
they may have.

The meeting chair will be me! Hope you can all make it ☺

Thanks,

Alex

__
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-docs] [Openstack-operators][dev][doc] Operations Guide future

[Alexandra Settle]

Hi Mario,

Just so everyone is aware that you’re offering assistance, I’ve re-added the ML 
back in.

Definitely appreciate the help! The only schedule is that it is delivered by 
the Pike release. You can see the details and dates here: 
https://releases.openstack.org/pike/schedule.html

Thank you again! Anyone else able to help Mario?

Cheers,

Alex

From: Mario Pranjic <ma...@pranjic.no>
Date: Wednesday, June 28, 2017 at 7:32 AM
To: Alexandra Settle <a.set...@outlook.com>
Subject: Re: [OpenStack-docs] [Openstack-operators][dev][doc] Operations Guide 
future


Hi,

I can help with wiki. It depends what are the schedules?

I am on vacation with sometimes limited access to machine with net. If it's not 
on a tight schedule day to day basis, count me in.


Mario Pranjic, M.Sc.C.S, RHCSA, RHCE
t: +47 454 90 613
e: ma...@pranjic.no<mailto:ma...@pranjic.no>
skype: mario.pranjic.no
LinkedIn: https://no.linkedin.com/in/mariopranjic
On 06/27/2017 05:52 PM, Alexandra Settle wrote:
Thanks everyone for your feedback regarding the proposal below.

Going forwards we are going to implement Option 3.

If anyone is able to help out with this migration, please let me know :)

Looking forward to getting started!

From: Alexandra Settle <a.set...@outlook.com><mailto:a.set...@outlook.com>
Date: Thursday, June 1, 2017 at 4:06 PM
To: OpenStack Operators 
<openstack-operat...@lists.openstack.org><mailto:openstack-operat...@lists.openstack.org>,
 
"'openstack-d...@lists.openstack.org'"<mailto:'openstack-d...@lists.openstack.org'>
 <openstack-d...@lists.openstack.org><mailto:openstack-d...@lists.openstack.org>
Cc: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org><mailto:openstack-dev@lists.openstack.org>
Subject: [Openstack-operators] [dev] [doc] Operations Guide future

Hi everyone,

I haven’t had any feedback regarding moving the Operations Guide to the 
OpenStack wiki. I’m not taking silence as compliance. I would really like to 
hear people’s opinions on this matter.

To recap:

1.  Option one: Kill the Operations Guide completely and move the 
Administration Guide to project repos.
2.  Option two: Combine the Operations and Administration Guides (and then 
this will be moved into the project-specific repos)
3.  Option three: Move Operations Guide to OpenStack wiki (for ease of 
operator-specific maintainability) and move the Administration Guide to project 
repos.

Personally, I think that option 3 is more realistic. The idea for the last 
option is that operators are maintaining operator-specific documentation and 
updating it as they go along and we’re not losing anything by combining or 
deleting. I don’t want to lose what we have by going with option 1, and I think 
option 2 is just a workaround without fixing the problem – we are not getting 
contributions to the project.

Thoughts?

Alex

From: Alexandra Settle <a.set...@outlook.com><mailto:a.set...@outlook.com>
Date: Friday, May 19, 2017 at 1:38 PM
To: Melvin Hillsman <mrhills...@gmail.com><mailto:mrhills...@gmail.com>, 
OpenStack Operators 
<openstack-operat...@lists.openstack.org><mailto:openstack-operat...@lists.openstack.org>
Subject: Re: [Openstack-operators] Fwd: [openstack-dev] [openstack-doc] [dev] 
What's up doc? Summit recap edition

Hi everyone,

Adding to this, I would like to draw your attention to the last dot point of my 
email:

“One of the key takeaways from the summit was the session that I joint 
moderated with Melvin Hillsman regarding the Operations and Administration 
Guides. You can find the etherpad with notes here: 
https://etherpad.openstack.org/p/admin-ops-guides  The session was really 
helpful – we were able to discuss with the operators present the current 
situation of the documentation team, and how they could help us maintain the 
two guides, aimed at the same audience. The operator’s present at the session 
agreed that the Administration Guide was important, and could be maintained 
upstream. However, they voted and agreed that the best course of action for the 
Operations Guide was for it to be pulled down and put into a wiki that the 
operators could manage themselves. We will be looking at actioning this item as 
soon as possible.”

I would like to go ahead with this, but I would appreciate feedback from 
operators who were not able to attend the summit. In the etherpad you will see 
the three options that the operators in the room recommended as being viable, 
and the voted option being moving the Operations Guide out of 
docs.openstack.org into a wiki. The aim of this was to empower the operations 
community to take more control of the updates in an environment they are more 
familiar with (and available to others).

What does everyone think of the proposed options? Questions? Other thoughts?

Alex

From: Melvin Hillsman <

[Openstack-operators] [dev][doc] Operations Guide future

[Alexandra Settle]

Thanks everyone for your feedback regarding the proposal below.

Going forwards we are going to implement Option 3.

If anyone is able to help out with this migration, please let me know :)

Looking forward to getting started!

From: Alexandra Settle <a.set...@outlook.com>
Date: Thursday, June 1, 2017 at 4:06 PM
To: OpenStack Operators <openstack-operators@lists.openstack.org>, 
"'openstack-d...@lists.openstack.org'" <openstack-d...@lists.openstack.org>
Cc: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-...@lists.openstack.org>
Subject: [Openstack-operators] [dev] [doc] Operations Guide future

Hi everyone,

I haven’t had any feedback regarding moving the Operations Guide to the 
OpenStack wiki. I’m not taking silence as compliance. I would really like to 
hear people’s opinions on this matter.

To recap:

1.  Option one: Kill the Operations Guide completely and move the 
Administration Guide to project repos.
2.  Option two: Combine the Operations and Administration Guides (and then 
this will be moved into the project-specific repos)
3.  Option three: Move Operations Guide to OpenStack wiki (for ease of 
operator-specific maintainability) and move the Administration Guide to project 
repos.

Personally, I think that option 3 is more realistic. The idea for the last 
option is that operators are maintaining operator-specific documentation and 
updating it as they go along and we’re not losing anything by combining or 
deleting. I don’t want to lose what we have by going with option 1, and I think 
option 2 is just a workaround without fixing the problem – we are not getting 
contributions to the project.

Thoughts?

Alex

From: Alexandra Settle <a.set...@outlook.com>
Date: Friday, May 19, 2017 at 1:38 PM
To: Melvin Hillsman <mrhills...@gmail.com>, OpenStack Operators 
<openstack-operators@lists.openstack.org>
Subject: Re: [Openstack-operators] Fwd: [openstack-dev] [openstack-doc] [dev] 
What's up doc? Summit recap edition

Hi everyone,

Adding to this, I would like to draw your attention to the last dot point of my 
email:

“One of the key takeaways from the summit was the session that I joint 
moderated with Melvin Hillsman regarding the Operations and Administration 
Guides. You can find the etherpad with notes here: 
https://etherpad.openstack.org/p/admin-ops-guides  The session was really 
helpful – we were able to discuss with the operators present the current 
situation of the documentation team, and how they could help us maintain the 
two guides, aimed at the same audience. The operator’s present at the session 
agreed that the Administration Guide was important, and could be maintained 
upstream. However, they voted and agreed that the best course of action for the 
Operations Guide was for it to be pulled down and put into a wiki that the 
operators could manage themselves. We will be looking at actioning this item as 
soon as possible.”

I would like to go ahead with this, but I would appreciate feedback from 
operators who were not able to attend the summit. In the etherpad you will see 
the three options that the operators in the room recommended as being viable, 
and the voted option being moving the Operations Guide out of 
docs.openstack.org into a wiki. The aim of this was to empower the operations 
community to take more control of the updates in an environment they are more 
familiar with (and available to others).

What does everyone think of the proposed options? Questions? Other thoughts?

Alex

From: Melvin Hillsman <mrhills...@gmail.com>
Date: Friday, May 19, 2017 at 1:30 PM
To: OpenStack Operators <openstack-operators@lists.openstack.org>
Subject: [Openstack-operators] Fwd: [openstack-dev] [openstack-doc] [dev] 
What's up doc? Summit recap edition


-- Forwarded message --
From: Alexandra Settle <a.set...@outlook.com<mailto:a.set...@outlook.com>>
Date: Fri, May 19, 2017 at 6:12 AM
Subject: [openstack-dev] [openstack-doc] [dev] What's up doc? Summit recap 
edition
To: 
"openstack-d...@lists.openstack.org<mailto:openstack-d...@lists.openstack.org>" 
<openstack-d...@lists.openstack.org<mailto:openstack-d...@lists.openstack.org>>
Cc: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-...@lists.openstack.org<mailto:openstack-...@lists.openstack.org>>



Hi everyone,

The OpenStack manuals project had a really productive week at the OpenStack 
summit in Boston. You can find a list of all the etherpads and attendees here: 
https://etherpad.openstack.org/p/docs-summit

As we all know, we are rapidly losing key contributors and core reviewers. We 
are not alone, this is happening across the board. It is making things harder, 
but not impossible. Since our inception in 2010, we’ve been climbing higher and 
higher trying to achieve the best documentation we could, and uphold

[openstack-dev] [Openstack-operators][dev][doc] Operations Guide future

[Alexandra Settle]

Thanks everyone for your feedback regarding the proposal below.

Going forwards we are going to implement Option 3.

If anyone is able to help out with this migration, please let me know :)

Looking forward to getting started!

From: Alexandra Settle <a.set...@outlook.com>
Date: Thursday, June 1, 2017 at 4:06 PM
To: OpenStack Operators <openstack-operat...@lists.openstack.org>, 
"'openstack-d...@lists.openstack.org'" <openstack-d...@lists.openstack.org>
Cc: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: [Openstack-operators] [dev] [doc] Operations Guide future

Hi everyone,

I haven’t had any feedback regarding moving the Operations Guide to the 
OpenStack wiki. I’m not taking silence as compliance. I would really like to 
hear people’s opinions on this matter.

To recap:

1.  Option one: Kill the Operations Guide completely and move the 
Administration Guide to project repos.
2.  Option two: Combine the Operations and Administration Guides (and then 
this will be moved into the project-specific repos)
3.  Option three: Move Operations Guide to OpenStack wiki (for ease of 
operator-specific maintainability) and move the Administration Guide to project 
repos.

Personally, I think that option 3 is more realistic. The idea for the last 
option is that operators are maintaining operator-specific documentation and 
updating it as they go along and we’re not losing anything by combining or 
deleting. I don’t want to lose what we have by going with option 1, and I think 
option 2 is just a workaround without fixing the problem – we are not getting 
contributions to the project.

Thoughts?

Alex

From: Alexandra Settle <a.set...@outlook.com>
Date: Friday, May 19, 2017 at 1:38 PM
To: Melvin Hillsman <mrhills...@gmail.com>, OpenStack Operators 
<openstack-operat...@lists.openstack.org>
Subject: Re: [Openstack-operators] Fwd: [openstack-dev] [openstack-doc] [dev] 
What's up doc? Summit recap edition

Hi everyone,

Adding to this, I would like to draw your attention to the last dot point of my 
email:

“One of the key takeaways from the summit was the session that I joint 
moderated with Melvin Hillsman regarding the Operations and Administration 
Guides. You can find the etherpad with notes here: 
https://etherpad.openstack.org/p/admin-ops-guides  The session was really 
helpful – we were able to discuss with the operators present the current 
situation of the documentation team, and how they could help us maintain the 
two guides, aimed at the same audience. The operator’s present at the session 
agreed that the Administration Guide was important, and could be maintained 
upstream. However, they voted and agreed that the best course of action for the 
Operations Guide was for it to be pulled down and put into a wiki that the 
operators could manage themselves. We will be looking at actioning this item as 
soon as possible.”

I would like to go ahead with this, but I would appreciate feedback from 
operators who were not able to attend the summit. In the etherpad you will see 
the three options that the operators in the room recommended as being viable, 
and the voted option being moving the Operations Guide out of 
docs.openstack.org into a wiki. The aim of this was to empower the operations 
community to take more control of the updates in an environment they are more 
familiar with (and available to others).

What does everyone think of the proposed options? Questions? Other thoughts?

Alex

From: Melvin Hillsman <mrhills...@gmail.com>
Date: Friday, May 19, 2017 at 1:30 PM
To: OpenStack Operators <openstack-operat...@lists.openstack.org>
Subject: [Openstack-operators] Fwd: [openstack-dev] [openstack-doc] [dev] 
What's up doc? Summit recap edition


-- Forwarded message --
From: Alexandra Settle <a.set...@outlook.com<mailto:a.set...@outlook.com>>
Date: Fri, May 19, 2017 at 6:12 AM
Subject: [openstack-dev] [openstack-doc] [dev] What's up doc? Summit recap 
edition
To: 
"openstack-d...@lists.openstack.org<mailto:openstack-d...@lists.openstack.org>" 
<openstack-d...@lists.openstack.org<mailto:openstack-d...@lists.openstack.org>>
Cc: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>



Hi everyone,

The OpenStack manuals project had a really productive week at the OpenStack 
summit in Boston. You can find a list of all the etherpads and attendees here: 
https://etherpad.openstack.org/p/docs-summit

As we all know, we are rapidly losing key contributors and core reviewers. We 
are not alone, this is happening across the board. It is making things harder, 
but not impossible. Since our inception in 2010, we’ve been climbing higher and 
higher trying to achieve the best documentation we could, and uphold

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

[Alexandra Settle]

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.

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

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.

Cheers,

Alex

From: Mike Perez 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, June 23, 2017 at 9:17 PM
To: OpenStack Development Mailing List 
Cc: Wes Wilson , "ild...@openstack.org" 
, "knel...@openstack.org" 
Subject: [openstack-dev] [docs][all][ptl] Contributor Portal and Better New 
Contributor On-boarding

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
 * 

[openstack-dev] [ptls][all][tc][docs] Documentation migration spec

[Alexandra Settle]

Hi everyone,

This morning (afternoon) the specification for the documentation migration was 
merged. Thanks to all that took time to review :)

You can now view here in all its glory: 
https://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html

If you have any questions, feel free to shoot them to me or Doug :)

Let’s begin!

Alex
__
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] [dev] [doc] Operations Guide future

[Alexandra Settle]

Hey Blair,

Thanks ( I appreciate your offer of assistance. We are in full swing at the 
moment. The spec is very close to being merged. You can view that here: 
https://review.openstack.org/#/c/472275/ 

I am still looking for someone who can help us out with the pandoc conversion. 
I am happy to go through it with said individual.

Cheers,

Alex

On 6/23/17, 3:47 AM, "Blair Bethwaite" <blair.bethwa...@gmail.com> wrote:

Hi Alex,

On 2 June 2017 at 23:13, Alexandra Settle <a.set...@outlook.com> wrote:
> O I like your thinking – I’m a pandoc fan, so, I’d be interested in
> moving this along using any tools to make it easier.

I can't realistically offer much time on this but I would be happy to
help (ad-hoc) review/catalog/clean-up issues with export.

> I think my only proviso (now I’m thinking about it more) is that we still
> have a link on docs.o.o, but it goes to the wiki page for the Ops Guide.

Agreed, need to maintain discoverability.

-- 
Cheers,
~Blairo


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

Re: [openstack-dev] [Openstack-operators] [dev] [doc] Operations Guide future

[Alexandra Settle]

Hey Blair,

Thanks ( I appreciate your offer of assistance. We are in full swing at the 
moment. The spec is very close to being merged. You can view that here: 
https://review.openstack.org/#/c/472275/ 

I am still looking for someone who can help us out with the pandoc conversion. 
I am happy to go through it with said individual.

Cheers,

Alex

On 6/23/17, 3:47 AM, "Blair Bethwaite" <blair.bethwa...@gmail.com> wrote:

Hi Alex,

On 2 June 2017 at 23:13, Alexandra Settle <a.set...@outlook.com> wrote:
> O I like your thinking – I’m a pandoc fan, so, I’d be interested in
> moving this along using any tools to make it easier.

I can't realistically offer much time on this but I would be happy to
help (ad-hoc) review/catalog/clean-up issues with export.

> I think my only proviso (now I’m thinking about it more) is that we still
> have a link on docs.o.o, but it goes to the wiki page for the Ops Guide.

Agreed, need to maintain discoverability.

-- 
Cheers,
~Blairo


__
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-docs] [openstack-docs][dev][all] Documentation repo freeze

[Alexandra Settle]

On 6/20/17, 2:12 PM, "Anne Gentle" <annegen...@justwriteclick.com> wrote:

On Tue, Jun 20, 2017 at 3:13 AM, Alexandra Settle <a.set...@outlook.com> 
wrote:
>
>
> On 6/19/17, 6:19 PM, "Petr Kovar" <pko...@redhat.com> wrote:
>
> On Mon, 19 Jun 2017 15:56:35 +
> Alexandra Settle <a.set...@outlook.com> wrote:
>
> > Hi everyone,
> >
> > As of today - Monday, the 19th of June – please do NOT merge any 
patches into
> > the openstack-manuals repository that is not related to the topic:
> > “doc-migration”.
> >
> > We are currently in the phase of setting up for our MASSIVE 
migration and we
> > need to ensure that there will be minimal conflicts.
> >
> > You can find all patches related to that topic here:
> > 
https://review.openstack.org/#/q/status:open+project:openstack/openstack-manuals+branch:master+topic:doc-migration
> >
> > The only other patches that should be passed is the Zanata 
translation patches.
> >
> > If there are any concerns or questions, please do not hesitate to 
contact either
> > myself or Doug Hellmann for further clarification.
>
> Can we still merge into stable branches? As the migration only affects
> content in master, I think there's no need to freeze stable branches.
>
>
> Good question. I would say yes, as we are only porting over everything 
that is currently in master for now.
>

Yep, that sounds right to me, if we need to change content in a stable
branch, go ahead.

> I would also like to clarify that this only affects the documentation 
suite, not the tooling.

Yes, speaking of tooling, can anyone review
https://review.openstack.org/#/c/468021/ -- changes to the them?

On it! Thanks Anne ( 

__
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-docs] [openstack-docs][dev][all] Documentation repo freeze

[Alexandra Settle]

On 6/19/17, 6:19 PM, "Petr Kovar" <pko...@redhat.com> wrote:

On Mon, 19 Jun 2017 15:56:35 +0000
Alexandra Settle <a.set...@outlook.com> wrote:

> Hi everyone,
> 
> As of today - Monday, the 19th of June – please do NOT merge any patches 
into
> the openstack-manuals repository that is not related to the topic:
> “doc-migration”.
> 
> We are currently in the phase of setting up for our MASSIVE migration and 
we
> need to ensure that there will be minimal conflicts.
> 
> You can find all patches related to that topic here:
> 
https://review.openstack.org/#/q/status:open+project:openstack/openstack-manuals+branch:master+topic:doc-migration
> 
> The only other patches that should be passed is the Zanata translation 
patches.
> 
> If there are any concerns or questions, please do not hesitate to contact 
either
> myself or Doug Hellmann for further clarification.

Can we still merge into stable branches? As the migration only affects
content in master, I think there's no need to freeze stable branches. 


Good question. I would say yes, as we are only porting over everything that is 
currently in master for now.

I would also like to clarify that this only affects the documentation suite, 
not the tooling.

Cheers,

Alex 

__
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-docs][dev][all] Documentation repo freeze

[Alexandra Settle]

Hi everyone,

As of today - Monday, the 19th of June – please do NOT merge any patches into 
the openstack-manuals repository that is not related to the topic: 
“doc-migration”.

We are currently in the phase of setting up for our MASSIVE migration and we 
need to ensure that there will be minimal conflicts.

You can find all patches related to that topic here: 
https://review.openstack.org/#/q/status:open+project:openstack/openstack-manuals+branch:master+topic:doc-migration

The only other patches that should be passed is the Zanata translation patches.

If there are any concerns or questions, please do not hesitate to contact 
either myself or Doug Hellmann for further clarification.

Thanks,

Alex
__
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][glance][nova][neutron][horizon][cinder][osc][swift][manila][telemetry][heat][ptls][all][tc][docs] Documentation migration spec

[Alexandra Settle]

Hi everyone,

Doug has been working hard in my absence to answer everyone’s questions and 
concerns on the migration spec. Thanks to all that have taken the time to 
review.

Due to our limited time frame, we are now looking for the PTLs to provide their 
respective +1’s (or -1’s) on the patch.

Cheers,

Alex

On 6/15/17, 11:26 PM, "Doug Hellmann"  wrote:

Excerpts from Doug Hellmann's message of 2017-06-12 11:43:25 -0400:
> I added subject tags for the projects most affected by this change. It
> would be good to have the PTLs or liaisons from those teams review the
> spec so there are no surprises when we start moving files around.

I have set up patches for oslo.config, glance, glance client,
python-openstackclient, and horizon for folks to use as examples
[1]. I've also updated the tracking etherpad [2] with some more
detailed directions.

I hope the examples will answer any remaining questions about the
plan and PTLs will sign-off on the spec so we can move forward in
earnest next week.

Doug

[1] https://review.openstack.org/#/q/topic:doc-migration
[2] https://etherpad.openstack.org/p/doc-migration-tracking

> 
> Excerpts from Alexandra Settle's message of 2017-06-08 15:17:34 +:
> > Hi everyone,
> > 
> > Doug and I have written up a spec following on from the conversation 
[0] that we had regarding the documentation publishing future.
> > 
> > Please take the time out of your day to review the spec as this affects 
*everyone*.
> > 
> > See: https://review.openstack.org/#/c/472275/
> > 
> > I will be PTO from the 9th – 19th of June. If you have any pressing 
concerns, please email me and I will get back to you as soon as I can, or, 
email Doug Hellmann and hopefully he will be able to assist you.
> > 
> > Thanks,
> > 
> > Alex
> > 
> > [0] 
http://lists.openstack.org/pipermail/openstack-dev/2017-May/117162.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


__
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] [ptls][all][tc][docs] Documentation migration spec

[Alexandra Settle]

Hi everyone,

Doug and I have written up a spec following on from the conversation [0] that 
we had regarding the documentation publishing future.

Please take the time out of your day to review the spec as this affects 
*everyone*.

See: https://review.openstack.org/#/c/472275/

I will be PTO from the 9th – 19th of June. If you have any pressing concerns, 
please email me and I will get back to you as soon as I can, or, email Doug 
Hellmann and hopefully he will be able to assist you.

Thanks,

Alex

[0] http://lists.openstack.org/pipermail/openstack-dev/2017-May/117162.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

[openstack-dev] [openstack-doc] [dev] Doc team meeting cancellation

[Alexandra Settle]

Hi everyone,

Next week, Thursday the 15th of June, the OpenStack manuals meeting is 
cancelled as I will be PTO.

The next documentation team meeting will be the following bi-weekly allotment 
on the 29th of June.

If anyone has any pressing concerns, please email me and I will get back to you 
when I am able. I will return online on the 19th of June.

Thanks,

Alex
__
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-operators] [dev] [doc] Operations Guide future

[Alexandra Settle]

O I like your thinking – I’m a pandoc fan, so, I’d be interested in moving 
this along using any tools to make it easier.

I think my only proviso (now I’m thinking about it more) is that we still have 
a link on docs.o.o, but it goes to the wiki page for the Ops Guide.

From: Anne Gentle <annegen...@justwriteclick.com>
Date: Friday, June 2, 2017 at 1:53 PM
To: Alexandra Settle <a.set...@outlook.com>
Cc: Blair Bethwaite <blair.bethwa...@gmail.com>, OpenStack Operators 
<openstack-operat...@lists.openstack.org>, "OpenStack Development Mailing List 
(not for usage questions)" <openstack-dev@lists.openstack.org>, 
"openstack-d...@lists.openstack.org" <openstack-d...@lists.openstack.org>
Subject: Re: [Openstack-operators] [dev] [doc] Operations Guide future

I'm okay with option 3.

Since we hadn't heard from anyone yet who can do the work, I thought I'd 
describe a super small experiment to try. If you're interested in the export, 
run an experiment with Pandoc to convert from RST to Mediawiki. 
http://pandoc.org/demos.html

You'll likely still have cleanup but it's a start. Only convert troubleshooting 
to start, which gets the most hits: 
docs.openstack.org/<http://docs.openstack.org/>ops-guide/ops-network-troubleshooting.html
Then see how much you get from Pandoc.

Let us know how it goes, I'm curious!
Anne



On Fri, Jun 2, 2017 at 4:03 AM, Alexandra Settle 
<a.set...@outlook.com<mailto:a.set...@outlook.com>> wrote:
Blair – correct, it was the majority in the room. I just wanted to reach out 
and ensure that operators had a chance to voice opinions and see where we were 
going (

Sounds like option 3 is still the favorable direction. This is going to be a 
really big exercise, lifting the content out of the repos. Are people able to 
help?

Thanks everyone for getting on board (

On 6/2/17, 2:44 AM, "Blair Bethwaite" 
<blair.bethwa...@gmail.com<mailto:blair.bethwa...@gmail.com>> wrote:

Hi Alex,

Likewise for option 3. If I recall correctly from the summit session
that was also the main preference in the room?

On 2 June 2017 at 11:15, George Mihaiescu 
<lmihaie...@gmail.com<mailto:lmihaie...@gmail.com>> wrote:
> +1 for option 3
>
>
>
> On Jun 1, 2017, at 11:06, Alexandra Settle 
<a.set...@outlook.com<mailto:a.set...@outlook.com>> wrote:
>
> Hi everyone,
>
>
>
> I haven’t had any feedback regarding moving the Operations Guide to the
> OpenStack wiki. I’m not taking silence as compliance. I would really like 
to
> hear people’s opinions on this matter.
>
>
>
> To recap:
>
>
>
> Option one: Kill the Operations Guide completely and move the 
Administration
> Guide to project repos.
> Option two: Combine the Operations and Administration Guides (and then 
this
> will be moved into the project-specific repos)
> Option three: Move Operations Guide to OpenStack wiki (for ease of
> operator-specific maintainability) and move the Administration Guide to
> project repos.
>
>
>
> Personally, I think that option 3 is more realistic. The idea for the last
> option is that operators are maintaining operator-specific documentation 
and
> updating it as they go along and we’re not losing anything by combining or
> deleting. I don’t want to lose what we have by going with option 1, and I
> think option 2 is just a workaround without fixing the problem – we are 
not
> getting contributions to the project.
>
>
>
> Thoughts?
>
>
>
> Alex
>
>
>
> From: Alexandra Settle <a.set...@outlook.com<mailto:a.set...@outlook.com>>
> Date: Friday, May 19, 2017 at 1:38 PM
> To: Melvin Hillsman <mrhills...@gmail.com<mailto:mrhills...@gmail.com>>, 
OpenStack Operators
> 
<openstack-operat...@lists.openstack.org<mailto:openstack-operat...@lists.openstack.org>>
> Subject: Re: [Openstack-operators] Fwd: [openstack-dev] [openstack-doc]
> [dev] What's up doc? Summit recap edition
>
>
>
> Hi everyone,
>
>
>
> Adding to this, I would like to draw your attention to the last dot point 
of
> my email:
>
>
>
> “One of the key takeaways from the summit was the session that I joint
> moderated with Melvin Hillsman regarding the Operations and Administration
> Guides. You can find the etherpad with notes here:
> https://etherpad.openstack.org/p/admin-ops-guides  The session was really
> helpful – we were able to discuss with the operators present the current
> situation of the docu

Re: [Openstack-operators] [dev] [doc] Operations Guide future

[Alexandra Settle]

Blair – correct, it was the majority in the room. I just wanted to reach out 
and ensure that operators had a chance to voice opinions and see where we were 
going (

Sounds like option 3 is still the favorable direction. This is going to be a 
really big exercise, lifting the content out of the repos. Are people able to 
help?

Thanks everyone for getting on board (

On 6/2/17, 2:44 AM, "Blair Bethwaite" <blair.bethwa...@gmail.com> wrote:

Hi Alex,

Likewise for option 3. If I recall correctly from the summit session
that was also the main preference in the room?

On 2 June 2017 at 11:15, George Mihaiescu <lmihaie...@gmail.com> wrote:
> +1 for option 3
>
>
>
> On Jun 1, 2017, at 11:06, Alexandra Settle <a.set...@outlook.com> wrote:
>
> Hi everyone,
>
>
>
> I haven’t had any feedback regarding moving the Operations Guide to the
> OpenStack wiki. I’m not taking silence as compliance. I would really like 
to
> hear people’s opinions on this matter.
>
>
>
> To recap:
>
>
>
> Option one: Kill the Operations Guide completely and move the 
Administration
> Guide to project repos.
> Option two: Combine the Operations and Administration Guides (and then 
this
> will be moved into the project-specific repos)
> Option three: Move Operations Guide to OpenStack wiki (for ease of
> operator-specific maintainability) and move the Administration Guide to
> project repos.
>
>
>
> Personally, I think that option 3 is more realistic. The idea for the last
> option is that operators are maintaining operator-specific documentation 
and
> updating it as they go along and we’re not losing anything by combining or
> deleting. I don’t want to lose what we have by going with option 1, and I
> think option 2 is just a workaround without fixing the problem – we are 
not
> getting contributions to the project.
>
>
>
> Thoughts?
>
>
>
> Alex
>
>
>
> From: Alexandra Settle <a.set...@outlook.com>
> Date: Friday, May 19, 2017 at 1:38 PM
> To: Melvin Hillsman <mrhills...@gmail.com>, OpenStack Operators
> <openstack-operators@lists.openstack.org>
> Subject: Re: [Openstack-operators] Fwd: [openstack-dev] [openstack-doc]
> [dev] What's up doc? Summit recap edition
>
>
>
> Hi everyone,
>
>
>
> Adding to this, I would like to draw your attention to the last dot point 
of
> my email:
>
>
>
> “One of the key takeaways from the summit was the session that I joint
> moderated with Melvin Hillsman regarding the Operations and Administration
> Guides. You can find the etherpad with notes here:
> https://etherpad.openstack.org/p/admin-ops-guides  The session was really
> helpful – we were able to discuss with the operators present the current
> situation of the documentation team, and how they could help us maintain 
the
> two guides, aimed at the same audience. The operator’s present at the
> session agreed that the Administration Guide was important, and could be
> maintained upstream. However, they voted and agreed that the best course 
of
> action for the Operations Guide was for it to be pulled down and put into 
a
> wiki that the operators could manage themselves. We will be looking at
> actioning this item as soon as possible.”
>
>
>
> I would like to go ahead with this, but I would appreciate feedback from
> operators who were not able to attend the summit. In the etherpad you will
> see the three options that the operators in the room recommended as being
> viable, and the voted option being moving the Operations Guide out of
> docs.openstack.org into a wiki. The aim of this was to empower the
> operations community to take more control of the updates in an environment
> they are more familiar with (and available to others).
>
>
>
> What does everyone think of the proposed options? Questions? Other 
thoughts?
>
>
>
> Alex
>
>
>
> From: Melvin Hillsman <mrhills...@gmail.com>
> Date: Friday, May 19, 2017 at 1:30 PM
> To: OpenStack Operators <openstack-operators@lists.openstack.org>
> Subject: [Openstack-operators] Fwd: [openstack-dev] [openstack-doc] [dev]
> What's up doc? Summit recap edition
>
>
>
>
>
> -- Forwarded message --
> From: Alexandra Settle <a.set...@outlook.com>
> 

Re: [openstack-dev] [Openstack-operators] [dev] [doc] Operations Guide future

[Alexandra Settle]

Blair – correct, it was the majority in the room. I just wanted to reach out 
and ensure that operators had a chance to voice opinions and see where we were 
going (

Sounds like option 3 is still the favorable direction. This is going to be a 
really big exercise, lifting the content out of the repos. Are people able to 
help?

Thanks everyone for getting on board (

On 6/2/17, 2:44 AM, "Blair Bethwaite" <blair.bethwa...@gmail.com> wrote:

Hi Alex,

Likewise for option 3. If I recall correctly from the summit session
that was also the main preference in the room?

On 2 June 2017 at 11:15, George Mihaiescu <lmihaie...@gmail.com> wrote:
> +1 for option 3
>
>
>
> On Jun 1, 2017, at 11:06, Alexandra Settle <a.set...@outlook.com> wrote:
>
> Hi everyone,
>
>
>
> I haven’t had any feedback regarding moving the Operations Guide to the
> OpenStack wiki. I’m not taking silence as compliance. I would really like 
to
> hear people’s opinions on this matter.
>
>
>
> To recap:
>
>
>
> Option one: Kill the Operations Guide completely and move the 
Administration
> Guide to project repos.
> Option two: Combine the Operations and Administration Guides (and then 
this
> will be moved into the project-specific repos)
> Option three: Move Operations Guide to OpenStack wiki (for ease of
> operator-specific maintainability) and move the Administration Guide to
> project repos.
>
>
>
> Personally, I think that option 3 is more realistic. The idea for the last
> option is that operators are maintaining operator-specific documentation 
and
> updating it as they go along and we’re not losing anything by combining or
> deleting. I don’t want to lose what we have by going with option 1, and I
> think option 2 is just a workaround without fixing the problem – we are 
not
> getting contributions to the project.
>
>
>
> Thoughts?
>
>
>
> Alex
>
>
>
> From: Alexandra Settle <a.set...@outlook.com>
> Date: Friday, May 19, 2017 at 1:38 PM
> To: Melvin Hillsman <mrhills...@gmail.com>, OpenStack Operators
> <openstack-operat...@lists.openstack.org>
> Subject: Re: [Openstack-operators] Fwd: [openstack-dev] [openstack-doc]
> [dev] What's up doc? Summit recap edition
>
>
>
> Hi everyone,
>
>
>
> Adding to this, I would like to draw your attention to the last dot point 
of
> my email:
>
>
>
> “One of the key takeaways from the summit was the session that I joint
> moderated with Melvin Hillsman regarding the Operations and Administration
> Guides. You can find the etherpad with notes here:
> https://etherpad.openstack.org/p/admin-ops-guides  The session was really
> helpful – we were able to discuss with the operators present the current
> situation of the documentation team, and how they could help us maintain 
the
> two guides, aimed at the same audience. The operator’s present at the
> session agreed that the Administration Guide was important, and could be
> maintained upstream. However, they voted and agreed that the best course 
of
> action for the Operations Guide was for it to be pulled down and put into 
a
> wiki that the operators could manage themselves. We will be looking at
> actioning this item as soon as possible.”
>
>
>
> I would like to go ahead with this, but I would appreciate feedback from
> operators who were not able to attend the summit. In the etherpad you will
> see the three options that the operators in the room recommended as being
> viable, and the voted option being moving the Operations Guide out of
> docs.openstack.org into a wiki. The aim of this was to empower the
> operations community to take more control of the updates in an environment
> they are more familiar with (and available to others).
>
>
>
> What does everyone think of the proposed options? Questions? Other 
thoughts?
>
>
>
> Alex
>
>
>
> From: Melvin Hillsman <mrhills...@gmail.com>
> Date: Friday, May 19, 2017 at 1:30 PM
> To: OpenStack Operators <openstack-operat...@lists.openstack.org>
> Subject: [Openstack-operators] Fwd: [openstack-dev] [openstack-doc] [dev]
> What's up doc? Summit recap edition
>
>
>
>
>
> -- Forwarded message --
> From: Alexandra Settle <a.set...@outlook.com>
> 

[openstack-dev] [Openstack-operators] [dev] [doc] Operations Guide future

[Alexandra Settle]

Hi everyone,

I haven’t had any feedback regarding moving the Operations Guide to the 
OpenStack wiki. I’m not taking silence as compliance. I would really like to 
hear people’s opinions on this matter.

To recap:


  1.  Option one: Kill the Operations Guide completely and move the 
Administration Guide to project repos.
  2.  Option two: Combine the Operations and Administration Guides (and then 
this will be moved into the project-specific repos)
  3.  Option three: Move Operations Guide to OpenStack wiki (for ease of 
operator-specific maintainability) and move the Administration Guide to project 
repos.

Personally, I think that option 3 is more realistic. The idea for the last 
option is that operators are maintaining operator-specific documentation and 
updating it as they go along and we’re not losing anything by combining or 
deleting. I don’t want to lose what we have by going with option 1, and I think 
option 2 is just a workaround without fixing the problem – we are not getting 
contributions to the project.

Thoughts?

Alex

From: Alexandra Settle <a.set...@outlook.com>
Date: Friday, May 19, 2017 at 1:38 PM
To: Melvin Hillsman <mrhills...@gmail.com>, OpenStack Operators 
<openstack-operat...@lists.openstack.org>
Subject: Re: [Openstack-operators] Fwd: [openstack-dev] [openstack-doc] [dev] 
What's up doc? Summit recap edition

Hi everyone,

Adding to this, I would like to draw your attention to the last dot point of my 
email:

“One of the key takeaways from the summit was the session that I joint 
moderated with Melvin Hillsman regarding the Operations and Administration 
Guides. You can find the etherpad with notes here: 
https://etherpad.openstack.org/p/admin-ops-guides  The session was really 
helpful – we were able to discuss with the operators present the current 
situation of the documentation team, and how they could help us maintain the 
two guides, aimed at the same audience. The operator’s present at the session 
agreed that the Administration Guide was important, and could be maintained 
upstream. However, they voted and agreed that the best course of action for the 
Operations Guide was for it to be pulled down and put into a wiki that the 
operators could manage themselves. We will be looking at actioning this item as 
soon as possible.”

I would like to go ahead with this, but I would appreciate feedback from 
operators who were not able to attend the summit. In the etherpad you will see 
the three options that the operators in the room recommended as being viable, 
and the voted option being moving the Operations Guide out of 
docs.openstack.org into a wiki. The aim of this was to empower the operations 
community to take more control of the updates in an environment they are more 
familiar with (and available to others).

What does everyone think of the proposed options? Questions? Other thoughts?

Alex

From: Melvin Hillsman <mrhills...@gmail.com>
Date: Friday, May 19, 2017 at 1:30 PM
To: OpenStack Operators <openstack-operat...@lists.openstack.org>
Subject: [Openstack-operators] Fwd: [openstack-dev] [openstack-doc] [dev] 
What's up doc? Summit recap edition


-- Forwarded message ------
From: Alexandra Settle <a.set...@outlook.com<mailto:a.set...@outlook.com>>
Date: Fri, May 19, 2017 at 6:12 AM
Subject: [openstack-dev] [openstack-doc] [dev] What's up doc? Summit recap 
edition
To: 
"openstack-d...@lists.openstack.org<mailto:openstack-d...@lists.openstack.org>" 
<openstack-d...@lists.openstack.org<mailto:openstack-d...@lists.openstack.org>>
Cc: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>


Hi everyone,

The OpenStack manuals project had a really productive week at the OpenStack 
summit in Boston. You can find a list of all the etherpads and attendees here: 
https://etherpad.openstack.org/p/docs-summit

As we all know, we are rapidly losing key contributors and core reviewers. We 
are not alone, this is happening across the board. It is making things harder, 
but not impossible. Since our inception in 2010, we’ve been climbing higher and 
higher trying to achieve the best documentation we could, and uphold our high 
standards. This is something to be incredibly proud of. However, we now need to 
take a step back and realise that the amount of work we are attempting to 
maintain is now out of reach for the team size that we have. At the moment we 
have 13 cores, of which none are full time contributors or reviewers. This 
includes myself.

That being said! I have spent the last week at the summit talking to some of 
our leaders, including Doug Hellmann (cc’d), Jonathan Bryce and Mike Perez 
regarding the future of the project. Between myself and other community 
members, we have been drafting plans and coming up with a new direction that 
will hopefully be sustainable in th

[openstack-dev] [doc] Docs team meeting

[Alexandra Settle]

Hey everyone,

The docs meeting will continue today in #openstack-meeting as scheduled 
(Thursday at 16:00 UTC). For more details, and the agenda, see the meeting 
page: - 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting

The meeting chair will be me! Hope you can all make it ☺

Thanks,

Alex

__
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] Strawman Queens PTG week slicing

[Alexandra Settle]

On 5/24/17, 4:34 PM, "Doug Hellmann"  wrote:

Excerpts from Thierry Carrez's message of 2017-05-24 16:44:44 +0200:
> Doug Hellmann wrote:
> > Two questions about theme-based initiatives:
> > 
> > I would like to have a discussion about the work to stop syncing
> > requirements and to see if we can make progress on the implementation
> > while we have the right people together. That seems like a topic
> > for Monday or Tuesday. Would I reserve one of the "last-minute WG"
> > rooms or extra rooms (it doesn't feel very last-minute if I know
> > about it now)?
> 
> We have some flexibility there, depending on how much time we need. If
> it's an hour or two, I would go and book one of the "reservable rooms".
> If it's a day or two, I would assign one of the rooms reserved for
> upcoming workgroups/informal teams. "Last-minute" is confusing (just
> changed it on the spreadsheet), those rooms are more to cater for needs
> that are not represented in formal workgroups today.

Ideally I'd like some time to actually hack on the tools. If that's not
possible, an hour or two to work out a detailed plan would be enough.

> > I don't see a time on here for the Docs team to work together on
> > the major initiative they have going to change how publishing works.
> > I didn't have the impression that we could anticipate that work
> > being completed this cycle. Is the "helproom" going to be enough,
> > or do we need a separate session for that, too?
> 
> Again, we should be pretty flexible on that. We can reuse the doc
> helproom, or we can say that the doc helproom is only on one day and the
> other day is dedicated to making the doc publishing work. And if the doc
> refactoring ends up being a release goal, it could use a release goal
> room instead.

Let's see what Alex thinks.

To be honest, I don’t want to assume we’re going to need all this space when 
potentially, we may not. Attendance for docs and I18N is low, but that was 
greatly increased last PTG due to the ability to have remote attendees. But 
that’s not what’s being discussed here…

I would appreciate the room the grow. I would like to find out, first and 
foremost, what is our action plan for docs. This is going to be a monstrous 
effort, and we’re quite possibly going to need space at events like the PTG to 
hack away and get things going.

So, I know that didn’t overly answer the question right now, but I hope it 
gives some perspective as to why I’m holding back a bit here. The strawman is 
appreciated, thanks Thierry. The small room for docs seems feasible. I just 
hope there will be the ability to spill over and open up the rest of the week 
to hack.

> All in all, the idea is to show that on Mon-Tue we have a number of
> rooms set apart to cover for any inter-project need we may have (already
> identified or not). The room allocation is actually much tighter on
> Wed-Thu :)

OK.

Doug

__
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 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] [doc][ptls][all] Documentation publishing future

[Alexandra Settle]

 
> I prefer option 1, which should be obvious from Anne's reference to my 
exiting work to enable that. Option 2 seems yucky (to me) because it adds yet 
another docs tree and sphinx config to projects, and thus is counter to my hope 
that we'll have one single docs tree per repo.
> 
> I disagree with option 3. It seems to be a way to organize the content 
simply to wall-off access to parts of it; e.g. docs people can't land stuff in 
the code part and potentially some code people can't land stuff in the docs 
part. However, docs should always land with the code that changed them. 
Separating the docs into a separate repo removes the ability to land docs with 
code.
> 
> I really like the plan Alex has described about docs team representatives 
participating more directly with the projects. If those 

+1 for option #1. I strongly believe the best way to keep all a
project's docs up to date with ongoing code changes is to make those
changes to contain in-repo docs updates as well. And here developers
should use the chance and benefit from rich experience of docs team
representatives, as no one else knows more about writing technical
documentation best practices!

I must admit, I’m quite surprised by everyone’s preference for option 1. 
Although not disappointed. I’m interested to see where and how this goes!

Pros:
* Code review shall cover docs changes and code changes at once, which
is great

+1000 to this. This is a lot of what I’m pushing for. Teams that have already 
implemented our project-specific installation guides say this as their #1 
feedback.
I’m hoping we can get more positive responses for this too.

* Docs team contributors may choose to start acting as representatives,
which is become mentors and/or "docs guarding sentries" rather than
technical writers. This offloads writing to projects' devs and perhaps
resolves the issue as mentoring/reviewing requires less time, or more haha.
* Developers shall become technical docs writers as well, that's a
really exciting perspective to advance and know more about your
projects! And, who knows, this as well may end up bringing more man
power to the docs team, after all.

Cons:
there are none, let's be optimistic! Developers love document changes
for code, we all know that.

Haha amazing! No cons! I guess my only concern is that this going to be a *lot* 
of work, and it can’t just fall on the doc team. We will have to move all the 
documentation to the appropriate repos, and build this infrastructure. As 
previously noted, there has been a dip in contributions to dev and doc, and 
it’s been hard to get people to work as CPLs to the doc team.

Do we think it is possible to make this a goal for the cycle across the board, 
and ensure we have this completed by $RELEASE?

representatives should be able to add a +2 or -2 to project patches,
then make those representatives core reviewers for the respective
project. Like every other core reviewer, they should be trusted to use
good judgement for choosing what to review and what score to give it.

So, I’ve been a docs core for the OpenStack-Ansible project for some time now 
and this works really well within our structure. I do not merge anything unless 
it has a dev +2 before I come along (unless it is a trivial doc-only 
spelling/grammar change). I think there is a lot of community fear that if you 
give a writer core status on a project, that they’re just going to run wild and 
pass things they don’t understand. I can’t speak for everyone, but I can say 
that this has been working really well in the OSA community. We now have 3 doc 
cores. 



__
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] Onboarding rooms postmortem, what did you do, what worked, lessons learned

[Alexandra Settle]

Project: Documentation and I18N
Attendees: 3-5 (maybe?)
Etherpad: https://etherpad.openstack.org/p/doc-onboarding 

What we did:

We ran the session informally based off whoever was there. Due to the small 
attendance, we just ran through how the project works (docs like code and all 
that).
Discussed the docs ML, IRC, and how best to get started (find some low hanging 
fruit). Ian also took the group through the translation team process, and gave 
a little demo on how the Zanata translation tool was used.

We gave everyone back 30 minutes of their lives.

On 5/19/17, 2:22 PM, "Sean Dague"  wrote:

This is a thread for anyone that participated in the onboarding rooms,
on either the presenter or audience side. Because we all went into this
creating things from whole cloth, I'm sure there are lots of lessons
learned.

If you ran a room, please post the project, what you did in the room,
what you think worked, what you would have done differently. If you
attended a room you didn't run, please provide feedback about which one
it was, and what you thought worked / didn't work from the other side of
the table.

Hopefully we can consolidate some of that feedback for best practices
going forward.

-Sean

-- 
Sean Dague
http://dague.net

__
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 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] [doc][ptls][all] Documentation publishing future

[Alexandra Settle]

Hi everyone,

The documentation team are rapidly losing key contributors and core reviewers. 
We are not alone, this is happening across the board. It is making things 
harder, but not impossible.
Since our inception in 2010, we’ve been climbing higher and higher trying to 
achieve the best documentation we could, and uphold our high standards. This is 
something to be incredibly proud of.

However, we now need to take a step back and realise that the amount of work we 
are attempting to maintain is now out of reach for the team size that we have. 
At the moment we have 13 cores, of whom none are full time contributors or 
reviewers. This includes myself.

Until this point, the documentation team has owned several manuals that include 
content related to multiple projects, including an installation guide, admin 
guide, configuration guide, networking guide, and security guide. Because the 
team no longer has the resources to own that content, we want to invert the 
relationship between the doc team and project teams, so that we become liaisons 
to help with maintenance instead of asking for project teams to provide 
liaisons to help with content. As a part of that change, we plan to move the 
existing content out of the central manuals repository, into repositories owned 
by the appropriate project teams. Project teams will then own the content and 
the documentation team will assist by managing the build tools, helping with 
writing guidelines and style, but not writing the bulk of the text.

We currently have the infrastructure set up to empower project teams to manage 
their own documentation in their own tree, and many do. As part of this change, 
the rest of the existing content from the install guide and admin guide will 
also move into project-owned repositories. We have a few options for how to 
implement the move, and that's where we need feedback now.

1. We could combine all of the documentation builds, so that each project has a 
single doc/source directory that includes developer, contributor, and user 
documentation. This option would reduce the number of build jobs we have to 
run, and cut down on the number of separate sphinx configurations in each 
repository. It would completely change the way we publish the results, though, 
and we would need to set up redirects from all of the existing locations to the 
new locations and move all of the existing documentation under the new 
structure.

2. We could retain the existing trees for developer and API docs, and add a new 
one for "user" documentation. The installation guide, configuration guide, and 
admin guide would move here for all projects. Neutron's user documentation 
would include the current networking guide as well. This option would add 1 new 
build to each repository, but would allow us to easily roll out the change with 
less disruption in the way the site is organized and published, so there would 
be less work in the short term.

3. We could do option 2, but use a separate repository for the new 
user-oriented documentation. This would allow project teams to delegate 
management of the documentation to a separate review project-sub-team, but 
would complicate the process of landing code and documentation updates together 
so that the docs are always up to date.

Personally, I think option 2 or 3 are more realistic, for now. It does mean 
that an extra build would have to be maintained, but it retains that key 
differentiator between what is user and developer documentation and involves 
fewer changes to existing published contents and build jobs. I definitely think 
option 1 is feasible, and would be happy to make it work if the community 
prefers this. We could also view option 1 as the longer-term goal, and option 2 
as an incremental step toward it (option 3 would make option 1 more complicated 
to achieve).

What does everyone think of the proposed options? Questions? Other thoughts?

Cheers,

Alex


__
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-doc] [dev] What's up doc? Summit recap edition

[Alexandra Settle]

Hi everyone,

The OpenStack manuals project had a really productive week at the OpenStack 
summit in Boston. You can find a list of all the etherpads and attendees here: 
https://etherpad.openstack.org/p/docs-summit

As we all know, we are rapidly losing key contributors and core reviewers. We 
are not alone, this is happening across the board. It is making things harder, 
but not impossible. Since our inception in 2010, we’ve been climbing higher and 
higher trying to achieve the best documentation we could, and uphold our high 
standards. This is something to be incredibly proud of. However, we now need to 
take a step back and realise that the amount of work we are attempting to 
maintain is now out of reach for the team size that we have. At the moment we 
have 13 cores, of which none are full time contributors or reviewers. This 
includes myself.

That being said! I have spent the last week at the summit talking to some of 
our leaders, including Doug Hellmann (cc’d), Jonathan Bryce and Mike Perez 
regarding the future of the project. Between myself and other community 
members, we have been drafting plans and coming up with a new direction that 
will hopefully be sustainable in the long-term.

I am interested to hear your thoughts. I want to make sure that everyone feels 
that we’re headed in the right direction first and foremost. All of these 
action items are documented in this WIP etherpad: 
https://etherpad.openstack.org/p/doc-planning

Some further highlights from the event…


· The documentation team was represented by myself, Olga, and Alex 
Adamov for the Project Update: Documentation on the Monday. If you’d like to 
catch up with what we talked about, the video is available online now: 
https://www.youtube.com/watch?v=jcfbKxbpRvc The translation team PTL, Ian Choi, 
also had a session about getting more involved with the I18N team. You can view 
that video here: https://www.youtube.com/watch?v=ybFI4nez_Z8


· Ian and I also hosted the joint I18N and documentation onboarding 
session. We were visited by some friendly faces, and some new ones. Between Ian 
and myself, we discussed the documentation and translation workflows, and how 
to get involved (the mailing list, IRC channel, etc). Which was lots of fun :) 
we’d love to see more people there in the future, hopefully we’ll slowly get 
there!


· This week I was focusing heavily on making the community aware that 
the documentation team was struggling to maintain contributors, but continuing 
with the same amount of work. This was a heavy conversation to be having, but 
it posed some really interesting questions to key leaders, and hopefully raised 
appropriate concerns. Ildiko and I hosted “OpenStack documentation: The future 
depends on all of us”. This was a really interesting session. I was able to 
pose to the group of attendees that the documentation team was struggling to 
maintain contributions. Major Hayden was kind enough to take notes during the 
session, you can find those here: https://etherpad.openstack.org/p/doc-future  
The project teams that came and represented their groups were interested in 
discussing the project-specific documentation (is living in the project’s repo 
tree the best place?) and voiced concerns I had otherwise not heard before. I 
recommend reading the notes to get a better idea :)


· Kendall Nelson and Ildiko also hosted a session on the OpenStack 
Upstream Institute highlights. I recommend watching the video which is now live 
and available here: 
https://www.openstack.org/videos/boston-2017/openstack-upstream-institute-highlights


· One of the key takeaways from the summit was the session that I joint 
moderated with Melvin Hillsman regarding the Operations and Administration 
Guides. You can find the etherpad with notes here: 
https://etherpad.openstack.org/p/admin-ops-guides  The session was really 
helpful – we were able to discuss with the operators present the current 
situation of the documentation team, and how they could help us maintain the 
two guides, aimed at the same audience. The operator’s present at the session 
agreed that the Administration Guide was important, and could be maintained 
upstream. However, they voted and agreed that the best course of action for the 
Operations Guide was for it to be pulled down and put into a wiki that the 
operators could manage themselves. We will be looking at actioning this item as 
soon as possible.

These action items will free up the documentation team to become gate keepers 
and reviewers of documentation. Our key focus as a team will be on the tooling 
for the docs.openstack.org site (including the API docs).

I’m really interested to hear everyone’s thoughts going forward – this is not 
set in stone. We need to change our strategy, and now is the time. If you’d 
rather reach out and discuss this personally, asettle on IRC is always the best 
place to find me.

Thanks,

Alex

[openstack-dev] [doc] Docs team meeting

[Alexandra Settle]

Hey everyone,

The docs meeting will continue today in #openstack-meeting as scheduled 
(Thursday at 16:00 UTC). For more details, and the agenda, see the meeting 
page: - 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting

The meeting chair will be me! Hope you can all make the new time ☺

Thanks,

Alex

__
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] Consolidating web themes

[Alexandra Settle]

This all sounds really great ☺ thanks for taking it on board, Anne!

No questions at present ☺ looking forward to seeing the new design!

From: Anne Gentle 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, May 15, 2017 at 2:33 PM
To: "openstack-d...@lists.openstack.org" , 
OpenStack Development Mailing List 
Subject: [openstack-dev] [all] Consolidating web themes

Hi all,

I wanted to make you all aware of some consolidation efforts I'll be working on 
this release. You may have noticed a new logo for OpenStack, and perhaps you 
saw the update to the web design and headers on 
docs.openstack.org as well.

To continue these efforts, I'll also be working on having all docs pages use 
one theme, the openstackdocstheme, that has these latest updates. Currently we 
are using version 1.8.0, and I'll do more releases as we complete the UI 
consolidation.

I did an analysis to compare oslosphinx to openstackdocstheme, and I wanted to 
let this group know about the upcoming changes so you can keep an eye out for 
reviews. This effort will take a while, and I'd welcome help, of course.

There are a few UI items that I don't plan port from oslosphinx to 
openstackdocstheme:

Quick search form in bottom of left-hand navigation bar (though I'd welcome a 
way to unify that UI and UX across the themes).
Previous topic and Next topic shown in left-hand navigation bar (these are 
available in the openstackdocstheme in a different location).
Return to project home page link in left-hand navigation bar. (also would 
welcome a design that fits well in the openstackdocstheme left-hand nav)
Customized list of links in header. For example, the page 
athttps://docs.openstack.org/infra/system-config/
 contains a custom header.
When a landing page like https://docs.openstack.org/infra/ uses oslosphinx, the 
page should be redesigned with the new theme in mind.

I welcome input on these changes, as I'm sure I haven't caught every scenario, 
and this is my first wider communication about the theme changes. The spec for 
this work is detailed here: 
http://specs.openstack.org/openstack/docs-specs/specs/pike/consolidating-themes.html

Let me know what I've missed, what you cannot live without, and please reach 
out if you'd like to help.

Thanks,
Anne

--
Technical Product Manager, Cisco Metacloud
annegen...@justwriteclick.com
@annegentle


__
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-doc] [dev] Docs team meeting today

[Alexandra Settle]

Hey everyone,

The docs meeting will continue today in #openstack-meeting-alt as scheduled 
(Thursday at 21:00 UTC). For more details, and the agenda, see the meeting 
page: - 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting

Last meeting before the summit ☺

Thanks,

Alex

__
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] [ptls][doc] Doc CPL update

[Alexandra Settle]

Hi everyone,

In light of the unfortunate news with OSIC, the documentation team has been hit 
pretty hard. As a result, we need more than ever for our documentation liaisons 
to step up and help us out.

However, looking at this list[1] it is unfortunately clear that a lot of people 
listed are a part of the OSIC work.

If your name is on this list, and you are unable to continue your role as 
documentation liaison for Pike, please contact the PTL of your project to 
arrange for there to be a new representative.

PTLs – could you please help us out and make sure there is a new assigned 
liaison to the role so that we don’t have any issues when it comes to release 
time.

Thank you to everyone for your cooperation during this difficult time.

Alex

[1] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Documentation
__
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-docs] [tripleo] Creating official Deployment guide for TripleO

[Alexandra Settle]

On 4/25/17, 3:40 AM, "Emilien Macchi" <emil...@redhat.com> wrote:

On Fri, Mar 24, 2017 at 11:35 AM, Emilien Macchi <emil...@redhat.com> wrote:
> On Wed, Mar 22, 2017 at 2:25 PM, Emilien Macchi <emil...@redhat.com> 
wrote:
>> Thanks to these who volunteered, it's appreciated.
>>
>> I'm going to kick-off initial work here:
>>
>> 1. Create CI job that build deploy-guide on tripleo-docs repo (when
>> required) - https://review.openstack.org/448740
>
> Step 1 done.
>
>> 2. In tripleo-docs, modify tox.ini and create initial structure for
>> deployment guide (I'll kick it off once we have the CI job)
>
> Step 2, done and ready for review: 
https://review.openstack.org/#/c/449684/
>
>> 3. Start moving deployment related bits from doc/source/ to
>> deploy-guide/source/ (I'll need your help for this step). We also need
>> to include Alexendra and her team to make sure we're moving the right
>> bits.
>
> Keep posted, that will be the next step.

So this step is ready now, since we have the directory in place:
https://github.com/openstack/tripleo-docs/tree/master/deploy-guide/source

I would need some help and feedback on the bits that we're going to move:

* what chapters do we want to move? (related to Deployment)
* how do we handle redirection from old URLs (to keep web search valid
until it's indexed again)

Redirection can be handled in multiple ways. You can look at doing what the 
kolla team did and not move it at all, but rather, use ‘includes’. For example: 
https://github.com/openstack/kolla-ansible/blob/master/deploy-guide/source/quickstart.rst
 

However, I would personally not recommend this action. Simply because if you 
are planning to have a deployment guide, I would recommend you commit to this 
action so there is one source of truth when people are looking for the guide 
itself. The OpenStack-Ansible team ‘created’ a new deployment guide, and moved 
most of their install content across. The team then linked to the Deployment 
Guide on their docs.o.o/dev page. You can see that here: 
https://docs.openstack.org/developer/openstack-ansible/ 

It is entirely up to the TripleO team what they intend to do here. But there 
are options, basically. There will be broken links without, we recommend 
implementing this method: 
https://docs.openstack.org/contributor-guide/project-deploy-guide.html#deployment-guide-and-installation-guide-links
 

>> 4. Expose TripleO deployment guide to deployment guides front page and
>> drink a gin tonic.

I haven't figured yet how to expose the guide to the frontpage but
maybe Alexandra or someone from Docs team can help. It's unclear to me
how to handle that since we have a branchless doc repo, so we would
likely have a versionless documentation link (and handle
version-specific bits inline).

I don’t think the versioning should matter so much here. We will not version 
your guides, and if you do not, there is no problem. To ‘publish’ the guides, 
you need to add your deployment guide to our www/project-deploy-guide/draft 
file. See here: 
https://github.com/openstack/openstack-manuals/blob/master/www/project-deploy-guide/draft/index.html
 Also for Ocata: 
https://github.com/openstack/openstack-manuals/blob/master/www/project-deploy-guide/ocata/index.html
 

Again, any help is welcome. It would be great to achieve this goal in
Pike: having an official TripleO deployment guide among other
deployment tools guides.

Hopefully this helps a bit ( ping me if you have any questions/concerns.

Thanks,

>> I'll give an update when 2. is done so we can start working on the 
content.
>>
>> Thanks,
>>
>> On Wed, Mar 22, 2017 at 8:22 AM, Flavio Percoco <fla...@redhat.com> 
wrote:
>>> On 20/03/17 08:01 -0400, Emilien Macchi wrote:
>>>>
>>>> I proposed a blueprint to track the work done:
>>>>
>>>> https://blueprints.launchpad.net/tripleo/+spec/tripleo-deploy-guide
>>>> Target: pike-3
>>>>
>>>> Volunteers to work on it with me, please let me know.
>>>
>>>
>>> It'd be awesome to have some input from the containers squad on this 
effort
>>> too.
>>> Put me on the list for now while we find another volunteer in the 
containers
>>> DFG.
>>>
>>> Flavio
>>>
>>>> Thanks,
>>>>
>>>> On Tue, Mar 14, 2017 at 7:00 AM, Alexandra Settle 
<a.set...@outlook.com>
>>>> wrote:
>>>>>
>>>>> Hey

Re: [openstack-dev] [openstack-doc] [dev] Docs team meeting tomorrow

[Alexandra Settle]

Hey everyone,

Just to clarify – that is Thursday the 20th of April, 2100 UTC.

Apologies for any confusion – just attempting to get ahead of the game and 
forgot to remove “today”.

See you there,

Alex

From: Alexandra Settle <a.set...@outlook.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, April 19, 2017 at 11:45 AM
To: "openstack-d...@lists.openstack.org" <openstack-d...@lists.openstack.org>
Cc: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [openstack-doc] [dev] Docs team meeting tomorrow

Hey everyone,

The docs meeting will continue today in #openstack-meeting-alt as scheduled 
(Thursday at 21:00 UTC). For more details, and the agenda, see the meeting 
page: - 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting

Specialty team leads – if you are unable to attend the meeting, please send me 
your team reports to include in the doc newsletter.

Doc team – I highly recommend you attend. In light of the OSIC news, we are 
heavily affected and attendance would be appreciated to discuss future actions.

Thanks,

Alex

__
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-doc] [dev] Docs team meeting tomorrow

[Alexandra Settle]

Hey everyone,

The docs meeting will continue today in #openstack-meeting-alt as scheduled 
(Thursday at 21:00 UTC). For more details, and the agenda, see the meeting 
page: - 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting

Specialty team leads – if you are unable to attend the meeting, please send me 
your team reports to include in the doc newsletter.

Doc team – I highly recommend you attend. In light of the OSIC news, we are 
heavily affected and attendance would be appreciated to discuss future actions.

Thanks,

Alex

__
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-docs] [OpenStack-I18n] [dev] What's up, doc?

[Alexandra Settle]

Team,

This week I have still been working on drafting a governance tag for our guides 
called "docs:follows-policy". I have been working with Doug Hellmann 
(dhellmann) in the last week to change to draft dramatically, so it would be 
good for doc people and doc liaisons to review. We are trying to make this a 
broader tag, so it can be applied for other guides too. To review: 
https://review.openstack.org/#/c/445536/ I am also in the process of 
documenting guidelines in our Contribution Guide - which would also benefit 
from doc reviews:  https://review.openstack.org/#/c/453642/

Would like to call out and thank John Davidge for his awesome work with the 
Networking Guide and neutron-related patches. He's been providing valuable 
guidance, and reviews, and it has been greatly appreciated by myself and the 
team.

Lana Brindley has done an awesome job for the last two weeks in keeping our bug 
list under control. We are down to an amazing 102 bugs in queue, and 82 bugs 
closed this cycle already!
Next week, I will be looking after the bug triage liaison role!
If you're sitting there thinking "bugs are for me, I really love triaging 
bugs!" well, you're in luck! We have one spot open for the rest of the cycle 
(14 Aug - 28 Aug): 
https://wiki.openstack.org/wiki/Documentation/SpecialityTeams#Bug_Triage_Team

== The Road to the Summit in Boston ==

Keep an eye out for the docs and I18n have a project onboarding room at the 
summit. Melvin Hillsman (mrhillsman) of the User Committee submitted a forum 
topic for the Ops Guide to get operator feedback.
David Flanders from the Foundation has also proposed a forum topic for 
developer.openstack.org (which currently houses our API, SDK, and other dev 
stuff). We'll be discussing major changes to that and would like to see some 
feedback from people here. Any questions on that, shoot it my way. My main 
objective for this forum topic is to reduce our current technical debt that 
lives on this site.
For more information on forum topics: https://wiki.openstack.org/wiki/Forum
Schedule has been released: 
https://www.openstack.org/summit/boston-2017/summit-schedul

== Specialty Team Reports ==

* API - Anne Gentle: API versioning in relation to release versioning is 
currently manually compiled for the 40-ish API services, so ideas on how to 
automate and surface that info welcomed. More info: 
http://lists.openstack.org/pipermail/openstack-dev/2017-March/114690.html
* Configuration Reference and CLI Reference - Tomoyuki Kato: N/A
* High Availability Guide - Ianeta Hutchinson: We are continuing to collaborate 
with OS DevOps team. See the tag ha-guide-draft for bugs opened to fill content 
for the new guide.
* Hypervisor Tuning Guide - Blair Bethwaite: N/A
* Installation guides - Lana Brindley: We have now branched, so please remember 
to backport if you have edits to the Ocata guide now. Big thanks to all the 
testers who have been working hard over the past month or two (that Nova cells 
bug was *tough*!), and to Brian and Mariia for doing the heavy lifting. Noticed 
a bunch links to draft versions of the guide in Newton/Ocata branches, 
backports for that have been merged, and the Contributor Guide updated so we 
don't miss it in the future (https://docs.openstack.org/contributor 
guide/release/taskdetail.html#update-links-in-all-books).
* Networking Guide - John Davidge: More patches landed in the last couple of 
weeks dealing with the move to OSC, and more are still in flight. Progress also 
continues on RFC 5737 compliance. Thanks to all contributors for their work.
* Operations and Architecture Design guides - Darren Chan: Arch Guide: edited 
architecture considerations content and cleaned up the index page structure 
which was applied across OS manuals. Some ops-related content was moved to the 
Ops Guide. Our current focus is improving the storage design content and 
networking design content.
* Training Guides - Matjaz Pancur: N/A
* Training labs - Roger Luethi: We released the Ocata version of training-labs 
this week.
* User guides - Joseph Robinson: For the user guides - the spec on migrating 
the Admin Guide content this week moved closer to merging. I started preparing 
the work items for action on the User Guides tasks wiki page.
* Theme and Tools - Brian Moss: Anne has a spec up for theme consolidation, 
please check it out: https://review.openstack.org/#/c/454346/, Brian has fixed 
up the sitemap tool tests, reviews welcome: 
https://review.openstack.org/#/c/453976/. 41 open bugs, 13 closed in Pike

== Doc team meeting ==
Our next meeting will be on Thursday, 20 April at 2100 UTC in 
#openstack-meeting-alt.
For more meeting details, including minutes and the agenda: 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting
The meeting chair will be me!

Big thanks to Joseph for stepping up in the last 2 meetings and hosting in my 
absence! Really appreciated it :)

--
Have a great weekend :)
Alex

IRC: asettle
Twitter: dewsday

[openstack-dev] [openstack-doc] Docs team meeting

[Alexandra Settle]

Hey everyone,

The docs meeting will continue today in #openstack-meeting-alt as scheduled 
(Thursday at 21:00 UTC). For more details, and the agenda, see the meeting 
page: - 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting

The meeting with be hosted by Joseph Robinson, as I have some personal business 
to attend to this evening.

Specialty team leads – if you are unable to attend the meeting, please send me 
your team reports to include in the doc newsletter.

Thanks,

Alex
__
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-docs] Project Navigator Updates - Feedback Request

[Alexandra Settle]

On 3/28/17, 2:10 PM, "Jeremy Stanley" <fu...@yuggoth.org> wrote:

On 2017-03-28 12:51:44 + (+0000), Alexandra Settle wrote:
[...]
> Is it possible to get docs and I18N represented here? I know we
> don’t make up a ‘project’ of OpenStack, but we play an important
> part, and I would be nice to be represented. Especially seeing as
> I18n work on translating a lot of the dev components as well,
> making OpenStack available to more countries across the world.
[...]

My understanding is that the Project Navigator is aimed at helping
operators/deployers figure out what software they should be
downloading and running, not as a place to celebrate the awesome
work in which all our official teams participate. If we add separate
sections for Docs and I18n, then do we also include Release
Management, Stable Branch Maintenance, Quality Assurance,
Requirements, et cetera? At what point does it just become yet
another copy of our governance site with different theming?
-- 
Jeremy Stanley

Makes sense, that’s good perspective :)

__
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 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 Navigator Updates - Feedback Request

[Alexandra Settle]

Hey Lauren,

It looks great with the new mascots :)

Is it possible to get docs and I18N represented here? I know we don’t make up a 
‘project’ of OpenStack, but we play an important part, and I would be nice to 
be represented. Especially seeing as I18n work on translating a lot of the dev 
components as well, making OpenStack available to more countries across the 
world.

Maybe we could go under a simple banner “Documentation & Translation”?

I know we are technically visible here: 
https://www.openstack.org/software/start/ but we’re kind of shunted down the 
line.

Also, OpenStack-Ansible should be edited with the hyphen if possible :)

Thanks,

Alex

From: Lauren Sell 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, March 24, 2017 at 4:57 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] Project Navigator Updates - Feedback Request

Hi everyone,

We’ve been talking for some time about updating the project navigator, and we 
have a draft ready to share for community feedback before we launch and 
publicize it. One of the big goals coming out of the joint TC/UC/Board meeting 
a few weeks ago[1] was to help better communicate ‘what is openstack?’ and this 
is one step in that direction.

A few goals in mind for the redesign:
- Represent all official, user-facing projects and deployment services in the 
navigator
- Better categorize the projects by function in a way that makes sense to 
prospective users (this may evolve over time as we work on mapping the 
OpenStack landscape)
- Help users understand which projects are mature and stable vs emerging
- Highlight popular project sets and sample configurations based on different 
use cases to help users get started

For a bit of context, we’re working to give each OpenStack official project a 
stronger platform as we think of OpenStack as a framework of composable 
infrastructure services that can be used individually or together as a powerful 
system. This includes the project mascots (so we in effect have logos to 
promote each component separately), updates to the project navigator, and 
bringing back the “project updates” track at the Summit to give each PTL/core 
team a chance to provide an update on their project roadmap (to be recorded and 
promoted in the project navigator among other places!).

We want your feedback on the project navigator v2 before it launches. Please 
take a look at the current version on the staging site and provide feedback on 
this thread.

http://devbranch.openstack.org/software/project-navigator/

Please review the overall concept and the data and description for your project 
specifically. The data is primarily pulled from TC tags[2] and Ops tags[3]. 
You’ll notice some projects have more information available than others for 
various reasons. That’s one reason we decided to downplay the maturity metric 
for now and the data on some pages is hidden. If you think your project is 
missing data, please check out the repositories and submit changes or again 
respond to this thread.

Also know this will continue to evolve and we are open to feedback. As I 
mentioned, a team that formed at the joint strategy session a few weeks ago is 
tackling how we map OpenStack projects, which may be reflected in the 
categories. And I suspect we’ll continue to build out additional tags and 
better data sources to be incorporated.

Thanks for your feedback and help.

Best,
Lauren

[1] 
http://superuser.openstack.org/articles/community-leadership-charts-course-openstack/
[2] https://governance.openstack.org/tc/reference/tags/
[3] https://wiki.openstack.org/wiki/Operations/Tags

__
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-docs] [dev] What's up, doc?

[Alexandra Settle]

Team team team team team,

Well the last month has just FLOWN by since the PTG. We've got plenty going on 
in the doc team...

This week I have been helping out the security team with the Security Guide. 
We've been working on some cursory edits, and removal of content. A few patches 
have already made it through - thanks to the OSIC security team for tackling 
some of the outstanding bugs. There'll be more edits coming from me in the next 
few weeks. To see our planning: https://etherpad.openstack.org/p/sec-guide-pike
I am also in the process of drafting a governance tag for our install guides. 
Would be great for everyone to review and understand what the process will 
involve: https://review.openstack.org/#/c/445536/

Shoutout and big thanks to Brian Moss and the nova team who worked together 
tirelessly to document Nova v2 Cells and Placement API - which was a massive 
blocker for our Installation Guide.

Also, thank you to our Ocata release managers, Maria Zlatkova and Brian Moss 
for cutting the branch! Pike is well and truly underway now.

Ianeta Hutchinson has done an awesome job for the last two weeks in keeping our 
bug list under control. We are down to an amazing 104 bugs in queue, and 59 
bugs closed this cycle already! Next week, we have Lana who will be looking 
after the bug triage liaison role! If you're sitting there thinking "bugs are 
for me, I really love triaging bugs!" well, you're in luck! We have a few spots 
open for the rest of the cycle: 
https://wiki.openstack.org/wiki/Documentation/SpecialityTeams#Bug_Triage_Team

== The Road to the Summit in Boston ==

* Schedule has been released: 
https://www.openstack.org/summit/boston-2017/summit-schedule/
* Docs and I18n have a project onboarding room at the summit, keep an eye out 
on the dev ML for more information. Kendall will inform us when the time comes. 
Anyone around to help me with that? 
http://lists.openstack.org/pipermail/openstack-dev/2017-March/114149.html
* Docs project update will be delivered by me (asettle) on Mon 8, 
3:40pm-4:20pm. 
https://www.openstack.org/summit/boston-2017/summit-schedule/global-search?t=Alexandra+Settle

== Specialty Team Reports ==

* API - Anne Gentle: There's still a lot of discussion on 
https://review.openstack.org/#/c/421846/ which is about API change guidelines. 
Take a look and join in on the review. Also on the openstack-dev list, there's 
a thread about the future of the app catalog, which is relevant to the app 
developer audience so I include it here: 
http://lists.openstack.org/pipermail/openstack 
dev/2017-March/113362.html<http://lists.openstack.org/pipermail/openstack%20dev/2017-March/113362.html>
 Also related to the app dev audience is the wrapping up of the App Ecosystem 
working group: 
http://lists.openstack.org/pipermail/user-committee/2017-March/001825.html

* Configuration Reference and CLI Reference - Tomoyuki Kato: N/A

* High Availability Guide - Ianeta Hutchinson: At the Atlanta PTG, the 
documentation team outlined a new table of contents that is now upstream as a 
draft here: 
https://github.com/openstack/openstack-manuals/tree/master/doc/ha-guide-draft. 
A blocker to progress in the past had been a lack of SME’s for the topic of 
high availability but that is no longer the case \o/. The OSIC DevOps team has 
an “adopt-a-guide” project in which they are collaborating with the OpenStack 
docs community and OSIC Docs team to apply the new ToC and validate all content 
for the guide. The progress of this collaboration is being tracked here 
https://docs.google.com/spreadsheets/d/1hw4axU2IbLlsjKpz9_EGlKQt0S6siViik7ETjNg_MgI/edit?usp=sharing
 We are calling for more contributors both as SME's and tech writers. Ping 
iphutch if interested!

* Hypervisor Tuning Guide - Blair Bethwaite: N/A

* Installation guides - Lana Brindley: Cells bug is closer to being fixed, and 
we are closer to a complete test install 
https://wiki.openstack.org/wiki/Documentation/OcataDocTesting look at all that 
green!). We're planning to branch Ocata by the end of this week.

* Networking Guide - John Davidge: N/A

* Operations and Architecture Design guides - Darren Chan: Arch Design Guide: 
Minor IA and general cleanup of the storage, compute, and networking sections 
in the Design chapter. Currently updating gaps in storage design content. Ops 
Guide: Removed cloud architecture content (migrated to the Arch Design Guide).

* Security Guide - Nathaniel Dillon: Edits from Alex going through, and patches 
from the OSIC DevOps team. See above for more info.

* Training Guides - Matjaz Pancur: For Training guides, related topics: a new 
brand for activities around OpenStack Upstream University/Training. It is now 
known as OpenStack Upstream Institute 
(https://wiki.openstack.org/wiki/OpenStack_Upstream_Institute)

* Training labs - Roger Luethi: We are currently testing our automated version 
of the Ocata install-guide. We had a problem with Ubuntu's new ISO image 
(16.04.2 L

Re: [openstack-dev] [openstack-docs] [tripleo] Creating official Deployment guide for TripleO

[Alexandra Settle]

Thanks for volunteering everyone :)

Carlos – The Contributor Guide link that Emilien shared has a list of the tasks 
(step-by-step process) that need to be done. The only other thing you might 
need to elaborate on is potential for editing and ensuring your guide is 
up-to-date and fully deployable.

The other thing is, the project deployment guides tend to focus entirely on a 
full deployment (rather than an AIO, or upgrade content). Although I see no 
reason why this scope can’t expand – just letting you know what is currently 
added/being added to the section :)

Cheers,

Alex

From: Carlos Camacho Gonzalez <ccama...@redhat.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Monday, March 20, 2017 at 3:21 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [openstack-docs] [tripleo] Creating official 
Deployment guide for TripleO

Hey,

I'll like to collaborate, please, just let me know what can I do to help with 
this task.

Might be a good idea to have in the blueprint a list of tasks?

Also, I think this can be called Deployment/Upgrade guide for TripleO.

Cheers,
Carlos.



On Mon, Mar 20, 2017 at 3:26 PM, Sanjay Upadhyay 
<supad...@redhat.com<mailto:supad...@redhat.com>> wrote:


On Mon, Mar 20, 2017 at 5:31 PM, Emilien Macchi 
<emil...@redhat.com<mailto:emil...@redhat.com>> wrote:
I proposed a blueprint to track the work done:

https://blueprints.launchpad.net/tripleo/+spec/tripleo-deploy-guide
Target: pike-3

Volunteers to work on it with me, please let me know.

Please add me (irc handle - saneax), I am interested on this.

regards
/sanjay


Thanks,

On Tue, Mar 14, 2017 at 7:00 AM, Alexandra Settle 
<a.set...@outlook.com<mailto:a.set...@outlook.com>> wrote:
> Hey Emilien,
>
> You pretty much covered it all! Docs team is happy to provide guidance, but 
> in reality, it should be a fairly straight forward process.
>
> The Kolla team just completed their deploy-guide patches and were able to 
> help refine the process a bit further. Hopefully this should help the TripleO 
> team :)
>
> Reach out if you have any questions at all :)
>
> Thanks,
>
> Alex
>
> On 3/13/17, 10:32 PM, "Emilien Macchi" 
> <emil...@redhat.com<mailto:emil...@redhat.com>> wrote:
>
> Team,
>
> [adding Alexandra, OpenStack Docs PTL]
>
> It seems like there is a common interest in pushing deployment guides
> for different OpenStack Deployment projects: OSA, Kolla.
> The landing page is here:
> https://docs.openstack.org/project-deploy-guide/newton/
>
> And one example:
> https://docs.openstack.org/project-deploy-guide/openstack-ansible/newton/
>
> I think this is pretty awesome and it would bring more visibility for
> TripleO project, and help our community to find TripleO documentation
> from a consistent place.
>
> The good news, is that openstack-docs team built a pretty solid
> workflow to make that happen:
> https://docs.openstack.org/contributor-guide/project-deploy-guide.html
> And we don't need to create new repos or do any crazy changes. It
> would probably be some refactoring and sphinx things.
>
> Alexandra, please add any words if I missed something obvious.
>
> Feedback from the team would be welcome here before we engage any work,
>
> Thanks!
> --
> Emilien Macchi
>
>



--
Emilien Macchi

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


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

__
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] Project On-Boarding Rooms

[Alexandra Settle]

Might be too late, but would be interested in having a docs room too :)

From: Kendall Nelson 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, March 15, 2017 at 6:20 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [ptls] Project On-Boarding Rooms

Hello All!
As you may have seen in a previous thread [1] the Forum will offer project 
on-boarding rooms! This idea is that these rooms will provide a place for new 
contributors to a given project to find out more about the project, people, and 
code base. The slots will be spread out throughout the whole Summit and will be 
90 min long.

We have a very limited slots available for interested projects so it will be a 
first come first served process. Let me know if you are interested and I will 
reserve a slot for you if there are spots left.
- Kendall Nelson (diablo_rojo)

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-March/113459.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] [openstack-docs] [tripleo] Creating official Deployment guide for TripleO

[Alexandra Settle]

Hey Emilien,

You pretty much covered it all! Docs team is happy to provide guidance, but in 
reality, it should be a fairly straight forward process.

The Kolla team just completed their deploy-guide patches and were able to help 
refine the process a bit further. Hopefully this should help the TripleO team :)

Reach out if you have any questions at all :)

Thanks,

Alex 

On 3/13/17, 10:32 PM, "Emilien Macchi"  wrote:

Team,

[adding Alexandra, OpenStack Docs PTL]

It seems like there is a common interest in pushing deployment guides
for different OpenStack Deployment projects: OSA, Kolla.
The landing page is here:
https://docs.openstack.org/project-deploy-guide/newton/

And one example:
https://docs.openstack.org/project-deploy-guide/openstack-ansible/newton/

I think this is pretty awesome and it would bring more visibility for
TripleO project, and help our community to find TripleO documentation
from a consistent place.

The good news, is that openstack-docs team built a pretty solid
workflow to make that happen:
https://docs.openstack.org/contributor-guide/project-deploy-guide.html
And we don't need to create new repos or do any crazy changes. It
would probably be some refactoring and sphinx things.

Alexandra, please add any words if I missed something obvious.

Feedback from the team would be welcome here before we engage any work,

Thanks!
-- 
Emilien Macchi


__
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-docs] [dev] What's up, doc?

[Alexandra Settle]

Team team team team team,

It's been a crazy few weeks since the PTG ramping up our goals for Pike! Big 
thanks to everyone who has really hit the ground running with our new set of 
objectives.

This week I have been helping out Ianeta with the High Availability Guide ToC 
plan, (which you can review here: https://review.openstack.org/#/c/440890/ ) 
and Rob Clark with the Security Guide plan 
(https://etherpad.openstack.org/p/sec-guide-pike ). I have also been working 
alongside Brian and the nova team to unblock ourselves from a particularly 
nasty, critical, bug affecting the Install Guide. For more information: 
https://bugs.launchpad.net/openstack-manuals/+bug/1663485

Big thanks to Darren Chan who has been doing an awesome job for the last two 
weeks in keeping our bug list under control. We are down to an amazing 108 bugs 
in queue.

Next week, we have Ianeta who will be looking after the bug triage liaison role!

If you're sitting there thinking "bugs are for me, I really love triaging 
bugs!" well, you're in luck! We have a few spots open for the rest of the 
cycle: 
https://wiki.openstack.org/wiki/Documentation/SpecialityTeams#Bug_Triage_Team

== Progress towards Pike ==
https://www.timeanddate.com/countdown/newyear?p0=24=Pike+release=1=slab

Bugs closed in Pike: 32! You guys rock :)

== The Road to the Summit in Boston ==
The summit schedule has been announced: 
https://www.openstack.org/summit/boston-2017/summit-schedule/#day=2017-05-08

I will be representing the docs team at the summit for the new 'Project Update' 
session. For more information: 
https://www.openstack.org/summit/boston-2017/summit-schedule/global-search?t=Project+Update+-+Documentation

Let me know if you had any doc talks accepted!

== Speciality Team Reports ==

API - Anne Gentle: One prominent change is that the Block Storage API v2 is now 
exactly replicated with v3 and so is now marked Deprecated. The list of all 
OpenStack APIs is now also here: https://developer.openstack.org/#api and you 
can see them based on support level here: 
https://developer.openstack.org/api-guide/quick-start/


Configuration Reference and CLI Reference - Tomoyuki Kato: N/A

High Availability Guide - Ianeta Hutchinson: So, we have this patch 
https://review.openstack.org/#/c/440890/13 to establish the new ToC for HA 
Guide. We are trying to move all content that is relevant in the current guide 
over to the new ToC. From there, we will be filing bugs to start collaboration 
with the OSIC DevOps team who have signed up to adopt-a-guide and will be 
helping to provide content as SME's.

Hypervisor Tuning Guide - Blair Bethwaite: The Scientific-WG is considering 
proposing a hypervisor tuning + guide session for the Boston Forum though, so 
hopefully if that goes ahead it will create some renewed interest.

Installation guides - Lana Brindley: Waiting to sort out the last couple of 
bugs before we branch, hopefully next week.

Networking Guide - John Davidge: Huge number of patches this week on the RFC 
5737 fix[1] - thanks to caoyuan! Continued progress on replacing neutronclient 
commands with OSC versions. Thank you to all contributors. A patch[2] changing 
a documented use of ’tenant’ to ‘project’ sparked a discussion in the neutron 
team about the mixture of terminology in neutron, with the conclusion that all 
remaining references to ’tenant’ in our config files and elsewhere are to be 
replaced with ‘project’ as soon as possible. Some of these will require 
deprecation cycles. Impact on the networking guide should be minimal.
[1] https://launchpad.net/bugs/1656378  [2] 
https://review.openstack.org/#/c/43816

Operations and Architecture Design guides - Darren Chan: A patch to move the 
draft Arch Guide to docs.o.o has merged. The previous guide has been moved to a 
"to archive" directory until the archiving process is ready. The Arch Guide 
working group met this week to rearchitect and scope the design content. We're 
currently focussed on the storage content.

Security Guide - Nathaniel Dillon: Rob Clark (PTL) and Alex are in the process 
of planning the ins and out of the overhaul of the guide. We're talking about 
dramatically reducing the scope, and introducing new, maintainable, content. 
Rob (hyakuhei) is also looking at getting a sprint in Austin at some point to 
get the security team all together and pump out some content. We also have the 
OSIC Security team pumping out some of the main, non-wishlist, bugs at preset.

Training Guides - Matjaz Pancur: N/A

Training labs - Pranav Salunke, Roger Luethi: We have pushed the current state 
of the Ocata training-labs changeset in case others find it useful. The scripts 
follow the install-guide and https://review.openstack.org/#/c/438328/ . The 
resulting cluster cannot launch instances because it fails to find a host (just 
like others following the install-guide have reported).

Admin and User guides - Joseph Robinson: For the User and Admin Guides, I've 
been looping through the 

[openstack-dev] [docs] Docs team meeting

[Alexandra Settle]

Hi everyone,

The docs meeting will be on today, Thursday the 9th March at 2100 UTC in 
#openstack-meeting-alt.

For more meeting details, including minutes and the agenda: 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting

Thanks,

Alex


__
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] [nova][docs] Broken nova instructions

[Alexandra Settle]

On 3/9/17, 11:18 AM, "John Garbutt" <j...@johngarbutt.com> wrote:

On 9 March 2017 at 11:05, Alexandra Settle <a.set...@outlook.com> wrote:
> I have attached the error logs that our tester, Brian Moss, sent to me 
earlier this morning.
> He has noted that some people have been able to get the instructions to 
work, but many others haven't.
> Also, noted that some are failing on Ubuntu and RDO, so it isn't a distro 
specific problem either.

The current compute logs seem to point at this bug:
https://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide/issues/71

The bug says you restart libvirt and the problem goes away. Seems like
a package issue, maybe? I am not sure.

But then why would this issue present in RDO and Ubuntu? Seems random for those 
two to have a similar packaging problem, no?
Regardless, having to restart libvirt is hardly a great option.

I notice some 404s for flavors. You need to create your own flavors
before you can boot an instance. Not sure if thats covered in the
install docs.

For me I found the order unclear in the currently proposed docs, so I
revised them so the cells and placement logic is more integrated into
the existing steps in the guide.

Yep! Going to set up and test today. Will take a while as I’m going to go from 
the beginning.
Stay tuned.

Thanks :)

Thanks,
John

__
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 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] [nova][docs] Broken nova instructions

[Alexandra Settle]

Hi everyone,

The installation guide for docs.o.o is currently broken and requires immediate 
attention from the doc and nova teams.

I have moved the relevant bug[0] to be CRITICAL at request. Brian Moss (bmoss) 
and Amy Marrich (spotz) have been working on a subsequent patch for the last 10 
days without result; the current instruction set still do not enable the user 
to start up an instance. There is another Red Hat bug tracking the issue for 
RDO.[1]

Any and all reviews on the patch[2] would be appreciated. We need to be able to 
branch

Thank you,

Alex

[0] https://bugs.launchpad.net/openstack-manuals/+bug/1663485
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1405098
[2] https://review.openstack.org/#/c/438328/


__
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-docs] [docs][release][ptl] Adding docs to the release schedule

[Alexandra Settle]

On 3/2/17, 4:42 PM, "Doug Hellmann" <d...@doughellmann.com> wrote:

Excerpts from Alexandra Settle's message of 2017-03-02 16:25:46 +:
> 
> 
> On 3/2/17, 4:08 PM, "Doug Hellmann" <d...@doughellmann.com> wrote:
> 
> Excerpts from Alexandra Settle's message of 2017-03-02 14:29:07 +:
> > 
> > 
> > From: Anne Gentle <annegen...@justwriteclick.com>
> > Date: Thursday, March 2, 2017 at 2:16 PM
> > To: Alexandra Settle <a.set...@outlook.com>
> > Cc: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>, "openstack-d...@lists.openstack.org" 
<openstack-d...@lists.openstack.org>
> > Subject: Re: [OpenStack-docs] [docs][release][ptl] Adding docs to 
the release schedule
> > 
> > 
> > 
> > On Wed, Mar 1, 2017 at 11:52 AM, Alexandra Settle 
<a.set...@outlook.com<mailto:a.set...@outlook.com>> wrote:
> > Hi everyone,
> > 
> > I would like to propose that we introduce a “Review documentation” 
period on the release schedule.
> > 
> > We would formulate it as a deadline, so that it fits in the 
schedule and making it coincide with the RC1 deadline.
> > 
> > For projects that are not following the milestones, we would 
translate this new inclusion literally, so if you would like your project to be 
documented at docs.o.o, then doc must be introduced and reviewed one month 
before the branch is cut.
> > 
> > I like this idea, and it can align certain docs with string freeze 
logically.
> > 
> > I think the docs that are governed with this set of rules should be 
scoped only to those that are synched with a release, namely the Configuration 
Reference, Networking Guide, and Install Guides. [1]
> > 
> > For reference, those are the guides that would best align with 
"common cycle with development milestones." [2]
> > 
> > Scope this proposal to the released guides, clarify which repo 
those will be in, who can review and merge, and precisely when the cutoff is, 
and you're onto something here. Plus, I can hear the translation teams 
cheering. :)
> > 
> > 
> > I completely agree with everything here :) my only question is, 
what do you mean by “clarify which repo those will be in”? I had no intention 
of moving documentation with this suggestion Install guides either in 
openstack-manuals or their own $project repos :)
> > 
> > Next question – since there doesn’t appear to be a huge ‘no don’t 
do the thing’ coming from the dev list at this point, how and where do we 
include this new release information? Here? 
https://docs.openstack.org/project-team-guide/release-management.html#release-1
> > 
> > Anne
> > 
> > 
> > 1. 
https://docs.openstack.org/contributor-guide/blueprints-and-specs.html#release-specific-documentation
> > 
> > 2. 
https://docs.openstack.org/project-team-guide/release-management.html#common-cycle-with-development-milestones
> > 
> > 
> > In the last week since we released Ocata, it has become 
increasingly apparent that the documentation was not updated from the 
development side. We were not aware of a lot of new enhancements, features, or 
major bug fixes for certain projects. This means we have released with 
incorrect/out-of-date documentation. This is not only an unfortunately bad 
reflection on our team, but on the project teams themselves.
> > 
> > The new inclusion to the schedule may seem unnecessary, but a lot 
of people rely on this and the PTL drives milestones from this schedule.
> > 
> > From our side, I endeavor to ensure our release managers are 
working harder to ping and remind doc liaisons and PTLs to ensure the 
documentation is appropriately updated and working to ensure this does not 
happen in the future.
> > 
> > Thanks,
> > 
> > Alex
> > 
> 
> As Thierry pointed out, we do need to consider the fact that more
> projects are using the cycle-with-intermediary process, so although
> we might tie dates to milestones we need to be careful that projects
> not tagging milestones are still covered in any processes.
> 
> Based on a similar discussion we had with the i18n team at the PTG,
> I think a good first step here is to

Re: [openstack-dev] [OpenStack-docs] [docs][release][ptl] Adding docs to the release schedule

[Alexandra Settle]

On 3/2/17, 4:08 PM, "Doug Hellmann" <d...@doughellmann.com> wrote:

Excerpts from Alexandra Settle's message of 2017-03-02 14:29:07 +:
> 
> 
> From: Anne Gentle <annegen...@justwriteclick.com>
> Date: Thursday, March 2, 2017 at 2:16 PM
> To: Alexandra Settle <a.set...@outlook.com>
> Cc: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>, "openstack-d...@lists.openstack.org" 
<openstack-d...@lists.openstack.org>
> Subject: Re: [OpenStack-docs] [docs][release][ptl] Adding docs to the 
release schedule
> 
> 
> 
> On Wed, Mar 1, 2017 at 11:52 AM, Alexandra Settle 
<a.set...@outlook.com<mailto:a.set...@outlook.com>> wrote:
> Hi everyone,
> 
> I would like to propose that we introduce a “Review documentation” period 
on the release schedule.
> 
> We would formulate it as a deadline, so that it fits in the schedule and 
making it coincide with the RC1 deadline.
> 
> For projects that are not following the milestones, we would translate 
this new inclusion literally, so if you would like your project to be 
documented at docs.o.o, then doc must be introduced and reviewed one month 
before the branch is cut.
> 
> I like this idea, and it can align certain docs with string freeze 
logically.
> 
> I think the docs that are governed with this set of rules should be 
scoped only to those that are synched with a release, namely the Configuration 
Reference, Networking Guide, and Install Guides. [1]
> 
> For reference, those are the guides that would best align with "common 
cycle with development milestones." [2]
> 
> Scope this proposal to the released guides, clarify which repo those will 
be in, who can review and merge, and precisely when the cutoff is, and you're 
onto something here. Plus, I can hear the translation teams cheering. :)
> 
> 
> I completely agree with everything here :) my only question is, what do 
you mean by “clarify which repo those will be in”? I had no intention of moving 
documentation with this suggestion Install guides either in openstack-manuals 
or their own $project repos :)
> 
> Next question – since there doesn’t appear to be a huge ‘no don’t do the 
thing’ coming from the dev list at this point, how and where do we include this 
new release information? Here? 
https://docs.openstack.org/project-team-guide/release-management.html#release-1
> 
> Anne
> 
> 
> 1. 
https://docs.openstack.org/contributor-guide/blueprints-and-specs.html#release-specific-documentation
> 
> 2. 
https://docs.openstack.org/project-team-guide/release-management.html#common-cycle-with-development-milestones
> 
> 
> In the last week since we released Ocata, it has become increasingly 
apparent that the documentation was not updated from the development side. We 
were not aware of a lot of new enhancements, features, or major bug fixes for 
certain projects. This means we have released with incorrect/out-of-date 
documentation. This is not only an unfortunately bad reflection on our team, 
but on the project teams themselves.
> 
> The new inclusion to the schedule may seem unnecessary, but a lot of 
people rely on this and the PTL drives milestones from this schedule.
> 
> From our side, I endeavor to ensure our release managers are working 
harder to ping and remind doc liaisons and PTLs to ensure the documentation is 
appropriately updated and working to ensure this does not happen in the future.
> 
> Thanks,
> 
> Alex
> 

As Thierry pointed out, we do need to consider the fact that more
projects are using the cycle-with-intermediary process, so although
we might tie dates to milestones we need to be careful that projects
not tagging milestones are still covered in any processes.

Based on a similar discussion we had with the i18n team at the PTG,
I think a good first step here is to document the agreement by
writing a governance tag with a name like doc:managed. The tag
description is the place to write down the answers to the questions
from this thread.

For example, it would list the manuals that are in scope, what
portion of the work the docs team will take on (initial writing?
reviews?), and what portion of the work the project team needs to
provide (contributing updates when major related happen in the code,
having a liaison, and a "checkup" at a date specified near the end
of the cycle). If there are any constraints about which projects
can apply, those should be documented, too. Maybe "independent"
projects (not following t

Re: [openstack-dev] [OpenStack-docs] [docs][release][ptl] Adding docs to the release schedule

[Alexandra Settle]

From: Anne Gentle <annegen...@justwriteclick.com>
Date: Thursday, March 2, 2017 at 2:16 PM
To: Alexandra Settle <a.set...@outlook.com>
Cc: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>, "openstack-d...@lists.openstack.org" 
<openstack-d...@lists.openstack.org>
Subject: Re: [OpenStack-docs] [docs][release][ptl] Adding docs to the release 
schedule



On Wed, Mar 1, 2017 at 11:52 AM, Alexandra Settle 
<a.set...@outlook.com<mailto:a.set...@outlook.com>> wrote:
Hi everyone,

I would like to propose that we introduce a “Review documentation” period on 
the release schedule.

We would formulate it as a deadline, so that it fits in the schedule and making 
it coincide with the RC1 deadline.

For projects that are not following the milestones, we would translate this new 
inclusion literally, so if you would like your project to be documented at 
docs.o.o, then doc must be introduced and reviewed one month before the branch 
is cut.

I like this idea, and it can align certain docs with string freeze logically.

I think the docs that are governed with this set of rules should be scoped only 
to those that are synched with a release, namely the Configuration Reference, 
Networking Guide, and Install Guides. [1]

For reference, those are the guides that would best align with "common cycle 
with development milestones." [2]

Scope this proposal to the released guides, clarify which repo those will be 
in, who can review and merge, and precisely when the cutoff is, and you're onto 
something here. Plus, I can hear the translation teams cheering. :)


I completely agree with everything here :) my only question is, what do you 
mean by “clarify which repo those will be in”? I had no intention of moving 
documentation with this suggestion Install guides either in openstack-manuals 
or their own $project repos :)

Next question – since there doesn’t appear to be a huge ‘no don’t do the thing’ 
coming from the dev list at this point, how and where do we include this new 
release information? Here? 
https://docs.openstack.org/project-team-guide/release-management.html#release-1

Anne


1. 
https://docs.openstack.org/contributor-guide/blueprints-and-specs.html#release-specific-documentation

2. 
https://docs.openstack.org/project-team-guide/release-management.html#common-cycle-with-development-milestones


In the last week since we released Ocata, it has become increasingly apparent 
that the documentation was not updated from the development side. We were not 
aware of a lot of new enhancements, features, or major bug fixes for certain 
projects. This means we have released with incorrect/out-of-date documentation. 
This is not only an unfortunately bad reflection on our team, but on the 
project teams themselves.

The new inclusion to the schedule may seem unnecessary, but a lot of people 
rely on this and the PTL drives milestones from this schedule.

From our side, I endeavor to ensure our release managers are working harder to 
ping and remind doc liaisons and PTLs to ensure the documentation is 
appropriately updated and working to ensure this does not happen in the future.

Thanks,

Alex


___
OpenStack-docs mailing list
openstack-d...@lists.openstack.org<mailto:openstack-d...@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs



--

Read my blog: justwrite.click<https://justwriteclick.com>
Subscribe to Docs|Code: docslikecode.com<http://docslikecode.com>
__
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] [Openstack-operators] Error in making connection Openstack Python SDK

[Alexandra Settle]

Hi Amit,

I have CC’d Andy McCrae, the OpenStack-Ansible PTL.

For all OpenStack-Ansible related queries, I would recommend tagging the 
subject line with [openstack-anisble] to help those with filters :)

Either that, or potentially ask your question in the IRC channel 
#openstack-ansible

Cheers,

Alex

From: Amit Kumar 
Date: Thursday, March 2, 2017 at 11:01 AM
To: Openstack , OpenStack Operators 

Subject: [Openstack-operators] Error in making connection Openstack Python SDK

Hi All,

I have deployed Openstack using Openstack-Ansible. I am using Newton release 
from tag 14.0.8. My test environment is containing only Compute Node and 
Controller Node (Infra Node).
When using Openstack Python SDK, I am getting following error while making 
connection to external_vib_lp_address (192.168.255.45) binded to port 5000.

openstack.exceptions.SDKException: Connection failure that may be retried.

Any clue about this issue? More detailed traces are at: 
http://paste.openstack.org/show/601053/

Python script which I am using for this purpose is attached with this e-mail.

Thanks.

Regards,
Amit
___
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] Error in making connection Openstack Python SDK

[Alexandra Settle]

Hi Amit,

I have CC’d Andy McCrae, the OpenStack-Ansible PTL.

For all OpenStack-Ansible related queries, I would recommend tagging the 
subject line with [openstack-anisble] to help those with filters :)

Either that, or potentially ask your question in the IRC channel 
#openstack-ansible

Cheers,

Alex

From: Amit Kumar 
Date: Thursday, March 2, 2017 at 11:01 AM
To: Openstack , OpenStack Operators 

Subject: [Openstack-operators] Error in making connection Openstack Python SDK

Hi All,

I have deployed Openstack using Openstack-Ansible. I am using Newton release 
from tag 14.0.8. My test environment is containing only Compute Node and 
Controller Node (Infra Node).
When using Openstack Python SDK, I am getting following error while making 
connection to external_vib_lp_address (192.168.255.45) binded to port 5000.

openstack.exceptions.SDKException: Connection failure that may be retried.

Any clue about this issue? More detailed traces are at: 
http://paste.openstack.org/show/601053/

Python script which I am using for this purpose is attached with this e-mail.

Thanks.

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

Re: [openstack-dev] [docs][release][ptl] Adding docs to the release schedule

[Alexandra Settle]

From: John Dickinson <m...@not.mn>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, March 1, 2017 at 11:50 PM
To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>
Cc: "openstack-d...@lists.openstack.org" <openstack-d...@lists.openstack.org>
Subject: Re: [openstack-dev] [docs][release][ptl] Adding docs to the release 
schedule


On 1 Mar 2017, at 10:07, Alexandra Settle wrote:

On 3/1/17, 5:58 PM, "John Dickinson" <m...@not.mn> wrote:



On 1 Mar 2017, at 9:52, Alexandra Settle wrote:

> Hi everyone,
>
> I would like to propose that we introduce a “Review documentation” period on 
> the release schedule.
>
> We would formulate it as a deadline, so that it fits in the schedule and 
> making it coincide with the RC1 deadline.
>
> For projects that are not following the milestones, we would translate this 
> new inclusion literally, so if you would like your project to be documented 
> at docs.o.o, then doc must be introduced and reviewed one month before the 
> branch is cut.

Which docs are these? There are several different sets of docs that are hosted 
on docs.o.o that are managed within a project repo. Are you saying those won't 
get pushed to
docs.o.o if they are patched within a month of the cycle release?

The only sets of docs that are published on the docs.o.o site that are managed 
in project-specific repos is the project-specific installation guides. That 
management is entirely up to the team themselves, but I would like to push for 
the integration of a “documentation review” period to ensure that those teams 
are reviewing their docs in their own tree.

This is a preferential suggestion, not a demand. I cannot make you review your 
documentation at any given period.

The ‘month before’ that I refer to would be for introduction of documentation 
and a review period. I will not stop any documentation being pushed to the repo 
unless, of course, it is untested and breaks the installation process.

There's the dev docs, the install guide, and the api reference. Each of these 
are published at docs.o.o, and each have elements that need to be up-to-date 
with a release.

>
> In the last week since we released Ocata, it has become increasingly apparent 
> that the documentation was not updated from the development side. We were not 
> aware of a lot of new enhancements, features, or major bug fixes for certain 
> projects. This means we have released with incorrect/out-of-date 
> documentation. This is not only an unfortunately bad reflection on our team, 
> but on the project teams themselves.
>
> The new inclusion to the schedule may seem unnecessary, but a lot of people 
> rely on this and the PTL drives milestones from this schedule.
>
> From our side, I endeavor to ensure our release managers are working harder 
> to ping and remind doc liaisons and PTLs to ensure the documentation is 
> appropriately updated and working to ensure this does not happen in the 
> future.

Overall, I really like the general concept here. It's very important to have 
good docs. Good docs start with the patch, and we should be encouraging the 
idea of "patch must have both tests and docs before landing".

I’m glad to hear you think so :) this is entirely my thought process.

On a personal note, though, I think I'll find this pretty tough. First, it's 
really hard for me to define when docs are "done", so it's hard to know that 
the docs are "right" at the time of release. Second, docs are built and 
published at each commit, so updating the docs "later, in a follow-on patch" is 
a simple thing to hope for and gives fast feedback, even after a release. (Of 
course the challenge is actually doing the patch later--see my previous 
paragraph.)

So, unfortunately, I can give you no promise this was ever intended to be an 
easy inclusion. But in fairness, this is something teams should have already 
been doing.

However, as a PTL – you already have enough on your plate. We recommend a docs 
liaison that is not the PTL so that the individual is able to dedicate time to 
reviewing the documentation to the best of their ability. The docs being “done” 
= all new features that have a user impact are documented, and “right” = the 
user is able to install $project without major incident.

However, to reiterate my point before – we cannot force any team to do 
anything, but we would like to start actively encouraging the project teams to 
start seeing documentation as an important part of the release process, just as 
they would anything else.

“Treat docs like code” means so much more than just having a contribution 
process that is the same, it means treating the d

Re: [openstack-dev] [OpenStack-docs] [docs][release][ptl] Adding docs to the release schedule

[Alexandra Settle]

FYI, there's a few bugs for the Configuration Reference mentioning 
options for some services require updating. I've gone through the doc 
and created additional bugs and included the relevant PTL and docs liaison.


Thank you, Darren! I will review this morning :(

__
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] [nova][docs] Is anyone interested in being the docs liaison for Nova?

[Alexandra Settle]

Hi!

Anyone who is happy to help out with the liaison role, I am happy to work 
alongside them and ensure they are pointed in the right direction.

As Matt said, the position at least means attending docs meetings, helping to 
review docs patches that are related to nova, helping to alert the docs team of 
big changes coming in a release that will impact the install guide, etc.

We don’t need someone to help correct our writing, we need a technical ‘expert’ 
:)

Alex

From: Zhenyu Zheng 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, March 2, 2017 at 1:22 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [nova][docs] Is anyone interested in being the 
docs liaison for Nova?

Hi,

I'm not a native English speaker but I would like to have a try if possible :)

On Wed, Mar 1, 2017 at 11:45 PM, Matt Riedemann 
> wrote:
There is a need for a liaison from Nova for the docs team to help with 
compute-specific docs in the install guide and various manuals.

For example, we documented placement and cells v2 in the nova devref in Ocata 
but instructions on those aren't in the install guide, so the docs team is 
adding that here [1].

I'm not entirely sure what the docs liaison role consists of, but I assume it 
at least means attending docs meetings, helping to review docs patches that are 
related to nova, helping to alert the docs team of big changes coming in a 
release that will impact the install guide, etc.

From my point of view, I've historically pushed nova developers to be 
documenting new features within the nova devref since it was "closer to home" 
and could be tied to landing said feature in the nova tree, so there was more 
oversight on the docs actually happening *somewhere* rather than a promise to 
work them in the non-nova manuals, which a lot of the time was lip service and 
didn't actually happen once the feature was in. But there is still the need for 
the install guide as the first step to deploying nova so we need to balance 
both things.

If no one else steps up for the docs liaison role, by default it lands on me, 
so I'd appreciate any help here.

[1] https://review.openstack.org/#/c/438328/

--

Thanks,

Matt Riedemann

__
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 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][release][ptl] Adding docs to the release schedule

[Alexandra Settle]

On 3/1/17, 5:58 PM, "John Dickinson" <m...@not.mn> wrote:



On 1 Mar 2017, at 9:52, Alexandra Settle wrote:

> Hi everyone,
>
> I would like to propose that we introduce a “Review documentation” period 
on the release schedule.
>
> We would formulate it as a deadline, so that it fits in the schedule and 
making it coincide with the RC1 deadline.
>
> For projects that are not following the milestones, we would translate 
this new inclusion literally, so if you would like your project to be 
documented at docs.o.o, then doc must be introduced and reviewed one month 
before the branch is cut.

Which docs are these? There are several different sets of docs that are 
hosted on docs.o.o that are managed within a project repo. Are you saying those 
won't get pushed to
docs.o.o if they are patched within a month of the cycle release?

The only sets of docs that are published on the docs.o.o site that are managed 
in project-specific repos is the project-specific installation guides. That 
management is entirely up to the team themselves, but I would like to push for 
the integration of a “documentation review” period to ensure that those teams 
are reviewing their docs in their own tree. 

This is a preferential suggestion, not a demand. I cannot make you review your 
documentation at any given period.

The ‘month before’ that I refer to would be for introduction of documentation 
and a review period. I will not stop any documentation being pushed to the repo 
unless, of course, it is untested and breaks the installation process. 


>
> In the last week since we released Ocata, it has become increasingly 
apparent that the documentation was not updated from the development side. We 
were not aware of a lot of new enhancements, features, or major bug fixes for 
certain projects. This means we have released with incorrect/out-of-date 
documentation. This is not only an unfortunately bad reflection on our team, 
but on the project teams themselves.
>
> The new inclusion to the schedule may seem unnecessary, but a lot of 
people rely on this and the PTL drives milestones from this schedule.
>
> From our side, I endeavor to ensure our release managers are working 
harder to ping and remind doc liaisons and PTLs to ensure the documentation is 
appropriately updated and working to ensure this does not happen in the future.
>
> Thanks,
>
> Alex


> __
> 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 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] [docs][release][ptl] Adding docs to the release schedule

[Alexandra Settle]

Hi everyone,

I would like to propose that we introduce a “Review documentation” period on 
the release schedule.

We would formulate it as a deadline, so that it fits in the schedule and making 
it coincide with the RC1 deadline.

For projects that are not following the milestones, we would translate this new 
inclusion literally, so if you would like your project to be documented at 
docs.o.o, then doc must be introduced and reviewed one month before the branch 
is cut.

In the last week since we released Ocata, it has become increasingly apparent 
that the documentation was not updated from the development side. We were not 
aware of a lot of new enhancements, features, or major bug fixes for certain 
projects. This means we have released with incorrect/out-of-date documentation. 
This is not only an unfortunately bad reflection on our team, but on the 
project teams themselves.

The new inclusion to the schedule may seem unnecessary, but a lot of people 
rely on this and the PTL drives milestones from this schedule.

From our side, I endeavor to ensure our release managers are working harder to 
ping and remind doc liaisons and PTLs to ensure the documentation is 
appropriately updated and working to ensure this does not happen in the future.

Thanks,

Alex

__
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] [docs] Docs PTG summary

[Alexandra Settle]

Hi everyone,

The OpenStack manuals project had a really productive week at the first PTG in 
Atlanta, collaborating with the I18n team on the Monday and Tuesday for the 
horizontal sessions.

We were able to have several key leaders in the room, including previous 
documentation PTL, Anne Gentle and I18n PTL, Ian Choi to help drive a lot of 
the sessions. Although we had a small localized attendance, we were visited by 
several members of different projects such as Neutron and Security, each 
interested in helping contribute to the documentation project. We also had a 
successful first attempt at incorporating remote attendees for a few different 
sessions.

Following the PTG, the documentation team will be having a renewed focus on the 
Administration, Networking, High Availability (HA) and the Architecture Guides. 
These guides in particular have been items of technical debt for some time. The 
team at the PTG was able to collaborate and work on plans to best deal with any 
and all concerns. You can see all our comments, and sessions here: 
https://etherpad.openstack.org/p/docs-i18n-ptg-pike

Things to look out for during Pike:


1.   HA Guide

· Specialty team lead Ianeta Hutchinson and SME Adam Spiers played a 
big hand in planning the future of the guide. One of the major concerns was 
ensuring the guide was written and delivered to an appropriate audience. After 
collaborating during the session, and later in a cross-project working session. 
The team was able to smash out some new deliverables.

· You can see the comments, and the ToC planning in the HA etherpad: 
https://etherpad.openstack.org/p/HA_Guide

· The team will be using SMEs like Adam to help craft the guide, with 
further assistance from the OSIC team.

2.   Administration Guide

· The topic of a project-specific admin guide has come up previously, 
but this time with more gusto. As a result of the discussions in the PTG 
sessions, Ildiko Vancsa and specialty team lead Joseph Robinson will be working 
together over the course of the Pike release to fashion a specification.

· https://etherpad.openstack.org/p/docs-i18n-ptg-pike-repos

3.   Networking Guide

· Specialty team lead John Davidge will be working closely with the 
neutron team to work on a better information delivery method using the 
DocImpact tag. He will also be working on reorganizing the guide, and working 
with the HA team to avoid duplication of content.

· https://etherpad.openstack.org/p/networking-guide-improvements

4.   Security Guide

· The security guide team and the documentation team got together to 
work on the future of the Sec guide. Due to limited resources, there has been a 
pause in necessary updates. The security team working with OSIC have 
volunteered their team to employ a tactical effort to deliver 10 non-wishlist 
bugs.

· Further planning is underway regarding the audience, services, and 
pre-existing content.

· You can find more information here: 
https://etherpad.openstack.org/p/docs-i18n-ptg-pike (line 202)

5.   Architecture and Operations Guide(s)

· The draft guide that Ben Silverman and specialty team lead Darren 
Chan have been working on tirelessly for the last few cycles is coming out of 
the darkness and being published. Hopefully this will generate more interest in 
the guide (help!). The team will be working on improving the visibility of 
issues overall, and creating an architecture template use case template to 
provide guidance for contributors.

· The Ops Guide team will also be focusing on a single source of truth 
for Networking content, and discussing best course of action for the Upgrade 
notes.

· For more information: 
https://etherpad.openstack.org/p/docs-i18n-ptg-pike (line 271)

6.   Reno release notes

· Adam Spiers is working alongside Doug Hellmann to enable reno release 
notes for the Pike release. https://docs.openstack.org/developer/reno/

· Adam already has a preliminary patch up: 
https://review.openstack.org/#/c/437611/ keep your eyes open for more!

7.   Archiving of documentation

· Specialty team lead Brian Moss will be working with the tools team 
and Lana Brindley to implement the plan for archiving as detailed here: 
https://review.openstack.org/#/c/426047/

· The docs team will be working with the I18n team to find a use case 
that suits both scenarios.

· More information and notes: 
https://etherpad.openstack.org/p/docs-i18n-ptg-pike (line 104)

8.   Website theme

· The docs team will be working on unifying the themes used 
(oslo.sphinx and openstackdocstheme). Specialty team lead Kato Tomoyuki will be 
working alongside Anne Gentle to write a specification for the new integration.

We also had a few new contributors that was really great to see. Thanks to 
everyone that came along to the documentation session locally or 

Re: [openstack-dev] [OpenStack-docs] [openstack-docs] [dev] What's up, Doc?

[Alexandra Settle]

Ah, thank you for calling it out :) it has indeed.

This is why you don’t write newsletters while you’re running around like a 
chicken with their head cut off.

One day I’ll get this email thing right. 

On 2/24/17, 1:36 PM, "Christian Berendt" <bere...@betacloud-solutions.de> wrote:


> On 24 Feb 2017, at 13:32, Alexandra Settle <a.set...@outlook.com> wrote:
> 
> Please vote for your fellow documenter below:

The community voting for Boston already closed.

Christian.

-- 
Christian Berendt
Chief Executive Officer (CEO)

Mail: bere...@betacloud-solutions.de
Web: https://www.betacloud-solutions.de

Betacloud Solutions GmbH
Teckstrasse 62 / 70190 Stuttgart / Deutschland

Geschäftsführer: Christian Berendt
Unternehmenssitz: Stuttgart
Amtsgericht: Stuttgart, HRB 756139



__
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-docs] [dev] What's up, Doc?

[Alexandra Settle]

Team team team team team,

Welcome to my second edition of What's up, Doc!

We have had an extremely busy week in Atlanta for the PTG. We had a really 
enthusiastic attendance and I am truly impressed by how much we have managed to 
get done. This newsletter will be a short one and focus on a small PTG update!

Our bug triager for the first 2 weeks of Pike is Darren Chan. Looking for more 
people to sign up and help out: 
https://wiki.openstack.org/wiki/Documentation/SpecialityTeams#Bug_Triage_Team

== Progress towards Pike ==

Thanks to our amazing release managers, Maria, Brian and Lana for all their 
amazing hard work on the Ocata release. Big thanks to Anne for stepping in at 
the last minute!

* 44 days to go! 
https://www.timeanddate.com/countdown/newyear?p0=24=Pike+release=1=slab

== The Road to the Summit in Boston ==

Voting is now open for topics. You can find the list of topics here: 
https://www.openstack.org/summit/boston-2017/vote-for-speakers#/
I was able to find some documentation related topics. If anyone has any more 
topics I am unaware of, please reply to this email thread and share your talks!

Please vote for your fellow documenter below:

1. https://www.openstack.org/summit/boston-2017/vote-for-speakers#/17888
2. https://www.openstack.org/summit/boston-2017/vote-for-speakers#/18078
3. https://www.openstack.org/summit/boston-2017/vote-for-speakers#/17711

Event info is available here: http://www.openstack.org/ptg
Purchase tickets here: https://pikeptg.eventbrite.com/
Tickets for the Boston summit: https://www.openstack.org/summit/boston-2017/

== PTG Update ==

We had a very successful PTG! Thanks to all those that were able to attend. 
Thanks to Ian Choi and the I18n team for being wonderful collaborators. We were 
able to get a lot done in our horizontal sessions. For anyone that is 
interested, here's our etherpad with all the notes from the sessions: 
https://etherpad.openstack.org/p/docs-i18n-ptg-pike
Here are a few of the exciting things to look out for in Pike:


1.   High Availability Guide improvements

a.   Adam Spiers and Ianeta Hutchinson will be leading the charge on the HA 
guide with a massive restructure and up-to-date new content.

2.   Reno release notes for OpenStack manuals

a.   Adam Spiers has been working alongside John Davidge and the Infra team 
to work on implementing the reno release notes process for documentation. 
Including looking at implementing new reno templates to work specifically for 
documentation!

3.   Networking Guide improvements and more collaboration with the neutron 
team.

a.   John Davidge has been working with the neutron team to develop the 
best way to ensure information flows into the guide. Discussions around the use 
of the DocImpact tag were successful.

4.   Administrator Guide changes! Keep your eye out for exciting 
developments.

a.   Ildiko Vancsa and Joseph Robinson will be working together to come up 
with a new specification to implement in Queens for our Administration Guide. 
Development teams have been enthusiastic about implementing the 
project-install-guide and are looking for similar structures with the Admin 
Guide. Stay tuned for more news here!

I had the opportunity to report back to meeting attendees yesterday afternoon, 
if anyone would like to know more, here are the meeting minutes: 
http://eavesdrop.openstack.org/meetings/docteam/2017/docteam.2017-02-23-20.59.log.txt

== Doc team meeting ==

Our next meeting will be on Thursday 9 March at 2100 UTC in 
#openstack-meeting-alt.

Meeting chair will be me (Alexandra Settle - asettle)! \o/

For more meeting details, including minutes and the agenda: 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting

--

Have a great weekend!

Alex
Lamp enthusiast and award winning marathon sleeper

IRC: asettle
Twitter: dewsday
__
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-docs] [all] Upstream Training Team meeting at PTG - Are you coming?

[Alexandra Settle]

Hi team,

I apologise for not making the meetup this lunch hour; I was caught up with 
documentation priorities.

I am still around for the rest of the week, and would like to see/introduce 
myself to you all at some point :)

Thanks,

Alex

From: Amy Marrich 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, February 22, 2017 at 12:06 PM
To: "Csatari, Gergely (Nokia - HU/Budapest)" 
Cc: "OpenStack Development Mailing List (not for usage questions)" 
, "openstack-d...@lists.openstack.org" 
, user-committee 

Subject: Re: [openstack-dev] [OpenStack-docs] [all] Upstream Training Team 
meeting at PTG - Are you coming?

I tried to get into the google hangout 
https://hangouts.google.com/call/4htgw2zmb5ar5mzihizsnppf4ye and it said I 
wasn't allowed to join. I did send Ildiko my phone number if I'm the only 
remote.

Amy

On Wed, Feb 22, 2017 at 11:04 AM, Csatari, Gergely (Nokia - HU/Budapest) 
> wrote:
Hi,
We are waiting in Savannah 1 as there is a meeting still ongoing in Savannah 3.
Br,
Gerg0

Sent from Nine

From: Ildiko Vancsa >
Sent: Feb 21, 2017 9:05 AM
To: OpenStack Development Mailing List (not for usage questions); 
openstack-d...@lists.openstack.org; 
user-committee
Subject: Re: [openstack-dev] [all] Upstream Training Team meeting at PTG - Are 
you coming?

Hi All,

A quick reminder that we will have our face to face gathering on __Wednesday 
(tomorrow) at lunch time (12pm ET)__.

I booked Savannah 3 on the second floor (Lobby level). Please grab a lunch box 
after the morning sessions and join us for lunch if you would like to get 
involved with the Upstream Training and/or new contributor on boarding 
activities.

Thanks and Best Regards,
Ildikó
IRC: ildikov


> On 2017. Feb 15., at 13:16, Ildiko Vancsa 
> > wrote:
>
> Hi,
>
> We are forming a virtual upstream collaboration training team including 
> everyone who’s either helping us out with maintaining and improving the 
> training material and/or who are attending the course as coaches or mentors.
>
> We are planning to meet at the PTG in person next week on Wednesday at lunch 
> time. We picked this slot as our first face to face gathering as all of us 
> have project related assignments to drive and sessions to attend that makes 
> scheduling a meeting even more challenging.
>
> If you are interested in what we are doing and how we are trying to make the 
> on boarding process for new contributors a pleasant experience and would like 
> to join our activities meet us there!
>
> The meeting time is __Wednesday (February 22) lunch time__. I will share the 
> meeting point next week before the meeting.
>
> If you would like to have a mail reminder prior to the meeting next week 
> please reach out to me.
>
> Thanks and Best Regards,
> Ildikó
> IRC: ildikov


__
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 mailing list
openstack-d...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs

__
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-docs] [dev] Thursday docs meeting

[Alexandra Settle]

Hi everyone,

The docs team will still be hosting their meeting on Thursday, 23 February at 
2100 UTC in #openstack-meeting-alt. We will not be skipping the meeting in 
favor for the PTG as the docs sessions are on the Mon-Tues and I would love the 
opportunity to immediately report back to people who cannot attend.

For more meeting details, including minutes and the 
agenda:https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting

Thanks,

Alex

__
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] [docs] 101 session

[Alexandra Settle]

Hey everyone,

If anyone is interested, I’ll be helping out a few new contributors getting set 
up with documentation tools tomorrow morning (Wednesday, 22nd February).

I’ll be on level 1, on the couches near the coffee station for anyone who’s 
interested in getting setup and learning a bit about how docs work.

Cheers,

Alex
__
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-docs] HA Guide session

[Alexandra Settle]

Hi everyone,

As per the HA discussion in the session today, we’ll be meeting in the room 
‘Macon’ at the Sheraton from 3pm, on Wednesday the 22nd of February.

If you would like to join remotely, please let me know :)

Thanks,

Alex
__
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-docs] [i18n] PTG schedule

[Alexandra Settle]

Hey everyone,

Ian and I have written up combined docs and I18n schedule for the PTG: 
https://etherpad.openstack.org/p/docs-i18n-ptg-pike

I have packed in everything on a pretty tight schedule with time allocations 
simply because we have a lot of *big* topics to talk about between the two 
projects and I want to make sure we cover the smaller stuff too, but this is 
only a recommended set of guidelines. We have the full 2 days no matter what – 
things can be changed. Please reach out if the time does not work for you.

I have included everyone’s names next to the sessions they have proposed. There 
is one session that is nameless – Upgrade Guide – please let me know if this is 
you (Darren Chan, maybe?)
Some of the time slots are purposefully done to accommodate for remote 
attendees – keep this in mind as well.

I have included a new section underneath the schedule for working sessions. I 
know a few docs people will be around on the Wed – Fri. If anyone is interested 
in getting together after the 2 days to smash some bugs, or implement a new 
plan, put your name down and I will organize a room for us. This will be an 
informal session.

Any questions, or if I have missed something, please reach out to me :)

Alex


__
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] [designate] Status of the project

[Alexandra Settle]

Sorry, I’m top posting to this reply because Outlook is a terrible inline 
poster.

Hey Designaters! 

Have you tried pinging the docs team? (ie: me – Hello! I’m the docs PTL)

Over the last few cycles our team has been able to step in and help with 
formatting, writing, and organizing documentation. Helping small projects (like 
OpenStack-Ansible) to fix several of the issues you noted below (install, 
operations, dev docs). During the Newton cycle I was able to help the OSA team 
organize their dev docs: 
http://docs.openstack.org/developer/openstack-ansible/developer-docs/index.html,
 and as a team we created the Deploy Guide 
http://docs.openstack.org/project-deploy-guide/openstack-ansible/newton/. And 
for Ocata, we have been working heavily on their operations content: 
http://docs.openstack.org/developer/openstack-ansible/draft-operations-guide/index.html
 

Technical writers do not often have the expertise to provide SME knowledge 
(that’s your job), but we are experts when it concerns ensuring documentation 
is in the right place to help new users. And we are the guardians of the 
Operations Guide.

I know your conversation is much larger than just fixing documentation, but if 
we can help, please shout out :) 

On 2/10/17, 3:53 PM, "Hayes, Graham"  wrote:

On 10/02/17 02:40, Jay Pipes wrote:
> On 02/09/2017 02:19 PM, Hayes, Graham wrote:
> 
> 
>> Where too now then?
>> ===
>>
>> Well, this is where I call out to people who actually use the project -
>> don't
>> jump ship and use something else because of the picture I have painted.
>> We are
>> a dedicated team, how cares about the project. We just need some help.
>>
>> I know there are large telcos who use Designate. I am sure there is 
tooling,
>> or docs build up in these companies that could be very useful to the
>> project.
>>
>> Nearly every commercial OpenStack distro has Designate. Some have had it
>> since
>> the beginning. Again, developers, docs, tooling, testers, anything and
>> everything is welcome. We don't need a massive amount of resources - we
>> are a
>> small ish, stable, project.
>>
>> We need developers with upstream time allocated, and the budget to go to
>> events
>> like the PTG - for cross project work, and internal designate road map,
>> these
>> events form the core of how we work.
>>
>> We also need help from cross project teams - the work done by them is
>> brilliant
>> but it can be hard for smaller projects to consume. We have had a lot of
>> progress since the `Leveller Playing Field`_ debate, but a lot of work is
>> still optimised for the larger teams who get direct support, or well
>> resourced
>> teams who can dedicate people to the implementation of plugins / code.
>>
>> As someone I was talking to recently said - AWS is not winning public 
cloud
>> because of commodity compute (that does help - a lot), but because of the
>> added services that make using the cloud, well, cloud like. OpenStack
>> needs to
>> decide that either it is just compute, or if it wants the eco-system. 
[5]_
>> Designate is far from alone in this.
> 
> 
> 
> Graham, thank you for the heartfelt post. I may not agree with all your 
> points, but I know you're coming from the right place and truly want to 
> see Designate (and OpenStack in general) succeed.

Thanks for reading - it ended up longer than expected.

> Your point about smaller projects finding it more difficult to "consume" 
> help from cross-project teams is an interesting one. When the big tent 
> was being discussed, I remember the TC specifically discussing a change 
> for cross-project team focus: moving from a "we do this work for you" 
> role to a "we help you do this work for yourself" role. You're correct 
> that the increase in OpenStack projects meant that the cross-project 
> teams simply would not be able to continue to be a service to other 
> teams. This was definitely predicted during the big tent discussions.

I remember the same things being discussed. However, that is not what
happened, at least not immediately, and it can be very hard to
motivate yourself to work on things when everytime you ask for help
you get nothing, other than a link to the docs page you have read
a 100 times.

> If I had one piece of advice to give Designate, it would be to 
> prioritize getting documentation (both installation as well as dev-ref 
> and operational docs) in good shape. I know writing docs sucks, but docs 
> are a springboard for users and contributors alike and can have a 
> multiplying effect that's difficult to overstate. Getting those install 
> and developer docs started would enable the cross-project docs team to 
> guide 

[openstack-dev] [openstack-docs] What's up, Doc? 10 Feb 2017

[Alexandra Settle]

Team team team team team,

Welcome to my first edition of What's up, Doc?

Firstly, I just want to thank everyone who supported me when I announced I 
would like to run for manuals PTL. Although I ran the election uncontested 
(like the beginning of all good dictatorships), it was wonderful to receive 
messages of support from everyone. I’ve slowly been ramping up and getting used 
to the mass influx of emails. Turns out I’m really good at sending out emails 
with the incorrect time and/or date. Big thanks to Andreas for informing me the 
next 9th of January will be in 2020.

Without further ado, let's get down to business! We have a very short window 
now between Ocata and the start of Pike, and we still have quite a number of 
things left to achieve.
- If anyone has time to dedicate to Install Guide testing - please sign up 
(links below). Thanks to those who have already volunteered to help Lana out!
- As per my email yesterday, I'd love to see some people out there smashing 
bugs! (links also below, and more info in the meeting minutes from yesterday).

== Progress towards Ocata ==

* 12 days to go!
* Closed 256 bugs so far. We have 128 open bugs left: 
https://bugs.launchpad.net/openstack-manuals/+bugs
* Release tasks are being tracked here: 
https://wiki.openstack.org/wiki/Documentation/OcataDeliverables
* Install Guide testing is being tracked here: 
https://wiki.openstack.org/wiki/Documentation/OcataDocTesting

== The Road to PTG in Atlanta ==

Docs is a horizontal project, so our sessions will run across the Monday and 
Tuesday of the event. We will be combining the docs event with i18n, so 
translators and docs people will all be in the room together. Everyone welcome! 
Conversation topics for Docs and i18n here: 
https://etherpad.openstack.org/p/docs-i18n-ptg-pike

Event info is available here: http://www.openstack.org/ptg
Purchase tickets here: https://pikeptg.eventbrite.com/
Tickets for the Boston summit: https://www.openstack.org/summit/boston-2017/

== Specialty Team Reports ==

API - Anne Gentle:
The trove API docs are incomplete after migration, and a user reported the bug 
to the ML. Anne to log the missing clustering API info. Alex and Anne to meet 
with the app dev community manager at the Foundation to talk about goals for 
developer.openstack.org. The NFV Orchestration (tacker) team landed their API 
ref this week.

Configuration Reference and CLI Reference - Tomoyuki Kato:
CLI Reference: Updated some CLI references. Added aodhclient. Config Reference: 
Start working on Ocata updates.

High Availability Guide - Ianeta Hutchinson:
Sent a message to the ML looking for people interested in helping out on the HA 
guide for Pike. Planning for the PTG as I can’t attend.

Hypervisor Tuning Guide - Blair Bethwaite:
No report this week

Installation guides - Lana Brindley:
Landing page review: https://review.openstack.org/#/c/425821/12. Install guide 
testing is well underway.

Networking Guide - John Davidge:
Working on organising a Networking Guide working group with the neutron team at 
the PTG. Also been smashing bugs.

Operations and Architecture Design guides - Darren Chan:
Darren and Ben are working on an action plan for the Arch Guide to be worked on 
during Pike to get the current draft guide published.

Security Guide - Nathaniel Dillon:
Moved the sec-guide bugs to the sec team Launchpad. Sec and doc team to 
coordinate and come up with action plan for the future of the sec guide at the 
PTG.

Training Guides - Matjaz Pancur:
No report this week

Training labs - Pranav Salunke, Roger Luethi:
Training-labs has a rough, but working Ocata patch. Issues we found are noted 
on the Etherpad as you requested. We should be able to release within a week or 
two after Ocata is official.

User guides - Joseph Robinson:
The legacy command changes have gone through well this release, and the next 
steps is to check with the nova, neutron, cinder, and glance teams on the 
status of some specific project commands

== Doc team meeting ==

Our next meeting will be on Thursday 23 February at 2100 UTC in 
#openstack-meeting-alt. We will not be skipping the meeting in favor for the 
PTG as the docs sessions are on the Mon-Tues and I would love the opportunity 
to immediately report back to people who cannot attend.

Meeting chair will be me (Alexandra Settle - asettle)! \o/

For more meeting details, including minutes and the agenda: 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting

--

Have a great weekend!

Alex
All round badass and supernaturally good potato peeler

IRC: asettle
Twitter: dewsday

__
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-docs] [docs] Docs meeting

[Alexandra Settle]

Correction: 9th of February.

Apparently, I’m not very good at emails lately.

Thank you, Andreas ;)

From: Alexandra Settle <a.set...@outlook.com>
Date: Thursday, February 9, 2017 at 10:36 AM
To: "openstack-d...@lists.openstack.org" <openstack-d...@lists.openstack.org>, 
"OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: [OpenStack-docs] [openstack-dev][docs] Docs meeting

Hello everyone,

Your friendly neighbourhood PTL reminder that the weekly OpenStack manuals 
(docs) IRC meeting will be Thursday, 9th of January at 2100 UTC in
in the #openstack-meeting-alt channel: 
http://www.timeanddate.com/worldclock/fixedtime.html?msg=Documentation+Team+Meeting=20161117T21=1440=1

The agenda for the meeting can be found here: 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting

Everyone is welcome to attend and bring items to discuss to the table ☺

Thanks,

Alex

__
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] [docs] Docs meeting

[Alexandra Settle]

Hello everyone,

Your friendly neighbourhood PTL reminder that the weekly OpenStack manuals 
(docs) IRC meeting will be Thursday, 9th of January at 2100 UTC in
in the #openstack-meeting-alt channel: 
http://www.timeanddate.com/worldclock/fixedtime.html?msg=Documentation+Team+Meeting=20161117T21=1440=1

The agenda for the meeting can be found here: 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting

Everyone is welcome to attend and bring items to discuss to the table ☺

Thanks,

Alex

__
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-docs] [openstack-docs] Bug smash

[Alexandra Settle]

Correction!

251 bugs* - good to see I can type an email without errors. 

On 2/8/17, 11:25 AM, "Alexandra Settle" <a.set...@outlook.com> wrote:

Hey everyone,

We have 2 weeks until the Ocata release. Hooray! We have fixed 251 so far! 
But, we have some more work to do… 

I know everyone is busy with their respective guides and testing, but we 
have 24 bugs (half are wishlist!) that were assigned for Newton and Ocata that 
we have not fixed.

It would be great if people could take the time over the next 2 weeks to 
assign themselves a bug: https://goo.gl/DnZU0q (this is a Launchpad link, just 
wanted to save you all from the 40 lines)

If you have any questions, please reach out ☺ 

Cheers,

Alex




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


__
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-docs] Bug smash

[Alexandra Settle]

Hey everyone,

We have 2 weeks until the Ocata release. Hooray! We have fixed 251 so far! But, 
we have some more work to do… 

I know everyone is busy with their respective guides and testing, but we have 
24 bugs (half are wishlist!) that were assigned for Newton and Ocata that we 
have not fixed.

It would be great if people could take the time over the next 2 weeks to assign 
themselves a bug: https://goo.gl/DnZU0q (this is a Launchpad link, just wanted 
to save you all from the 40 lines)

If you have any questions, please reach out ☺ 

Cheers,

Alex




__
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-ansible] Propose Marc Gariepy as core reviewer

[Alexandra Settle]

+1 from me ☺

Thanks for all your hard work, Marc!

From: Jesse Pretorius 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, February 3, 2017 at 1:33 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [openstack-ansible] Propose Marc Gariepy as core 
reviewer

Hi everyone,

I’d like to propose Marc Gariepy [1] as a core reviewer for OpenStack-Ansible. 
His tireless effort to get CentOS as a supported platform in the last two 
cycles is getting very close to completion, and I feel that it’s important that 
he’s able to safeguard this work and help grow the maintenance community for it.

[1] 
http://stackalytics.com/?module=openstackansible-group_id=mgariepy=ocata=person-day

Best regards,

Jesse
IRC: odyssey4me


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
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-docs][security] Sec guide change

[Alexandra Settle]

Hi everyone,

As of today, all bugs for the Security Guide will be managed by 
ossp-security-documentation and no longer will be tracked using the OpenStack 
manuals Launchpad.

All tracking for Security Guide related bugs can be found here: 
https://bugs.launchpad.net/ossp-security-documentation

Big thanks to the security team and Ian Cordasco for creating and updating the 
bug list in Launchpad!

Thank you,

Alex
__
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-ansible] Proposing Amy Marrich for core

[Alexandra Settle]

Hi OpenStack-Ansible team,

I would like to propose Amy Marrich for the core team for OpenStack-Ansible.

Amy has been consistently in the top 10 reviewers for our team in the last 30 
[1] and 90 [2] days, respectively, this release alone.

She has been an active and diligent member of the OpenStack-Ansible team since 
the end of 2015 and has continuously provided assistance for code and 
documentation reviews.

I think she will make a great addition to the core team and will help move code 
and doc issues forward quicker.

+1 from me

Thanks,

Alex

[1] http://stackalytics.com/report/contribution/openstackansible-group/30
[2] http://stackalytics.com/report/contribution/openstackansible-group/90







__
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-I18n] What's Up, Doc? Farewell edition

[Alexandra Settle]

I am sad too ☹ end of an era. 

Looking forward to what we can achieve together ☺ 

Thank you to everyone for your support ☺ 

On 1/27/17, 1:17 AM, "Lana Brindley" <openst...@lanabrindley.com> wrote:

Hi everyone,

I must confess, I'm feeling a little sad. This is my very last What's Up, 
Doc. Next week, I'll be handling the Docs PTL mantle to Alexandra Settle. I've 
worked with Alex in varying capacities over many years, and I have no doubt 
that she will be a fabulous PTL. I'm really looking forward to working with 
her, and seeing what new directions she's able to take this team. I want to 
take this opportunity to thank each and every one of you for your continued 
support and encouragement over the last two years (and almost-four releases!). 
I have had an absolute ball doing this job, and it's all because of the amazing 
people I get to work with every day. Of course, I'm not going anywhere just 
yet. I will stay on as a core contributor, and continue to help out as much as 
I can.

In the meantime, we have a release to get out the door! We now only have 26 
days until Ocata is released, please keep an eye on the docs mailing list for 
updates, and consider getting your hands dirty with some Install Guide testing: 
https://wiki.openstack.org/wiki/Documentation/OcataDocTesting

== Progress towards Ocata ==

26 days to go!

Closed 211 bugs so far.

Release tasks are being tracked here: 
https://wiki.openstack.org/wiki/Documentation/OcataDeliverables
Install Guide testing is being tracked here: 
https://wiki.openstack.org/wiki/Documentation/OcataDocTesting

== The Road to PTG in Atlanta ==

Event info is available here: http://www.openstack.org/ptg 
Purchase tickets here: https://pikeptg.eventbrite.com/ 

Docs is a horizontal project, so our sessions will run across the Monday 
and Tuesday of the event. We will be combining the docs event with i18n, so 
translators and docs people will all be in the room together.

Conversation topics for Docs and i18n here: 
https://etherpad.openstack.org/p/docs-i18n-ptg-pike

Also, a quick note that the CFP and ticket sales for *Boston in May* are 
now open: https://www.openstack.org/summit/boston-2017/call-for-presentations/

== Speciality Team Reports ==

No speciality team reports this week, as we didn't have quorum for the docs 
meeting. 

== Doc team meeting ==

Our next meeting will be on Thursday 9 February at 2100 UTC in 
#openstack-meeting-alt

Meeting chair will be Alexandra Settle.

For more meeting details, including minutes and the agenda: 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting

--

Keep on doc'ing!

Lana

https://wiki.openstack.org/wiki/Documentation/WhatsUpDoc#27_January_2017

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



__
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] [docs] PTG planning

[Alexandra Settle]

Hi everyone,

For anyone who is not on the docs mailing list but is interested in 
attending/knowing what we’re up to for the PTG, the joint docs and i18n 
planning is here: https://etherpad.openstack.org/p/docs-i18n-ptg-pike

I would like to extend an invitation to anyone who would like to attend and get 
involved, but previously hasn’t before. The docs session are Monday and Tuesday 
but I have been granted the time to float around till Friday. I am happy to sit 
down and discuss docs-things with you all.

If anyone would like assistance from a doc team member with their developer 
documentation or projects, please reach out and contact us. We’d be happy to 
help in any way we can ☺

I promise we’re nice.

Thanks,

Alex
__
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] [kolla] Docs status?

[Alexandra Settle]

CCing Ianeta Hutchinson and Joseph Robinson that I know were helping the 
efforts ☺ 

On 1/24/17, 12:06 PM, "Paul Bourke"  wrote:

Hi Kolla,

Does anyone know the current status of docs refactor? I believe there 
was someone looking into it (apologies can't remember their name).

If not, I'd like to propose a vote for some immediate changes that can 
improve things.

Regards,
-Paul

__
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 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] [launchpad] [docs] Adding checklist to bug reporting

[Alexandra Settle]

Hi everyone,

The documentation team has been having issues with bugs being filed asking for 
troubleshooting and support for years. We have been doing our best to redirect 
and close, but it is becoming increasingly unmanageable.

I know other projects struggle with this issue too. We implemented a (hopeful) 
solution and if anyone is interested, here’s what we did:


1.   Using ‘Configure bug tracker’ within Launchpad, we updated the 
‘Helpful guidelines for reporting a bug’ with information about where to go if 
you have a troubleshooting or support question. You can view the checklist 
here: https://bugs.launchpad.net/openstack-manuals/+configure-bugtracker or 
here: https://bugs.launchpad.net/openstack-manuals/+filebug



2.   Using the openstackdocstheme we implemented a checklist. When a 
reporter goes to report a bug using the ‘Report a Bug’ bug button in the guides 
(on the right hand side), the “Further information” section will now produce a 
checklist.
This checklist states the following:


This bug tracker is for errors with the documentation, use the following as a 
template and remove or add fields as you see fit. Convert [ ] into [x] to check 
boxes:



- [ ] This doc is inaccurate in this way: __

- [ ] This is a doc addition request.

- [ ] I have a fix to the document that I can paste below including example: 
input and output.



If you have a troubleshooting or support issue, use the following resources:



- Ask OpenStack: http://ask.openstack.org

- The mailing list: http://lists.openstack.org

- IRC: 'openstack' channel on Freenode

You can see the checklist in action here: 
https://bugs.launchpad.net/openstack-manuals/+bug/1658965

This was our solution to the problem – hopefully this helps some others with 
implementing their own ☺

If you have any questions, feel free to reach out ☺

Thanks,

Alex

IRC: asettle
Twitter: dewsday




__
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-docs] [Docs] PTL Candidacy for Pike

[Alexandra Settle]

Hi everyone,

I am announcing my candidacy for the OpenStack manuals PTL position. 

Some of you may know me from the 2014 Paris summit where I cooed like a pigeon 
[1] in a panel discussion, but I hope that most of you will know me from my 
documentation work across OpenStack, specifically the OpenStack manuals project 
and OpenStack-Ansible contributions.

I have been an active contributor to OpenStack manuals since the beginning of 
2014, and have been a core member since early 2015. Over these last 3 years, I 
was privileged to be a part of the sprint team that authored the first edition 
of the OpenStack Architecture Design Guide [2] (and the subsequent swarm team 
that fixed it up), the team that converted the manuals from XML to RST, the 
specialty team that worked on the creation and curation of the Contributor 
Guide, and the release management team for Ocata. I also worked with the 
OpenStack Infra team to create the new Deployment Guides section [3] at 
docs.openstack.org.

I regularly work in different OpenStack projects. For example, I assisted the 
Swift team to curate the Swift Ops Runbook [4], and have been helping the 
OpenStack-Ansible team rework their documentation [5]. 

I am passionate about our documentation, our community, and our team’s 
involvement across OpenStack. OpenStack manuals was never organised and 
facilitated by a single person. Behind the scenes there are a great number of 
individuals who work hard to ensure our ship stays afloat. As PTL, I would like 
to continue this trend by:

1. Improving cross-project documentation liaison relationships
a. Over the course of the Pike release, I plan to focus on developing better 
relationships with the cross-project liaisons and PTL’s of individual projects. 
I would like to promote and encourage developers and operators to get more 
involved in the development of OpenStack manuals content. OpenStack manuals 
takes on the responsibility of documenting and maintaining guides that 
represent the projects and tools developers and operators are working so hard 
to build and maintain. This written representation of their work is equally as 
important as the output. 
2. Continuing with Lana’s bug-depletion legacy
a. I plan to achieve this by reporting on completed bugs on a weekly basis and 
encouraging other contributors to report and fix one bug per week. When Lana 
first became PTL, she vowed to attack our enormous (and continuously growing) 
bug list. I'd like to continue this work, and will strive to find innovative 
ways to reduce our technical debt.

If you would like to know more about how I will work to improve our community 
and the manuals, I’d love to chat with you more on IRC or via email.

Coo coo,

Alexandra Settle

IRC: asettle
Twitter: dewsday
Email: a.set...@outlook.com

[1] https://youtu.be/PtomtKeJ0tc?t=1783 
[2] 
http://docs.openstack.org/arch-design/introduction-how-this-book-was-written.html
 
[3] http://docs.openstack.org/project-deploy-guide/newton/
[4] http://docs.openstack.org/developer/swift/ops_runbook/index.html 
[5] 
https://blueprints.launchpad.net/openstack-ansible/+spec/osa-install-guide-overhaul
 

 

__
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-ansible] Can someone run tomorrow's (2016-01-12) meeting for me?

[Alexandra Settle]

Hey,

I can run the meeting tomorrow ☺

Thanks,

Alex

On 1/11/17, 3:29 PM, "Major Hayden"  wrote:

Hey folks,

A conflict came up and I won't be available to run tomorrow's weekly 
meeting in IRC. Would someone else be able to take over this meeting for me?

--
Major Hayden

__
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 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-Infra] [OpenStack-docs] [infra][docs] Steps to migrate docs.o.o to new AFS based server

[Alexandra Settle]

Looks good, Andreas.

Let me know if I can do anything from the docs side to make the transition 
smoother. 

Thanks!

Alex

On 12/28/16, 6:09 PM, "Andreas Jaeger"  wrote:

[cross-posting to both infra and docs mailing lists]

We're running since several weeks developer.openstack.org using the
OpenStack Infra server and I reviewed what is needed to make the final
switch. An analysis of missing pages showed that only 4 repos have not
been published (step 1 below), we need to copy those over.

Once that is done, we can do the switch


The following steps need to be done:

1) update some missing content since a few projects haven't published
   content since we started:
   http://users.suse.com/~aj/missing-docs.tar.bz2 is a copy from
   docs.o.o that needs to be added to our AFS tree.

2) Change IP address of docs.openstack.org to point to the new site.

3) Create docs-archived.openstack.org pointing to the old CloudDocs
   docs site so that we can still access any content that wasn't
   published recently. Update 404 handler to point to docs-archived.


Later (most can be done independently, so not using numbers), we should do:

A) Set up https for docs.openstack.org and developer.openstack.org

B) Stop publishing to CloudDocs site docs-archived but keep site as
   is.
   Archive all content on it.

   Remove docs-archived.openstack.org

C) Stop publishing to old CloudDocs developer.openstack.org page (
   https://review.openstack.org/415506 )

D) Remove docs-beta and developer-beta aliases and IP addresses, those
   are not needed anymore.

Is anything missing?

Otherwise, let's move forward once an infra admin has time. Since we
continue publishing to both sites for a time, we can always migrate back
if needed.  Infra team, please go ahead if there's no veto - but let's
not do it this year anymore;)

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


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


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

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

[Alexandra Settle]

My recommendation, as a documenter for OpenStack, would be to include a link to 
each project’s contributor guidelines (as most tend to keep in their developer 
documentation pages) in the README file.

I appreciate the README as previously not always been for this purpose, but I 
believe it would be beneficial to include a link and not to create a whole new 
file for the purpose of 3 lines.

I have had people in the past ask me how to contribute to individual project 
repositories, not knowing that each project has developer documentation that 
includes contributing documentation. There is clearly a gap, and this is just 
one option to fix that.

I appreciate if people disagree whoever, I don’t overly believe this is a 
necessary step as the contributor guidelines are already documented and this is 
a form of duplication.

Cheers,

Alex

On 12/22/16, 12:46 PM, "Ian Cordasco"  wrote:

On Wed, Dec 21, 2016 at 11:20 PM, Zhenyu Zheng
 wrote:
> Agreed with Amrith, it might be useful and maybe also good for new
> contributors to learn how to have a commit to OpenStack. BUT over 130
> identical patches to 130 different projects from one company/person in one
> run? I don't think this is going to help OpenStack growing. We should not
> let this happen.
>
> On Thu, Dec 22, 2016 at 12:44 AM, Amrith Kumar  wrote:
>>
>> For those who would like to know exactly what this set of changes cost in
>> the CI, the answer is approximately 1050 jobs which consumed 190 compute
>> hours of CI time.
>>
>> -amrith
>>
>> -Original Message-
>> From: Amrith Kumar [mailto:amr...@tesora.com]
>> Sent: Wednesday, December 21, 2016 11:13 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to
>> projects
>>
>> Ian, Andreas, Emilien,
>>
>> My sentiments on the subject of these kinds of "production line" changes
>> is unchanged from [1] and [2]. A complete list of these changes is at 
[3].
>>
>> I've updated all of the changes in this thread with a block comment and a
>> -1. My apologies to other reviewers (and active contributors in those
>> projects) for this automated comment across 131 commits.
>>
>> It is high time we eliminated these kinds of changes which do little to
>> improve the overall quality of the product and serve merely to generate a
>> huge amount of pointless work on the CI systems, and boost some 
meaningless
>> statistics that someone wants to put on a slide someplace.
>>
>> -amrith
>>
>> [1] http://openstack.markmail.org/thread/dsuxy2sxxudfbij4
>> [2] http://openstack.markmail.org/thread/3sr5c2u7fhpzanit
>> [3] https://review.openstack.org/#/q/topic:addCONTRIBUTING.rst

So, I want to reiterate why I started this thread:

I want a productive outcome of this contributor's efforts. -1'ing
everyone of their changes was not something I was looking for. Having
people pile on after those -1s is also not something that leads to a
productive outcome.

Yes, these mass produced changes are annoying. I get it. We're all a
little jaded, ostensibly because we've all seen the statistical
nonsense that people at our very own companies use for marketing or
whatever else. I understand it quite well.

All of that aside, I specifically asked that we not turn this thread into 
that.

There is some ambiguity right now with projects as to where to put
easy-to-find documentation (even if it is just a brief paragraph with
a link to longer-form documentation) into our repositories. Let's
focus on that discussion here. We can come up with a productive
conclusion and work with this contributor. While you've chosen (and
yes, you've chosen this) to have a negative assumption about this
contributor's efforts, I've chosen to believe they're looking to fill
a gap. Increasing the productivity of new contributors to OpenStack is
a positive improvement for our community. It may not fix a bug or add
a feature, but it helps ramp up the people who will do that.

So please, let's keep this productive. If you want to discuss ways of
ratelimiting patchset contributions or some other nonsense, please
start a new thread.

Cheers,
-- 
Ian Cordasco

__
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 Development Mailing List (not for