community work

Google I/O 2015, Looking Back and Forward

I wore my Google I/O t-shirt the other day while hiking, and realized I hadn’t posted a write up from that developer conference back in May 2015. This year they had a big push towards bringing women to the conference through effective methods.

Google has an Android developer community called Women Techmakers, led by Natalie Villabos. She did an amazing job with the event itself, but what most impressed me was the building of community prior to the event through the use of Slack, emailed communications, and networking opportunities both online and in person. Natalie said they went from 10% female attendees in 2013 to 23% this year. The first night I went to a Women Techmakers dinner was at an amazing Peruvian restaurant. The giveaways were lovely zippered canvas bags with Adafruit’s Gemma wearables package for hacking on later, which is awesome. I got the system working the other night, and ordered an additional soft potentiometer hoodie pull so I can make this project with the hoodie I bought at the conference.

Gemma kit

This article offers a good overview of what they did to get more women to I/O. Here’s a short list:

  • Grants
  • Hackathons
  • Nominations from Googlers
  • Reserved invites to women coding groups
  • Dinners together
  • Network enablement such as a Slack channel before and after the event

I sat with three women at dinner: one is an engineer at Quora in SF, about a year out of college, the other was a product manager at Fox News in New York City for their app work, and the third I spoke to most is a developer at

Faves and Raves

On Tap Now demo — or, how to not lose 20 minutes to your phone — was an example of a truly amazing context search. First, it brings us back to why we love Google in the first place. Second, she had a Skrillex song up and said, “OK Google, what’s his name.” I kid you not, I audibly gasped when it “just worked” and said “His name is John Moore.”

Expeditions gives Cardboard/VR to kids in classrooms. I went to this demo and it was pretty cool, we all sat on 360-degree swivel stools and turned to see what the “teacher” pointed us to in the VR screens. It was like having a fancy view finder. We went to Versailles in France, which I had very recently visited. It was impressive, but one aspect that threw me off was the cameras must have been super high off the ground. The Hall of Mirrors felt like I was floating through it rather than walking through it. But wow, what a cool experience for a classroom of kids. My second grader absolutely LOVED this.

Jump gives 16 cameras to do VR recording (Go Pro made one), Google assembler then makes it so you can interpolate the viewpoints and get 3 dimensions (depth-corrected stereo). gopro jump
I just read an article that said YouTube supports Cardboard for its videos now, here’s the help page.

Developer advocacy observations

Half the dev sessions were in these “alcoves” which were rooms created with cardboard tubes and boxes. It made for difficult hearing the presenter, even with mics on. Basically, no one left their comfy seating, so it was extremely hard to go around to different sessions.
cardboard alcove

I went to a Firebase demo, which had a great example of a developer advocate trying to identify with audience and do story telling. They did an example app that’s a chat application in a web browser that the audience could interact with right there. He could also turn the example chat off quickly if the crowd got out of hand in playing with it live. Side-by-side display made for a great demo as the noSQL updated before our very eyes.

Women at conferences, what’s in store?

As I reflect back on what it was like to go to a large tech conference with at least twice as many women as any I’d been to, I felt like the proof in the techniques to get us there is going to be in the return rate and the new signup rate. Will women feel like it was “their” conference too? Will they be annoyed with the overcrowding and not feel like it’s worth the extra effort to get on a plane? Will women keep returning because they’re there with their friends and it’s a tradition? Will women be more likely to spread the word about the conference itself to a wider group than just developers? I heard a woman explaining Google I/O to a man on the BART transit back to the airport, and thought, I haven’t seen much of that type of evangelism to the general public before. I think it’s going to take a while to see the effects of the special outreach efforts. I definitely think the diversity in networking effect is going to make a lasting change in the system. I sure hope so.


Lastly, I give you a great tweet from the guy in the hat in this picture said it with tongue in cheek, “14.2% men in tech at #io15.”
14.2 % men at Google I/O

Here’s the code lab I worked through.

Here are talks I watched later:

To tell even more of the story, here are all my photos from Google I/O, appropriately uploaded to the announced-at-I/O Google Photos, with captions.

techpubs writing

Treat Docs like Code: Doc Bugs and Issues

This is a follow on to a post on about using git and GitHub for technical documentation. In the article, I discuss reviews and keeping up with contributions. This post talks about fixes and patches.


What about doc issues in GitHub, how do you get through all those?

In OpenStack, we document how to triage doc bugs, and that’s what you need to do in GitHub, is establish your process for incoming issues. Use Labels in GitHub to indicate the status and priority. Basically, you have to accept that it’s a doc bug, if it’s not a doc bug, ask for more information from the reporter. If you want to create labels for particular deliverables, like the API doc or end-user doc, you can further organize your doc issues. You will need to define priorities as well — what’s critical and must be fixed? What’s more “wishlist” and you’ll get to it when you can? If you use similar systems for both issues and pull requests you’ll have your work prioritized for you when you look at the GitHub backlog.

