docs: Contribution page

[Phlow2001]

Per discussion in discord documentation channel:

The Contribution page could probably use additional information:

• node version (not enforced at package.json?)
• Commit message format (lower case, length limit, ?)
• Merge style (Team prefers rebased merge, all the time or only when not PRing to master/dev?)
• Troubleshoot info for common error messages (node version, windows-build-tools?, yarn?)
• For those with mutiple environments (work vs open source), info on setting local user.name and user.email in the vuetify repo

[KaelWD]

not enforced at package.json?

vuetify/package.json

Line 25 in 9e78c05

"node": ">= 11.7.1",

Commit message format

There's a kinda confusing template from three years ago, could be cleaned up a bit: https://github.com/vuetifyjs/vuetify/blob/master/.github/.git_commit_msg.txt

Merge style

We squash PRs, so people can do whatever they want on their branch. Should probably mention to actually create a new branch, I see lots of PRs from master. If I've requested changes on a PR though I prefer it to not be rebased afterwards as it makes it harder to follow new changes.

info on setting local user.name and user.email in the vuetify repo

Set core.autocrlf input too, all the scripts assume sane line endings.

[Phlow2001]

Ok, we should stipulate node also < 14 too then, if it's broken (which it seems it may be)
So squash merge when we're in normal mode. When working in feature branches without PR's, cleaner commits are desired (rebase to avoid merge commit)?
Is core.autocrlf input needed with * text=auto in .gitattributes?

[MajesticPotatoe]

core.autocrlf=input is git config setting, which is actually one of the prompts during the installation of git, so may be best to actually mention something along those lines (and how to manually apply it).

Not sure we would want to do text=auto in .gitattributes, per the git docs

When text is set to "auto", the path is marked for automatic end-of-line conversion. If Git decides that the content is text, its line endings are converted to LF on checkin. When the file has been committed with CRLF, no conversion is done

Which would give us mixed line endings

[KaelWD]

We already have text=auto in .gitattributes. Adding eol=lf would fix that without requiring a config change:

This setting forces Git to normalize line endings to LF on checkin and prevents conversion to CRLF when the file is checked out.

https://git-scm.com/docs/gitattributes#_eol

cleaner commits are desired (rebase to avoid merge commit)?

Yeah if you're working on a shared branch and it's dirty when you fetch, use pull --rebase to avoid merge spaghetti. Granular commits on feature branches are fine.

[KaelWD]

Node 14 should work now

[damienrobinson]

During my first time contributing, I noticed a couple things while trying to understand how to get started.

I didn't understand how to test changes using the playground. It would have been nice to have some documentation mention it, maybe in the Contributing page? I only figured it out after looking at the markup section in the pull request template and trying to work the dev environment.

Since I am on windows it would be nice to have the git config setup for eol=lf or as mentioned above core.autocrlf=input in .gitattributes.

[johnleider]

autocrlf was fixed in ~2.2 of Git I believe.

[icleolion]

FYI, Yarn 2 works fine also. Just need to avoid the per project install that they now recommend for v2, as you'll end up with additional untracked files. https://yarnpkg.com/getting-started/install#per-project-install

[KaelWD]

We can add those to .gitignore