Category Archives: community

community

Male allies for women in tech: What’s needed?

I realized the other day that I have given my “Women in Tech: Be That Light” presentation a half a dozen times in the last year. One question that I still want a great answer for is when a man in the audience asks, “What can I do to make it better? How can I be that light?” I have ideas from my own experiences, and also point to the training courses and Ally Skills workshops offered by the Ada Initiative. Updated to add: Register now for the Monday 5/18 workshop at the OpenStack Summit in Vancouver!

flickr-ngmmemuda-ally

On a personal level, here’s my short list based on my own experiences. My experiences are colored by my own privileges being white, straight, married with an amazing partner, a parent, living in a great country in a safe neighborhood, working in a secure job. So realize that even while I write my own experiences at a specific place in my career, all those stations in life color my own views, and may not directly help people with backgrounds dissimilar to mine.

What do women in tech need? How can I help?

  • Be that friendly colleague at meetups, especially to the few women in the room, while balancing the fact that she probably doesn’t want to be called out as uniquely female or an object to be admired. If you already know her, try to introduce her to someone else with common interests and make connections. If you don’t already know her, find someone you think she would feel comfortable speaking with to say hello. It’s interesting, sometimes I’m completely uncertain about approaching a woman who’s the only “other” woman at a meetup. So, women should also try to find a commonality — maybe one of her coworkers could introduce you to her. For women, it’s important make these connections in friendly and not competing ways, because oddly enough, when I’m the second woman in the room I don’t want to make the other woman feel uncomfortable either!
  • Realize that small annoyances over years add up to real frustration. I don’t point this out to say “don’t be annoying” but rather, be a great listener and be extremely respectful. Micro annoyances over time add up to women departing technical communities in droves. See what you can do in small ways, not just large, to keep women in your current tech communities.
  • For recruiting, when new women show up online on mailing lists or IRC or Github, please do answer questions with a “there are no questions too small or too large” attitude. I never would have survived my first 90 days working on OpenStack if it weren’t for Jay Pipes and Chuck Thier. Jay patiently helped me set up a real development environment by walking me through his setup on IRC. And since he was used to Github and going to Launchpad/Bazaar himself, he didn’t make me feel dumb for asking. Chuck didn’t laugh too hard when I tried to spell check the HTTP header “referer” to “referrer.” I felt like any other newbie, not a “new girl” with these two. (Woops, and I should never use the term “girl” for anyone over the age of 18.)
  • Recognize individuality when talking to team members, regardless of visible differences like gender or ethnicity. I struggle with this myself, having to pause before talking about my kids or my remodeling projects, since not everyone is interested! I struggle with assumptions about people all the time, and have to actively fight them myself. For men, you don’t want to assume an interest in cars or sports, so really this applies regardless of gender. All humans struggle with finding common interests without making assumptions.
  • See if you can do small, non-attention-drawing actions that ensure the safety of women in your communities. With the OpenStack Summit being held in different cities twice a year, I’ve been concerned for my personal safety as a woman traveling alone. Admitting that fear means I try to be more savvy about travel, but I still make mistakes like letting my phone battery die after calling a cab in another city after 11 at night. If you see a woman at a party alone, see if you can first make her feel welcome, but then also ensure there are safety measures for her traveling after the event.
  • If you see something, say something, and report correctly and safely for both the bad actor and target. This is really hard to do in the moment, believe me, I’ve been there. For me, being prepared is best, and knowing the scenarios and reporting methods ahead of time gives me the slightly better confidence I can do the right thing in the moment even if I’m shocked or scared. Find the “good and bad” ways to deal with incidents through this excellent Allies_training page.

If you’ve read this far, you really do want to make life better as a male ally. Realize that it’s okay to make mistakes — I’ve made them and learned from them over the years. This inclusion work by allies is not the easiest work to do, nor is it rewarding really. It’s the work of being a good human, and we’re all going to screw up. If someone points out a foible to you, such as saying “girls” instead of “women,” say “thank you” and move on, promising to do better next time.