How can you encourage contributors to create a good pull request for docs?

The best answer for this is “documentation” but also great onboarding. Make sure someone’s first pull request is handled well with a personal touch. There’s a lot of coaching going on when you do reviews. Ensure that you’ve written up “What goes where” as this is often the hardest part of doc maintenance for a large body of work that already exists. This expansion problem is only getting harder in OpenStack as more projects are added. We’re having a lot of documentation sessions at the OpenStack Summit this week and we’d love to talk more about creating good doc patches.

One person I work with uses GitHub emojis every chance he gets when he reviews pull requests. I think that’s fun and sets a nice tone for reviews.

Nitpicking can be averted if you point to your style guide and conventions with a good orientation to a newcomer so that new contributors don’t get turned off by feeling nitpicked.

Have you heard of anyone who has combined GitHub with a different UI “top layer” to simplify the UI?

O’Reilly has done this with their Atlas platform. For reviews, the Gerrit UI has been extremely useful to a large collection of projects like OpenStack. There’s Penflip, which is a better frontend for writers than GitHub. The background story is great in that it offers anecdotes about GitHub being super successful for collaborative writing projects.

I think that GitHub itself is fine if your docs are treated like code. I think GitHub is great for technical writing, API documentation, and the like. Academic writers haven’t found GitHub that much of a match for their collaborative writing, see “The Limitations of GitHub for Writers” for example. It’s the actual terms that have to be adapted and adopted for GitHub to be a match for writers. For example, do you track doc bugs (issues) and write collaboratively with added content treated like software features? I say, yes!

If you just want simple markup like markdown for collaborative writing, check out Beegit. With git in the name I have to wonder if it’s git-backed, but couldn’t figure it out from a few minutes on their site. Looks promising but again, for treating docs like code, living and working with developers.


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!


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?

work writing

Be sure to read about my Stacker journey

The editors at The New Stack do great things with their articles, and mine is no exception! Be sure to read Anne Gentle: One Stacker’s Journey.

Even though I’ve lived in Austin, Texas, for over 14 years now, I tend to say I’m a midwesterner when asked. There are traits associated with the spirit of the midwest that I’ll always identify in myself: hard work, resource creativity and conservation, humility, and a sense of wonder at trends being set somewhere in the world. Read more…


State of the Migration to Sphinx/RST

I wanted to document the migration journey while we are in the middle of it. Last week the OpenStack Super User site did a great article about the migration, How you can help with the documentation site refresh. We talked about the reasons for it: enable more contributors, offer simpler markup, be more Pythonic.

And more Pythonic we are. Let’s dig into what’s going on with the migration, what we’ve learned, and what we still have to learn.

Migration process

We’re nearly done with patches to review converted End User Guide files, but just a few Admin User Guide files are complete. Sign up on the OpenStack wiki at Documentation/Migrate. I’ve figured out how to include certain files in a build conditionally with an extension we’ll call “scope” for now. Using (and abusing) the meta information by putting a special directive in a file meant for admin-only lets us “tag” certain files for inclusion and build output with those files included.

New content page design
New content page design

How to build locally

We have always had tox jobs for building and testing the docs. The newest one runs the sphinx-build command for the end user guide.

If you don’t want to use tox, install these prereqs locally to test only the build:

pip install sphinx; pip install openstackdocstheme

Next, switch to the directory containing a and run:

sphinx-build /path/to/source/ path/to/build/

This command builds html output by default.

In troubleshooting some markup I found that the sphinx-build command does not give as much information about the markup as python build_sphinx does. So I will test a switch with a file as well as a file for each guide in the openstack-manuals repo.

To build locally with tox, follow the instructions on the wiki page. Building with tox is preferred as that matches our gate tests for patches. Feel free to ask for help in #openstack-doc on freenode IRC if you run into errors. We have tested the instructions on Linux, Mac, and Windows.

Conventions and editing RST markup

Docs tools guru Andreas Jaeger already had a head start in adding RST markup conventions to our Documentation/Markup_conventions wiki page on the OpenStack wiki. I’m finding that there are some types of content, such as extra information embedded in a list item like a table, that just can’t come over in its current state. I’m still working through these questions and it seems as though numbered lists can’t have much more than single list items. Anyone with info, please let us know if these are possible:

  • How to get numbered list continuation to work when you have a table after a #. list item?
  • How to get numbered list continuation to work when you have a bulleted list between #. list items?
  • How to get get embedded .. note: directives to work between numbered list items?

