The Iron release includes a brand new template contribution from Team Dolphin (Templates AMER/EMEA). We’re thrilled to congratulate Elena Baska on her first template contribution to the project: the Software Development Kit (SDK) Overview template, the first part of a proposed template pack for SDKs.

This template teaches SDK writers to craft an effective introduction for SDKs, and it will be genuinely useful for anyone developing that kind of documentation. We’re also looking forward to the next template in the pack, a getting started guide for SDKs, which Elena has already started working on.

In Elena’s own words, she built the template to make SDK documentation more consistent and reusable, so anyone can pick it up and adapt it to their own project rather than starting from scratch. The template gives writers a clear structure for covering the essentials: what the SDK is, what it does, and where to go next. And this is just the beginning. More is on the way, so stay tuned!

Elena’s project did more than add to our template library. It was also instrumental in helping us refine our template development process. Team Dolphin used her template to experiment with better approaches to community reviews, and it was one of the first templates to go through our new editorial review process. Great work, Elena! 🎉

A big thank-you to Elena Baska for authoring the template, to working group lead Dina Bennet, and former working group lead Valeria Hernandez for their support throughout the project. Thanks also to Maggie H.D. and Alyssa Rock from the template editorial team for their quality feedback during reviews.

The Chronologue is our fictional documentation project, used to show what Good Docs templates look like in practice. It spans three documentation sets: OCTAVIA (the API documentation), KronoPy (the open-source community), and Zaius Inc. (the commercial software platform).

We want to give a huge congratulations to Carrie M. from the Chronologue team for merging in a wonderful example of the open source contributing guide template: the KronoPy contributing guide. This is a high quality example of our template in action, and Carrie’s project turned out to have some really meaningful benefits for the project beyond just adding a new example.

On the template side, working through this project helped us identify some important improvements needed in the original template, which we plan to incorporate going forward. On the process side, we learned a lot about where friction can build up in our contributing process, particularly around catching issues earlier before projects reach the merge request stage. We’ve made changes on both the Chronologue and template side to address this, and we’re hopeful those improvements will make the experience smoother for future contributors. Great work, Carrie!

Congratulations also go to Thad F. from Chronologue Team Dolphin, whose concept example for our fictional software company Zaius, Inc. was completed during this release. This is a first for the Zaius documentation and a genuinely exciting addition. Together with Carrie’s contributing guide, it marks the Chronologue’s comeback to publishing documentation after two release cycles, which is a big win for the whole team. A huge thank you to everyone who helped make this happen.

Special thanks to the author, Thad F, and to Michael Hungbo and Andrea Wright who provided guidance throughout the drafting process. Thad also shared that it’s been a delight working with the Chronologue and Chronologue Editorial teams since he started contributing last year. Well done, team!

We’re pleased to welcome Ariel Kaiser and Deirdre French as new members of the Project Steering Committee (PSC)!

This cycle, the co-chairs put together a document describing the current state of the project and a vision for where the project might become in the future. They worked to build consensus around it with the Project Steering Committee (PSC) and the broader community, and brought forward ideas from last cycle’s brainstorming sessions to see which possible themes for future directions resonated most with the community leaders.

From there, the co-chairs asked the PSC to assess and vote on the project vision. After some great discussion, the PSC landed on three potential themes for TGDP to focus on and grow into: documentation excellence, AI, and potentially evolving into a fully open source documentation consulting team.

To get to that future state, we’re bringing together a few overlapping ideas that had the strongest support: documentation excellence research and advocacy with documentation standards alliance, AI documentation governance with AI-ready documentation infrastructure, and open source documentation team with documentation consulting team.

This is an exciting time for TGDP and we can’t wait to see where these conversations take us as we refine the project vision.

In addition to the new concept and contributing guide examples mentioned above, the Chronologue working group spent time this cycle getting clearer on what we actually know about the Chronologue world. They generated a list of open questions, worked through answers to the highest priority ones, and shared those answers with the other working groups for feedback. It’s the kind of work that makes a real difference to the consistency of Chronologue content going forward.

Previously, Chronologue work was split across Team Macaw (APAC and EMEA) and Team Dolphin (AMER and EMEA). This cycle, we made the decision to consolidate Chronologue under Team Dolphin. The Chronologue is a collaborative project at heart, and we found that working across multiple time zones asynchronously made that collaboration harder than it needed to be. Moving to one team means tighter communication and a stronger, more connected Chronologue community.

The community managers successfully completed a listening tour with working group leads, conducting interviews to understand where support would be most helpful and to hear what’s been working well. They used that research to put together an outline for a set of resources specifically for working group leads and plan to collaborate with the Knowledge Base to produce this helpful guide for working group leads.

