Welcome! This guide will help you contribute to NANI's documentation. We use Vocs as our documentation framework, which makes it easy to write and maintain documentation in MDX format.
- Make sure you have Bun installed on your system. If not, you can install it with:
curl -fsSL https://bun.sh/install | bash
- Clone the repository and install dependencies:
git clone https://github.com/NaniDAO/nocs.git
cd nocs
bun install
- Start the development server:
bun run dev
This will start a local server, typically at http://localhost:5173
, where you can preview your changes in real-time.
docs/
├── pages/ # Documentation content (MDX files)
│ ├── docs/ # Main documentation pages
│ └── blog/ # Blog posts (optional)
├── public/ # Static assets like images
├── vocs.config.ts # Vocs configuration
└── package.json # Project dependencies
- Create a new
.mdx
file in the appropriate directory underpages/docs/
. - Add your document's route to the sidebar in
vocs.config.ts
:
sidebar: [
// ... existing entries
{
text: "Your New Page",
link: "/docs/your-new-page"
}
]
Your MDX files should start with a title:
# Your Page Title
Content goes here...
You can use all standard Markdown features plus React components.
- Headers: Use
#
,##
,###
, etc. - Code blocks: Use triple backticks with optional language specification
- Links:
[Link Text](URL)
- Images:
![Alt Text](image-path)
- React components: Import and use them directly in MDX
Example:
# Getting Started
This is a paragraph with **bold** and *italic* text.
## Code Example
```solidity
contract Example {
// Your code here
}
\```
## Running Locally
Development server (with hot reload):
```bash
bun run dev
Build for production:
bun run build
Preview production build:
bun run preview
- Create a new branch with a descriptive name:
git checkout -b docs/add-new-section
- Make your changes and commit them with clear messages:
git add .
git commit -m "docs: add section about XYZ"
- Push your changes:
git push origin docs/add-new-section
- Create a Pull Request on GitHub:
- Use a clear and descriptive title (e.g., "docs: add guide for smart contract integration")
- Include a detailed description of your changes
- Reference any related issues
- Add labels if applicable (e.g., "documentation")
- Request reviewers if you know who should review your changes
- Title Format: Use conventional commit format
docs: add X
for new documentationdocs: update X
for documentation updatesdocs: fix X
for documentation fixes
- Description: Explain what changes you are making and why
- Breaking Changes: Clearly mark any breaking changes
- Documentation: Make sure your documentation follows our style guidelines
- Use clear, concise language
- Include code examples where relevant
- Use proper heading hierarchy (don't skip levels)
- Add links to related documentation
- Include diagrams or images for complex concepts
Join our Discord for support and discussions about documentation.