Workshop

Contribute As A Writer

Ibekwe Chinedu O'Brien

September 19th, 2025

Day 1 Recap

The first day set the tone for the entire workshop. We explored what it truly means to contribute as a writer in the blockchain and Web3 space, starting with the idea of blockchain as an open-source ecosystem. It’s not just about developers writing lines of code, it’s about a community of builders, creatives, and storytellers who keep the space alive. Writers have a unique role here. They translate the complex into the relatable, and they turn ideas into narratives people can connect with. From there, we dove into the pillars of content creation, showing how different forms of writing, whether it’s an explainer, a thought piece, or a story, all play a part in shaping how people understand Web3. We also drew a line between content writers and content developers. While one focuses on creating the words themselves, the other looks at strategy and structure, making sure the message fits into a bigger picture. Both are crucial, and both have a place in this industry. To wrap things up, we touched on the importance of writing styles and how the same message needs to shift depending on where it lives. A post on X won’t read the same as a deep-dive article or a LinkedIn update, and knowing how to adapt makes the difference between being heard and being overlooked. Day 1 reminded us of something simple but powerful: Web3 needs writers just as much as it needs developers. Code builds the foundation, but words give it meaning.

Day 2 Recap

Day two moved us from storytelling to the nuts-and-bolts of documentation, showing how technical writing is a powerful way to contribute to open source. We began by defining technical writing not as dry manuals but as the work that makes software usable: clear guides, precise references, helpful examples and onboarding that bridge the gap between code and people. From there the conversation broadened to the types of technical writing you might do, why it matters for product adoption and community growth, and how it can also build a career, whether through paid roles, freelance gigs, bounties, or creating a visible portfolio that opens doors.Practicality was the theme. we talked about concrete steps you can take to become a technical writer, learning documentation formats, getting comfortable with markdown and version control, reading existing docs to see what’s missing, and practicing by rewriting or expanding real examples. Finding places to contribute was handled practically too. scanning projects for documentation issues, joining repo communities, and looking for beginner-friendly labels so your first contributions land in the right spot. The day closed with a walk-through of a contribution workflow that takes you from spotting an issue to submitting a polished pull request and iterating with maintainers. In short, Day 2 turned documentation from an afterthought into a clear, actionable path for contribution and income, reminding everyone that writing good docs is itself a form of building.

Day 3 Recap

Day three brought us even closer to the heart of technical communication writing for developers. We explored what it really means to educate through writing, not to persuade. In technical writing, the goal isn’t to sell a product; it’s to make people understand it, clearly, accurately, and without unnecessary jargon.We touched on the difference between SDKs and APIs, clarifying how each plays a unique role in helping developers interact with technology. It was a reminder that before you can explain something well, you need to understand how it works. That’s why technical writers are encouraged to learn the basics of markdown, explore documentation tools, and get comfortable with the technical side of things.A key point that stood out was that technical writing isn’t the same as blog writing or ghostwriting. The intent is different. While blogs may entertain or persuade, technical documentation is about precision and usefulness. A reference that developers can depend on. It doesn’t have to sound overly complex or “smart”; in fact, the best technical writing is the kind that every developer, anywhere in the world, can easily understand. We also touched on the mindset and qualities of a good technical writer, adaptability, curiosity, and clarity. And as always, the session ended practically, showing where writers can start contributing: from GitHub repositories to developer forums and X, where the global open-source conversation is constantly happening.By the end of the session, it was clear that writing for developers isn’t just about documenting code. It’s about creating tools in written form. Guides that make building easier, faster, and less frustrating