Matt Kassawara asked if there is a side-by-side editor for RST like there is for Markdown, and so far there is not, but the Sphinx development mailing list has a thread about what authors currently do as well as what they’d like to build.


We still need output bugs fixed. To me, the top priorities are:

  1. Sphinx template needs precise “Log a doc bug” link created on-demand similar to current functionality
  2. Sphinx openstackdocstheme needs to be tested for the translation toolchain
  3. Sphinx openstackdocstheme doesn’t style admonitions (note, warning, important) correctly
  4. Plus sign appearing when numbered list followed by bulleted list

What I need to understand is what would compel us to update Sphinx itself, considering we don’t know when their next release is. We already pin to a beta version (1.3b) so perhaps  we can patch as needed and pin our version.


Generally, make sure your Python environment is installed and ready to go, and then use a virtualenv to be sure you have “corded off” the environment and know exactly what’s installed.

Use “pip freeze” to get a list of what is installed. If a package is missing, make sure you have access to pypi by running the pip install command with -vvv. Also if you’re not working in a virtualenv, ensure you run the install command with sudo on Mac or Linux.

If you’re working within a virtual machine like VirtualBox, you may find that networking settings change even if you go from wired to wireless or from one wireless network to another.

If the output looks strange to you, delete the /build/ directory then re-build. I suspect that CSS and JS files remain outdated or are not copied over every time.

Please log bugs in openstack-manuals with the tag “openstackdocstheme” if you see bugs in the output.

What this means for new guides in progress

The only new guide in progress is the Networking Guide and some of it’s in markdown, some of it’s in DocBook, and all of it can go to RST. We must get the translation toolchain working prior to publishing, and I’d prefer to get more output bugs fixed prior to switching any more guides.


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,, and 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 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, 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 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 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!


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.


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

API techpubs tools work

API Archaeology: Complexity and sizing of an interface

For both OpenStack and Rackspace cloud APIs, we use WADL, Web Application Description Language, to build an API reference listing for all REST API calls. In a previous post I discuss how the reference pages at are made with WADL source and a Maven plugin, clouddocs-maven-plugin. You can see the output for the Rackspace API reference page at, built with the same tool chain but different branding through CSS. I can discuss the tooling decision process in another post, but let’s talk about ongoing upkeep and maintenance of this type of API reference information.

In this post I want to dig beneath the surface to discover how complex these APIs are, how that complexity might translate into difficulty or time spent in documenting the interfaces, and discuss some of the ways you could assign the work for creating and maintaining reference information for APIs. In another post I said, start with a list. This post looks into what happens after you have a list and need more lists to know the shape and size of your API and its documentation needs.

Some of the complexity also lies in documenting the parameters and headers for each API. Just like unearthing the walls of an ancient structure, you can look at the various ways an API is put together by looking at the number of calls, the number of parameters on each call, whether there are headers on any given call, and how the calls are grouped and related. I’ve summarized some of that below for the comparison cultures, er, grouped APIs.



A call is defined as a GET PUT POST DELETE command sent to a resource. These are known as HTTP verbs.

A header is defined as an optional or required component of a HTTP request or response. There are plenty of standard headers, what I’m talking about here are the extra headers defined by the API you document specifically.

A parameter may be a query parameter or provide a way to filter the response for example. Parameters specify a varying part of the resource and your users need to know what parameters are available and what they can do with them.

Running the numbers

To get these numbers, I first built each reference site so that the WADL files can be built into a single folder, which lets me do a grep for a count.

So I cloned each repo, ran mvn clean generate-sources with in the api-ref directory, then ran this command from with in from within api-site/api-ref/target/docbkx/html

