Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
127 lines (92 loc) · 5.81 KB

CONTRIBUTING.md

File metadata and controls

127 lines (92 loc) · 5.81 KB

Contributing to VercelZero

First off, thank you for taking the time to contribute! 🎉👍

The following are guidelines for contributing to VercelZero, an open-source deployment platform inspired by Vercel's early V0 experience. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.

Code of Conduct

This project and everyone participating in it is governed by the Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to [dsimoespaiva@gmail.com].

How Can I Contribute?

Reporting Bugs

This section guides you through submitting a bug report. Following these guidelines helps maintainers and the community understand your report, reproduce the behavior, and find related reports.

Before creating bug reports, please check this list to avoid duplicates. When you are creating a bug report, include as many details as possible.

Before Submitting A Bug Report

  • Check the documentation for solutions.
  • Search existing issues to see if the problem has already been reported.
  • Verify the bug persists in a more recent version of the software.

How Do I Submit A Good Bug Report?

Bugs are tracked as GitHub issues. Create an issue and provide the following information:

  • Use a clear and descriptive title for the issue to identify the problem.
  • Describe the exact steps to reproduce the problem in as many details as possible.
  • Provide specific examples to demonstrate the steps.
  • Describe the behavior you observed after following the steps.
  • Explain which behavior you expected to see instead and why.
  • Include screenshots or animated GIFs showing the problem.
  • If the problem wasn't triggered by a specific action, describe what you were doing before the problem happened.

Suggesting Enhancements

This section guides you through submitting an enhancement suggestion, including completely new features and minor improvements to existing functionality.

Before Submitting An Enhancement Suggestion

  • Check if the enhancement already exists by searching through open and closed issues.

  • Verify if your idea fits with the scope and aims of the project by reviewing the README and documentation.

    How Do I Submit A Good Enhancement Suggestion?

    Enhancement suggestions are tracked as GitHub issues. Create an issue and provide the following information:

  • Use a clear and descriptive title for the issue.

  • Provide a step-by-step description of the suggested enhancement in as much detail as possible.

  • Explain why this enhancement would be useful to most users.

  • List some other projects or applications where this enhancement exists, if applicable.

  • Specify which version you're using.

Your First Code Contribution

Unsure where to begin? You can start by looking through these issues:

  • beginner - issues which require only basic programming knowledge.

  • help-wanted - issues which need assistance.

  • good-first-issue - good issues for first-time contributors.

    Pull Requests

  • Fill in the required template.

  • Do not include issue numbers in the PR title.

  • Include screenshots and animated GIFs in your PR whenever possible.

  • Follow the style conventions.

  • Document new code based on the project documentation.

  • End all files with a newline.

Style Conventions

Git Commit Messages

  • Use the present tense ("Add feature" not "Added feature")
  • Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
  • Limit the first line to 72 characters or less
  • Reference issues and pull requests liberally after the first line
  • Consider starting the commit message with an applicable emoji:
    • 🎨 :art: when improving the format/structure of the code
    • ⚡️ :zap: when improving performance
    • 🔥 :fire: when removing code or files
    • 🐛 :bug: when fixing a bug
    • 🚑 :ambulance: when fixing a critical bug
    • ✨ :sparkles: when introducing new features
    • 📝 :memo: when adding or updating documentation
    • 🚀 :rocket: when deploying stuff
    • 💄 :lipstick: when adding or updating the UI and style files
    • 🎉 :tada: when beginning a project
    • ✅ :white_check_mark: when adding, updating, or passing tests
    • 🔒 :lock: when dealing with security
    • 👷 :construction_worker: when adding CI build system
    • 📈 :chart_with_upwards_trend: when adding analytics or tracking code
    • ♻️ :recycle: when refactoring code
    • 🔧 :wrench: when adding or updating config files
    • 🌐 :globe_with_meridians: when dealing with internationalization and localization
    • 💩 :poop: when writing bad code that needs to be improved
    • ⏪ :rewind: when reverting changes

JavaScript & TypeScript

  • Use 2 spaces for indentation
  • Use single quotes for strings
  • End statements with semicolons
  • Prefer const over let (and avoid var)
  • Put spaces after keywords
  • Use PascalCase for React classes and components
  • Use camelCase for functions and variables
  • Prefer arrow functions
  • Use destructuring when possible
  • Avoid large functions, prefer shorter and more focused functions
  • Use meaningful comments where necessary

Documentation

  • Use JSDoc to document functions and classes
  • Provide examples in documentation comments
  • Keep documentation updated when changing code
  • Write README.md for important new components

Additional Questions?

If you have any questions, feel free to create an issue with the tag question or contact the maintainers directly.

Thank you for contributing! 🚀