The UX working group completed a report summarizing the findings from user research conducted during the previous cycle. Those findings fed directly into the project vision discussions and will help shape several crucial conversations in the next release cycle including which template files we provide for each template, our target users, and how to best reach them and meet their needs.

The knowledge base working group has been busy figuring out where things go, which sounds simple but makes a huge practical difference. They kicked things off by going on a listening tour, attending other working groups to interview members and gather ideas for what content belongs in the knowledge base. Those ideas are now sitting in the backlog and will feed into a card sorting activity to help shape the information architecture. From there, they are defining the basic structure of the knowledge base, so there’s now a clear answer to the question "where should this new article live?" They also defined the target personas for the knowledge base, which will guide what content gets created next.

The outreach team is busy preparing a community event called the Blog-a-thon, a tech writing hackathon. The goal is to collaborate with both community members and external contributors to generate a batch of blog posts for The Good Docs Project’s blog. More details are coming soon, so keep an eye out!

The tech team ran experiments with holding project meetings in Discord and built out the logistical infrastructure for handling inactive members, something that had been on the to-do list for a while and will help keep the project’s membership in good shape. Implementing our inactive members policy allows us to get a more accurate view of our current active members (as mentioned at the top of the community news).

After careful consideration and discussion, we have made the decision to retire the DocOps Registry working group. Attendance numbers made it difficult to sustain the initiative going forward, but we hope to reform the group at a later time as the work coming out of this group has been truly valuable to the project. A special thank-you to Rick L. for leading the group over the past year, and to previous leads Bryan Klein and Michael Park, and to all members who contributed along the way. The GitLab repository has been archived but remains publicly accessible as a resource.

We truly enjoy working with our partners and are excited about the opportunities ahead. We’re currently exploring potential partnerships with Twilio and CASS and can’t wait to share more as things develop!

We’re delighted to announce that Michael Addison, from Team Alpaca (Templates AMER/APAC), has completed his comprehensive rework of the general-purpose reference template for the Helix release. Michael has been thoughtfully iterating on this template for quite some time, refining its structure, improving clarity, and aligning the format with modern documentation practices. His diligence and commitment have resulted in a polished, flexible template that strengthens our core documentation pack.

A reference topic plays a vital role in any documentation set. It provides users with concise, structured descriptions of specific components or characteristics of an application, such as commands, configuration fields, UI elements, and more. Reference content should be easy to scan, helping users quickly locate key facts without wading through narrative or how-to material. To preserve this clarity, the template emphasizes limiting procedural or instructional content, keeping the focus on factual, descriptive information.

The updated reference template reflects these principles and is designed to integrate seamlessly with other templates in our core documentation pack. Its improvements make it especially valuable for open-source maintainers, developer advocates, and technical writers who need to present dense, technical information in a clean and predictable format. You can view the Reference template in our core documentation pack on GitLab.

We couldn’t be more grateful for Michael’s persistent and thoughtful work. Congratulations, Michael! Your contribution elevates the entire Good Docs template library and supports better documentation across countless projects.

For the Helix release cycle, Team Alpaca (Templates AMER/APAC) introduced an exciting proposal for a new type of template pack: the user-focused docs pack. This pack is designed to help writers plan and structure documentation from the user’s perspective, rather than centering solely on tools or features. It will include a collection of pre-planning and analysis templates that guide documentarians in understanding user goals, objectives, and workflows. Now that this pack is planned and added to the roadmap, we’re excited to begin working on the templates planned for this pack, starting in the next release cycle.

Team Dolphin (Templates AMER/EMEA) focused this cycle on exploring ways to strengthen the quality and consistency of community reviews for template projects. Their goal was to understand what makes a review effective and how contributors, both new and experienced, could provide thoughtful, actionable feedback.

For the Helix release, Team Dolphin led an initiative to develop recommended practices for community reviews. They ran a series of review experiments to improve community reviews within their working group and then discussed what went well with each experiment. In the next release cycle, they hope to socialize their findings with the other template working groups. This collaborative effort will help ensure that reviews across The Good Docs Project are consistent, constructive, and supportive, strengthening both our templates and our community culture.

The Template Editorial Team focused this cycle on refining the full workflow for handling editorial review requests from initial submission through to final approval. Their new process will go into effect next release cycle, ensuring faster template turnarounds and improved trust and communication between the editorial team and the template working groups.

In addition, they worked with members from Team Alpaca and Team Dolphin to test the new template quality checklists that they drafted during the previous release. These early beta tests received highly positive feedback from those who used the new checklists, giving the template editorial team confidence to roll out the checklists to the wider project in the next release cycle.

We’re thrilled to announce that Andrea Wright has joined the Project Steering Committee (PSC). Andrea has played a vital role as the lead of the Chronologue Editorial Team, and we want to recognize her outstanding service and dedication to the project. In this role, she has made numerous high-impact contributions, ensuring the quality of our Chronologue examples and mentoring Chronloguers to help them strengthen their proposals and drafts. Her guidance and expertise have been invaluable in supporting both the team and the broader community.