If you think you already do all these things, make sure you look for ways to expand your reach to other minority groups and less privileged participants. I’m trying to do better with the physically different people I encounter at work. I would like to find ways to work well with people suffering from depression. I’ve got a son with Type I diabetes, what sort of advocacy can I do for people with unique medical needs? I’m asking myself how to make a difference. How about you? How can you do your part to equalize the tech industry?

API community content strategy techpubs

Deep Data Dive into Supporting Developers

Here at Rackspace, we watch several sources to determine if a developer is having trouble with Rackspace Cloud services, many of which are based on OpenStack. We even have a notification tool, aptly named peril, that offers an aggregation of the many sites where developers may seek help. I’ve been on the Rackspace developer experience team since the very early days when we started supporting developers at the code level a few years ago. We monitor stackoverflow.com, serverfault.com, and superuser.com for questions tagged with Rackspace, rackspace-cloud, fog, cloudfiles, jclouds, pyrax, or keystone. At Rackspace we have been supporting cross-cloud SDKs such as Apache jclouds, Node.js pkgcloud, Ruby Fog, Python Pyrax, .NET, and PHP. Let’s look at the data from these many places to find out the patterns for application development.

A developer is in peril!

We have a group email address that we monitor for developer support requests. In the last year, about 6.25% of support requests came in through email. We saw nearly half of support requests on the jclouds bug list (JIRA tracker) and a community forum at community.rackspace.com. Tracking Github issues on our supported SDKs was another 40% with the 14% remaining support requests coming from Stack Overflow, where we track certain tags on questions asked. Here’s a screenshot showing what our notifications look like in a Slack channel internally. I like how it cycles through various alert messages, “Heads up, incoming!” and not shown is “BWEEEEEP BWEEEEP BWEEEEP” which naturally makes us want to help!

Peril example
True story: sometimes our slurps catch and notify before our email server. We are on it!

Documentation comments

If you’ve read my blog for a while or my book, you know I appreciate documentation that offers back-and-forth discussion in comment threads. We use Disqus comments for developer documentation at Rackspace. These comments tend to uncover three categories of requests:

  • Request for help when something doesn’t work as expected
  • Request for a feature that doesn’t exist
  • Request for correction: pointing out typos or incorrect formatting, such as JSON examples that lose their indentation

We see about 20 comments a month on API docs spanning all our products, with about 27.5% on Cloud Files (Object Storage), about 20% Cloud Servers (Compute), and Identity coming in third at 12%. In OpenStack docs, we have a doc bug link that serves for the third type of comment — pointing out a doc bug — but not on the API reference, yet. One pattern we see that’s comparable to a review of the document is someone asking a bunch of questions at once to gain understanding.

Stack Exchange sites

Stack Exchange sites are question and answer sites with built-in features to boost motivations for answering questions posted by others. Some examples sites include Stack Overflow for developers and Server Fault for administrators.

We track these tags on Stack Overflow with our peril tool:

rackspace rackspace-cloud fog cloudfiles jclouds pyrax keystone

When people don’t get a satisfactory answer on Stack Overflow, one interesting pattern is that they come to ask.openstack.org, the OpenStack open source equivalent site.

The Stack Exchange API is a ton of fun to scrape data. I wrote some Python scripts that request data from these calls, using the tag “openstack”:

  • Top Answerers: Matt Joyce, Everett Toews, and Lorin Hochstein are great at answering questions on Stack Overflow, and since Everett’s on the developer support team at Rackspace that makes sense.
  • Related Tags: openstack-nova, cloud, python are the top three related tags for openstack on Stack Overflow.
  • Top Tags: python, ruby, csharp/.net, php, javascript(node.js). One interesting observation is that overarching concepts like security and networking were often tagged along with the language itself.
  • Frequently Asked Questions: It’s not surprising that authentication is the root of the most frequently asked questions. Networking is also particularly complex and it shows in the number of questions asked. What was interesting though is the number of questions about monitoring and metrics on the cloud consumption itself.
  • Unanswered Questions: For the openstack tag, the unanswered questions had less than 100 views, compared to over 1000 views for the answered questions.

While your browser automatically decompresses the results when you enter http://api.stackexchange.com/2.2/tags/openstack/top-answerers/all_time?site=stackoverflow in your browser, I had to figure out how to have Python unzip the results and put them into JSON. Then I got stuck trying to automate putting the JSON into CSV, so I used konklone.io/json/ to convert the JSON to CSV.