grep -c “rax:id” wadls/*.wadl | sort -n -k2 -t:

Then I imported the output from the command as a colon-delimited file to a spreadsheet to get these counts.
OpenStack API Reference Metrics
Number of Compute v2.0 calls:290
Number of Networking v2.0 calls:92
Number of Orchestration v1.0 calls:41
Total documented calls:755

Rackspace API Reference
Number of Cloud Files calls:21
Number of Compute v2.0 calls:70
Number of Networking v2.0 calls:18
Total documented calls:670

Here’s a breakdown for just a few of the OpenStack APIs header and parameter counts.
Object Storage API Parameters: 12, Headers: 75
Volume API Parameters: 23 Headers: 0
Compute core API Parameters: 69 Headers: 1

Other metrics

We track doc bugs for the OpenStack API reference in Launchpad with the openstack-api-site project. There are nearly 200 doc bugs logged against the API Reference right now.

The three APIs with the most calls for Rackspace are Monitoring, Email & Apps, and Load Balancers, all of which are not OpenStack APIs. So a full two-thirds of Rackspace calls are not OpenStack-sourced. However, this means that a full third of Rackspace calls are identical to OpenStack.

What are some of the differences between OpenStack and Rackspace?
Extensions are complete in OpenStack; Rackspace only implements a handful of extensions.

Internal (admin-only) and external (user) calls are documented in OpenStack; Rackspace API Ref only documents external calls.

Rackspace has paid API writers and accepts pull requests on Github; OpenStack docs are written by writers and developers in the community (often with corporate sponsors) using the OpenStack gerrit process.


So that’s a lot of numbers, but what’s your point? My point is that making lists helps you determine the size and complexity of documenting multiple APIs. Not all companies or projects will have more than one API to document, but as we move towards more application interfaces for more business reasons, I believe that writers and developers need to get really accurate in their estimations of just how much time to allocate to document their APIs and do it well. Since these estimates are for API reference information only, don’t fail to also estimate time to write and maintain viable, tested example code as well. That’s a post for another day, thanks for reading about the complexity and comparison of OpenStack and Rackspace cloud APIs.

content strategy techpubs

How to get started writing API docs

I know a lot of people who want to consume awesome API docs. Let’s talk about what it takes to get started writing them. I’m not talking about completing your API docs. I’m talking about just getting started, what does it take?

For API documentation especially REST APIs, I’d advocate a reference-first approach. Like the couch to 5K program for running, let’s start API documentation on your couch. You look under your coffee table and find your shoes. You pull them on (make sure you have wrinkle-free socks!) and lace them up. You’re ready!
Please write API docs! Photo courtesy jypsygen on Flickr.

If you are working on REST APIs, I’d also recommend understanding how they’re designed. I like the book, “A Practical Approach to API Design:From Principles to Practice,” by D Keith Casey Jr. and James Higginbotham. You can read a sample for free online, and then support their efforts by buying a copy at a price you set!

If you work is with another style of API, be sure you understand the underlying reasons for using that interface. It’ll help you understand your audience first.
Make a list. First, a list of all the calls. Then for each call, make a list of requirements. What must a user give to the interface to get back what they want? What are the requests, what are the responses? Then list the optional parameters the call can take. Are there any headers that can be sent or received? Be sure to write those on your list also.

Let’s not get tied up in tools yet, this initial writing work can be on a notebook or any text editor. You don’t run out and buy an expensive heart monitor or activity sensor when you’re just starting out as a runner. Figure out how far you can get with a pair of shoes (your notebook) before investing in cool tools and gear. Otherwise, you’ll get distracted by the cool tools and gear and not write stuff down!

With these lists, you’re building scaffolding. Just like a running program, you need to make a pattern to learn to pace yourself and spend your energy wisely. Once you have a list of the calls, you can write or diagram the users, the tasks they want to complete, and then see if your reference is filled in for all the users and tasks. I highly advocate the reference-first approach as it’ll help you test the completeness and helpfulness of your documentation.

I have some additional posts I’m writing for this year where I want to dive into increasing complexity of APIs so that writers and develeopers can estimate the amout of time needed for good documentation. I’ll also analyze some tooling for REST API documentation and offer benefits and tradeoffs for different tools. Looking forward to digging into API documentation in 2015!

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.


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.

blogging writing

More posts around the web

Seems like more and more I’m writing everywhere but here! I wanted to do a round-up of some of my writing around the web.

On the Rackspace Developer Blog: Austin Ladies Hackathon

This weekend was a blast, hacking with all women at Rackspace, and wow were the projects impressive. Here’s how it went.

Friday night we gathered at a restaurant, the Flying Saucer, to meet each other and start to form teams. I’d guessimate that 20 of the 30 participants showed up. I helped out by facilitating discussions for people to find teams, and I spent a lot of the night talking to complete newcomers about what a hackathon is like, what to expect, and especially how to learn at one. We also recruited for the upcoming NoSQL Mobile App Challenge ( (Read more …)

On the O’Reilly Radar blog: The book sprint: Not just for code any more

Do you really want a technical book for your project? Does your community need to provide more helpful docs to support even more users? Does your community have a lot of knowledge they need to get out of heads and into bits and bytes? Do you have a good mix of technical experts and technical writers and users who would enjoy each other’s company for a week of hard work?
If the answer is yes, then consider a book sprint. (Read more…)

On the blog: The Women of OpenStack talk outreach, education, and mentoring

In the open source world, a women-only event seems counter-intuitive. Yet I am finding reasons for such events the more I attend them.

At the OpenStack Summit, a twice-a-year event where OpenStack contributors get together to plan the next release, the Women of OpenStack group has set up events where we invite the women first. Men aren’t excluded, but our hope is to get more OpenStack women together. I can hardly capture the value of getting together with other women in OpenStack at the Summit, but here goes.(Read more…)