Black lives matter.
We stand in solidarity with the Black community.
Racism is unacceptable.
It conflicts with the core values of the Kubernetes project and our community does not tolerate it.
We stand in solidarity with the Black community.
Racism is unacceptable.
It conflicts with the core values of the Kubernetes project and our community does not tolerate it.
Author: Aimee Ukasick, Independent Contributor
I began contributing to the SIG Docs community in August 2019. Sometimes I feel like I am a stranger in a strange land adapting to a new community: investigating community organization, understanding contributor society, learning new lessons, and incorporating new jargon. I'm an observer as well as a contributor.
I contributed code and documentation to OpenStack, OPNFV, and Acumos, so I thought contributing to the Kubernetes documentation would be the same. I was wrong. I should have thoroughly read the Contribute to Kubernetes docs pages instead of skimming them.
I am very familiar with the git/gerrit workflow. With those tools, a contributor clones
the master
repo and then creates a local branch. Kubernetes uses a different
approach, called Fork and Pull. Each contributor forks
the master repo, and
then the contributor pushes work to their fork before creating a pull request. I
created a simple pull request (PR), following the instructions in the Start
contributing page's Submit a pull
request
section. This section describes how to make a documentation change using the
GitHub UI. I learned that this method is fine for a change that requires a
single commit to fix. However, this method becomes complicated when you have to
make additional updates to your PR. GitHub creates a new commit for each change
made using the GitHub UI. The Kubernetes GitHub org requires squashing commits.
The Start contributing page didn't mention squashing commits, so I looked at
the GitHub and git documentation. I could not squash my commits using the GitHub
UI. I had to git fetch
and git checkout
my pull request locally, squash the
commits using the command line, and then push my changes. If the Start
contributing had mentioned squashing commits, I would have worked from a local
clone instead of using the GitHub UI.
While working on my first PRs, I had questions about working from a local clone
and about keeping my fork updated from upstream master
. I turned to searching
the internet instead of asking on the Kubernetes Slack
#sig-docs channel. I used the wrong process to update my fork, so I had to git rebase
my PRs, which did not go well at all. As a result, I closed those PRs
and submitted new ones. When I asked for help on the #sig-docs channel,
contributors posted useful links, what my local git config file should look
like, and the exact set of git commands to run. The process used by contributors
was different than the one defined in the Intermediate contributing page.
I would have saved myself so much time if I had asked what GitHub workflow to
use. The more community knowledge that is documented, the easier it is for new
contributors to be productive quickly.
The Kubernetes community has a contributor guide for
code
and another one for documentation. The
guides contain conflicting information on the same topic. For example, the SIG
Docs GitHub process recommends creating a local branch based on
upstream/master
. The Kubernetes Community Contributor
Guide
advocates updating your fork from upstream and then creating a local branch
based on your fork. Which process should a new contributor follow? Are the two
processes interchangeable? The best place to ask questions about conflicting
information is the #sig-docs or #sig-contribex channels. I asked for
clarification about the GitHub workflows in the #sig-contribex channel.
@cblecker provided an extremely detailed response, which I used to update the
Intermediate contributing page.
It's common for large open source projects to have information scattered around various repos or duplicated between repos. Sometimes groups work in silos, and information is not shared. Other times, a person leaves to work on a different project without passing on specialized knowledge. Documentation gaps exist and may never be rectified because of higher priority items. So new contributors may have difficulty finding basic information, such as meeting details.
Attending SIG Docs meetings is a great way to become involved. However, people have had a hard time locating the meeting URL. Most new contributors ask in the #sig-docs channel, but I decided to locate the meeting information in the docs. This required several clicks over multiple pages. How many new contributors miss meetings because they can't locate the meeting details?
A contributor may wait days for feedback on a larger PR. The process from submission to final approval may take weeks instead of days. There are two reasons for this: 1) most reviewers work part-time on SIG Docs; and 2) reviewers want to provide meaningful reviews. "Drive-by reviewing" doesn't happen in SIG Docs! Reviewers check for the following:
Do the commit message and PR description adequately describe the change?
Does the PR follow the guidelines in the style and content guides?
Is the content technically correct?
Sometimes the review process made me feel defensive, annoyed, and frustrated. I'm sure other contributors have felt the same way. Contributors need to be patient! Writing excellent documentation is an iterative process. Reviewers scrutinize PRs because they want to maintain a high level of quality in the documentation, not because they want to annoy contributors!
Non-native English speakers read and contribute to the Kubernetes documentation. When you are writing content, use simple, direct language in clear, concise sentences. Every sentence you write may be translated into another language, so remove words that don't add substance. I admit that implementing these guidelines is challenging at times.
Issues and pull requests aren't translated into other languages. However, you
should still follow the aforementioned guidelines when you write the description
for an issue or pull request. You should add details and background
information to an issue so the person doing triage doesn't have to apply the
triage/needs-information
label. Likewise, when you create a pull request, you
should add enough information about the content change that reviewers don't have
to figure out the reason for the pull request. Providing details in clear,
concise language speeds up the process.
In SIG Docs, triaging issues requires the ability to distinguish between support, bug, and feature requests not only for the documentation but also for Kubernetes code projects. How to route, label, and prioritize issues has become easier week by week. I'm still not 100% clear on which SIG and/or project is responsible for which parts of the documentation. The SIGs and Working Groups page helps, but it is not enough. At a page level in the documentation, it's not always obvious which SIG or project has domain expertise. The page's front matter sometimes list reviewers but never lists a SIG or project. Each page should indicate who is responsible for content, so that SIG Docs triagers know where to route issues.
Documentation is the number one driver of software adoption1.
Many contributors devote a small amount of time to SIG Docs but only a handful are trained technical writers. Few companies have hired tech writers to work on Kubernetes docs at least half-time. That's very disheartening for online documentation that has had over 53 million unique page views from readers in 229 countries year to date in 2019.
SIG Docs faces challenges due to lack of technical writers:
kubernetes/website
repo. This involves people having a
technical understanding of Kubernetes, knowing which code release changes
impact documentation, and knowing where content is located in the
documentation so that all impacted pages and example code files are updated
in a timely fashion. Other SIGs help with this, but based on the number of
issues created by readers, enough people aren't working on keeping the content
fresh.lgtm
label
and eventual approval. My size/M
and larger PRs took from five to thirty
days to approve. Sometimes I politely poked reviewers to review again after
I had pushed updates. Other times I asked on the #sig-docs channel for any
approver to take a look and approve. People are busy. People go on
vacation. People also move on to new roles that don't involve SIG Docs and
forget to remove themselves from the reviewer and approver assignment file.
A large part of the time-to-merge problem is not having enough reviewers and
approvers. The other part is the high
barrier
to becoming a reviewer or approver, much higher than what I've seen on other
open source projects. Experienced open source tech writers who want to
contribute to SIG Docs aren't fast-tracked into approver and reviewer roles.
On one hand, that high barrier ensures that those roles are filled by folks
with a minimum level of Kubernetes documentation knowledge; on the other
hand, it might deter experienced tech writers from contributing at all, or
from a company allocating a tech writer to SIG Docs. Maybe SIG Docs should
consider deviating from the Kubernetes community requirements by lowering
the barrier to becoming a reviewer or approver, on a case-by-case basis, of
course.kubernetes/<project>
repo and to put installation,
configuration, usage details, and tutorials in the Kubernetes docs.kubernetes/website
repo. It's hard to keep up with all the issues that are created. We encourage
those creating simpler issues to submit PRs: some do; most do not.Kubernetes has seen unparalleled growth since its first release in 2015. Like any fast-growing project, it has growing pains. Providing consistently high-quality documentation is one of those pains, and one incredibly important to an open source project. SIG Docs needs a larger core team of tech writers who are allocated at least 50%. SIG Docs can then better achieve goals, move forward with new content, update existing content, and address open issues in a timely fashion.
When I said that to my former colleagues, the response was a healthy dose of skepticism and lots of laughter. It seems that many developers, as well as managers, don't fully know what tech writers contributing to open source projects actually do. Having done both development and technical writing for the better part of 22 years, I've noticed that tech writers are valued far less than software developers of comparative standing.
SIG Docs core team members do far more than write content based on requirements:
If you have any doubts about the complexity of the Kubernetes documentation project, watch presentations given by SIG Docs Chair Zach Corleissen:
Additionally, Docs as Code: The Missing Manual (Jennifer Rondeau, Margaret Eker; 2016) is an excellent presentation on the complexity of documentation projects in general.
The Write the Docs website and YouTube channel are fantastic places to delve into the good, the bad, and the ugly of technical writing.
Think what an open source project would be without talented, dedicated tech writers!
The SIG Docs community, and the larger Kubernetes community, is dedicated, intelligent, friendly, talented, fun, helpful, and a whole bunch of other positive adjectives! People welcomed me with open arms, and not only because SIG Docs needs more technical writers. I have never felt that my ideas and contributions were dismissed because I was the newbie. Humility and respect go a long way. Community members have a wealth of knowledge to share. Attend meetings, ask questions, propose improvements, thank people, and contribute in every way that you can!
Big shout out to those who helped me, and put up with me (LOL), during my break-in period: @zacharaysarah, @sftim, @kbhawkey, @jaypipes, @jrondeau, @jmangel, @bradtopol, @cody_clark, @thecrudge, @jaredb, @tengqm, @steveperry-53, @mrbobbytables, @cblecker, and @kbarnard10.
Do I grok SIG Docs? Not quite yet, but I do understand that SIG Docs needs more dedicated resources to continue to be successful.
1 @linuxfoundation. "Megan Byrd-Sanicki, Open Source Strategist, Google @megansanicki - documentation is the #1 driver of software adoption. #ossummit." Twitter, Oct 29, 2019, 3:54 a.m., twitter.com/linuxfoundation/status/1189103201439637510.