Once I had the CSV files, I could use Tableau to get interesting data visualizations like a bubble grouping for related tags showing the frequency of the tags.

Tag bubbles

Github data

I found that Github issues were a great place to dive into the use cases for particular software development kits. I even discovered that our Austin-based real estate agent’s web site was developed by Rackspace Cloud php-opencloud users!

TryStack

One extremely helpful sandbox for trying OpenStack services through API use is Trystack, with over 15,000 users and growing every year. I find it very helpful to have my own sandbox besides the Rackspace Cloud to test the actual API calls and see what is returned from OpenStack. In looking at the logs, I found many queries about quotas which also explain the many questions about policies. It’s a free, community-donated cloud, and support is entirely through a Facebook group, so it’s a bit unusual but I still found interesting data around it.

Other findings

I found that many of the SDKs do not yet have full support for certain OpenStack services. For example, jclouds, the Java multi-cloud toolkit has a lot of users but doesn’t yet support the newest OpenStack services like Orchestration (heat templates), the Metering module ceilometer, the new versions of APIs for Images and Identity, and the latest storage policies implementation for Object Storage.

I also surmise that the service catalog coming through the Identity service needs stricter documentation and expectations setting. So the OpenStack API Working Group is tackling that issue by first discovering all the common patterns for the service catalog. Feel free to join the OpenStack API Working Group and review the incoming suggestions for consistency going forward or review patches going into OpenStack services that affect APIs.

Presentation

You can get the full presentation from slideshare.net, or watch me give it on YouTube.

community sxsw work

Hackathons of Late

I’ve participated in a few hackathons in the past year, since I’ve been working on a team of developer advocates at Rackspace. I wanted to chronicle some of my experiences with a few goals in mind: recording memories for myself, letting others get ideas for the wide range of hackathons, and chronicling the wide variety of types of hackathons and outcomes of hackathons.

For a bit of context, I’m female, have a family and weekend obligations that include sports practices, and I’m a generation-Xer if that gives you a sense of my age (with a range). I’ve definitely read and enjoyed a lot of articles about women and inclusive hackathons, “Running an Inclusive Hackathon: How to get better representation at your hackathon and recently about “grownups” and hackathons, “Why I don’t like hackathons, by Alex Bayley aged 39 1/2. I appreciate a well-run, inclusive hackathon for my own participation, but I also see a need for well-run, inclusive college-age hackathons.

Internal Hackathon at Rackspace

Screen Shot 2014-12-22 at 4.50.30 PM
This was a bunch of fun for me to dig into one of our SDKs (Python and pyrax) and services (Cloud Files) to make a gallery of photos from a balloon photography project we did for a girls in engineering day at the University of Texas. This project has had some re-use in demonstrating to school-age students about what code for the cloud looks like and it offers a nice demonstration since it’s visual. I sat next to another developer advocate who helped me break the idea into parts that I could manage more easily with my rudimentary coding skills. It was a ton of fun and at the end of the day I didn’t demo it for a group but did show it to our vice president who was walking around to see what we were working on. The hackathon was held in the office after another technical event during work hours, so it was easy to make it part of my day.

Austin Ladies Hackathon

This one involved a lot of time from a fun event Friday night to form teams and included hacking on two weekend days. I served as a mentor for teams in this hackathon rather than participating myself. It wasn’t the time investment that prevented me from participating, it was just my role to mentor rather than hack. I have a write-up on the Rackspace Developer Blog.
Austin Ladies Hackathon

Slashathon at SXSW Interactive

This event was one of the highlights of my week at SXSW Interactive, as a bookend with a really neat experience interviewing a woman on the StartUp Bus, Nicole Dominguez.

After the last day of SXSW Interactive, we all arrived at Capitol Factory in the morning for the hackathon. I was toting a Rackspace red bike and scheduled to be a developer mentor for the Rackspace Cloud APIs for the morning session.

IMG_2444