The Good Docs Project co-chairs (Alyssa Rock, Michael Park, and Valeria Hernandez) have been actively working on defining potential long-term themes and vision for the project, looking ahead for the next 2, 5, and 10 years in the project’s future. Once refined, these proposals will be presented to the PSC for further discussion. We’re grateful for their thoughtful leadership and continued dedication to shaping the future of our community.

Our Community Managers work tirelessly to ensure that our community remains healthy, vibrant, and welcoming for everyone who wants to participate. During this release cycle, they made several key contributions: they refined and improved the Git training workshop and established a policy for offboarding inactive community members. These efforts help strengthen the community’s structure, support leadership development, and maintain a safe and inclusive environment for all contributors.

Our Welcome Wagon onboarding model has been updated and we now host onboarding sessions twice per release cycle. Big thanks to Alyssa Rock for creating and organizing the Welcome Wagon. During the Helix release, we welcomed 15 new community members. Thanks to our improved and comprehensive onboarding guide created by the Knowledge Base working group, we’re seeing stronger retention, with more newcomers choosing to remain active community members after their initial onboarding.

The Knowledge Base working group develops curated content to support contributors across The Good Docs Project. Their current focus is a growing collection of articles designed specifically for new community members, helping them onboard smoothly and participate confidently in the Good Docs ecosystem. These resources provide clear guidance on essential topics such as navigating working groups, engaging in discussions, submitting contributions, and using project tools. By offering structured, accessible documentation, the team ensures that newcomers have the support they need to become active, informed, and empowered members of the community.

The Chronologue is a fictional documentation project that offers sample content to illustrate how The Good Docs Project’s templates can be used in real-world scenarios. Both Team Dolphin and Team Macaw continued their work this cycle on defining the core user personas for the three Chronologue documentation sets: OCTAVIA (the API documentation), KronoPy (the open-source community), and Zaius Inc. (the commercial software platform). This effort will help ensure that content across all three doc sets is tailored to the needs, goals, and workflows of their intended audiences.

The Chronologue working groups completed a new set of user personas. The Team Dolphin Working Group collaboratively created an expanded set for OCTAVIA’s APIs, including a lead developer, high-school teacher, project manager, researcher, and hobbyist.

The Tech Team is working on enhancing the system that automates Welcome Wagon registrations. The new registration is now live on the website and makes several improvements to allow new community members to register for the project more easily. These improvements will make onboarding new community members smoother, faster, and more reliable from this point forward.

The UX working group spent the release preparing a comprehensive report summarizing the insights from their user research conducted during the last cycle. These findings will be invaluable for guiding the project’s long-term vision and strategy. We greatly appreciate the team’s thorough work and thoughtful analysis, which provide a strong foundation for informed decision-making across the Good Docs Project.

For the Helix release, the Outreach working group completed The Good Docs Project’s public representation policy. This policy provides clear guidelines for how members should represent the project or speak about it in public forums, and it explains how the Outreach group can support them in doing so effectively.

The Outreach team also developed a slide deck on what makes documentation "good" and how to create it. Alyssa Rock and Carrie Wattula presented "From Code to Clarity: What Makes Good Docs?" to the Consortium for the Advancement of Scientific Software (CASS) community, from which they received thoughtful questions and valuable feedback. The team is grateful for the opportunity to share their work and learn from the broader community.

In addition, the Outreach squad continues to maintain and grow our blog. Stay tuned for an exciting announcement from the Outreach working group!

In the short term, yes, putting in processes for documentation may seem cumbersome. But the longer this is put off, the harder it will be to fix or create documentation. Much evidence points to the benefits of documentation in the long run. For example, teams with quality documentation are 2.4x more likely to meet or exceed their reliability targets: State of DevOps 2021 report, Google Cloud.

Emphasize that the "less is more" principle works well in documentation. Often it is better to produce less documentation (as long as it is high-quality, easy to refer to, and easy to update) rather than extensive unmaintained documentation that is unreliable. This is consistent with the approach proposed by Daniele Procida: Always complete, never finished.

Not all documentation is good documentation. Work out which documentation types provide a return on investment for your organization and then focus on that.

Yes, the value of good documentation is more challenging to measure than many other aspects of the business. However, just because it is challenging to measure doesn’t mean you are not experiencing the impacts (both positive and negative) of the quality of your documentation experience. Consider referencing case studies by others to predict your impact from documentation.

Or look at the following ways to measure the impact of documentation:

It’s a good idea to use Generative AI as an assistant in documentation efforts, but at the time of writing, Generative AI is still a way off from being able to produce reliable, reproducible content without oversight from writers or other stakeholders.

