Documentation & Technical Writing

The Documentation & Technical Writing devroom is for people who like to call themselves “documentarians”, who write, maintain, design, test, publish, or even think seriously about documentation in free and open source software and beyond: be it technical writers, software engineers, documentation architects, content writers, FOSS contributors and maintainers, activists, proponents of digital freedom and information access, and more.

Scope

Documentation tooling and workflows: We would love to receive talks about the practical FOSS stack around documentation work: Sphinx, MkDocs, MyST, Jekyll/Hugo and the broader family of static site generators, and the docs-as-code workflows around them; such as preview environments, prose linting and style enforcement, CI/CD pipelines, versioning, generation of automated references, and the migration work involved in moving older/legacy documentation systems to something more modern/maintainable. We are also interested in discussions of interactive documentation, executable examples, and publishing patterns that help 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 versioning history, and the decisions that make those formats work.

AI, verification, and trust: We would welcome discussions 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 but hard to stand behind. We are also looking for answers to structural questions, such as the implications for attribution, licensing, and contributors' motivations, especially as we notice trends where users are shifting towards reaching out for agentic workflows and chat interfaces to interact with “distilled” documentation pages rather than reading them directly. Meta-discussions about suitable formats for an AI-enabled world rooted in FOSS are welcome.

Documentation accessibility and inclusivity: We would appreciate discussions on workflows for screen-reader-compatible markup, alt text for technical diagrams, appropriate contrast levels, etc., and on how projects adopt workflows to audit and improve the accessibility of their documentation. Many FOSS documentation toolchains and themes do not meet digital accessibility standards such as WCAG by default, and we are interested in how projects and communities can address this at an intersectional level.

Contribution paths and community: We would also like proposals about how people enter the world of FOSS through writing: blogs, guides, tutorials, onboarding docs, translations, examples, public notes, and community-facing explanations. Programmes such as Google Season of Docs, Outreachy, and documentation-focused apprenticeships by Wikimedia are worth mentioning here as part of that history, even though the former itself has now concluded; the broader lesson still stands: that documentation has long been a real contribution path into open source, and not a consolation prize to be won for those who do not involve themselves in coding. We would be glad to hear from people who came into open source and open knowledge communities and stayed, from maintainers who carefully consider how to make their contributor pathways welcoming, and from communities that have built cultures around documentation-oriented contributions. What does good onboarding for a new documentation contributor look like? How do FOSS projects more effectively signal that writing is valued? How do mentorship and review work when the contribution is in prose rather than as a patch?

Documentation accessibility and inclusivity: We would appreciate discussions on workflows for screen-reader-compatible markup, alt text for technical diagrams, appropriate contrast levels, etc., and on how projects adopt workflows to audit and improve the accessibility of their documentation. Many FOSS documentation toolchains and themes do not meet digital accessibility standards such as WCAG by default, and we are interested in how projects and communities can address this at an intersectional level.

Contribution paths and community: We would also like proposals about how people enter the world of FOSS through writing: blogs, guides, tutorials, onboarding docs, translations, examples, public notes, and community-facing explanations. Programmes such as Google Season of Docs, Outreachy, and documentation-focused apprenticeships by Wikimedia are worth mentioning here as part of that history, even though the former itself has now concluded; the broader lesson still stands: that documentation has long been a real contribution path into open source, and not a consolation prize to be won for those who do not involve themselves in coding. We would be glad to hear from people who came into open source and open knowledge communities and stayed, from maintainers who carefully consider how to make their contributor pathways welcoming, and from communities that have built cultures around documentation-oriented contributions. What does good onboarding for a new documentation contributor look like? How do FOSS projects more effectively signal that writing is valued? How do mentorship and review work when the contribution is in prose rather than as a patch?

Translation, localisation, and language access. Documentation that exists only in English excludes most of the world, and this is as true for open knowledge projects, community encyclopaedias, and open educational resources as it is for software. We are looking for talks about how individuals, communities, and organisations handle the full arc of translation work with FOSS: the coordination and editorial decisions, the challenge of keeping translated content from silently drifting out of date as the source evolves, and the governance questions that arise when different language communities want editorial independence rather than just a faithful copy. Beyond word-for-word translation, there are deeper questions worth discussing: how do you localise technical or specialist knowledge for communities where the vocabulary does not yet exist in the target language? How do you handle scripts, bidirectional text, or locale-specific conventions in documentation toolchains not designed with them in mind? How do projects, whether a software library or a community knowledge base, decide which languages to prioritise, and how do they sustain that work without burning out translation contributors? We are also interested in submissions talking about the infrastructure that supports this kind of work; projects like zdoc and Tolgee are examples of efforts to make multilingual documentation workflows more practical.

Governance and editorial policy: Another angle we would be glad to see is how projects handle ownership, review standards, “voice”, deprecations, and editorial consistency over time. These questions often decide whether docs remain trustworthy for users and stakeholders long after the first good draft is written.

Talks centred at or significantly involving proprietary tools whose source code is not publicly available under an OSI-approved license are not eligible (we are 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 priority and review process

We are accepting proposals for both full-length talks (20 minutes) and lightning talks (10 minutes). Please indicate your preferred format when submitting.

Proposals will be reviewed by our reviewers and evaluated on the following criteria, listed in our order of priority:

1. Proposals grounded in direct, specific experience with a FOSS project, community, or FOSS-aligned organisation:
2. where the experience has produced a finding, a method, or a hard-won lesson worth sharing
3. that give the audience something they could not have got from reading a blog post
4. that come with a clear point of view and takeaways, the audience can act on or carry forward
5. Underrepresented themes in mainstream technical writing and documentation events, including translation and language access, accessibility, the knowledge commons, and governance
6. Proposals that reflect a diversity of backgrounds, communities, and contribution types, including first-time speakers and contributors who came into open source through writing rather than code
7. Proposals that speak to more than one of the devroom's themes or connect concerns that are usually treated separately
8. All other relevant proposals that fall within the devroom scope, and beyond it, but tie back to FOSS, documentation, and technical writing

Each proposal will be scored independently by all reviewers and managers, after which the organisers will meet to discuss and finalise the selection, with particular attention to borderline cases and overall programme balance. Reviewers will have access to submitter names and affiliations. We will endeavour to provide brief feedback on unsuccessful proposals, though this may depend heavily on the volume of submissions we receive. Selection notifications and conference-related specifics will go out alongside the main IndiaFOSS selection announcements, but may not be aligned with dates.

Proposal Submission

Please submit proposals for this devroom using the link below. Ensure that you select "Documentation & Technical Writing" as the track.