As an open source project, Aptos needs your knowledge to grow. Follow the instructions on this page to update Aptos.dev, the developer website for the Aptos blockchain. Every contributor to Aptos.dev is listed as an author on the pages they edit and update. See the Authors list at the bottom of any page for an example.
See the Aptos Docs project for open issues by status. See detailed instructions for making updates below.
Simply click Edit this page at the bottom of any location to go to the source and trigger editing there. The contents are in Markdown format. You may then edit in browser and use the Preview function to view your changes.
Here are the basic steps for editing in your web browser:
- Click Edit this page at the bottom to get started.
- Modify and add source Markdown files in the developer-docs-site directory.
- See your changes in Netlify (by swapping
- Have at least two verified reviewers examine and test the change.
- Merge in the change and see it go live.
For more complex documentation updates, we recommend forking the repository and using a local editor to make changes. To edit at the command line and preview your changes on your localhost, see our Developer Documentation README.
When ready, start a pull request with your changes. We will get back to you shortly.
The Aptos Docs recommends these materials for good documentation:
- Aptos Style - A brief set of guidance for contributions to Aptos.dev.
- Google Style Guide - A Google standard adopted by companies large and small.
- Technical writing courses - Google offers basic courses on tech writing for engineers and others.
- DITA - The Aptos Docs team adheres to the Darwin Information Typing Architecture whereby all technical documentation is broken down into concepts (overviews), tasks (procedures), and references (lists) to best suit our audiences and their mindsets (learning, doing, finding) at the time of reading.
- Open source templates - The Good Docs Project gives us myriad templates in Markdown for various documentation types we should take advantage of in Aptos.dev.
Make updates directly
Whenever possible, update Aptos.dev directly to reflect your changes to development. This might be as simple as changing a value or as complex as adding an entirely new page or set of pages.
To update Aptos.dev directly:
- Trigger an edit to the source files in the developer-docs-site directory:
- In web browser:
- for simple, one-page changes, use the Edit this page link on the bottom of any page to access the source Markdown file in GitHub: Then click the pencil icon and select Edit this file to work in the GitHub web editor, and create a pull request to have it reviewed:
- To add a new page, navigate to the relevant subdirectory of the developer-docs-site/docs/ directory, click Add file, give it a name, append the
.mdfile extension, include your contents, and create a pull request to have it reviewed:
- Via local editor - for more complex, multi-page changes, use your preferred source code editor to navigate to and update the source Markdown files in GitHub. See our CONTRIBUTING README for
- In web browser:
- For web edits, use the Preview function at top to see your updates in browser.
- For local edits, use the local doc build instructions to see your updates at: http://localhost:3000
- After creating the pull request, use the Deploy Preview in Netlify to see your updates made in web browser or via local editor by replacing the prnumber with your own in: https://deploy-preview-prnumber--aptos-developer-docs.netlify.app/
- Have at least two verified reviewers review and test your changes.
- Make direct commits during review.
- Request review from the Docs team (currently, clay-aptos in GitHub).
- Use the Assignee field in the PR to identify the review the change is blocking upon.
- Receive and address all feedback.
- Get approval from at least two verified reviewers.
- Merge in the change.
- Monitor builds at: https://app.netlify.com/sites/aptos-developer-docs/overview
Request docs changes
If you are unable to make the update yourself or simply need Docs team help along the way:
- See the existing list of open issues tagged as Documentation in GitHub.
- If one does not exist, file a new Documentation issue.
- Answer all relevant questions/sections in the bug template (such as URL to the affected page).
- Set a priority for the doc issue:
- Explain in the issue precisely what is expected in the doc; what requirements must it meet?
- Assign the issue to and work with the subject matter experts and the Docs team to generate new and updated materials.
- Associate all related pull requests with the issue by adding the issue number to the Development field of each PR.
- Re-open the issue when related PRs are merged and work is still needed.
- Close the issue only when all relevant parties are satisfied with the work.