Thank you for considering contributing to create-project-files
! Any contributions you make are greatly appreciated.
To set up your development environment for create-project-files
:
- Fork the repository and clone your fork to your local machine.
- Ensure you have Node.js and npm installed.
- Navigate to the cloned directory and run
npm install
to install all required dependencies. - To start the development server, run
npm start
. - Make changes in a new branch created from the
main
branch.
This project and everyone participating in it is governed by the create-project-files
Code of Conduct. By participating, you are expected to uphold this code.
Contributions are made to this repo via Issues and Pull Requests (PRs). A few general guidelines that cover both:
- Search for existing Issues and PRs before creating your own.
- We follow the "fork-and-pull" Git workflow.
This section guides you through submitting a bug report for create-project-files
. Following these guidelines helps maintainers and the community understand your report, reproduce the behavior, and find related reports.
Bugs are tracked as GitHub issues. Create an issue on the repository and provide the following information:
- Use a clear and descriptive title for the issue to identify the problem.
- Describe the exact steps which reproduce the problem in as many details as possible.
- Provide specific examples to demonstrate the steps. Include links to files or GitHub projects, or copy/pasteable snippets, which you use in those examples.
- Describe the behavior you observed after following the steps and point out what exactly is the problem with that behavior.
- Explain which behavior you expected to see instead and why.
- Include screenshots and animated GIFs which show you following the described steps and clearly demonstrate the problem.
This section guides you through submitting an enhancement suggestion for create-project-files
, including completely new features and minor improvements to existing functionality.
Enhancement suggestions are tracked as GitHub issues. Create an issue on the repository and provide the following information:
- Use a clear and descriptive title for the issue to identify the suggestion.
- Provide a step-by-step description of the suggested enhancement in as many details as possible.
- Provide specific examples to demonstrate the steps. Include links to files or GitHub projects, or copy/pasteable snippets, which you use in those examples.
- Describe the current behavior and how this enhancement would change it.
- Explain why this enhancement would be useful to most
create-project-files
users. - List some other text editors or applications where this enhancement exists.
- Specify which version of
create-project-files
you're using.
Unsure where to begin contributing to create-project-files
? You can start by looking through these beginner
and help-wanted
issues:
- Beginner issues - issues which should only require a few lines of code, and a test or two.
- Help wanted issues - issues which should be a bit more involved than
beginner
issues.
The process described here has several goals:
- Maintain
create-project-files
's quality. - Fix problems that are important to users.
- Engage the community in working toward the best possible
create-project-files
. - Enable a sustainable system for
create-project-files
's maintainers to review contributions.
Please follow these steps to have your contribution considered by the maintainers:
- Follow all instructions in the template.
- Follow the styleguides.
- After you submit your pull request, verify that all status checks are passing.
While the prerequisites above must be satisfied prior to having your pull request reviewed, the reviewer(s) may ask you to complete additional design work, tests, or other changes before your pull request can be ultimately accepted.
- 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.
- Use CSS selectors that are as short as possible but as long as necessary.
- Use dashes for class names (not camelCase or under_scores).
- Avoid excessive and arbitrary shorthand notation.