readme-md-generator is able to read your environment (package.json, git config…) to suggest you default answers during the README.md creation process

Nice to see it using All Contributors.

Twilio uses a custom-made, 8-bit RPG game to teach developers their APIs, both online and at events like Superclass and Twilio Signal. Created by Kevin Whinnery, TwilioQuest is a premier example of how to educate developers without putting them to sleep.

“Younger generations of technologists […] have grown up collecting loot and gaining XP”

This is basically an API for the (excellent looking) Mermaid.

Safia, Nick, Jerod, and Chris get together to talk about documentation. Documentation is essential in our work but it can be difficult to get buy in. The crew talks about how you can get others to care about it in your organization, tools that make documentation easier, and some examples of companies doing it right.

Remember Docz? Well, Pedro has been hard at work making it even more awesome. What’s new:

• ⏳ Fetch data on documents
• 📺 Edit playground code
• 💅 Change playground theme
• 🔖 Resolve markdown files
• 🔗 Auto Github link
• ⚡️ A lot of bug fixes and improvements

See also the demo video embedded in this tweet.

Resources to help you get started quickly with Apollo.

Whether you’re experimenting with GraphQL or running Apollo in production, we want to make every developer’s journey as smooth as possible. This is why we’re releasing two new resources to help you along the way: the GraphQL Glossary and an FAQ guide! 🚀

Do you have documentation? Do you have a documentation content strategy? No?!!

If you want to create guides for your software, having a solid content strategy can help you write useful content. This article will walk you through how to develop that strategy, whether you’re an engineer or a technical writer, new to writing documentation or just looking to get more strategic about it.

Dennis Reimann:

The UIengine is a tool to build pattern libraries and documentation for design systems. It helps designer and developers to work closely together and offers features to boost their productivity.

Alternatives already exist in the ecosystem (Fractal, Storybook, etc). Why reinvent the wheel?

Most of the existing tools focussed on the component development, but lacked ways to also provide good documentation. Some were limited to using a specific templating language or framework, which was suboptimal for me: As a freelancer I am working on many projects and each one has its own set of constraints and requirements. I wanted to build a tool with an open source license, which I could use and extend with every project I work on.

Docz’ high-level principles give you an idea of what they’re all about:

• Zero config and easy. No unnecessary build steps with confusing setups.
• Blazing fast. Always use the fastest things to build our tools.
• Easy to customize. Create something that will be easy to use and customize.
• MDX Based. Have the best standard to write documents.
• Pluggable. Plugins are the best choice when you need to be custom and flexible.

Watch the demo video on the homepage to see just how nice this tool is to use.

From Kelly Burke:

You can use this web app to write and sell books on your own domain. We use it for our own book, which teaches you how to build the app from scratch: https://builderbook.org/book

Pretty cool. Writing your documentation or book in Mardown is amazing for a lot of writers. The reading experience on the web could be a bit better, but the app comes with all the third-party integrations you’d want to sell your book.

Unlike the guide which walks you through building a Vue app in story form, the cookbook is all about focused examples of how to accomplish specific goals with the framework.

This is an excellent addition to the compendium of documentation in support of the project, and one that’s worthy of emulation once your framework has a base set of docs that are solid.

Facebook announced Docusaurus to more easily maintain open source documentation websites.

We created Docusaurus for the following reasons:

1. To put the focus on writing good documentation instead of worrying about the infrastructure of a website.
2. To provide features that many of our open source websites need like blog support, search and versioning.
3. To make it easy to push updates, new features, and bug fixes to everyone all at once.
   And, finally, to provide a consistent look and feel across our all our open source projects.

Will Norris (Engineering Manager at Google’s Open Source office) joined the show to talk about their new release of the Google Open Source website as well as the release of Google’s internal documentation on how they do open source. Nearly 70 pages of documentation have been made public under creative commons license for the world to use. We talked about the backstory of Google’s Open Source office, their philosophy on OSS, their involvement in the TODO group, and much more.

On today’s show Nadia and Mikeal are joined by Eric Holscher to discuss non-code contributions, how they are regarded in open source culture, their value, and how to incentivize this type of work. They also talked about how Read the Docs grew a documentation community, contribution guides, and why this work matters.