While Generative AI tools like ChatGPT and GitHub Copilot offer convenience and automation in generating text, they have notable limitations when it comes to producing quality documentation. For example:

Generative AI might work well for some use cases,such as documenting code and writing commit messages. But at the time of writing, it still needs human oversight.

Sure, when you have a small intuitive product and only a couple of users who you know personally, it is more efficient to explain things to them rather than write documentation. However, as things start to scale, the case for good docs keeps growing.

Initially, you can lean on your existing team to write docs and point them to The Good Docs Project templates to get started. As you grow, you’ll likely want to start investing in a tech writer.

Developers who write docs should use a modern documentation tool or format that technical writers can later take on as they start to enhance and scale up documentation. Incentives could also be given to community members to contribute to documentation.

Erin Grace has written a practical guide on how to determine the writer-to-developer ratio based on various factors: "audience-facing dev work, required documentation, relative experience, sprint cadence, developer and business analyst responsiveness, story quality, and existing documentation lag."

So instead of aiming for a specific ratio, focus on these indicators of a well-balanced documentation team:

Signs of strain include:

If you observe these signs, it may indicate a need for additional resources or process improvements.

The goal is to have a sustainable, effective documentation process, not to achieve a specific numerical ratio.

This kind of thinking, even if not acknowledged, can influence decisions about investing in documentation. It is, however, a short-sighted view.

Documentation should at least be good enough to help most typical users achieve most of their goals. If many users struggle to install the software or to figure out how to get started with it, that’s a documentation fault. With their frustration, they might not be willing to pay for training or support services. On the other hand, if a rather advanced user is trying to do innovative things with the software, they might be willing to pay for expert services.

List the tangible and intangible benefits of good documentation. For example, to support onboarding efficiency, enhanced user experience, improved productivity, and more.

Choose relevant key performance indicators (KPIs). Rita Khait from Zoomin suggests categorizing key performance indicators into three groups:

Estimate the costs associated with creating, editing, reviewing, and updating documentation content. Consider the time and resources invested by subject matter experts, writers, editors, and reviewers, as well as ongoing maintenance efforts.

You can also calculate the hidden costs of reading the docs, which are often overlooked.

As Henneke Duistermaat wisely notes in her blog post: "The LOWER the effort to read, the HIGHER the effort of the writer. Writing clearly and simply is hard work." This principle directly applies to all texts, including documentation. While it demands significant effort up front to create clear, simple texts, this "high writer effort" directly translates into "low reader effort" for your users and internal teams, which ultimately lowers the overall investment for those who need to read it.

Express the benefits in monetary value (it could be money or effort, such as person-hours). This is where your line manager can help you. You don’t have to come up with intricate calculations or a variety of numbers. Just one monetary figure that helps you emphasize the value of good documentation might be enough.

Scenario: Your company provides software solutions to clients. Without comprehensive documentation, clients frequently contact your support team for assistance, leading to high support costs.

Calculation: Calculate the average hourly rate of your support engineers. Then, track the number of support tickets related to issues that could have been resolved with better documentation. Multiply the number of tickets with the average time spent per ticket and the hourly rate of support engineers. This will give you the potential cost savings from reduced support tickets.

Scenario: Your company offers a software product with extensive documentation. The documentation not only helps existing users but also attracts potential customers through organic search traffic.

Calculation: Analyze your website analytics to track the increase in organic traffic attributed to your documentation (redirects from a doc website to a product website). Then, measure the conversion rate of visitors who access your documentation to become paying customers. Multiply the increase in conversions by the average revenue per customer or a customer lifetime value to estimate the additional revenue generated through improved documentation.

Team Dolphin templateers Elliot Spencer, Michael Hungbo, and Sakura Ticer made several updates and reworked our API getting started template. Elliot, Michael, and Sakura worked incredibly hard on this project, which involved incorporating feedback from several internal reviews. As a result, they created an excellent template that will help writers and developers create effective API documentation. In the process of reworking that template, they renamed the API quickstart template to the API getting started template to better reflect what this content type is commonly called.

API getting started guides provide users with a streamlined path to get started with an API without having to read through lengthy documentation to understand key steps. Having an API Getting Started guide results in faster user integration, reducing the learning curve for your users and providing them with practical examples.

To create your own high-quality guide, check out our API Getting Started template in our templates GitLab repository!

Team Dolphin templates lead Alyssa Rock and Team Alpaca templateer Christine Belize made great improvements to our README template. They did excellent work and focused on adding the process and resource files to this template. The process file provides in-depth information on how to plan and research your project’s README, how to author your README file, and how to maintain a README file for your project. The README resource guide provides high-quality examples of READMEs in action and additional resources that assisted in the creation of our template.

