Contributing to the Docs
We’re currently making rapid changes to the product so our docs may be out of date. If you need help, please email firstname.lastname@example.org.
Contributing to Forem's developer documentation
Contributions to the documentation are always appreciated! Thank you for making an effort to improve the developer experience of contributing to the DEV project.
Running the documentation locally
Like Forem, this site is open source and the code is hosted on GitHub. If you find any incorrect information, or a even a typo, we'd love to see a pull request. Follow these steps to get the documentation site running locally.
Forem's documentation is built with Docusaurus.
Once installed, you should run
yarn start in the root of the
This will start a server where you can browse the documentation: http://localhost:3000/
If you add new pages or rename existing pages, those changes will be to take effect shortly, so you don't need to restart the server.
Since our documentation is built on Docusaurus, which is built on Netlify, you can use the generated deploy preview link to check out your documentation changes. Once you make a PR, click on "Show all checks" and find the "deploy/netlify" row. If your deploy preview is ready, you can click on "Details" to see the preview. Please note that the deploy preview only reflects any documentation changes you make (and not any changes elsewhere in the app).
For more information on how to use Docusaurus, read the Docusaurus docs.
Regarding language & style
We ask that you avoid trivializing terms when contributing to documentation. This includes words like "just", "simply", "easy", "obvious", and "straightforward". You can learn more about why we want to avoid this kind of language in this blog post.
Generally speaking, the documentation hosted on this site is informal. There is no need to make things more complicated by writing these articles like a textbooks.
However, it's expected that contributions to these documents are reasonably structured and mostly free of spelling and grammar errors. For this reason, if you submit a PR you might be asked to make changes before your PR is merged.
Prettier is used to autowrap lines in these files to 80 characters. Using 80 characters per line allows us to retain a more specific git history over time. If lines are not wrapped, changing a comma in a paragraph would attribute the entire paragraph to one commit. By line wrapping we are helping git to correctly attribute smaller changes to their commits. This keeps information from getting lost over time.
For more information on effective technical writing, check out writethedocs.org.