Documentation & Technical Writing devroom
Motivation
Documentation has always mattered in free and open-source software, but it is easier now to see just how much work it has been doing all along. The old “talk is cheap, show me the code” line made sense when code was still the expensive part; it lands differently in a moment when code is cheap and the talk around it has started to matter in new ways. What feels scarce now is judgment: deciding what is worth saying, how to say it clearly, what can be trusted, and who is willing to stand behind it. That is part of why documentation feels heavier now than it did a few years ago. As output becomes cheap to generate and expensive to verify, the people and projects that can still make technical work legible, dependable, and teachable start to matter much more.
That is the conversation this (proposed) devroom is trying to make room for. Not documentation as a side task or cleanup pass, but documentation as one of the places where projects explain themselves, onboard contributors, record intent, and earn trust. In healthy FOSS projects, it is often the difference between software that merely exists and software that other people can actually use, extend, or join.
It is also one of the clearest ways communities come to understand themselves. People many of us already recognise make that point quietly but clearly: Carol Willing in notebook and Jupyter circles, Daniele Procida through Django and Diátaxis. Their example is useful not because they are exceptions, but because they show what happens when writing, explanation, structure, and stewardship become part of the project itself. The person who writes clearly often ends up shaping how the rest of the community understands what the project is, what it values, and how others are meant to enter it.
There is already enough of an overlap around IndiaFOSS for this conversation to hold together well: maintainers shipping docs as part of project work, people writing for developer audiences, contributors who begin with guides or README fixes before moving deeper into projects, and notebook- or tutorial-heavy communities that think about explanation as part of the technical work itself.
Proof of feasibility
This is a broad enough area to fill a strong three-hour programme without stretching. Documentation in FOSS now spans writing and editorial craft, docs-as-code workflows, information architecture, review and governance, contributor experience, accessibility, translation, reference generation, migration work, and the changing relationship between documentation and AI-assisted systems. Once you look a little closer, the topic opens out very quickly.
That is partly because most documentation problems in FOSS projects are not prose problems. They are type problems, architecture problems, and ownership problems. A tutorial that tries to be reference stops being a tutorial. A how-to that drifts into long background explanations stops helping someone do the thing. References that tell people what they should do instead of what the system does stops being referenced. That is why frameworks like Diátaxis matter here not just as neat classification schemes, but as diagnostic tools: they help explain why documentation breaks, not only how it should look.
The speaker pool is also wider just technical writers; it extends to maintainers, educators, developer advocates, tooling authors, community organisers, etc. There is room for talks about writing and editorial judgment, docs testing, API and reference docs, notebook-shaped and interactive documentation, migration stories, contributor pathways, changelogs and release notes, review standards, and the practical reality of using AI around docs without giving up on verification or ownership.
There is also a strong case for making interactive documentation part of the scope from the start. Notebooks, executable tutorials, live examples, and browser-based teaching material have changed what many people now expect from technical docs, especially in scientific Python and adjacent ecosystems. I (Srihari) have a well-known soft spot for this kind of thing after spending so much time around notebooks, and that bias is probably useful here: interactive docs are no longer a novelty, they are one of the clearer ways explanation and experimentation have started to collapse into the same surface.
A three-hour slot should fit comfortably as six to seven standard talks. For a first edition, the smaller 35-seater room feels like the better fit.
Call for Proposals
The Documentation & Technical Writing devroom is for people who write, maintain, design, test, publish, or think seriously about documentation in free and open-source software.
Tooling and workflow: We would love talks about the practical stack around documentation work: Sphinx, MkDocs, MyST, and the docs-as-code workflows around them; preview environments, validation, link checking, CI, versioning, reference generation, and the migration work involved in moving older / legacy documentation systems to something more modern / maintainable. We are also interested in talks about interactive documentation, executable examples, and publishing patterns that let readers learn by trying.
We are equally interested in talks about information architecture, editorial judgment, and writing that actually helps people get unstuck. That could include tutorials, how-tos, reference docs, contributor guides, API docs, changelogs, and the decisions that make those formats work.
AI, verification, and trust. We would welcome talks about what LLMs are changing in documentation practice: where they help, where they flatten judgment, how teams verify AI-assisted output, and how projects think about provenance, review, and trust when text is easy to generate and harder to stand behind.
Contribution paths and community. We would also like proposals about how people enter FOSS through writing: blogs, README improvements, beginner-friendly guides, onboarding docs, translations, examples, public notes, and community-facing explanations. Programmes such as Google Season of Docs are worth mentioning here as part of that history, even though the programme itself has now concluded; the broader lesson still stands, which is that documentation has long been a real contribution path into open source.
Governance and editorial policy. Another angle we would be glad to see is how projects handle ownership, review standards, voice, deprecation, and editorial consistency over time. These questions often decide whether docs remain trustworthy long after the first good draft is written.
As with all IndiaFOSS devrooms, talks centred on proprietary tools whose code is not publicly available under an open-source licence are not eligible (not looking for product pitches). We are looking for talks that add something useful back into the commons.
First-time speakers are warmly encouraged.
Selection criteria
-
Talks grounded in hands-on work with or contributions to open-source documentation, tools, or projects
-
Real-world case studies with concrete takeaways
-
Deep dives into specific tools, workflows, migrations, or architectural decisions
-
Community and contributor-journey talks, where they offer clear and useful insight
-
All other relevant proposals
Preferred talk durations
We would be happy to accept both 10 + 5 minute lightning talks and 20 + 5 minute standard sessions.
Organisers and devroom support
The primary contact for the devroom would be Srihari Thyagarajan, Technical Writer at Deepnote, co-organiser of SciPy India, an active participant across PyCon India, IndiaFOSS, and FOSS United circles, and involved in early efforts around kickstarting the WriteTheDocs India chapter. They recently ran a workshop on technical writing in the age of AI, and some of the thinking behind this proposal is visible both in the slides.
Agriya Khetarpal: would be involved as a supporting organiser. He is a software engineer and open-source maintainer working across the Scientific Python ecosystem, including projects such as Pyodide and JupyterLite.
For proposal review, we expect to be able to draw on ~two reviewers.