To create your own high-quality README, check out our README template in our templates GitLab repository!

During the Golden Gate release, our community continued to grow. In addition to being a co-lead for the UX working group, Valeria Hernandez became a project co-chair, which means The Good Docs Project now has project co-chairs in every major region: AMER, APAC, and EMEA. We also welcomed tech team member Melissa Mergner to the Project Steering Committee!

The Team Alpaca (Templates and Chronologue - AMER/APAC) working group now has two new co-leads: Cat Keller and Deidre French. They did an excellent job co-leading during the Golden Gate release, which was their first full release cycle. We also want to thank Deanna Thompson and Ailine Dominey for their many years of service as Alpaca co-leads.

The DocOps Registry has a new lead, Rick Larsen. Rick has helped to reinvigorate that group, which is now meeting regularly and accomplishing important work.

We want to thank Elliot Spencer for his year of service as co-lead for the Team Dolphin (Chronologue) working group. We also want to thank Marat Yapparov for his service as co-lead for the Knowledge Base working group. We will miss you both!

In May, community members Alyssa Rock, Rick Larsen, and Carrie Wattula attended the Write the Docs Portland conference. This conference brought together 415 in-person attendees and 170 virtual attendees for three days of knowledge sharing and community building. The unconference sessions sparked lively discussions about docs-as-code practices and tips for new and experienced technical writers.

Among the many compelling presentations at Write the Docs, Stephanie Fuller’s Writing the Shipwreck stood out as a masterclass in managing sprawling documentation repositories. Stephanie’s nautical metaphor resonated strongly as she shared practical strategies for navigating and restructuring large-scale documentation projects. We want to thank Stephanie for giving The Good Docs Project a shout-out during her talk. We were excited to learn that Stephanie borrowed some of her ideas from us and recommends our templates!

In addition to the new templates in this release, the template editorial team spent this release cycle developing our template quality checklists. Their main goal was to define the acceptance criteria for each of the template deliverables. They wanted to create a quality rubric that would ensure template editorial team members can provide standardized review criteria when assessing template quality. They also hoped to provide clearer guidance to our community members about expectations for their projects.

To accomplish this task, they held a 10-week workshop where they discussed many different aspects of template quality and brainstormed which dimensions of quality would best meet the project’s needs. Each editorial team member helped create portions of the quality checklist, and then they brought them together to ensure they were streamlined and normalized. We’re very pleased with the final results and look forward to sharing them with the broader community later.

As a nice side benefit from this project, they also identified potential usability problems in our current templates that they want to address in future release cycles. The editorial team hopes to generate a robust backlog of easy issues for first-time contributors to work on to help our project improve the quality of existing templates in our repository.

As part of our project’s commitment to maintaining a respectful and inclusive community, the community managers recently completed a Code of Conduct review process. This resulted in a formal correction plan related to a contributor’s behavior that impacted team collaboration. We remain focused on ensuring that The Good Docs Project continues to be a safe, collaborative space for all participants, and we deeply appreciate the community’s trust and support during this process.

In lighter news, the community managers also worked to help break down silos between working groups by introducing some new social channels on Discord. Now community members can talk and share about common interests such as food, music, books, movies, travel, and pets. They can also share any wins that happened recently. So far, these channels have generated fun discussions and many cute or beautiful photos.

Lastly, the community managers explored potential solutions to improve cross-coordination across the project. Their goal was to propose a way to foster greater social trust through shared expectations and increased predictability, reduce project inefficiencies, and prevent member burnout through better resource allocation. They released their proposal to the community for feedback and they hope to fully implement it in the next cycle, pending an upcoming vote from the Project Steering Committee.

The UX team is working on a project-critical mission to better understand our user base and assess the overall usability of our template projects. They have interviewed 10 different professionals working in development and technical writing to learn more about their needs and friction points when using templates.

They plan to continue conducting interviews in the next release cycle with the goal of summarizing their research findings and presenting a list of suggestions and recommendations to the Project Steering Committee when the research project concludes.

The Outreach team is proud to share The Good Docs Project’s blog series on the value of documentation and its impact on business goals. A huge thank you to the authors, Ravi Murugesan and Lana Novikova from Team Macaw, for their dedication and insightful contributions to the series. We also want to thank the Outreach team for their edits, feedback, and publication of each post.

If you’ve ever wondered how you can elevate the role of documentation within your organization and create a business case for your docs, this series is a must-read. Check out Parts 1-7 of the Making a Business Case for Documentation series on The Good Docs Project’s blog now.

The Tech team has continued to support the project across a range of platforms and services, and continues to improve workflows and facilitate member contribution, communication, and collaboration.

As the Tech team handles ongoing maintenance and management of our website, GitLab repositories, Google services, Discord server, automations, and more, we want to thank all members for their hard work this release cycle.

