Open Stack

Hi Everyone,

Sorry for the delay in response, I was out of town and just got back on
Tues. Thank you for the meeting notes, very thorough. I will review the
editorial calendar and provide input on the topics now. Thanks again

Shilla



On Fri, May 23, 2014 at 11:43 AM, Matt Van Winkle <mvanwink at rackspace.com>wrote:

>  Greetings all,
> Some thoughts.  Apologies if it's not completely cohesive.  I've been
> writing this in between meetings and operational stuff (<- technical term)
> while trying to get to the appropriate coffee/bloodstream ratio.
>
>   From: Nate Gandomi <nate at jones-dilworth.com>
> Date: Thursday, May 22, 2014 6:37 PM
> To: "superuser at lists.openstack.org" <superuser at lists.openstack.org>
>
> Subject: [Superuser] Editorial Advisory Board, meeting notes, how to get
> involved
>
>    Hello everyone,
>
>  Welcome to the Superuser editorial advisory mailing list!
>
>  The purpose of this list is for coordinating among ourselves and to get
> your input. It’s a public list to which anyone can subscribe or send
> feedback/ideas about the publication, but we expect it will primarily be
> the editorial team and advisors.
>
>  Thank you for volunteering to help and for those of you that attended
> our first meeting at the Atlanta Summit. The editorial team came away with
> a great deal of insight from the discussion, and we want to continue
> iterating and building out plans for the publication with your feedback.
>
>  For those who are new or were unable to attend in Atlanta, we've
> captured notes from the meeting below. We are also sharing a few
> collaborate documents for your input, and have a few specific follow up
> questions and areas that we think warrant continued discussion.
>
>  *Primary Takeaways from Atlanta*
>  ​- Consider two audiences: We had originally scoped the Superuser
> publication to focus on the operator community, folks who are setting up
> and running cloud infrastructure. From the meeting, it seems like there is
> interest in expanding that scope to also include the app dev / API consumer
> audience. We are certainly open to this feedback, but need some help
> setting the editorial direction and identifying the best resources to get
> involved.
>
>
>  So, I still worry here.  I ABSOLUTELY get the need to package and
> present the concepts of OpenStack in a way that can be put in front of
> business decision makers – especially those who are non-technical.  I also
> understand the need to reach out to those creating the apps that run on
> OpenStack based clouds.  Where I get a little nervous is that a lot of the
> recent effort around Operators/Superusers has been to separate the two
> "user" voices – those who run OpenStack clouds and those who run ON
> OpenStack clouds.  The first group needing to be made much more vocal (in a
> positive light).  In my opinion, superuser.openstack is an excellent
> vehicle to help drive that.
>
>  Now, that all being said, I do think that highlighting app
> deployers/endusers that are reaching back into the process and helping to
> make OpenStack better falls squarely in the sweet spot of a "Superuser" and
> we should definitely highlight those folks in the publication.  The bulk of
> the app developer assistance, how-tos, etc, however, should probably be
> pushed to the vehicle being built for them. (didn’t I hear we were building
> something to target developers running ON OpenStack – not writing it?)
>
>    - Highlight release development progress: There were several people
> who wanted the publication to report on the software development progress,
> especially highlighting issues where operators may want to weigh in or get
> involved, possibly driving users back to the appropriate mailing list
> conversations. What’s the best process and format for these updates? We
> need to highlight the important conversations that are happening on the
> mailing lists, in IRC, and other channels. How do we capture conversations
> and bring them back in ways that the broader community can consume them?
>
>
>  We need to maybe highlight specific cases where Superusers of any stripe
> jumped in the development process and made a difference.  That's what would
> be most useful for the publication.  In doing so, we should also plug all
> the ways others can do the same – IRC, mailing lists, specs repositories,
> etc.   Conversely, we could pull out specific conversations from those
> mechanisms that lead to significant change (e.g the thread that led to
> nova-specs) and highlight them.  To me, tracking the nitty gritty of the
> development process here would dilute the purpose of the publication and
> potentially duplicate other mechanisms that already exist
>
>     - Developer and user feedback loop: How can we build empathy between
> developers and operators? Focus on the combined effort as the solution
> rather than the problem itself, or the dichotomy of users and/or
> developers. For example, Developer and Operator interaction and "success
> stories.” How can we discover these interactions?
>
>
>  As I said above, this is were I think the best place to play in the
> "development process" space is.  We  have to highlight productive conflict,
> developer/user interaction and Superuser efforts that solved real problems
> and made real progress in a positive manner.
>
>
> - Consider product and vendor reviews: Several saw the value in sharing
> their experiences with vendors, but we discussed whether this was
> appropriate and how we would need to approach it in a very balanced way
> (like giving the vendors a heads up if there was an article appearing about
> them for a chance to comment). It’s not something we need to settle on
> right away, but can see how the content evolves and what makes the most
> sense.
>
>
>  Product/Project reviews within OpenStack, I can see happening, and we
> will definitely want to give those dev teams a heads up.  I'm not so sure
> about Vendors per se.  That seems like a slippery slope.  Maybe we can
> highlight any that are taking the learnings from their products and driving
> meaningful and positive change in greater process and community.  We'll
> see.  Just seems worth treading lightly in the "vendor" space.
>
>
> - Business case also important: Another role several of you see for this
> publication is to help provide the business value content needed to help
> sell OpenStack internally (or to users/customers). We may even want to tag
> this by industry over time.
>
>
>  In line with my first set of comments, I'd love to see us, to quote
> Jonathan, highlight the business cases where users " … Are really making a
> difference in the industries that they play in…"
>
>
> - Help users along the journey: There should be content for beginners, as
> well as more advanced users, and we should find a way to tag that
> appropriately and help drive people to the best resources or next steps.
>
>
> - Video is an important medium, especially for the business value content
> and shorter attention spans :)  We will of course have a significant amount
> of video content from the Summit that we can curate/summarize/tag for the
> publication.
> - Users that came to the Superuser booth expressed the need to have more
> basic how-tos and guides. We may play a role in helping market appropriate
> documentation and guides that the community has already developed.
>  - If you attended, please feel welcome to add your notes or thoughts here
> ​
>
>
>  All good stuff.  In general it's highlight the right content for the
> right people, and when necessary point them at the other, more technical
> and detailed, resources that will help them grow.  We should not try to
> solve all the things here.
>
>  In fact, I've been playing with an idea on and article called "Cave
> Paintings and Campfire Tales"  - specifically about how it falls somewhat
> on the Superusers to pull themselves up out of the "HOW' (technical docs,
> mailing lists, training materials, etc) for a bit to tell a better story
> about the "WHY" ( what OpenStack is, what it means to us, and how it just
> might change the world) to the devs who are building it, the bosses we are
> asking to buy into it and the outside world (analysts, journalists, etc)
> who may not completely understand it yet.   No promises, but I have an 8
> week break from work coming up, so in between reconnecting with the family,
> I'm hoping to do a bit of writing.  When I think about this publication,
> though, I think it needs to have bit of the same flavor mixed in with good
> technical hooks.
>
>
>  *​Next Steps*​
> - Please weigh in on any of the comments and takeaways above. We
> specifically need more input and help scoping out how we’ll highlight
> release development process, dev/user feedback stories and whether we
> should target end user / app developers initially.
> - We are planning one major/topical feature story per month. Please help
> us review the editorial calendar and provide input on the topics, whether
> you like it, think we should skip it, or have ideas about a specific angle
> we should take:
>
> https://docs.google.com/a/openstack.org/spreadsheet/ccc?key=0Atf9_ocTTlmLdDFVTTRoTTlNUFFCYkxlLXJKMjZwUkE&usp=drive_web#gid=4
> - We have one feature article in flight about best practices for building
> OpenStack skills and career development. If you have any ideas or know of
> anyone we should speak to, please let us know.
> - Based on the feedback from the first meeting, we’re considering
> re-working the navigation. We’ll wait a few weeks to gather more feedback
> and see how the content develops before making any major changes, but we’re
> open to feedback and will circulate some ideas to the mailing list.
>
>
>  Sounds great.  Thanks for all the hard work on this!
>
>
> - We are always looking for more contributors and and guest authors. Do
> you know of anyone that is blogging about how they use OpenStack?  Do you
> relationships with any technical writers or even journalists we might hire
> for a feature story?
>
>
>  Will think about it.
>
>
>  One quick note on promotion. We launched the publication at the Summit
> so we could start getting the community involved and capture content at the
> event. While we would definitely like to start building a core audience and
> promoting great articles, we have deliberately held off on bigger campaigns
> to amp up readership until we get our feet under us. We’d like a chance to
> incorporate the feedback you’ve provided and build up a good base of
> content over the next few weeks, and then we’ll start to put more marketing
> muscle behind it.
>
>
>  Sound more than reasonable.
>
>
>
>  Our next in person meeting will be at the Paris summit. In the meantime,
> please share your ideas, comments, feedback, questions about Superuser on
> this list. Let's keep the conversation going.
>
>
>  Fingers crossed – hope to see you there :)
>
>
>
>  Thank you again for taking the time to participate in what we hope will
> become a valuable resource for the OpenStack community!
>
>  ​Best,
> Nate​
>
>
>  Thanks for letting me ramble!
> Matt
>
>
>
>   --
>
>  Nate Gandomi // Jones-Dilworth, Inc.
> M: 510-999-6283 // @ngandomi <https://twitter.com/ngandomi> // Skype:
> ngandomi
>
>
> _______________________________________________
> Superuser mailing list
> Superuser at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/superuser
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/superuser/attachments/20140528/d3609516/attachment-0001.html>