Everett Toews and I both work on the developer relations group at Rackspace, and he gave a presentation about how to hack the hackathon by using our cloud services. The other presenters really piqued my interest in metadata about music, bands, albums, and artists headphone hardware advances (hacking headphones are amazing!), cool uses of location and proximity hardware devices, all of the technology really makes ideas fire off in your brain. We came up with an idea collaboratively with four of us – Everett, and two web developers from Harvard Business Review who had to catch afternoon flights. We wanted to create a site for seeing on a map where your favorite band or musician is, with related Tweets and social media posts and the ability to buy tickets for their next gig. Everett presented to the panel of judges – Slash himself, Robert Scoble, and the guy who invented bittorrent, Bram Cohen. It went over really well! The winner had some cool hardware that helped enhance a concert experience and second place went to a Google Glass app that performers could wear to measure the decibels of audience noise. LoudWire covered the event in a post.

Types of Hackathons

I definitely see a difference between hackathons for college-age or students and for working adults or non-traditional students. There are also hardware hackathons versus software hackathons or hackathons with a specific theme, such as the Slashathon that featured music or audio hardware and music-based APIs. There should be a hackathon for many interests, then it’s a matter of determining your own goals for participating.

Outcomes of Hackathons

I think there are different types of outcomes: projects by participants, learning by participants, and then for sponsors and mentors, recruiting and learning more about participants or testing their products. The outcomes I don’t like to see are companies trying to get hard work for “free” or with little investment, or participants focusing too much on winning prize money.

What do you think about hackathons lately? What are your experiences? I’d love to hear more from others experiencing hackathons as a participant and as a sponsor and mentor.

community techpubs tools

Tearing down obstacles to OpenStack documentation contributions

Rip. Shred. Tear. Let’s gather up the obstacles to documentation contribution and tear them down one by one. I’ve designed a survey with the help of the OpenStack docs team to determine blockers for docs contributions. If you’ve contributed to OpenStack, please fill it out here:

https://docs.google.com/forms/d/136-BssH-OxjVo8vNoOD-gW4x8fDFpvixbgCfeV1w_do/viewform

barriers_sameleighton
I want to use this survey to avoid shouting opinions and instead make sure we gather data first. This survey helps us find the biggest barriers so that we can build the best collaboration systems for documentation on OpenStack. Here are the obstacles culled from discussions in the community:

  • The git/gerrit workflow isn’t in my normal work environment
  • The DocBook and WADL (XML source) tools are not in my normal work environment
  • My team or manager doesn’t value documentation so we don’t make time for it
  • Every time I want to contribute to docs, I can’t figure out where to put the information I know
  • When I’ve tried to patch documentation, the review process was difficult or took too long
  • When I’ve contributed to docs, developers changed things without concern for docs, so my efforts were wasted
  • Testing doc patches requires an OpenStack environment I don’t have set up or access to in a lab
  • I think someone else should write the documentation, not me
  • I would only contribute documentation if I were paid to do so

Based on the input from the survey, I want to gather requirements for doc collaboration.

We have different docs for different audiences:

  • cross-project docs for deploy/install/config: openstack-manuals
  • API docs references, standards: api-site and others

These are written with the git/gerrit method. I want to talk about standing up a new docs site that serves our requirements:

Experience:
Solution must be completely open source
Content must be available online
Content must be indexable by search engines
Content must be searchable
Content should be easily cross-linked by topic and type (priority:low)
Enable comments, ratings, and analytics (or ask.openstack.org integration) (priority:low)

Distribution:
Readers must get versions of technical content specific to version of product
Modular authoring of content
Graphic and text content should be stored as files, not in a database
Consumers must get technical content in PDF, html, video, audio
Workflow for review and approval prior to publishing content

Authoring:
Content must be re-usable across authors and personas (Single source)
Must support many content authors with multiple authoring tools
Existing content must migrate smoothly
All content versions need to be comparable (diff) across versions
Content must be organizationally segregated based on user personas
Draft content must be reviewable in HTML
Link maintenance – Links must update with little manual maintenance to avoid broken links and link validation

Please take the survey and make your voice heard! Also please join us at a cross-project session at the OpenStack Summit to discuss doc contributions. We’ll go over the results there. The survey is open until the first week of May.