With the UX and Outreach teams running UX interviews this cycle, it’s been important for those who signed up to be able to receive authentic communication from the project. The Tech team has facilitated communication with 40+ UX interview attendees and created meeting rooms for each interview.

The Welcome Wagon meetings have always required significant logistical work completed by the primary organizer (Alyssa Rock). Thank you, Alyssa! The Tech team has worked together this cycle to develop automation processes to replace the existing manual triage of Welcome Wagon meeting sign-ups. This automation is undergoing testing and will be deployed at the start of The Good Docs Project’s Helix release.

If you are interested in learning more about The Good Docs Project, we invite you to a Welcome Wagon meeting.

A contact form is being developed for our website to provide a way to reach the team outside of Welcome Wagon meeting sign-ups. Automations for the form will ensure users can directly contact The Good Docs Project’s key members. This will provide a communication pathway for new partnerships, outreach requests, and general inquiries. The form is undergoing testing and will be deployed as part of the upcoming Helix release.

There have been significant changes in our Chronologue project this release, from project management to new examples. We’re very excited about these developments, as they lay a strong foundation for new examples currently in development.

Many thanks to Andrea Wright, Elliot Spencer, Michael Hungbo, and Michael Park for their work running the Chronologue working groups this cycle.

This cycle has seen significant new developments in the world of the Chronologue. Previously, developing a consistent picture of the Chronologue world had hampered the development of examples. New work around basic use cases, developing our understanding of the entities within the Chronologue world, and proposing a new core API for OCTAVIA’s Chronologue have all contributed to a much more mature view of the Chronologue project as a whole. This provides a platform for many more examples to be developed.

With the changes to the Chronologue canon and additional thought put into our overall contribution process, new Chronologue repositories have been deployed that separate project management from documentation.

A new Chronologue Project repository has been deployed with our community health and meta documentation to help contributors, where issues will be tracked and managed. Additionally, a new Chronologue documentation repository has been deployed to replace the old Chronologue websites.

Existing repositories have been archived, including the repository containing the previous website, and the mock tool. These will be retired, as the old website and the mock tool no longer represents our new collective understanding of the Chronologue and the canon.

The new Chronologue website has been deployed and showcases the best of our existing templates, and some new content.

This replaces our old Chronologue documentation site with a focused, Sphinx based deployment. With an easier contribution model, this site better reflects common tooling for open-source documentation projects.

An example of the concept template has been developed and merged into the new website. This example details the coordinate system of OCTAVIA’s Chronologue, and provides a data structure for the Chronologue API.

With this hard science approach to a foundational aspect of the Chronologue, this provides a theoretical basis for the operation of the Chronologue, and will tie into many examples for the Chronologue moving forward.

Using the new concept example, a new API has been proposed by Team Alpaca Chronologue members (Michael Park and Yerin Chang) to facilitate development of consistent, high quality API documentation moving forward. This embraces the new understanding of the Chronologue canon, and will provide a theoretical API for contributors to use in documentation examples rather than creating the API as they write their examples.

With this new development, the old API reference document has been flagged for deprecation, and the old API overview has been retired.

Focuses on expanding market share, increasing revenue, and scaling the business.

Documentation supports growth by:

Aims to create unique value by offering products or services that are distinctly different from competitors, often through innovation.

Documentation becomes a key differentiator by:

Seeks to become the lowest-cost producer in an industry, allowing the company to offer competitive pricing.

Documentation drives cost efficiency through:

Concentrates on serving a specific market segment or narrow customer group extremely well.

Documentation reinforces niche positioning by:

The updated release notes template is authored by community member Leigh Hutchens. The release notes template is an excellent starting point for you to to create release notes for your project. Release notes communicate improvements, bug fixes, and known issues to users. Release notes are important to document and share because they act as a communication tool betweeen you and your users, keeping users up to date on the latest changes. Documenting and sharing high-quality release notes builds trust with your users by demonstrating that you actively maintain your product and care about the user experience.

Leigh documented and added the process and resource file to the release notes template. Additionally, she also made some improvements to the original template as well. She created and introduced her great idea of "mini-templates" as part of this project. "Mini-templates" are short, sentence-level examples for different ways to phrase different types of release note items. For users who struggle knowing to write individual release note items, these examples aim to help them overcome writer’s block and write clear, well-crafted release notes.

When asked about "mini-templates" and her template writing process, Leigh shared:

This template is Leigh’s first contribution to The Good Docs Project. In June, Leigh joined the project and became an active member of the Team Dolphin Templates working group. The release notes template also represents the first template contribution from the Team Dolphin Templates group and is a major milestone for that working group.

