Write the Docs Kenya 2025

skoech · July 4, 2025, 3:28pm

This report was originally posted on the internal Canonical Discourse forum, and is slightly modified and reposted here to serve external readers. There may be one or two inside jokes/“internal-speak” left; please ignore.

Docs or it didn’t happen!

Last month, on Saturday the 7th, at the break of dawn, I left my warm and cosy bed to attend Write the Docs Kenya 2025. It has to be warm and cosy when you live on the windward side of Ngong Hills. It is a little over 50 km from the hills to Ruiru, where the event would be happening. And with the event set to start at 8:35 a.m, I knew I had to be there by 8 to get enough time to grab a tea, socialise a little and get my badge scanned by the EA team. Boy, have they scared me straight. One nduthi and two matatus later, there I was.

In the end, the event surely started at 8:30 a.m. Kenyan time, or 10:30 a.m. More and more people streamed in as we got closer to the food.

The conference this year

This year’s conference was the second in-person event in the history of Write the Docs (WTD) Kenya, with the first one happening last year and ten virtual events ever since. This year, the conference aimed to build a community of documentarians, share knowledge and inspire documentation. The question of the day was this: What makes a good technical writer, a good technical writer? What do you think does?

WTD Kenya 2025 group photo

Around 40 people attended, which I was initially disappointed by since over 150 people had RSVPd, but after speaking with some Technical Authors who have attended other WTD chapter events in different places, I realised that it was actually quite a decent turnout, after all, especially for such a young community. I had a conversation with Nastia from our events team, and learnt that it is quite a common thing in the world of events, and that it requires acceptance and some statistics to cope. There are also other things you can do to encourage remembrance and attendance like, sending out invitations that allow prospective attendees to add the event to their calendars.

Talks and workshops

The conference had been structured to include talks and workshops, some in the main auditorium and others in breakout rooms. But, because of the lower-than-expected turnout, everything happened in the auditorium:

What does it take to make a PDF document accessible for users with disabilities? - Radina Matic, Barcelona - Spain

Radina, a translator and technical writer at Learning Equality talked to us about why we should care about accessible documents, how we can make documents accessible for people with disabilities and diverse abilities, and how we can test accessibility requirements of the PDF documents we create. She provided compelling statistics about people living with disabilities and various global standards, quoting Chapter 26 of the Person with Disabilities Act, 2025 of the Kenyan constitution. With that, she made a firm declaration: “If you are not taking this into account in your product, you are deliberately excluding them.”

She encouraged us to always offer alternatives within our documentation rather than rewriting separate accessible documents, and to use other formats other than PDFs, whenever possible, because they are that much harder to make accessible.

Bridging the content needs: This is how we roll! - Susheel Kumar C., Bangalore - India

After educating us about Bangalore, previously known as Garden City, and what it means to be “Bangalored”, Susheel talked about authoring at SAP, and their network of technical writers, or User Assistance Developers (UADs), and translators. He took us through the origins of the program, their approach to user assistance, their achievements over the years, lessons learnt and what next for the program. Susheel also touched on SAP’s recognition model, which I found quite interesting as we are refining our own Open Documentation Academy recognition model.

Interactive and executable API documentation - Sooter Saalu, Nigeria

Sooter presented some challenges when using API documentation, e.g. static, text-heavy pages; outdated code examples; no real-time testing capabilities; a steep learning curve for developers; failure to cater for edge cases, and a disconnect between documentation and API behaviour. “If your docs suck, developers will assume your product does too”, he said, providing some statistics to show developer reliance on documentation without which they end up digging through source code. He explored ways to transform static documentation into an interactive experience, an approach that allows users to explore, test and understand API docs directly within the product documentation.

Crafting living documentation that lives with your app - Michael Maina, Kenya

Michael helped us view documentation as a garden, not a statue. A garden that must be tended to regularly, and with care. He put forward the concept of living documentation which requires documentation to be co-located with source code, to be updated through an automated process, and to always reflect the status of the code. Docs should not drift from the source of truth.

Enhancing technical documentation with MDX - Felix “Blackie” “Batman”Jumason, Kenya

Batman dared us to use MDX in our documentation. He set up a blog with MDX and Next.js to demonstrate the power of MDX in providing:

Rich content and interactive elements, e.g. live code examples
Reusable components, e.g. buttons, tabs and alerts
Layout flexibility with custom components
Better developer experience, i.e. a more engaging experience

Prompt engineering for technical writing - Gloria Mwendwa, Kenya

Gloria posited that prompt engineering is more than just typing commands and talking to AI; it’s a structured approach to guiding AI that requires understanding the AI’s capabilities and providing precise instructions to achieve desired outputs. A good AI prompt has four components:

Context and constraints - background information for the AI to fully understand your request. Constraints are the boundaries you set to help it stick to the topic; the specific rules to follow.
Role - who should the AI act as? Technical writer? Senior developer? Beginner tutor?
Instructions - what specific actions should the AI perform?
Format and output - how should the output be structured and presented? Bullet points? Code snippets? A summary?

She also performed a short live prompting demo to show how even a slight adjustment to your prompt can lead to dramatically different outputs, e.g. adjusting the tone for different audiences.

Storytelling with logs: Using cloud logging to write better troubleshooting docs - Samuel Macharia - Kenya

Samuel began with a question for the audience: If a client tells you that they can’t log into an app, where do you start looking for the problem as a developer? The audience seemed to agree that the first place to look for errors is in the logs. He demonstrated how to analyse logs with BigQuery and visualise them with Looker Studio, arguing that while debugging through logs, every error has a story and those stories can help us write better troubleshooting documentation.

Storytelling in documentation - Ayoade Adegbite, Los Angeles - United States (Virtually)

Speaking of stories, Ayoade focused on documentation reviews and using analytics to know your user journeys and stories, and using them to improve documentation and consequently, user experience. For example, analysing which sections users engage with the most, page views, bounce rates and search queries.

The Art of test documentation: Testing documentation across different levels - Mandela Winnie, Kenya

Winnie presented a process for documenting what is happening when performing software Quality Assurance (QA) testing, keeping in mind if you are testing manually or have automated the process, and using tools like Cypress or Playwright:

Creating a test plan, or a summary of what you will go through as a QA, e.g. what you plan to do, who will be in the team, features you’ll be testing, test phases, etc. (see test plan sample)
When the testplan is approved, draw up a checklist
Prepare a test case to implement your checklist
Write a test report

Turbocharge your docs: Leveraging GenAI for rapid documentation prototyping presentation - Brackly Murunga, Kenya

Brackly, a data scientist at M-Kopa, proposed a solution to “make the documentation process catch up with the development process”: GenAI.

I think it should be one and the same process.

Everything AI

Like Brackly and Gloria’s talks, there were many other talks on AI:

Scaling open-source documentation with AI - Bethany Jepchumba from Microsoft talked about integrating Prompty in documentation workflows.
Africa’s Talking’s API documentation - Ben from Africa’s Talking reminisced about their team’s proud attempt to find ways to communicate to their developers and users at the same time using their API documentation. He also touched on their documentation process:
- A product developed
- A developer explains to a non-technical person what the product does
- The non-technical person writes the documentation

Nick, his colleague, talked about giving LLMs tools to do things for you.
At the end of their talk(s), they invited the attendees to take part in their June documentation challenge (a little too late for this now, isn’t it? I apologise for not publishing sooner):

Caleb Jephunneh, founder of BricklabsAI, admitted that everything he had wanted to say about using AI for documentation had already been said, so he vibe coded GitDocify, a project for using AI to automatically generate comprehensive documentation from GitHub repositories, and having conversations about the codebase. With the tool, you can:
- Connect or upload your GitHub URL
- Create documentation with AI
- Collaborate on documentation
- Sync with your project README
- Chat with your documentation
- Write a blog about the documentation
- Share, print, edit and improve your documentation
- Use it as a VS Code extension

He then handed over the project to the WTD Kenya community, welcoming us all to tinker away, which was pretty cool.

African timing has consequences

The last two talks were so rushed, I didn’t get much:

IMPORT, COPY, REPEAT: Breaking free from the tech karaoke cycle - Danfold Mosongo, Kenya

Danfold challenged us to subscribe to innovation, not just for titles and clout, but for better life. He highlighted the lack of documentation, not even READMEs, in many African projects. He attributed this to our overreliance on technology from the west, and put forward a challenge to decolonise by documenting.

Scaling documentation for a global Audience: Localization and accessibility best practices - Charles Moruri, Kenya

Charles closed the day’s sessions with another look into making documentation accessible - and global. He proposed some localisation and accessibility best practices like, including glossaries, having a style guide, internationalising from the start, and always including native translators and reviewers.

Have you noticed that we opened the day thinking about document accessibility, and ended the day with the same thought? I have. And now I am thinking, are we doing enough to make our documentation truly accessible?

Friends from CODA and happy times

Somebody came in and asked if she could sit next to me, and what do you know, she recognised me from our documentation Academy! Too bad I don’t have any proof. Sandra left before we could take a picture together.

What I do have a picture of is the lead organiser and one of the speakers sharing a cake because it was both their birthday.

Appreciation

It is never easy organising such an event, but the organising team did well.

All in all, Write the Docs Kenya 2025 was a good event that left me with a lot to think about. I noticed an information architecture gap that I’d like to fill. I hope to be among the speakers in next year’s conference, and some of the virtual events in the middle.