From code to communicating clearly: How PKP’s technical writer approaches development updates

Urooj Nizami sits down with PKP’s Project Management and Technical Writing Consultant, Magnus Lu, to talk about one critical aspect of her work at PKP: technical writing and communication.
Magnus Lu joined PKP in 2024 to lead its role in the Open Research Europe project, but it quickly became clear her impact would extend far beyond that mandate. She soon became a familiar presence on PKP’s quarterly development news webinars, helping to connect technical work with the broader community.
Magnus brings a rare ability to distill complex development into clear, meaningful updates, making her a valued and regular contributor to Archipelago, PKP’s community newsletter, through her column, Development Dispatch. What sets her approach apart is not only her ability to explain what’s changing in PKP’s free and open source software, but to clearly articulate why those changes matter to the community.
I’m delighted to sit down with Magnus to talk about one critical aspect of her work at PKP: technical writing and communications.
How do you define technical writing and communications in the context of your work at PKP?
I gather and organize scattered bits of knowledge and turn them into useable content. That shows up as contributions to the PKP News Blog and the Archipelago newsletter, but also as requirements documentation, user stories in GitHub, and docs written specifically for the internal PKP teams. I especially like the “reporter” aspect of my work where I can take part in a sprint, or requirements and feature discussions, and match it up with the questions or gaps I’ve seen from users and support teams.
What skills or perspectives from your background inform your approach to this work?
I’ve been a content writer, copywriter, and technical writer for the last four years. I have a background in computer science and I’ve been a software project management (PM) consultant for over ten years.
The PM experience helps me anticipate and empathize with client and end-user needs when it comes to software and handovers. The writing experience as a whole taught me that all information must serve a purpose.
A key part of your role involves communicating technical developments, often seen as “dry”, or highly specialized. How do you make this information not only accessible, but engaging?
Unfortunately, some topics are inherently dry! That said, I think the best way to make technical communication engaging is to make it not frustrating. But the fact is, I’ve mostly been filling in the gaps by trying to answer questions that I already know are out there, so by the time I write it, people are starved for the information. We’ll be more proactive about this with future releases.
Why is technical writing and clear communication especially critical in an open-source, community-driven project like PKP?
Particularly in open-source projects, with multiple sources of contribution and feedback — from coders, end-users, admins, hosted clients, and collaborators — it can be tricky to make sense of it all.
Part of the technical communication that I do involves capturing intent. How will future releases solve present-day problems? What features are being prototyped and what problems might they solve? How do we pre-emptively address user needs prior to a new release?
With so many voices in GitHub tickets and comment threads, how do we establish a direction for what a feature is meant to do?
Development communications can sometimes feel one-directional. Do you see opportunities to make this more of a conversation? How has community feedback shaped your approach?
GitHub and the PKP Community Forum are the main channels for two-way communication between PKP and the community.
On the dev side, we have started to make requirements documentation part of our process in GitHub and this is relevant to your question because this will make it easier to understand the scope of a feature and will give users a chance to add feedback, ask questions, technical or otherwise.
Community feedback has the most impact early in the process of scope definition so by exposing feature requirements in real time, we won’t have the situation where people are learning about a feature after it’s already been built.
This is part of a larger process update in GitHub so that anyone can track a feature from requirements through to design, development, and release.
Magnus’ contributions strengthen every team’s ability to advance PKP’s vision, mission, and values. Her work reminds us that technical writing is far more than content creation; it is essential in building trust and sustaining shared infrastructure. In community-driven, open-source projects like the Public Knowledge Project, technical communication is a critical part of the ongoing dialogue between developers and the community. It supports the full lifecycle of feature development, from identifying needs and shaping requests, to documenting progress, explaining functionality, and communicating the purpose behind each decision. Thank you, Magnus, for helping make PKP’s work more transparent, collaborative, and connected to the community it serves.