community work writing

How to Build OpenStack Docs and Contributors through Community

I’m well past the three year mark, working on a new open source project that grows and grows every six months. I’ve been working closely with Diane Fleming at Rackspace to focus completely on upstream OpenStack. Upstream means that all of our documentation work goes to the open source project itself. So while Rackspace runs OpenStack in production and for our customers private clouds, Diane and I focus on documentation that helps any organization run and use OpenStack. We have put together an outline of what we do to make upstream OpenStack documentation better all the time.

Growth, scaling, and related challenges

When I started, there were just two projects with two APIs. Now we have 130 git repositories fostered by over twenty related programs. As you can imagine this scenario causes scaling difficulties but we are bravely making our way. Here are some of the challenges we have faced and what we’ve done to lessen the pain of coordinated, collaborative technical documentation in an open source community.

conversationplus_black_white

In the face of language and technical barriers, the OpenStack docs team used a combination of IRC meetings, documentation boot camp, Google hang-outs, a busy docs-team mailing list, and other methods to create a flourishing, global team of writers and technical contributors who have immensely improved the OpenStack docs in the last couple of years. The release that went out in Spring of 2013, three people wrote half of the docs. For the release that went out in Fall of 2013, seven people wrote half the docs. I can’t wait to see what our numbers are for the release going out next, on April 17th.

Team-building tools – the good, the bad, and the ugly

Here are some benefits and pitfalls of these tools:

  • IRC: Pros – clear agenda, follow-through week-to-week, global participation now that we have APAC and North American meetings. IRC meeting bogs enable an automated log of minutes. Cons: difficult to find agreeable time, no face-to-face, hard to introduce new topics.
  • Office hours: Seemed like a good idea but fell by the wayside, we did not have much attendance. As our team grows, people can stop by the IRC channel at any time to get one-on-one help.
  • Google Hangouts: With the video and voice enabled, it is nice to see each other’s faces without having to travel. Hard to find an agreeable time with the round-the-world team.
  • Boot camp: Extremely positive experience – spawned new ideas and new connections. Downside is the cost/time factor. We had great survey responses but decided we didn’t need one every six months.
  • Mailing list: Good way to resolve immediate issues and gather consensus as well as multiple view points.
  • Book sprints: Good way to get a needed book written and distributed. Not a good way to build ongoing community for maintenance, and in some ways you have to be careful not to build a book that no one else thinks they should contribute to. But community is just one part of good docs – this is a good complement to other efforts.

OpenStack docs – before and after

How have the docs changed due to team building?

  • Cleaner, more compact library. We did a huge refactor prior to the Boot Camp, which has made it easier to specify what types of content goes where.
  • Better writing. Professional technical writers have done an amazing job avoiding “frankendoc” — by editing, reviewing, and polishing with an agreed-upon style guide, we improve the actual writing to better serve readers and users.
  • Better technical content. In OpenStack, teams have core reviewers and most teams require two core reviewers must approve a change before it gets built to the published site. As we expand our reviewers (not just core but many reviewers) our docs have improved technically.
  • Better automation. By writing tools that scrape the code for docstrings we are able to keep up with fast-moving projects that release every six months.
  • Timing with releases. We carefully scope what documents are considered tied to a release. The Install Guides and Configuration Reference are the only two books built from a set release. All other documents are continuously published.

OpenStack contributors – before and after

How have the relationships among contributors and contributors’ roles changed due to team building?

  • Much greater communication among contributors – now we know each other on a more personal level, and feel more comfortable working together
  • Contributors have found where their strengths lie in the community. Some people are more tools and gear heads and build gates and tests and build tools. Some people are natural editors and review heavily with suggested edits. Some people are blue-sky visionaries. Some people are heads-down system administrators and architects. There’s a place for everyone, not just writers.

What’s to come?

We want to discuss revisions to our original vision openly. This blog post is a starting point, but we are listening on all available channels. At the OpenStack Summit in Atlanta in May, I want to collaborate on a request for proposals for a new front-end design for our documentation that can help us make changes to how docs are authored. I’d like to find out more about ways to enable non-CLA contributors to the docs. I have lots of ideas and look forward to working with this amazing group to improve our processes and results.