The release notes template is a part of the core documentation template pack. The core pack is The Good Docs Project’s flagship template pack, so we’re very excited to see such a big enhancement to this template. Congratulations and big thanks to Leigh on a really great first contribution to The Good Docs Project. Big thanks to the original release template authors, Tara Sweeney and Rachel Stainer, for giving Leigh such a strong foundation to build upon and for cooperating with building the resources file. We also want to thank the members of Team Dolphin, the template editorial team, and the template leads for all their support.

Check out the Release notes template in our templates GitLab repository!

The Changelog template, authored by community members Cat Keller and Deanna Thompson, is an excellent addition to The Good Docs Project’s template collection. The Changelog template is a high quality complement to our release notes template. Changelogs are often confused with release notes. They are both essential documents in software development for documenting and communicating product changes over time. However, there are several key differences between the two.

For example, Changelogs are written for a technical audience that wants a more comprehensive breakdown of what is going into a specific release, including detailed code changes. Release notes can be written for both a technical and non-technical audience who wants a more high-level description of new features and fixes for a release.

The Changelog template is Cat’s first template contribution to the project and Deanna’s second template contribution to the project. Both Cat and Deanna are members of the Team Alpaca Templates working group, with Deanna serving as co-lead of Team Alpaca. Cat and Deanna are also members of the community management team.

When asked about their paired writing process, Cat and Deanna shared their experiences:

Deanna adds:

This template is a great example of successful collaboration and our paired writing buddy system. The Changelog template is a part of the open source software community docs template pack. We feel strongly that this template will empower engineering teams, API developers, and open source maintainers to write effective changelogs for their own projects.

Congratulations and thanks to Cat Keller for a wonderful first contribution and to Deanna Thompson for another great contribution. We would also like to thank Rob Beg who was one of the original templateers on the project before Cat joined the project and who brought it a long way. Last but definitely not least, thanks to the members of Team Alpaca, the template editorial team, and the template leads for all the excellent feedback on this project along the way!

Check out the Changelog template in our templates GitLab repository!

Gitlab partnered with the Community Health Analytics in Open Source Software (CHAOSS) project to integrate GitLab with their DEI Project Badging program, which enables open source projects to build diverse communities. They highlight the work open source communities are doing to welcome and support new members by awarding DEI badges to open source projects. These badges are used to showcase commitment to improving and supporting diversity, equity, and inclusion in open source projects.

As a GitLab partner, The Good Docs Project was inspired to work closely with CHAOSS to create our own DEI Initiative and we are proud to announce that we have been awarded a bronze DEI badge from CHAOSS. Our reviewer from CHAOSS said:

In order to earn this badge, we had to write a policy explaining our policies and procedures for improving diversity, equity, and inclusion in several different focus areas. Some of our favorite highlights from our new DEI policy are:

You can read our full DEI policy on our Community and governance repository.

During the Friendship release, we changed the project’s communication platform from Slack to Discord. The successful migration to Discord was proposed by co-chair and Tech Team member, Michael Park, and lead by the Tech Team after gathering positive community feedback and approval from the Project Steering Committee (PSC). As our community continues to grow, it was important for us to archive and save project history while also keeping our overhead costs low. Discord also came with some additional benefits, such as the ability to better monitor entry into our communication platform and requiring everyone who joins the platform to agree to The Good Doc Project’s Code of Conduct. The migration went incredibly smoothly and we want to thank the Tech Team for successfully leading this migration!

The Community managers continue to ensure our community is healthy, vibrant, and safe for all who want to participate. During the Friendship release, the Community Managers led in the creation and delivery of our DEI policy.

The Community managers also focused their efforts on creating an exit survey for The Good Docs Project. The goal of the exit survey is to provide an opportunity for contributors who have left or are leaving the community to share feedback about their overall experience, including positive feedback and feedback on areas where we can improve. Gathering this information would allow us to share successes, take note of trends in data, and address any pain points that contributors might have experienced.

During the Friendship release, our community grew quite a bit, especially in the EMEA region. As a result, Team Dolphin, which is one of the working groups that serves the EMEA region, nearly doubled in size. We’re excited that Team Dolphin has experienced so much growth and enjoy the energy coming from our new contributors. During this time, Elliot Spencer became the Team Dolphin Chronologue working group co-lead, joining Michael Hungbo.

Recently, a few tooling providers and other organizations have stated their interest to incorporate our templates into their products and processes and establish a more formal relationship with us. We see this as an exciting tipping point and validation of the value our templates and community bring.

To read about our exciting partnership with GitLab, see the the partnership announcment on the GitLab Open Source Partners page and our blost post, We are GitLab Open Source Partners.

We are also thrilled to share about our great partnership with JetBrains. As of recently, you can access The Good Docs Projects templates in JetBrains Writerside. To learn more, see our blog post, We are JetBrains partners.

