2. 2015
Questions at the end…
…but you can always
ask me anything:
documenting 20 cloud services
across 130 GitHub repositories
With 800 docs contributors in 4 years
@annegentle, #GHC2015
anne.gentle@rackspace.com
www.justwriteclick.com
3. 2015
Git and GitHub
2005 born after spectacular Linux tooling failure
Social web, leads to social coding
Git is for command line, GitHub is the web interface
Cross-platform tooling - Windows, Mac, Linux
Merge files rather than a “lock and checkout” model
Non-linear branching model
4. 2015
GitHub Vocabulary
BRANCH
Indicator of
divergence
from base
COMMIT
Point in time
snapshot of
repository with
changes
FORK
Copy
repository,
copy of
repository
PUSH
Move changes
branch to
branch
ORGANIZATION
Collection of
repositories
PULL REQUEST
Comparison of
edits to see if
team wants to
accept changes
RESPOSITORY
Collection of
stored code or
documentation
ISSUE
Defects, tasks,
or feature
requests
7. 2015
MOTIVATIONS
Ensure that contributors are
valued and rewarded!
Sense of belonging
Pay it forward (reciprocity)
Effective, time-saving, user support
Reputation, recruiting
Flickr:elkaypics
8. 2015
MOTIVATIONS
Ensure that contributors are
valued and rewarded!
Sense of belonging
Pay it forward (reciprocity)
Effective, time-saving, user support
Reputation, recruiting
LET’S CURATE
Authors
Processes
Tools
Mindsets
Attitudes
Jobs
Flickr:roswellsgirl
9. 2015
MOTIVATIONS
Ensure that contributors are
valued and rewarded!
Sense of belonging
Pay it forward (reciprocity)
Effective, time-saving, user support
Reputation, recruiting
TREAT DOCS
LIKE CODE
Flickr:roswellsgirl
10. 2015
Long Tail Contributions
Rise of the niche
Finding like-minded
people interested in
your content
Dark corners of
knowledge gap are
filled with docs
12. 2015
Doc Issues Tracking
Tasks, outright errors
and feature requests
I’ll triage the issue and
guide you in fixing it,
issue reporter
http://guides.github.com/f
eatures/issues/
13. 2015
Writers Never Get Reviews
Documentation system
so separate from code
system that technical
reviews are through
email
Or
*gasp*
Frozen-in-time PDF files Flickr:elkaypics
14. 2015
Reviewers Fix Docs
“This is wrong, here’s how to fix it”
Working in the same
collaboration tools as technical
people gives better reviews
We can merge as many as 50
patches per day; running four
automated tests per patch and
requiring two humans to check
the patch and click in order to
publish
17. 2015
White Coat Tools
Closely guarded secrets
of proprietary tool chains
with expensive per-seat
licenses
Or
Secret developer
workflows are
mysterious to writers
Flickr:darthnick
18. 2015
Beautiful Docs
Widely accepted
tooling built in the
open so we can make it
work for us and for
devs (readthedocs.org)
Simple markup
Flat file builds
We can patch and log
issues against the
tooling
19. 2015
ONLY DEV
TEAMS GET CI/CD
Deploying containers and micro
services oh my.
Docs, use some horrifyingly slow
proprietary tool, kthnxbai.
Flickr:photohome_uk
20. 2015
CI/CD FOR ALL
Docs can be published automatically after
reviewers merge the change
Docs can have simple tests to ensure quality
and that you “don’t break the build.”
Scrape the code to build more helpful docs
(especially reference)
https://opensource.com/business/15/7/cont
inuous-integration-and-continuous-
delivery-documentation
Flickr:pedrovenzini
21. 2015
What Pairs Well with GitHub?
Simple markup: Markdown, RST
GitHub Pages: http://pages.github.com
Static site generators:
https://staticsitegenerators.net/
Well-documented style guide and
contributor guide
Open licensing: Creative Commons
Borrowing development techniques
22. 2015
========================================
Discover the version number for a client
========================================
Run the following command to discover the version number for a
client:
.. code-block:: console
$ PROJECT --version
For example, to see the version number for the ``nova`` client, run the
following command:
.. code-block:: console
$ nova --version
2.31.0
Source | Output
23. 2015
Who Uses Git and GitHub?
O’Reilly Media for book publishing
GitHub uses GitHub to document GitHub
OpenStack uses open source Git
Rackspace Cloud documentation uses GitHub
Many, many more organizations
25. 2015
Flickr:pedrovenzini
What Are Some
Difficulties?
Scope and scale questions
Official-ness
Identity
Naming
Flickr:davebloggs007
QUALITY GATE
You shall not pass…
Test for unwanted
white space
Test docs syntax
Test docs build
26. 2015
Flickr:pedrovenzini
What Are Some
Difficulties?
Scope and scale questions
Official-ness
Identity
Naming
Flickr:hddod
END THE TEDIUM
ENABLE THE ROBOTS
Build the docs and publish them
to drafts or staging area
Docs are always available for
reviews
27. 2015
Flickr:pedrovenzini
Coach Better Writing
Become the experts and
consultations while
enabling others to improve
their writing
The people with the
knowledge can become
better writers and learn
more empathy by writing
for the users
Flickr:philgaldys
28. 2015
Flickr:pedrovenzini
What Are Some
Difficulties?
Scope and scale questions
Official-ness
Identity
Naming
Flickr:mortimer
CREATE TEAMS
We now divide the work by
deliverable: user guides, install
guides, configuration guides
We scrape the code as often as
we can to deliver continuously
29. 2015
Flickr:pedrovenzini
What Are Some
Difficulties?
Scope and scale questions
Official-ness
Identity
Naming
Flickr:turbojoe
BUILD A REPUTATION
Measure quality and quantity
Count contributions and
improvements
Compare over time; benchmark
and reward
30. 2015
“We’re crazy, but
we’re writing a book
in five days.”
- Anne Gentle
https://youtube.com/watch?v-
IYfHEy6E2n0
32. 2015
MOTIVATIONS
Ensure that contributors are
valued and rewarded!
Sense of belonging
Pay it forward (reciprocity)
Effective, time-saving, user support
Reputation, recruiting
33. 2015
Got Feedback?
Rate and Review the session using the GHC
Mobile App
To download visit www.gracehopper.org
Editor's Notes
Welcome everyone, I can’t wait to tell you about my experiences collaborating on GitHub.
If I told you we had over 1900 documentation changes you might rightly ask, in what time period and how many people are on your team. If I said 6 months time with over 300 people you might snort some diet Coke out of your nose. Yes, we have evidence that our techniques can give us over 300 doc changes in a month. Let’s talk more about how.
I’m Anne Gentle and you can ask me anything, but I’ll ask that you jot down your questions and save them until the end.
I’ve been working on open source documentation since 2007 or so and working on OpenStack at Rackspace for almost five years. OpenStack offers open source cloud computing software. Developer contributors number in the 4,000s. I wrote the book, Conversation and Community: The Social Web for Documentation and I’ve been working on the principals in practice ever since. Today I’m going to tell some stories about documentation across multiple GitHub repositories. Let’s get started.
Like many tools, git and GitHub were created by fire — through a pressing need for performant and efficient source control management for the Linux kernel.
I’ve found that the principles in the social web for coding works extremely well for documentation as well.
Plus, our modern documentation needs are very driven by the way software today is developed - tightly with code, Agile methods, and web output first, print output secondary if at all. Releasing with software matters also.
Yes, fork can be a verb and a noun.
These terms can mean you will have decisions to make about information architecture so pay attention.
You can also keep docs in a source code repository then the developers will have to review all your changes prior to merging them in.
Unlike traditional source code management, branches are not full copies of entire code base so they are “cheap” and “fast.”
Assignments over the wall
Project-centric instead of user-centric
Deadlines set by dev not docs
Devs write for dev, operators write for operators, users write for users
This is not about free labor. Contributors should be highly, highly valued and rewarded.
Let’s curate authors, not just content.
Let’s curate processes to create jobs.
OpenStack Glossary appearing from a sys admin in Iowa on the wiki; bringing it into the official OpenStack docs.
Logged a doc bug late in my work day, came in to a patch the next morning that fixed it.
The Long Tail for open source docs is the obscure knowledge gathering and hard-to-find info
This is my frowny bug face. What can we do about it? Issue tracking.
Tell me which page.
Tell me your expectations for that page.
Tell me how to fix it.
We have systems in place that let us merge as many as 50 doc patches a day, though typically it's about 15. Each reviewer who can publish must adhere to our review rules.
Truth: Working in the same collaboration tools as technical people gives better reviews.
Story of install guide: I wrote the first one in 2012, hired a contractor for a revision, and then another person completely testing the entire install guide for OpenStack since he had to do a proof of concept at work, testing it completely.
In Open Source, we don’t want the docs group to be misunderstood or second-class citizens. Take your seat at the contributor table.
Writers contributions, when treated like code, are valued equally with developer coding.
We give free passes to the OpenStack Summit for docs contributions because the patching and review processes are identical.
Imagining a doctor or surgeon with very specialized expensive tooling
or
Developers arrogantly think they rule despite a lack of documentation so no one can use their code
This leads to continuous integration for docs.
Continuous Integration/Continuous Deployment
Mimic production environment in your local environment.
Development teams do continuous integration and deployment; completely mimicking their local environment in production and continuously updating the code and product to make it better
Example: scrape the current code for reference information and use the code itself to build the docs. - documented over 6,000 configuration options this way
working on REST API docs this way as well, building Swagger
399 static site generators. So let’s see what this looks like in practice.
The source file in this case is in RST, ReStructuredText, used by Python developers and for making web pages. You can also view it on GitHub to see it rendered with their simple renderer. Lastly, see the built documentation on the docs.openstack.org site with more navigation and web design and styling.
Technical authors want to use technical tools.
Writers tend to, well, review writing quality first, technical quality second. Can still have an “us vs. them” mentality from reviewers when doc writers nit pick about style rather than adding value.
Who’s the audience? Multiple hats for multiple audiences
What’s the name? Naming is the toughest problem in docs
Scaling across repositories is really difficult. People still write content in their blog and ask you to bring it in to official doc. Scope for “official” can be difficult.
Round the clock publishing, reviewers burden lifted by having gate checks.
Lets experts review for content and organization; do higher level technical editing and technical tests as well on the content. Curate the content as a focus rather than messing around a bunch with the process. We have even automated the translation tool exports and imports. Also when sharing content we can automate the file copying.
I’ve never had a developer not help me improve my programming skills. Let’s reciprocate.
Just today I made a simple suggestion for someone to eliminate the use of “will” and he was super excited to delete those and improve his writing.
Specialty teams now abound — subject matter experts for security, for high availability. This lets us deliver more complex content more often.
GitHub shows who is contributing and to what areas. I’m now an O’Reilly author along with six other collaborators.
The people with the knowledge can become better writers and learn more empathy by writing for the users. This, to me, is the New Bliss, the new way to work on documentation together. What does it look like in practice? Let’s take a look.
https://www.youtube.com/watch?v=lYfHEy6E2n0
A couple of notes: that sprint tool is moving to GitHub. Also this book was then edited by O’Reilly and offered a set of info not available another way. Each author had run OpenStack for at least six months in production and brought all their notes and docs as well, wanting to share with others.
“We’ll help them hate their managers just a little bit less.” - Tom Fifield
“Our facilitator is whipping us repeatedly to get us to work on the content repeatedly so we’re writing the book in about four days.” - Everett Toews
Have I set a vision that seems attainable? What are your questions?
After this I have a final vision for you that should show you what’s old is new again.
Booth 1001
Tight collaboration, equal footing with dev, and a value proposition that puts both dev and doc on the path to well-loved customer experience. The new bliss:
What docs like code looks like
What happens when you release with code
What happens when you invite developers and users to write with you
This new normal for documentation, imagine what it can do for you
This is the last slide and must be included in the slide deck