Ways to Contribute
- Add new server type support
- Fix bugs and issues
- Improve documentation
- Add new features
- Report issues and suggestions
Adding a Server Type
Adding support for a new serverTYPE varies in complexity depending on how the server is obtained and configured.
Copy an existing deploy script
Copy an existing
start-deploy* script, such as start-deployFabric, and rename it with the “start-deploy” prefix.Modify type-specific behavior
Edit your new script to implement the type-specific logic between:
- The “start-utils” preamble at the beginning
- The hand-off to
start-setupWorldat the end
Test your changes
Use the iterative development process (described below) to develop and test your changes.
Register in start-configuration
Add a case entry to the
case "${TYPE^^}" statement in start-configuration:Add documentation
Add a documentation section in the docs directory. Copy and modify an existing section to maintain consistent style and detail level.
Submit a pull request
Submit your pull request with:
- Clear description of the new server type
- Testing notes
- Documentation updates
Iterative Script Development
Thecompose-dev.yml file enables rapid development by mounting local scripts into the container.
Setup
Development Workflow
To speed up the development cycle, set
SETUP_ONLY=true to skip starting the actual Minecraft server:- Edit scripts locally in your editor
- Run the container to test changes
- See results immediately without rebuilding
- Iterate quickly
Using Development Copy of Tools
You can test local versions of supporting tools likemc-image-helper.
Java-based Tools (mc-image-helper)
Go-based Tools
Setup github-releases-proxy
Clone and run itzg/github-releases-proxy according to its instructions.
Contributing to Documentation
The documentation is written in Markdown and built using Zensical.Documentation Structure
- Source files:
docs/directory - Organized into sections by directory
- Written in Markdown with Zensical extensions
The
README.md rarely needs modification - it only serves as a brief project introduction. Most updates should go in the docs/ directory.Local Documentation Development
View live documentation
Open http://localhost:8000 in your browser.
Documentation Guidelines
- Follow existing patterns: Look at similar pages for style and structure
- Be concise but complete: Provide enough detail for users to succeed
- Include examples: Show both docker run and docker-compose.yml examples
- Use proper formatting: Follow Zensical markdown conventions
- Test locally: Always preview changes before submitting
Generating Release Notes
When preparing a release, use this git command to generate release notes:Pull Request Guidelines
When submitting a pull request:Create a focused PR
- Address one feature or fix per PR
- Keep changes focused and atomic
- Avoid mixing unrelated changes
Write a clear description
Explain:
- What the PR does
- Why the change is needed
- How you tested it
- Any breaking changes or special considerations
Include tests and documentation
- Test your changes thoroughly
- Update or add documentation
- Include example configurations if applicable
Getting Help
If you need help contributing:- Discussions: Ask questions in GitHub Discussions
- Issues: Check existing issues for similar problems
- Code examples: Look at existing server type implementations
- Community: Join the community for support and collaboration