🌟 Thank you for your interest in contributing to Open Hotel! 🌟
The following guidelines are here to help you contribute to Open Hotel, a project dedicated to creating a free and customizable virtual hotel experience. These are suggestions, not strict rules, so use your best judgment when contributing!
- Before Contributing
- Code of Conduct
- How Can I Contribute?
- Coding Guidelines
- Have Questions? Join Our Discord!
- License
Open Hotel is an open-source project aiming to provide a free and customizable virtual self-hosted hotel experience. The project is composed of multiple repositories, which you can find on our GitHub organization page.
The main repository is openhotel/openhotel, and it’s the best place to start contributing.
To ensure a welcoming and inclusive environment, all contributors are expected to:
- Be respectful and considerate to others.
- Refrain from using abusive, derogatory, or discriminatory language.
- Provide constructive feedback and engage in collaborative problem-solving.
Violations of this code may result in your contributions being rejected and further actions taken to maintain community standards.
If you encounter a bug:
- Search existing issues to see if it’s already reported.
- If not, create a new issue. Include:
- A clear and descriptive title.
- Steps to reproduce the bug.
- Expected vs. actual behavior.
- Your operating system, browser version, and any logs if applicable.
We welcome feature suggestions! To propose a feature:
- Check existing issues to ensure it hasn’t been suggested.
- Open a new issue and include:
- A detailed description of the feature.
- Why this feature would benefit users.
- Any implementation ideas (optional).
We accept contributions of all sizes! Examples include:
- Improving existing functionality or adding new features.
- Resolving issues.
- Fixing typos or improving documentation.
Open Hotel uses a pixel art style for its assets, and it uses metadata to define some of the properties of the assets. We strongly recommend taking a look at our Asset Editor repository to create compatible assets. Some examples of contributions include:
- Icons, sprites, furniture, character clothes...
- UI/UX improvements.
- Backgrounds, tiles, and other visual elements.
Make sure any artistic contributions align with the overall aesthetic and respect licensing terms.
We welcome pull requests! Here’s how to ensure a smooth process:
- Use the following convention for PR titles:
type: descriptive text - fix #XXX. Here:typeshould be descriptive (e.g.,featfor features,fixfor bug fixes,artfor art-focused PRs).XXXrefers to the related issue (if there is one).- Examples:
feat: Add user profile customization - fix #12(On merge, issue 12 will be closed automatically)fix: Bug where character doesn’t move - fix #42(On merge, issue 42 will be closed automatically)
- Ensure your branch is up-to-date with the latest
masterbranch before opening a pull request. - Provide a clear description of your changes in the pull request body.
- Add tests if applicable.
- Run tests if available and ensure all checks pass before submitting.
- Check the coding guidelines below for code formatting and style. Your PR will be automatically checked for formatting issues.
- Write Tests: If possible, add tests for any new functionality. If a feature is hard to test, mention it in your PR. Run existing tests if available.
- Follow Commit Guidelines: Use clear and descriptive commit messages.
- Respect the Project Scope: Ensure contributions align with the project's mission to remain open and non-commercial.
- Use kebab-case for file names (e.g.,
my-component.ts). - If files are inside a shared folder like
utils,consts,enums, etc., they must have a descriptive suffix:my-function.utils.tsconfig.consts.tsstatus.enums.ts
- Whenever possible, use arrow functions:
const myFunction = () => { // code here };
- Use
camelCasefor variables and functions:const myVariable = "value";
- Use
UPPER_CASEfor global constants:const MAX_USERS = 100;
- Use
PascalCasefor class and component names:class UserProfile {}
const MyComponent = () => { return <div>Hello</div>; };
- Only use classes when there is no other alternative. Prefer functional programming and simpler constructs whenever possible.
- Order imports in the following order:
- Native Node.js modules
- Third-party libraries
- Internal project imports
import fs from "fs"; // Native module import React from "react"; // Third-party library import { myFunction } from "@/utils/my-function.utils"; // Internal import
- Use 2 spaces for indentation.
- Avoid semicolons (
;) at the end of lines. - Use single quotes (
') instead of double quotes ("). - Add a blank line between logical code blocks.
const getUser = () => { return { name: "openhotel" }; }; const saveUser = (user) => { console.log(user); };
- Enable Prettier: Use
npx prettier --write .to format your code. On Windows, Prettier sometimes incorrectly marks all files as modified. Ignore it and proceed withadd/commit/pushas usual.
- Regularly sync with the
masterbranch to avoid conflicts. - Run existing tests (if any) before pushing changes.
If you have any further questions, need clarification, or just want to connect with the community, join our Discord server. We’re happy to help and always open to feedback and collaboration!
By contributing, you agree that your contributions will be licensed under the same CC BY-NC-SA 4.0 license as the project. Please read the LICENSE and README carefully. Any use of this project or derivative work for commercial purposes is strictly forbidden and will be prosecuted.
Thank you for contributing to Open Hotel! Let’s build something amazing together. 🌟