I am back from my very first Write The Docs (WTD) conference in Portland. I represented Cockroach Labs at the Writing Day. We set up our project for open source contributions and the response was amazing! And we were in good company – the other open source Writing Day projects included Kubernetes, Write The Docs, and Netlify. I also met up with Mike Lewis from GitLab and had a productive discussion about their open source contribution process. To summarize, I am pumped up about all things open source docs, and want to share all I learned with you!
Which brings me to an exciting announcement: I am teaming up with Information Developers Foundation to conduct a webinar about “Contributing docs to open source projects”. This is a topic I am passionate about because I have benefited immensely from working with open source projects. But my pet peeve is that while everyone agrees that contributing to open source is a great idea, nobody really talks about how to actually go about it. What is an open source project? How do you get started with one? What do you need to know to make meaningful contributions? What are the things to look out for, or things not to do? I intend to answer all these questions and also walk you through a few open source projects I personally like. So join me on May 19 at 8:30 PM IST to discuss how to contribute to open source projects. Here’s the registration link:
Also, feel free to send in any questions or topic suggestions you might have and I will try to answer them in the webinar:
In April, I had the privilege of sharing with you the day-in-the-life posts from four inspiring technical writers. To wrap up the series, I wanted to do something special. Which is why I made my very first day-in-my-life vlog! Here it is for your viewing pleasure:
Don’t forget to check out the day-in-the-life posts of our amazing guests:
Bart Leahy: Day in the life of a freelance technical writer (who previously worked at NASA and Disney)
Jason Tham: Life of a PhD student in Technical Communication
Swapnil Ogale: Day in the life of a contract technical writer in Australia
Larry Kunz: Day in the life of a technical writing veteran
Special announcement: There will be no post next week because I will be at the Write The Docs conference. However, I am planning to live-tweet the conference. Follow me on Twitter to keep up with the live updates!
The last post in this month’s series of guest posts is by Larry Kunz, a technical writing pro for 39 years! I have been a follower of Larry’s insightful blog for quite some time now, and it is an honor for me to have Larry share his perspective here on my blog. So let’s get to it! Here’s Larry’s post:
I’ve worked in technical writing, and in closely related fields, like project management or marketing, for almost 39 years. Today I’m a Lead Technical Writer at Extreme Networks.
We make and sell equipment for data networks — switches, routers, wireless access points — and the software that controls them. I write the documentation for installing, customizing, and maintaining the physical equipment.
You might’ve heard that technical writing is humdrum, that we do the same work day in and day out. That isn’t my experience.
One of the things I love about working in technical writing, in fact, is that every day is unique. We serve our employers and our customers in so many ways, and we use so many processes and tools, that every day presents new variety.
Let me show you what I mean, by stepping through a day in my life.
Knowing the technology
You might’ve heard that technical writers only need to know the basics of the technologies they work with. That isn’t my experience.
Today I’ll read the design specs for a new product the company hopes to introduce. I’ll read with two purposes in mind: to learn about the product, and to return comments to the designer if anything seems out of whack or is unclear. I might challenge the author to explain the app in terms that a customer would understand — to help me (and the customer I represent) understand how to use the app, not how the app works.
Working on teams
You might’ve heard that technical writing is a solitary profession — that you spend most of the time by yourself. That isn’t my experience.
Today I’ll meet with a software designer to get a big-picture understanding of a new app that customers will use to monitor our equipment. I’ll visit the hardware lab, where one of our test engineers will show me how our new switches are cabled together. In both cases, my colleague will help me gain the understanding I’ll need to describe our products to our customers.
You might’ve heard that technical writers aren’t respected by subject-matter experts, or accepted as colleagues. That isn’t my experience.
Today I’ll meet with three colleagues from Engineering, one from Tech Support, and one from Marketing to discuss a white paper I’m developing. This particular piece was inspired by something a customer wrote on the company’s user forum. It looked so good that I suggested touching it up and publishing it on the company website. But now, questions have arisen about whether its recommendations are in sync with the company’s overall marketing themes. I’m sure we’ll have a lively discussion, with each constituency being heard before I try to lead the group to consensus.
Solving problems creatively
You might’ve heard that technical writing isn’t a creative endeavor. That isn’t my experience.
Today I have to write instructions for mounting switches in a rack, when three different switch models come with three different mounting brackets. Some of the steps will be common to all three models, but some will vary. Making each step clear and not leaving anything out will require cleverness and imagination. It’ll require creativity.
Creativity is the art of solving problems, whether the problem is how to paint the creation of Adam on a curved surface (as it was for Michelangelo) or how to document the best way to mount three switch models with different mounting brackets. Don’t misunderstand: I’m not saying that I have even a tiny fraction of Michelangelo’s genius or talent. But I’m saying that he would recognize the creative process involved in doing the job of a technical writer.
A new day tomorrow
After a day of delving into technical details, of talking – and leading a conversation – with subject-matter experts, of solving problems creatively, I’ll rest up for tomorrow.
Tomorrow’s tasks will be different. I’ll post the final, approved version of a Hardware Configuration Guide. I’ll meet with the team that maintains the Confluence wiki we use to communicate throughout the Tech Pubs organization. Since I hold a senior-level position within my team, I’ll also be helping to rewrite the template our organization uses for documentation plans.
See what I mean? Every day is different. But every day makes use of my technical knowledge, every day has me working on teams, and every day gives me a chance to solve problems creatively.
Is technical writing the life for you?
Today’s post in this month’s series of guest posts is by Swapnil Ogale, a contract technical writer residing in Australia. I follow Swapnil on social media, and find his insights and experiences of the Australian technical writing community interesting and informative. I am so glad he’s here to give us a deeper insight into the Australian Tech Comm culture. Here’s Swapnil’s post:
When Amruta contacted me a couple of weeks back for this guest post, I wasn’t sure how to approach this. As a Technical Writer who contracts, I am often working a couple of jobs most of the days. In addition, I also organise the Write the Docs Australia meetups across a few cities, so I am constantly looking for speakers and thinking of topics that would interest the attendees.
If you are in the fortunate position of working on exciting projects simultaneously, here are some of my experiences on how you could make it work.
The Early Bird
I like starting early (around 5.30am), because the peace and quiet (and a fresh cup of chai) helps me focus into getting a mental list of tasks ready. Often, early in the mornings, I like reading through my Slack channels to get a sense of the conversations that have happened overnight. Some days, it could just be reviewers getting back to me with feedback, whereas some days it could the developers talking about bug fixes or designers prototyping new interfaces.
This short early morning ritual helps me schedule and priortise work for later in the day.
Public transport, social media, opportunities
My workplace (day job) is a 45 min ride and 2 train connections away. I usually catch up on documentation news via Twitter, looking for tips, hints and any other interesting chats around documentation. I also initiated the Write the Docs Australia meetups a couple of years back, so I follow up on potential speakers, conversations and other themes around this.
I also use this time to search for projects needing documentation or potential consulting opportunities and Twitter surprisingly provides a lot of interesting material for this.
At my last workplace, work hours were pretty flexible, and since I was already up early, I got into work before the rest of my team did (around 7.30 am). For the last couple of years, I was documenting processes for a number of internal teams. Process documentation is not unlike product documentation, but it is slightly more chaotic. While product or software documentation is reliant on periodic changes (such as sprints or releases), process documentation is driven by continuous changes to the processes. These changes come about due to refinement or improvement to existing processes.
I spent a few minutes to understand these process changes, compare them with existing processes and update or create new documentation (work instructions, quick reference guides). We used Confluence to create documentation and JIRA and Trello to track our projects.
Plan, design and innovate
Along with process changes, I also spent time looking at our existing documentation and making improvements to make the content more useful, readable and reusable. If there was something that I really needed to focus on without distractions, I use the Pomodoro timer.
If the documentation changes required talking to the engineers or operators, I would set up one-on-one meetings to source this information and/or review the documentation.
Work from home afternoons
The flexibility at work made it possible for me to head home mid-afternoon (for my son’s school bus pick up) and work from home for the afternoon. I would usually schedule any meetings in the afternoon, usually done via Skype.
Spending time away from the desk, also gave me a chance to catch up on emails or requests for changes to the content without any interruptions.
In addition to my regular day job as a Tech Writer, I also work part time on documentation projects remotely. Most nights, I usually work a couple of hours, planning, creating or curating content for software applications. These projects could be local (Australian) or anywhere across US, UK, Europe or Asia.
I currently document online help, release notes and other content for a project management tool for architects and engineering firms.
I use a range of tools to plan (Trello, JIRA, Mindmaps),create (Madcap Flare, Zendesk, Confluence, Google Docs), and curate (JIRA, Slack) for my projects, depending on the customers need and setup.
Working in Australia
Over the last 12 years, I have been lucky to work in some terrific Australian born and bred organisations across a range of industries. A lot of organisations reflect the same kind of multicultural mix that is now a large part of the nation. This provides some great opportunities to work with, understand and collaborate a range of thoughts, ideas and beliefs.
The work culture also largely reflects the core Australian values of mateship, fair go and a sense of integrity. While Technical Writing is not a new concept here, I’ve found, in my contracting experience, that it still not fully understood and lacks the same amount of support from management resultantly. The value of a technical writer or what they bring to the table is still a bit unclear. Also, a large number of companies are still reluctant to support remote working due to various reasons. From my own personal experience, Australia is still a few years behind in catching up with the tools and technologies that can be adopted to make documentation an entirely fulfilling experience, both for the writers and the users alike.
Today’s post in this month’s series of guest posts is by Jason Tham, a graduate student currently pursuing a PhD in Technical Communication at University of Minnesota. I have studied Jason’s articles for the Research Methods in Tech Comm course for my Masters program and followed his academic career via social media. I am so excited you get to hear from him today. Here’s Jason’s post:
Collaboration is at the heart of technical communication, and I see at least two reasons to why that’s so: 1) technical communication materials are produced for human use and therefore always require human input; and 2) as cliche as it may sound, it remains true to me that no one knows everything, but everyone knows something––thus two or more heads are better than one when it comes to solving technical communication issues or tasks.
As a PhD student, my work in the past 4 years has been largely collaborative. Whether in practice or pedagogy, I have been acculturated to working with users, designers, researchers, and teachers. These interactions are often productive and rewarding; they help me create more effective documents, design and perform better studies, and deliver innovative instructions. In this guest post, I share some of my collaborative experiences in research, publishing, teaching, service, and professional practice.
Collaboration in research
After reviewing my CV, I realized more than half of my current projects are shared with other researchers in and out of my home department at my university. While I have worked in larger teams that ranged from four to eight researchers, my typical collaborations are in teams of two (myself and another researcher or scholar). Whether we are co-investigating a common problem or co-authoring a report, my experience with sharing a research project has been rewarding. I have always learned new research methods and strategies for communicating my findings. Furthermore, from a research standpoint, collaboration may boost the validity and reliability of a qualitative study if inter-rater reliability is utilized and achieved.
Collaboration in publishing
When publishing in technical communication journals (or any journal, I suppose), authors tend to work with journal editor(s) to identify the publication’s scope, standards, and other publishing specifications. I consider this interaction with journal editors and even responses to blind reviews as a kind of professional collaboration. Such collaboration ensures the quality of a publication––that authors produce scholarship that advance knowledge, reviewers provide feedback that enhance the scholarly merits of the refereed work, and editors ensure the integrity of the publication is preserved and supervise the production process.
I have also been blessed with the opportunities to co-edit some special issues of technical communication journals––most recently for the Journal of Business and Technical Communication and Computers and Composition––on special topics like “design thinking approaches for technical communication” and “immersive technologies and writing pedagogy.” In these co-editing experiences, I have collaborated with other academics to create calls for papers, review submissions, coordinate peer reviews, and work with authors and publishers. Special issue publications such as these tend to require a kind of collaborative dynamic that’s different from a regular journal issue as we had to draw resources from a select pool of experts and work within a specific publication timeline that complements the publisher’s workflow.
Collaboration in teaching
Based on my teaching experience, students find it more meaningful to work with problems that have tangible impact on their lives and those around them. As an instructor of technical communication, this means I need to work to bridge theory and practice in student learning. To achieve this goal, I have been collaborating with faculty members with other disciplinary expertise to co-design course modules and learning activities that benefit students in our classes. For instance, in the current (Spring 2018) semester, I am teaming up with a professor from mechanical engineering to create a learning unit for my business writing course where my students serve as press release writing consultants to graduate engineering students whom they are partnered with. This collaborative effort gives both my students and the graduate engineers in another course an opportunity to cross path and learn from each other.
Collaboration in service
As a member of the technical communication discipline, I am also called to provide services to the field that advance its visibility and wellbeing. In my opinion, these services are best done through collective effort and thus I have collaborated with other graduate students and scholars to co-organize events that led to the aforementioned goals. One example is the 21st Annual Great Plains Alliance for Computers and Writing Conference, where three active scholars in my department and I co-hosted in the Fall of 2017. Pulling together a regional conference isn’t a task that can be easily accomplished by an individual; by collaborating with colleagues and other graduate students, we were able to co-design a program that reflected the trends of the field and attracted presenters that had interesting topics to share.
Collaboration in professional practice
When not teaching or conducting research studies, I work as a leasing agent for a student housing provider. Collaboration is ingrained into my work routine; more often than not, I am working with other fellow agents to address leasing and marketing needs––we review our weekly leasing (sales) performance, discuss existing customer service issues, and come up with solutions to address these situations collaboratively. Also, part of my work is dedicated to maintaining a shared database of resident profiles and incoming prospects. Every leasing agent at my property plays a part in keeping shared notes and updating the database. Each year, it takes a team of six leasing agents, working very closely with a leasing manager, to fully lease our residence. While leasing and customer service may not be directly related to technical communication, they are communicative activities that require similar professional rigor.
Together, all these experiences help me grow as a technical communicator, whether through research, publishing, teaching, service, or professional practice. Indeed, as my academic advisor––Dr. Ann Hill Duin––wrote with her collaborator more than 25 years ago, collaboration in technical communication is a research continuum, rather than a static phenomenon or theory. The motivation and techniques for collaboration in technical settings keep shifting according to the context within which the collaboration occurs. My advice for rising technical communicators is to dip their toes in multiple collaborative contexts as part of their training so they may be hone their skills in collaborating with others.
Contact: Jason Tham, firstname.lastname@example.org
Since January 2018, I have been blogging thrice a week about pursuing a Masters in Technical Communication, being a Technical Writer, and becoming “more technical”. However, all the posts were based solely on my experience, thereby providing only my limited perspective about the field of technical communication. I wanted to know more about others’ experiences and provide diverse perspectives on the blog. So I invited the technical communicators that I have admired and learned from over the years, to share their experiences on this blog, and they accepted my invitation!
Hence in April, I am tuning down the frequency of my posts from thrice a week to once a week to focus the spotlight on our guest bloggers each week. Here’s the schedule:
April 4: Bart Leahy – Former technical writer at NASA and Disney, currently freelancing. In his post, Bart gives us a sneak peek into the day-in-the-life of a freelancer juggling multiple projects.
April 11: Jason Tham – A student pursuing a Ph.D. in Technical Communication. In his post, Jason gives us an insight into the collaborative projects in technical communication across academia, service, research, and publishing.
April 18: Swapnil Ogale – A technical writer in Australia, Swapnil shares a day in his life as a contract technical writer in Australia.
April 25: Larry Kunz – A veteran technical writer with 30 years of experience, he is a treasurehouse of knowledge!
I am so excited to share their knowledge and insights with you! Stay tuned and don’t forget to subscribe.
Note: I had written the following article review as part of my Annotated Bibliography project during my graduate program.
Clark, D. (2016). Content Strategy: An Integrative Literature Review. IEEE Transactions on Professional Communication, 59(1), 7-23.
Clark’s article looks at how content strategy is defined and discussed in scholarly and trade literature, and what do the discussions indicate about the direction of the technical communication field. Clark conducted an integrative literature review to find answers to the research questions. Clark traces the emergence of content strategy across multiple disciplines such as technical communication, marketing, knowledge management, and so on. Because content strategy is an integral part of several disciplines, an integrative literature review was the most suitable research instrument.
Clark selected the literature to be reviewed based on whether the work contributed to the knowledge about content strategy, if the work was published after 2009 so as to include recent publications, if the work had the potential of being widely cited and shape the conversation about content strategy, and if the work was publicly available. Based on these criteria, Clark narrowed down the literature to 37 publications comprising of 24 articles and 13 books.
To analyze the literature, Clark resorted to the Classical Rhetorical theory that provides the terminology for discourse analysis. Clark manually read the publications carefully. He noted the definitions and descriptions of content strategy in the publications, and the processes and tools they discussed to meet the content strategy goals. He also collected the employment history of the authors of the publications.
The analysis of the collated data suggests a lack of a common definition of the term “content”. The analysis reveals that content strategy is considered to be the process of creating and maintaining material, is integrated with business and technical needs, and is primarily focused on the customer. The literature promises content strategy as a viable career path for technical communicators, but lacks concrete, real-world examples of putting the concepts into practice. The literature related to content strategy is found in trade publications than academic journals. It indicates that though there is a demand for content strategists in the industry, faculty are not giving it due attention.
The audience for the article are content strategists, instructors of professional communication courses, and documentation managers. Clark discusses the relevant literature snippets thematically instead of presenting a patchwork of quotations and annotations from the literature. He presents a rich level of detail in the literature review. He analyzes the cited literature and provides suggestions for future research in the area of content strategy. He thus meets Hughes and Hayhoe’s (2008, p. 121) criteria of a good literature review.
After last week’s post about Docs FixIt Day at Cockroach Labs, I received several requests asking me to suggest open source projects that people can contribute docs to. As far as I know, almost all open source projects accept docs contributions. The following list includes some open source projects I find interesting:
If you have any favorite docs-friendly open source projects, tell me about them in the comments. And don’t forget to subscribe!
Update 1: Suggestions from the community:
Update 2: Came across this article: Open Source Maintainers Owe You Nothing, which I thought was a mandatory read for anyone who wants to contribute to open source projects. It is important to remember that developers and maintainers of open source projects usually work on these projects on their own time and dime, and it is not their responsibility to help us understand how the project works. We need to put in our own efforts, read all available documentation, learn about the project on our own, before we ask for their help.
Note: I had written the following article review as part of my Annotated Bibliography project during my graduate program.
Tham, J. C. K. (2016). Wearable Writing Enriching Student Peer Review With Point-of-View Video Feedback Using Google Glass. Journal of Technical Writing and Communication, 0047281616641923.
Tham’s article discusses a case study of using Google Glass in student peer review sessions. The article also discusses the benefits, challenges, and recommendations of incorporating the process in technical communication courses.
Tham presents an extensive overview of wearable technology and student peer review sessions. He then elaborates on his research methodology of participatory design. In participatory design research, the participants collaborate with the researcher to study the research topic. The study was conducted in three stages. In the first stage, Tham introduced the students to the concept of peer reviews using Google Glass and conducted a device orientation workshop. In the second stage, Tham collaborated with the students to determine the evaluation metrics for the study. In the third phase, Tham and the students used Google Glass to conduct four peer reviews. The first two peer reviews were experimental and the next two reviews were evaluative.
The data collected was triangulated: the data included the students’ narratives, exit survey responses, and Tham’s observations. Using Google Glass, students could track comments and editing suggestions through video recordings. Reviewers may indicate places in writing where revisions are recommended by snapping a picture or recording the suggestions in video. These images and videos could be sent to the respective writers after the review session. With Google Glass, the focus of review shifted from written critiques to spoken comments. Students would employ the think-aloud protocol when reviewing their peers’ drafts.
The students had mixed responses to the exercise. Students appreciated the first-person perspective video feedback helped them understand the reviewer’s thought process while providing feedback. They also found the feedback to be more detailed than written comments. But they found wearing the device physically uncomfortable, reported being distracted by their classmates’ simultaneously talking into their own devices, and felt unsure if they were doing the process right.
On analyzing the students’ responses and his own observations, Tham summarized that the use of Google Glass for student peer review sessions led to personable, unfiltered feedback, provided verbal and visual channels in reviewing, and captured the reviewer’s emotion. Tham also identified the potential challenges to implementing the process as procuring the wearables, connectivity and file sharing issues, technical and financial support, and getting familiar with the technology.
The study is a qualitative developmental study. It has credibility because the students could freely share their opinions, and Tham relied on his observations and not just the students’ self-reports. The study also has transferability because it was conducted in a real-world classroom scenario. Tham shares his course material with the audience, thereby providing material to replicate the study.