Technical writing, asking for help, and other things I learned during my Outreachy internship
Here are all the things I learned about writing, community, and accessibility during my time with the Wagtail project
Finally, I have completed my Outreachy project with the Wagtail community! This program marks my entry into open source. It is also my first time working on such a large-scale project. Being a part of this project has taught me many lessons, particularly the importance of community building. Here’s a few of the lessons I learned while completing my project:
Digesting information is a marathon, not a sprint.
In every project, you’re expected to work with source material. My first interaction with Wagtail was the Outreachy contribution stage. This meant understanding several things, especially the community, the product and the required tasks. All of these parts became much more important at the start of my internship phase.
Wagtail is an open source community with many parts moving towards a single goal— the improvement of the Wagtail CMS. As I discovered during my UX research, these multiple parts didn’t always move the same way, and so the approaches I used had to be different. When I got started on my interviews, I had a base template thinking it would cover everyone I’d interview. The template went somewhat like:
- Casual talk with the interviewees (1 min)
- Questions about the interviewees’ backgrounds (2 mins)
- Easing interviewees into accessibility-related questions (8 mins)
- Continue with documentation-related questions ( 10 mins)
- Bonus questions (2 mins)
The template was decent, but I hadn’t realized that I’d be speaking to members of different professions within the community. The template could work but the questions had to be structured to fit these professions. For example, the questions I chose to ask the developers had to be different from the ones I chose for the content authors or the product managers, but they all had to be within the same parameters. I also had to consider years of experience among the same group— I realized that I would likely have more follow-up questions for a developer with 5+ years experience compared to a developer with 2+ years experience with the community. All of this meant I had to do more research on each individual and how their roles uniquely fit in the community.
When it came to understanding the product, there were several paths. One path was learning how to set up Wagtail. With my background, this proved a bit technical and time-consuming. The next best thing was determining how the CMS works. I learned to use the CMS with the bakery demo demo website. Also, my mentors and I had multiple one-on-one sessions explaining how the CMS worked and to go over the accessibility features that required documentation. Spending time with the actual CMS improved my knowledge of the features over time.
For my list of tasks, a major concern I had was my technical writing skills or the lack thereof. Prior to the internship, I did different types of writing- academic essays, UX case studies, and content writing, but never technical writing. With my mentors’ guidance, I learned a lot. They recommended the Google Technical writing courses, and I dedicated some time to understanding the material. Even at the start of my documentation, I still had to review the material. A lesson I learned here was that this type of writing required both rigidity and simplicity. For example, in other types of writing “He is like a cat” will be interpreted as he is a cat or has cat-like attributes. In technical writing “He is like a cat” must mean he has cat-like features. So, I had to be careful, especially because I was documenting accessibility features that could be compared to conventional features in many cases.
When in doubt, ask the community.
My project was set up to help the community and doing so meant asking lots of questions. A major task was having interview sessions with community members. All of these led with “how best can we…?” because it meant we could improve accessibility features on many levels. Of course, my first questions went to my mentors, especially when it came down to the basic requirements— technical writing and knowledge of Wagtail. However, getting started on UX research was different because there wasn’t any source material. Figuring out the elements required me to ask a lot of “why” and “how” questions in the community. To identify the profiles to use in my research, I had to figure out how to ask the right questions. Even reaching out to my fellow intern about certain topics helped me. At some point, my questions were so specific, I could only get answers through observation. This was perhaps my biggest lesson— sitting still and observing procedures. One way I did this was by listening during the accessibility team meetings and a few webinar sessions I was lucky to attend.
Wagtail to infinity and beyond?
Other than my personal lessons, I’ve been exposed to the priorities of accessibility and witnessed how certain accessibility decisions affect Wagtail as a community and as a product. Moving forward, I’d like to replicate some of these practices in future projects.
I’d like to thank my mentors, Thibaud and Damilola for their support in making the project a success and contributing deeply to my personal development and confidence. I’d also like to thank Meagen Voss, Wagtail’s accessibility team and everyone else for their time and contributions. For more information on my project, read my user research report and Wagtail accessibility features.