The Contact support template authored by community member, Christine Belzie, is a fantastic starting point for you to create a contact support page for your project. A contact support page typically consists of communication channels, discussion forums and links to other resources to assist your users with issues that they are having with your product. This page can also provide insights into the user experience, which can be helpful in improving the product and the onboarding process.

Christine is a a member of the Team Alpaca templates working group. She has been actively working on this template for close to year. When asked about her template writing process, Christine shared:

Check out the Contact support template in our templates GitLab repository!

The glossary template authored by community member, Rachel Stainer, is an excellent addition to The Good Docs Project’s template suite as it was one of the most highly requested content types when we first created our template roadmap. The glossary template will assist us in forming the foundation for other important work in the glossary working group and The Chronologue. Rachel researched and worked on this template for nearly a year as a member of the Team Alpaca templates working group.

You can use our glossary template to help identify and document terms and definitions related to a specific topic that may be unfamiliar to your reader or product user.

Check out the Glossary template in our templates GitLab repository!

Last but not least, we are very excited to release our user personas template authored by project member and Team Alpaca template working group lead, Ailine Dominey. The primary purpose of user personas is to guide teams and stakeholders toward decisions that are closely aligned to user needs. You can use our template to fill out your relevant user characteristics to create user personas for your project.

Ailine thoroughly researched this template, beginning in the summer of 2023. She planned and conducted a user persona research project for the Salt Project which led to her documenting real user personas. As a result of her research and hard work, she received highly positive feedback from the Salt user community and maintainers. When asked about her template writing process, Ailine shared:

Check out the User personas template in our templates GitLab repository!

When writing our templates, our templateeers reference our style guide. Our style guide empowers community members to create templates that are consistent in style and tone. The great, big process of creating our style guide was led by Ane Tröger, in collaboration with the template product management team and template editorial team. Well done, Ane!

Our project steering committee has grown and we are thrilled to welcome the following contributors into our leadership team:

The Good Docs Project has welcomed Michael Park as our new co-chair! Michael is now co-chairing the project with Tina Lüdtke. Carrie Wattula has completed her two year term as a co-chair and we thank her for her service.

The Tech team has been working closely in cooperation with the UX and Outreach team to overhaul our website. Our website now has a fresh new design with streamlined navigation that makes it easy for people to learn about our project and join our community. This was a massive effort and we’re excited to reveal it as part of the Eko release.

Alongside our blog and template guides, you can now find our latest The Good Docs Project offering, Tatics. Tactics are a series of articles that provide guidance and best practices on a variety of topics related to improving your documentation.

In addition to working closely on the website with the Tech team, UX and Outreach has focused their energy on conducting user research and growing our core user base. This group researched and drafted our Outreach Strategy which defines our users journey from initial discovery of our templates to successfully implementing our templates in their projects and sharing their success stories with others. The Outreach Strategy explains what future content and initiatives we will create to take our users through this journey.

The UX and Outreach working group wants to hear from you! We encourage you to take our doc maintainers survey and share your experiences with us so that we can identify how to best help you in creating and maintaining great documentation effectively.

The Good Docs Project’s co-chair and UX working group leader, Tina Lüdtke presented at the Linux Foundation’s Open Source Summit - North America 2024. Check out Tina’s talk, where she shares the importance of understanding your users so that you can create documentation that is clear, concise and easy to understand.

Tina also recently presented on the The Content Wrangler, where she introduced The Good Docs Project. In her talk, Tina shared how our community fosters collaboration among technical writers, software developers and UX designers while providing mentorship and networking opportunities.

The community managers welcomed Cat Keller to the team. Cat is leading our initiative of "Fostering a positive community culture". We’re excited to see what interesting ideas she brings about how to best meet this objective!

As part of the community management team’s initiative to onboard, mentor and train community members, The Good Docs Project launched our Welcome Wagon meeting program last year.

The Welcome Wagon meetings are hosted by Alyssa Rock and Michael Vallance. Our working group leads and seasoned community members also join as welcomers. The purpose of the Welcome Wagon is to introduce welcomees to the community, familiarize them with our Code of Conduct, discuss their interests and connect them to leaders of the working group of their choice.

Due to the great success of the Welcome Wagon, we offer friendly meeting times in the AMER, EMEA and APAC regions. This release cycle is the first cycle where our community has offered additional Welcome Wagon time slots for contributors in APAC and EMEA to give them more meeting time options.

The majority of newcomers that have attended our Welcome Wagon are located in the West Africa Time (WAT) timezone (18%). Welcome!

How do newcomers hear about us? The majority of welcomees found us through internet search (27.5%). Before attending the Welcome Wagon, many folks heard about us from active community members (7.5%).

If you are interested in learning more about The Good Docs Project, we invite you to our Welcome Wagon.