conversation_black_white

community work

Finding an OpenStack Mentor

Last week I ran an internal “So You Want to be an OpenStack Contributor?” workshop showing the different ways to work on OpenStack. Here’s the slide show so you can see the way I approached it. As the Documentation Program Technical Lead you’d think I’d steer people straight to the documentation bug backlog, but I try to find out where interests lie before going straight to doc fixes. Definitely people should read the docs as a great start.

You can work on OpenStack in non-code ways, such as bug triaging. Also the OpenStack Foundation does community marketing and staffs booths at events from the community. But a great way to understand the ins and outs of OpenStack-landia is to commit a patch.

I have to admit, I didn’t know much when I first started working on OpenStack at Rackspace. The Swift team was the group I had immediate access to in person. Wow were they patient with me while I made hilarious-in-hindsite errors. I had a patch where I changed “referer” one r to “referrer” two rs, because duh that’s how referrer is spelled. Well as it turns out that’s not the way the WC3 HTTP Protocol specifies request headers since 1992 or so, woops! Then I also managed to change the RST backticks (`) to single quotes (‘) which is absolutely not going to render correctly with Sphinx. Chuck Thier patiently explained the errors I had made and how to correct them. So do not be discouraged if it’s difficult to get the hang of your first patch or two or ten. Code reviewers are happy to help you iterate and revise. I’ve heard of good and bad patch reviewing going on in the community so I encourage you to find a real person who can help you get helpful reviews.

We also have organized OpenStack mentor programs now. We’ve been participating in the GNOME Outreach Program for Women for three rounds, and we’re a participating organization with the Google Summer of Code program for 2014. There are ideas for projects on the OpenStack wiki:

We have dedicated IRC channels for new contributors – #openstack-101 and #openstack-opw on freenode. Our OPW interns have written great blog entries about getting started with OpenStack (In a nutshell:how OpenStack works) and DevStack (Installing DevStack with Vagrant). Their fresh eyes make for great starting points. I encourage us all make this work both ways – people of OpenStack, be mentors, and newcomers, seek out the people in OpenStack who want to help you get started. Updated to add: be sure to check out opensource.com for “How to Contribute to OpenStack.”

community techpubs work writing

OpenStack Operations Guide Mini Sprint

oreilly-openstack-ops-guide

We held a two-day mini-sprint in Boston at the end of January to update the OpenStack Operations Guide. You may remember the first five-day sprint was in Austin in February 2013. This time, the sprint was shorter with fewer people in Boston and a few remote, but we had quite specific goals:

  • Update from Folsom to Havana (about a year’s worth of OpenStack features)
  • Roadmap discussion about nova-network and neutron, the two software-defined networking solutions implemented for OpenStack
  • Add upgrade instructions from grizzly to havana
  • Implement and test the use of parts to encapsulate chapters
  • Address editor comments from our developmental editor at O’Reilly
  • Add a reference architecture using RedHat Enterprise Linux and neutron for networking

Some quick wins for adding content were:

We added and updated content like mad during the two days:

The two toughest updates are still in progress, and our deadline for handover to O’Reilly is this Wednesday. The first tough nut to crack was getting agreement on adding an example architecture for Red Hat Enterprise Linux. We are nearly there, just a few more fixes to go, at https://review.openstack.org/#/c/69816/. The second is testing the upgrade process from grizzly to havana on both Ubuntu and RedHat Enterprise Linux. That’s still in progress at https://review.openstack.org/#/c/68936/.

The next steps for the O’Reilly edition are proofreading, copyediting, and indexing over the next six weeks or so. I’ll be keeping the O’Reilly edition in synch with our community-edited guide. As always, anyone in the OpenStack community can contribute to the Operations Guide using the steps on our wiki page. This guide follows the O’Reilly style guide rather than our established OpenStack documentation conventions. I’m looking forward to a great future for this guide and we’re all pretty happy with the results of the second mini-sprint.

Thanks to everyone making this a priority! Our host at MIT was Jon Proulx joined by Everett Toews who braved airport layovers and snow, and Tom Fifield who wrote the most patches despite a complete lack of sleep. Joe Topjian worked on edits for months leading up and has been tireless in making sure our integrity and truth lives on through this guide. Thanks too to the the hard working developmental editor at O’Reilly who offered lunch in Boston, Brian Anderson, joined by Andy Oram. David Cramer got DocBook parts working for us in time for the sprint. Summer Long worked long and hard on the example architecture for RedHat. Our remote reviewers Matt Kassawara, Andreas Jaeger, and Steve Gordon were so valuable during the process and ongoing. Shilla Saebi gave some nice copyediting this past week. What an effort!

community content strategy techpubs tools

A Few of my Favorite Things for 2013

tumblr_m8lsqnjijt1qgx2ojo4_250

This year has been filled with interesting finds, discoveries, and productivity. Plus oxford commas! Here are my favorite things for 2013.

The Hunger Games trilogy, because it’s like a window into a mind of a smart writer who writes with purpose.

The Documentation chapter of the Developer Support Handbook has to be one of my very favorite things I discovered this year. I’m on the Developer Relations Group team at Rackspace and this is a great handbook for all of our team.

Animated GIFs, pronounced jifs, am I right? OpenStack Reactions cracks me up.


Grace Hopper Conference by the Anita Borg Institute, especially the Open Source day, and the GNOME Outreach Program for Women which OpenStack started participating in this year. Women in technology are my favorite!

The Houzz App on my Android tablet for eye candy while messy remodeling was actually happening. Plus it’s the best content remix site I’ve seen in a while, more targeted than Pinterest.

Photo kids

Probably the best photo of my kids this year, I make it a favorite because at their ages it’s difficult to get one of the both of them.

OpenStack Docs Boot Camp

OpenStack Security Guide book sprint, read it at http://docs.openstack.org/sec/.

oreilly-openstack-ops-guide

OpenStack Operations Guide book sprint, now an O’Reilly edition, read it at http://docs.openstack.org/ops/.

How about you? What are some of your favorite things from this past year?

community

Reflecting on the OpenStack Summit in Hong Kong

We have come such a long way since November 9, 2010, when I attended my first-ever OpenStack Summit in San Antonio Texas. I couldn’t pronounce Vishvananda Ishaya’s name, I kept interchanging swift and nova code names, and I could hardly remember two Linux commands in a row. But I got some great t-shirts, kept asking questions, got answers from encouraging co-workers and community members, and I learned as quickly as I could. Fake it ’til you make it, right? Fast forward three years, and we come to the first non-US-based OpenStack Summit in Hong Kong, my seventh. Here’s a summary of my favorites.

Dragon welcome dance

What else would we do to get ready for the Summit on the other side of the globe than be welcomed by two dancing dragons! This was a perfect start to the week.
Dragon dance opening

Summit 101 session

I helped with the OpenStack Design Summit 101 again this time, where we let newcomers know how the sessions go, what to expect, how to get the most out of the sessions. Loïc Dachary, Thierry Carrez and I talked about what PTLs want to get out of the summit, how blueprints work, and fielded good questions, all of which are Q&A on https://etherpad.openstack.org/p/icehouse-101. Here are a couple, see the Etherpad for more.
Q: Is the idea to discuss one specific blueprint?
A: More generally, how to we do X, and what blueprints are required to do that. Depends on the session, what blueprints already exist in the area, impact on multiple projects, etc.

Q: Do we make decisions about the specifics of the design?
A: Again depends on session, some session leaders will want a recorded decision as the outcome of the session. At the very least at the end of the session aim to know what the next step is.

If you’re curious, this is pretty much what design summit sessions look like. We intently read the Etherpad displayed on the screen, and if you sit forward, it means you have something to contribute to the discussion.

In an Infra session

Install guide, unleashed

Midweek, I had to make an observation – we’ve never had a working install guide at the Summit until Havana, and the fact we have one has been super helpful for getting it tested. There were doc comments overnight each day of the Summit. I told the docs team through the mailing list:

We need to be sure we are keeping up with the changes to the install guide by fixing what people tell us is wrong. Let’s make install guide bug fixes top priority for the next week to capitalize on all the testing that has come in.

Also, please update https://wiki.openstack.org/wiki/HavanaDocTesting. For example, there are doc comments confirming a page works on 13.04. We need to ensure that’s captured in the wiki page so we have an accurate assessment.

Thanks all for the work on the install guide — it is paying off, let’s take the time to clean up what’s being tested.

Sure enough, we have merged in over 50 changes in a week, complete with backports to ensure the Havana install guide gets better and better.

Meet the Technical Committee

One of the highlights of the week was the opportunity to sit on the big stage with my fellow technical committee members. We answered prepared questions from Thierry Carrez, and also queries from the audience. One audience question I didn’t jump on is at 32:40, “… you’re representative of your communities, we are in China, but there is no Asian on the podium. What can you do to actually try to improve the situation?”

John Griffith answered, it’s a matter of who has contributed, and who wants it badly enough to do the work and lead the way. Michael Still said, “You have to be in it to win it,” and noted that Beijing had the highest number last release, but it’ll take time for contributors to self-nominate and run for a spot. Mark McClain noted that as a contributor from Ireland, he has faced the facts as well that he’s in a region with fewer contributors, but he acknowledges how much our understanding of a meritocracy is cultural, and that it’s not shared by everyone. We have to talk about diversity because we don’t have a massive amount of it. I agree that it’s not easy, and I know what it means to feel underrepresented. I think outreach is a great path forward, and I’m dedicated to it for women. I’d love to see more outreach to other communities and learn from them the cultural norms that we can take to the TC and keep working on diversity. It’s a marathon and not a sprint, that’s for certain. We can get better as a community, though, and we need to iterate on ideas all the time. Glad it was brought up in this forum.

Meet the OpenStack Technical Committee

OpenStack Operations Guide

We announced the O’Reilly Early Edition of the OpenStack Operations Guide last week. I had some fun on Twitter trying to get people to guess the animal on the cover. I blogged about it on the OpenStack blog, take a look.

Hong Kong itself

The most incredible thing about OpenStack Summits is all the stackers there together. I never had trouble finding people to go sightseeing with. Here’s the one sightseeing day I had, going on a “crystal bottom” cable car ride to get to a big Buddha statue with a monastery nearby with my teammate Everett Toews, whose write up is on his blog.

Untitled

We went to the Night Market one evening to buy gifts and eat super fresh seafood. 
Untitled

All in all it was an amazing trip and another great Summit. I’m so grateful to the OpenStack Foundation and Rackspace for making it happen for me for the seventh time. Feels like a lucky Summit.

community wiki work writing

Game Changers: Rackspace supporting Girlstart here in Austin

Creative, brave, resilient, these are all words we cherish for our daughters, our best friends, our coworkers, all those who have faced any sort of technical or scientific challenge and wondered if they were up to it. Rackspace sponsored at table at the GirlStart Game Changers Luncheon yesterday and we managed to overflow one table to another. We had a great time!

IMG_0038

Girlstart is an Austin-based organization that offers after-school and summer camps for girls to try science, technology, engineering, and math through fun experiments and solving real problems. We had a great time listening to Mythbuster’s Kari Byron talk about her journey to science ed TV from sculptor to tester of myths. One especially grabbing tale was a test for the smell of fear in a glass coffin trapped with a mass amount of crawling scorpions.

One story of hers that stuck with me was how she got her start with special effects work in the M5 studio, owned by Jamie Hyneman. A friend encouraged her to go see what special effects were all about, thinking there was more money in movie-making artisan work than other starving artist outlets. She was so inspired she went back to put together a portfolio and told him she’d work for free so she could learn as much as possible about making effects and movie props. Well as it turns out, Jamie’s a frugal guy, and definitely got returns on his not-too-much-investment!

IMG_0041

In listening to her story I realized there’s a parallel to my journey to open source. I was interested in “how are wikis really working for technical documentation?” so I offered to work for free on one. Turns out, that volunteer effort launched me into the career I have now, working on a large open source documentation efforts for OpenStack, the open source cloud. I could identify with the need to be brave, creative, empowered, resilient, and all of those are offered to me while working on OpenStack and in open source. How about you, when have you volunteered for work just to learn as much as you could about the work?