Blog Archives
Countdown to the first Write the Docs Sydney meetup of 2020
A new year. A new decade. New friends and old. New skills. New ideas. It’s all happening in Sydney at the first 2020 meetup of Write the Docs Australia’s Sydney group. The date is nearly upon us!
The meetup is open to technical writers in all disciplines, and to engineers, editors, product managers, and others I’ve unwittingly left out. If you think technical documentation is a good thing, you’re in. If you think technical documentation is not a good thing, you’re in too. Just be prepared to explain your reasoning. 🙂
- Date and time: Tuesday 25 February at 6pm to 7.30pm.
- Location: Google, 48 Pirrama Road, Pyrmont. (Map.)
- Registration: Sign up to the meetup and then click Attend, or email me. Details are on the Meetup page.
Pizza and conversation are a given. We also have two talented and interesting speakers lined up:
David Parker (Deaf Dave) will talk about Accessible Media for the Deaf and Hard of Hearing.
From David:
My short presentation will be about how accessible media is for the deaf and hard of hearing communities in Australia and worldwide. Digital examples will be given. I will talk about myself as a Deaf person and how I utilise technology to do my job effectively.
Giles Gaskell will talk about Using Antora to build public and internal docs sites.
From Giles:
At Squiz, we’ve built a powerful documentation system with Antora. This presentation provides an overview of how we’ve used Antora and other tools to produce both our public documentation site, and an internal site with additional docs for review and Squiz staff only.
I’m looking forward to this gathering of doc-aware people! I hope you can make it.
From the Tech Writing 101 workshop at Write the Docs AU 2019
Sydney hosted the annual conference of Write the Docs Australia this week. As part of the conference, I ran a Tech Writing 101 workshop. It was a very rewarding experience. If you ever consider running a conference or workshop for a group of technical writers, do it! Tech writers are an engaged, humour-loving, smart group of people.
The workshop
The workshop teaches the principles and patterns of effective technical writing. Before the event, the participants do some pre-reading. Then, during the two-hour workshop, we do a series of exercises and discussions based on the principles in the pre-reading. This is a good way of cementing the patterns into your brain. The next time you write an overlong sentence, or use the passive voice, you’re likely to recognise the anti-pattern and do something to correct it.
We had around 45 participants at the workshop during the conference. Here’s a shot of the room during the workshop. At this stage, the participants had just finished one of the exercises and were discussing their solutions with their partners:
Three assistants helped with running the workshop. They walked around the room answering questions, assisting with logistics, and generally making sure everyone had a good experience. A big thank you to:
The Tech Writing 101 workshop was developed by tech writers at Google to train engineers and others in the principles of effective technical writing. Google is currently preparing a revised, improved set of pre-reading and presentation content, which will be available for tech writers all over the world who want to run the workshop. Stay tuned for news on this front.
What else happened at the conference?
Write the Docs Australia 2019 was jam-packed with talks, workshops, lightning talks, and unconferences. Take a look at the full program.
Here’s the Twitter hashtag: #wtdau2019.
Thanks so much to all the organisers and attendees. Write the Docs AU 2019 was awesome. See you at Write the Docs AU 2020!
Results of open source doc fixit at Write the Docs Australia 2019
This week saw the 2019 conference of Write the Docs Australia. I was delighted to be able to take part in this event. So many good discussions, interesting talks, and lovely people!
On the Thursday afternoon of the conference, I ran an open source doc fixit. A doc fixit is an event where people get together to fix problems in a set of documentation. In the space of just two hours, a group of Write the Docs attendees contributed polish and shine to the Kubeflow documentation. Two fellow tech writers from Google assisted at the event: Alec Glassford and Riona MacNamara.
Fixit results
Together the fixit participants fixed 33 bugs and merged 31 pull requests (PRs). Thirty-three sets of textual and formatting improvements. That’s a really great contribution to the Kubeflow open source doc set.
The screenshot shows some of the PRs submitted on GitHub by the fixit participants. A pull request (PR) is a set of changes that a contributor is presenting for merging into the open source project:
What do the resulting docs look like? One of the pages that received tech writer love was the guide to authenticating Kubeflow to GCP:
The contributors
Approximately 20-25 people took part in the fixit. A few people paired up to work together, which resulted in 15 individuals submitting pull requests (PRs). Some people submitted two or three PRs, leading to a total of 31 PRs.
The participants were a diverse group. Most were technical writers, given that the fixit was part of a Write the Docs conference. A few people had prior experience of GitHub, but most were new to open source and GitHub.
Goals and tactics
My goal for this fixit was to ensure that the participants had an enjoyable experience as well as the opportunity to learn a bit about open source processes and GitHub technology. I knew that the participants would have no knowledge of the product that the docs cover (Kubeflow).
Another important goal was to contribute meaningful improvements to the Kubeflow docs. Kubeflow is working towards a v1.0 release in January 2020. In the open source world, v1.0 is an important milestone, bringing certain guarantees of stability and polish. The v1.0 docs need to be polished too.
With the above in mind, I decided on a few tactics:
- Keep the fixes relatively simple: typos, list formatting, broken links, outdated content. I did sprinkle in a couple of more complex fixes, where people needed to trawl through other PRs or issues to gather information. Those were for the folks who were already comfortable on GitHub.
- Describe the fixes in detail, so that people didn’t inadvertently change the meaning of a sentence when polishing the syntax.
- Make sure that only one person would submit a PR for a given page. I wanted to avoid messy merge conflicts, which may be frustrating and may even be difficult to resolve in the course of a two-hour fixit. I created a spreadsheet with one row per page, listing all the fixes required on that page. The fixit participants would then put their names next to one or more rows, to claim the pages they would work on.
- Have three of us (Riona, Alec, and myself) walking around the room and assisting with the tricky bits.
- Have the three of us reviewing and approving PRs as they came in, so that the participants could see the results of their work published in the doc set as soon as possible.
- Provide a detailed guide for participants, including the basics of how to work in GitHub and how to update the Kubeflow docs. I wrote the guide, then asked Alec to test it. It was a good thing that he did test the guide, because it turns out that the GitHub experience is quite different for someone who doesn’t have contributor rights to a repository (Alec didn’t yet have them when he tested the guide) as opposed to someone who does (I’m an administrator of the GitHub repo and a member of the Kubeflow organisation).
- Direct participants to use the GitHub web interface rather than the git command line interface.
- Attempt to review and approve the PRs during the course of the fixit, so that participants could see the results of their work in the repository and on the docs website. To make this happen, I granted Alec and Riona the necessary review and approval permissions on the GitHub repository where the docs reside. We’ll remove those permissions now that the fixit is over.
What happened at the fixit
At the start of the fixit, I presented a short talk introducing the concepts of open source software and documentation, and the goals of the Kubeflow project.
Then the participants chose a page to work on, based on the spreadsheet we had prepared, and started work.
- Their first task was to create an issue in the GitHub repo where the docs reside, to track their work.
- Their second task was to find the page that needed fixing, and open the page in edit mode.
- After making the necessary updates, the participants submitted a PR for review.
Alec, Riona, and I moved around the room, answering questions and helping people do the initial signups and then submit their issues and PRs.
In between answering questions, we also reviewed the incoming PRs and approved each one when it was ready for merging into the docs repository on GitHub. The continuous merge/publish tools on the GitHub project merged the change and published the update in the docs.
Hiccups and learning
All in all, things went smoothly. I’m very happy with the results. Huge thanks to the participants and to Alec and Riona for their help both before and during the fixit.
Alec, Riona and I were pretty busy helping the participants with various signup processes, GitHub idiosyncrasies, and other tricky bits. We didn’t have much time for reviewing and approving PRs. Next time, more assistants!
A few participants were confused about the difference between an issue and a PR in the GitHub repository. This reminds me how easy it is to succumb to the curse of knowledge: the fixit guide explained why it’s a good idea to create an issue (thanks Alec for suggesting this addition!) but it didn’t go into detail about the difference between an issue and a PR. If both those things are new to you, the difference is not obvious, particularly since they look very similar on GitHub.
A number of participants commented that the initial process of starting to contribute was lengthy and a bit bumpy. People need to sign up to GitHub, sign the contributor licence agreement (CLA), open a page for editing, then follow the GitHub prompts to submit the change, then create a PR (twice, seemingly, as the UI is a little clumsy). People were delighted to know that much of the process is once-off, and their second PR went more smoothly.
On a side note: We were using the GitHub UI because it’s initially a simpler experience than the git command line. Personally, I much prefer the command line. It’s restful. When I sit down with my laptop and type git status, it’s as if I’m saying:
Hey git, it’s been a while. I got distracted by messier things, but I know you’ve been keeping track of the important stuff for me. Let’s get going.
Feedback from participants
Fixit participants said that they appreciated the opportunity to learn about open source and to have their first experience of working in GitHub.
During the general feedback at the close of the conference, people mentioned that they were pleased some parts of the conference involved active participation, instead of listening passively to talks for the full two days.
What else happened at the conference?
Write the Docs Australia 2019 was jam-packed with talks, workshops, lightning talks, and unconferences. Take a look at the full program.
Here’s the Twitter hashtag: #wtdau2019.
Thanks so much to all the organisers and attendees. Write the Docs AU 2019 was awesome. See you at Write the Docs AU 2020!
Join the Kubeflow doc fixit at Write the Docs AU conference
Are you coming to the Write the Docs Australia 2019 conference on 14-15 November in Sydney? You’re invited to join us in a two-hour doc fixit on Thursday afternoon, as part of the conference.
Become a contributor to an open source project, learn a bit about how open source works, and help improve the experience of Kubeflow users. All in just two hours!
During the fixit, you’ll add a touch of tech writer shine to the Kubeflow docs. Docs are a super important part of the user experience of any product. Typos and grammatical inconsistencies can spoil that UX. Yet typos and odd syntax creep into any doc set so easily, especially when the doc set is largely written by non tech writers. You can help us set things right.
Where and when
The doc fixit is part of the Write the Docs Australia 2019 conference.
- Date and time: Thursday, 14 November, at 1pm.
- Location: Water Police Court, Sydney.
Registration
You don’t need to register separately for the doc fixit. Just register for the conference, then come along to the fixit on Thursday.
Your friendly doc fixit helpers
The doc fixit hosts are:
- Sarah Maddox (that’s me: Kubeflow tech writer at Google)
- Alec Glassford (Tech writer at Google)
- Riona MacNamara (Tech writer manager at Google)
What happens at the fixit
Here’s how the fixit will work:
- Before the fixit, I’ll create a spreadsheet with a list of doc bugs that need fixing. They’ll mostly be small things: typos, consistency in page structure, capitalisation, and so on.
- At the start of the fixit, I’ll give a very short talk introducing the product (Kubeflow) and open source.
- Then the group will look at the list of bugs and each person will choose what they want to do.
- My assistants and I will help people create GitHub IDs if necessary.
- Each person will create an issue in the GitHub issue tracker, describing the bug they’re about to fix.
- Each person will then update the relevant doc on GitHub and send a pull request (PR) for review.
- My assistants and I will help people sign the contributor licence agreement if necessary. (A bot will prompt them to do this when they send their first PR.)
- My assistants and I will review the pull requests and approve each one when it’s ready.
- The continuous merge/publish tools on the GitHub project will merge the change and publish the update in the docs.
- The contributor will see their update appear in the docs!
I’ll also prepare a guide to for fixit participants, with the basics on how to work in GitHub and how to update the Kubeflow docs. The guides, in combination with the three of us helping during the fixit, should make the fixit fun and a useful learning experience for everyone.
Prerequisites
Here’s how you can prepare for the Kubeflow doc fixit:
- Bring a laptop with WiFi capabilities.
- If you don’t already have a GitHub account, sign up for one. If you have time to do this before the start of the sprint, that’s great. If not, you can do it during the sprint.
- Sign the Google Contributor License Agreement (CLA). If you have time to do this before the start of the sprint, that’s great. If not, you can do it during the sprint.
- It’s not mandatory to do any prework, but it will help if you know some Markdown.
References
- Details of the Kubeflow doc fixit on the WtD AU site.
- The Kubeflow documentation site.
- The Kubeflow docs source on GitHub.
Join us for Tech Writing 101 workshop at Write the Docs Australia
As part of the Write the Docs Australia 2019 conference, we’re running a two-hour workshop on the principles and techniques of technical writing. You don’t need to be a tech writer to qualify for the workshop, and Write the Docs welcomes anyone who’s interested in technical documentation. Do come and join us!
Tech Writing 101 is a class developed by tech writers at Google to train engineers and others in the principles of effective technical writing. Everyone at Write the Docs Australia Conference 2019 is welcome. For tech writers and others, the class offers an interactive, discussion-filled approach to learning tech writing patterns.
Date and venue
- Date and time of the workshop: Friday 15 November at 2.45pm.
- Location: Justice and Police Museum, Sydney. See the map and venue details.
Workshop details
Tech Writing 101 consists of two parts:
- Pre-work that you should read before the class. Don’t be put off! The pre-work is full of interesting patterns and points for discussion: https://github.com/LisaFC/tw101-reading
- A two-hour workshop at Write the Docs Australia 2019, where you integrate the principles from the pre-work into your writing practices. The interactive format of this class has proved to be an effective way of learning the material. And it’s fun!
Training the trainers: Google is planning to make the course material available for tech writers all over the world who want to run the workshop. You can take part in the workshop purely as a participant, or you can have a dual purpose in mind: take part in the workshop and at the same time observe the facilitator and assistants, with a view to running the workshop yourself sometime in the future.
Your workshop hosts are three tech writers from Google:
Prerequisites
- Read through the prework, so that you can enjoy discussing it during the class:
https://github.com/LisaFC/tw101-reading - Bring a laptop with WiFi capabilities. (A laptop is not essential, but it makes things easier. During the workshop you’ll write some short pieces and review the work of other participants. Having a keyboard and editing facilities helps.)
Cost (included in conference admission fee)
The workshop fee is included in your conference admission. There is no extra charge for the workshop.
Who’s welcome
All conference attendees are welcome! The workshop is intended for people who want to understand the basic principles and techniques of technical writing. The workshop material is tailored for engineers, and is suitable for new technical writers, editors, UX designers, and anyone else interested in technical communication.
Experienced technical writers are sure to enjoy the content too, both as a refresher and as a reminder of how debatable technical language can be.
The workshop format is highly discursive and entertaining. You’ll find yourself debating the principles as you apply them. The material is designed to stimulate such discussions.
The venue?
No, this is not a picture of the venue. It’s just a building that I found interesting on a recent trip to Prague. I’m also rather taken with the reflections in the windows, showing the windows of the opposite building for a nice Renaissance effect:
ffeathers 