Skip to content

Latest commit

 

History

History
203 lines (146 loc) · 6.6 KB

CONTRIBUTING.md

File metadata and controls

203 lines (146 loc) · 6.6 KB
Raw

🤝 Contributing to octasol

Welcome to Octasol! We are glad about your interest in contributing. Please take a look at this document to support an easy and effective contribution process for everyone.

Following these guidelines shows respect for our maintainer's time, and in turn, they will respond to your issues and evaluate your contributions. You are also invited to join our Discord for any help and support.

 

👀 Table of Contents

  1. Setting Up Local Development Environment
  2. Pull Requests Process
  3. Code Guidelines
  4. Commit Guidelines
  5. How to Report Bugs
  6. Your Help is needed

 

Setting Up Local Development Environment

  1. Fork the Repository

  2. Clone the Repository

    git clone https://github.com/yourusername/octasol.git octasol

cd octasol

  3. Install Dependencies

    npm install

  4. Start the Development Server

    npm run dev

  5. Set Up Environment Variables

    Prisma uses an environment file (.env) for database connection details. Create your own .env file.

    Add your database connection string:

    DATABASE_URL="postgresql://USER:PASSWORD@HOST:PORT/DATABASE"

  6. Migrate the Prisma Database

    After setting up your .env file with the correct database connection, you’ll need to run Prisma migrations to set up the local database schema.

    npx prisma migrate dev

  7. Generate Prisma Client

    If it's not automatically generated during the installation or migration process, run:

    npx prisma generate

  8. Start the Development Server

    npm run dev

  9. Keep your repo up-to-date

Note

Keep your main branch pointing at the original repository and make pull requests from branches on your fork. To do this, run:

git remote add upstream https://github.com/Octasol/octasol.git
git fetch upstream
git branch --set-upstream-to=upstream/main main

This adds the original repository as a "remote" called "upstream," fetches the latest changes from that repo, and sets your local main to track the upstream main branch. To update your main branch, run git pull. Afterward, create new branches from main for your pull requests.

 

Pull Requests Process

  1. Fork the Repository

  2. Clone the Repository

    git clone https://github.com/yourusername/octasol.git octasol

cd octasol

  3. Create a branch for your PR

    git checkout -b your-branch-name

  4. Commit, push changes to your PR

    git add . 
git commit -m "Include a message about your PR"
git push origin your-branch-name

  5. Open Pull Request

    • Go to your fork on GitHub, where you'll see a notification that your branch has recent pushes and an option to create a Pull Request.
    • Click on the Compare & Pull Request button and select your branch from the "head repository" dropdown, and compare it with the main branch of the original repository.
    • Provide a title and clear description for your pull request and which issue it fixes.
    • Prefer async/await over promises for handling asynchronous operations, as it improves readability.

  6. Pull Request Review

    • One or more maintainers will review the changes and may request modifications. After approval, your PR will be merged into the main codebase.

Note

Respond to feedback: If the maintainer requests changes, commit those changes to the same branch. Push the updated code, and GitHub will automatically update your PR. Approval: Once the changes are satisfactory, the reviewer will approve the PR.

 

Code Guidelines

  • Use Consistent Naming Conventions
  • Use camelCase for variables and function names (e.g., myVariable, calculateTotal)
  • Use PascalCase for class names and components (e.g., MyComponent, UserProfile).
  • Use UPPER_SNAKE_CASE for constants (e.g., MAX_USERS).
  • Write clear and concise comments to explain complex logic.
  • Leverage TypeScript's features like interfaces, enums, and type annotations to enhance type safety.
  • Use strict mode for stricter type checking ("strict": true in tsconfig.json).
  • Use OOP concepts for code organization and reuse.
  • Use .env.local for environment variables to separate secrets and configurations from your codebase.
  • Use Tailwind’s responsive utilities to build responsive designs easily.
  • Customize your theme in the tailwind.config.js file to define your own color palette, spacing, and more.

 

Commit Guidelines

Each commit consist out of a mandatory subject, an optional body and an optional footer:

<subject type>: <subject description>
<BLANK LINE>
< optional body>
<BLANK LINE>
< optional footer>

Subject:

  • The subject contains a type of the change and a description, which must not be longer than 60 characters.
  • Must be present tense.
  • Written in the imperative.
  • First letter is not capitalized.
  • Does not end with a '.'.

Allowed Subject Types:

  • feat -> feature
  • fix -> bug fix
  • docs -> documentation
  • style -> formatting, lint stuff
  • refactor -> code restructure without changing external behavior
  • test -> adding missing tests
  • chore -> maintenance
  • init -> initial commit
  • rearrange -> files moved, added, deleted etc
  • update -> update code (versions, library compatibility)

Body:

  • Use the imperative, present tense.
  • Include the motivation for the change and contrast this with previous behavior.
  • Keep lines under 73 characters in width.

Footer:

  • Contain any information about Breaking Changes.
  • Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines.
  • Place reference to GitHub issues that this commit Closes.

 

How to Report Bugs

If you encounter any bugs or have ideas for new features, please open an issues in the repository. Make sure to include as much information as possible, such as screenshots, text output, and both the expected and actual results.

 

Your Help is needed

Please check out the issues. Comment on an issue you would like to work on.

 

Important

By submitting patches, you agree to allow the project owners to license your work under the terms of the GNU License.