# Contributing

# Playground.vue

The Playground file is a cleanroom used for Vuetify development and is the recommended way to iterate on changes within the framework.

<template>
  <v-container>
    <!--  -->
  </v-container>
</template>

<script>
  export default {
    data: () => ({
      //
    }),
  }
</script>

The App.vue file used for Vuetify development is located in packages/vuetify/dev. It contains a v-app and v-main component and the local Playground.vue file.

# Choosing a base branch

Before starting development you should know which branch to base your changes on. If in doubt use master as changes to master can usually be merged into a different branch without rebasing.

# Switch to the desired branch
git switch master

# Pull down any upstream changes
git pull

# Create a new branch to work on
git switch --create fix/1234-some-issue

Commit your changes following our guidelines, then push the branch to your fork with git push -u fork and open a pull request on the Vuetify repository following the provided template.

# For Docs - Language

We do not accept PRs for any documentation changes pertaining to languages other than en. All changes for languages other than en are to be submitted through our Crowdin project. You can help translate in one of 2 ways:

• Using in-context translation service directly through the documentation site. To get started simply select Help Translate in the language drop down in the docs.
• Directly through the Crowdin project.

Note: Languages will not be added to the language drop down on the docs site until they have at least 50% of their translations completed.

# Getting started

In order to get a major feature added to Vuetify you must get your RFC merged into this repository as a .md file. The following is a guide on how to get started:

• Fork the Vuetify RFC repo https://github.com/vuetifyjs/rfcs

• Copy 0000-template.md to active-rfcs/0000-my-feature.md (where my-feature is descriptive. do not assign an RFC number yet).

• Fill in the RFC. Be detailed and put care into the details.

  RFCs that do not present convincing motivation, demonstrate understanding of the impact of the design, or are disingenuous about the drawbacks or alternatives tend to be poorly-received

• Submit a pull request. As a pull request the RFC will receive design feedback from the larger community, and the author should be prepared to revise it in response. New RFC pull requests start in the Pending stage.

• Build consensus and integrate feedback. RFCs that have broad support are much more likely to make progress than those that don’t receive any comments.

• Eventually, the Core Team will decide whether the RFC is a candidate for inclusion in Vuetify.

• An RFC can be modified based upon feedback from the Core Team and community. Significant modifications may trigger a new final comment period.

• An RFC may be rejected after public discussion has settled and comments have been made summarizing the rationale for rejection. A Core Team member will close the RFCs associated pull request, at which point the RFC will enter the Rejected stage.

• An RFC may be accepted at the close of its final comment period. A Core Team member will merge the RFCs associated pull request, at which point the RFC will enter the Active stage.

Once an RFC is merged and the corresponding functionality implemented within the Vuetify repository, it will be part of the next major or minor release. Once released, the RFC will enter the Released stage and be locked.

For more information regarding RFCs, see the official repository: https://github.com/vuetifyjs/rfcs

# General Rules

• Commit messages must have a subject line and may have body copy. These must be separated by a blank line.

• The subject line must not exceed 60 characters

• The subject line must be written in imperative mood (fix, not fixed / fixes etc.)

• The body copy must include a reference all issues resolved:

  docs(sass-variables): fix broken link to api
  
  resolves #3219
  resolves #3254
  

• The body copy must be wrapped at 72 characters

• The body copy must only contain explanations as to what and why, never how. The latter belongs in documentation and implementation.

# Commit types

The following is a list of commit types used in the angular preset:

• feat: Commits that result in new features or functionalities. Backwards compatible features will release with the next MINOR whereas breaking changes will be in the next MAJOR. The body of a commit with breaking changes must begin with BREAKING CHANGE, followed by a description of how the API has changed.
• fix: Commits that provide fixes for bugs within vuetify’s codebase.
• docs: Commits that provide updates to the docs.
• style: Commits that do not affect how the code runs, these are simply changes to formatting.
• refactor: Commits that neither fixes a bug nor adds a feature.
• perf: Commits that improve performance.
• test: Commits that add missing or correct existing tests.
• chore: Other commits that don’t modify src or test files.
• revert: Commits that revert previous commits.

# Commitizen

The Vuetify team uses commitizen for all repository commits. This allows for easy to read and organized commits with minimal change to normal commit functions. Commitizen provides a fluid interface for handling semantic versioning and makes it easier to write release notes.

To get started, globally install the commitizen package using yarn by running the following commands in your terminal:

# Install commitizen and the conventional changelog adapter
yarn global add commitizen cz-conventional-changelog

# Then create a .czrc file that tells commitizen
# which adapter to use globally.
echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc

Once complete, instead of using git commit you will run the command git cz in your terminal. From here, you are presented with a series of prompts used to build the commit message. For additional information, please review our guidlines on commits.