Welcome to the Admincraft Wiki! This is a community-driven Minecraft server administration guide. Feel free to contribute!
Admincraft Wiki

How to Contribute

A comprehensive guide to contributing to our documentation

How to Contribute

Welcome to our contribution guide! This comprehensive document will walk you through everything you need to know about contributing to our documentation, from setup to submission.

Before starting your contribution journey, please familiarize yourself with our code of conduct and contribution guidelines available in the repository.

Quick Start Guide

Fork the repository from admincraft-community/admincraftwiki.

Clone your fork: git clone https://github.com/YOUR-USERNAME/admincraftwiki.git.

Create a new branch: git checkout -b feature/your-feature-name.

Make your changes following our documentation guidelines.

Test your changes locally.

Submit a pull request with a clear description of your changes.

Development Environment Setup

Choose your preferred package manager to set up the development environment:

# Install dependencies
npm install
 
# Start development server
npm run dev
 
# Build documentation
npm run build
 
# Run linting
npm run lint

Documentation Components

Interactive Components

Content Enhancement Components

Image Zoom

Enable zoomable images in your documentation:

import { ImageZoom } from '@/components/ui/image-zoom'
 
<ImageZoom src="/path/to/image.png" alt="Description" />

Inline Table of Contents

Add a table of contents within your content:

import { InlineTOC } from '@/components/ui/inline-toc'
 
<InlineTOC />

Step-by-Step Guides

Create guided tutorials:

import { Steps, Step } from '@/components/ui/steps'
 
<Steps>
  <Step>
    First step description
  </Step>
  <Step>
    Second step description
  </Step>
  <Step>
    Third step description
  </Step>
</Steps>

Documentation Elements

Callouts

Highlight important information:

<Callout type="info" title="Note">
  Important information goes here.
</Callout>
 
<Callout type="warning">
  Warning message goes here.
</Callout>
 
<Callout type="error">
  Error message goes here.
</Callout>

Cards

Display content in card format:

<Cards>
  <Card
    title="Getting Started"
    href="/docs/getting-started"
    icon={<BookOpenIcon />}
  >
    Learn the basics of our platform!
  </Card>
</Cards>

Code Blocks

Add syntax-highlighted code examples:

```typescript title="example.ts" {1,3-4}
interface User {
  id: string;
  name: string;
  email: string;
}
```

File Structure and Organization

Directory Structure

docs/
├── _meta.json
├── getting-started/
│   ├── _meta.json
│   ├── installation.mdx
│   └── configuration.mdx
├── components/
│   ├── _meta.json
│   ├── buttons.mdx
│   └── forms.mdx
└── api/
    ├── _meta.json
    └── reference.mdx

Meta File Configuration

Each directory should contain a _meta.json file to define the section structure:

{
  "index": "Overview",
  "getting-started": "Getting Started",
  "components": "Components",
  "api": "API Reference",
  "---": {
    "type": "separator"
  },
  "contributing": "Contributing"
}

Writing Guidelines

Markdown Conventions

  • Use ATX-style headers (# for h1, ## for h2, etc.)
  • Include a single space after header markers.
  • Use backticks for inline code and triple backticks for code blocks.
  • Use reference-style links for better maintainability.
  • Include alt text for all images.

Component Usage Best Practices

  1. Headings

    • Use sentence case for titles.
    • Include descriptive slugs.
    • Keep hierarchy logical (don't skip levels)
  2. Code Blocks

    • Always specify the language.
    • Use line highlighting when helpful.
    • Include copy buttons for longer snippets.
  3. Callouts

    • Use appropriate types (info, warning, error)
    • Keep content concise.
    • Include titles when beneficial.

Pull Request Process

  1. Preparation

    • Update your fork to the latest upstream changes.
    • Run tests locally.
    • Ensure all links work.
    • Check for spelling and grammar.
  2. Submission

    • Fill out the pull request template completely.
    • Include screenshots for visual changes.
    • Link to related issues.
    • Add labels as appropriate.
  3. Review Process

    • Respond to reviewer feedback promptly.
    • Make requested changes in new commits.
    • Squash commits before final merge.

Documentation Preview

All pull requests automatically generate a preview deployment. Check the PR comments for the preview URL.

Style Guide

Writing Style

  • Use active voice.
  • Keep sentences concise.
  • Break up long paragraphs.
  • Use consistent terminology.
  • Include examples for complex concepts.

Code Examples

  • Follow our coding standards.
  • Include comments for clarity.
  • Show both basic and advanced usage.
  • Provide working examples.
  • Include error handling.

Community Guidelines

Additional Resources

For the latest updates and detailed documentation, always refer to the official Fumadocs documentation.

Need more help? Join our Discord community or open a GitHub discussion.

Edit on GitHub

Last updated on