We at Koyot Digital are a Roblox development group, our current game is Oakridge Nuclear Power Station, or ONPS for short- is a reactor simulation game, not one of those "core" games, we emulate a fully-functional RMBK-1500 Reactor!

• How Can I Contribute?
• Getting Started
• Development Workflow
• Commit Messages
• Pull Requests
• Style Guides
• Testing
• Reporting Bugs
• Requesting Features
• Documentation
• License

🔗 Koyot Digital Discord

🔗 Koyot Digital Website

🔗 Koyot Digital Wiki

The Wiki Team is responsible for creating, updating the offical Wiki. They help maintain an accurate source of information and making sure everyone can access it. They also contribute ideas for improving both the wiki and the game. This includes optimization, fixing bugs, maintaining accessibility and other things. They maintain the hosting services and the techinal side of the wiki

The Engineering Team are responsible for other aspects of Koyot Digitals, Digital footprint such as the main site and any other official subsidiaries infrastructure to ensure its running and well maintained.

Thanks for considering contributing! 🎉 We welcome bug reports, feature requests, documentation improvements, and code contributions. This document outlines how to get involved and what we expect so collaboration stays smooth and respectful.

You can contribute by:

• Reporting bugs
• Suggesting features or enhancements
• Improving documentation
• Writing or refactoring code
• Reviewing pull requests

If you’re unsure where to start, look for issues labeled good first issue or help wanted.

[Wiki Example]

1. Fork the repository

2. Clone your fork locally

   git clone https://github.com/Koyot-Digital/Wiki.git
   cd your-repo

3. Create a new branch for your change

   git checkout -b feature/your-feature-name

4. Install dependencies and run the project locally (see README.md)

• Keep changes focused and scoped
• Write clear, readable code
• Add or update tests when applicable
• Update documentation if behavior changes

Please rebase your branch on the latest main before opening a pull request.

We prefer clear, descriptive commit messages:

• Use the imperative mood ("Add feature" not "Added feature")
• Keep the first line under 72 characters
• Reference issues when relevant (e.g. Fixes #123)

Example:

Add validation for user input

Fixes #42

When opening a pull request:

• Explain what you changed and why
• Link related issues
• Include screenshots or logs if relevant
• Ensure all checks pass

Pull requests may be reviewed for:

• Correctness
• Readability and maintainability
• Test coverage
• Alignment with project goals

Please be patient—reviews may take some time.

• Follow existing code style and patterns
• Run linters/formatters if provided
• Avoid unnecessary refactors unrelated to your change

If the project uses a specific style guide, it will be documented in the README.md or a dedicated config file.

• Add tests for new features or bug fixes when possible
• Ensure all existing tests pass before submitting
• Include steps to manually verify behavior if automated tests aren’t feasible

When reporting a bug, please include:

• A clear and descriptive title
• Steps to reproduce the issue
• Expected vs actual behavior
• Environment details (OS, version, browser, etc.)

Use the bug report issue template if available.

Feature requests are welcome! Please:

• Describe the problem you’re trying to solve
• Explain your proposed solution
• Mention any alternatives you’ve considered

This helps maintainers evaluate scope and fit.

Documentation improvements are always appreciated.

• Fix typos or unclear explanations
• Add examples where helpful
• Keep tone clear and friendly

By contributing, you agree that your contributions will be licensed under the same license as this project.

Thank you for helping make this project better 💙