I've found that reducing the friction, as much as possible, is the only way to get people to actually contribute.
Excluding things like .vscode and .DS_store, which is a common and universal "don't need that in my repo", is a trivial way to reduce the burden for everyone (the goal of software, imo), maintainer included.
I’m old and cranky enough to want to believe that excluding contributions from VS Code and macOS users is a trivial way to reduce the maintainer’s burden and improve software quality.
That’s completely unfair, of course, and probably false too.
I don't think you need to fencesit that hard. VS Code and macOS users *that don't know how to double check their commit or ignore their junk files locally will definitely cause extra burden and lower software quality. If they can't check their commits for .vscode, do you really think they tested their code properly or thought hard about the code that they wrote? If they don't know abut local git ignore files, do you think they know the language and libraries well enough? If they didn't read the Git docs, then did they read the docs that said to not use a specific function in this way?
If you want to attract novice contributors, sure. This is as much give-and-take as anything else; if you want these kind of people, then you're going to have to throw a bone to these people.
Now, if you don't want contributors, or at least novice contributors that don't know to proofread their commits or ignore their own IDE files, then this actually helps you screen out the contributors you don't want to engage with early.
Comments
I've found that reducing the friction, as much as possible, is the only way to get people to actually contribute.
Excluding things like .vscode and .DS_store, which is a common and universal "don't need that in my repo", is a trivial way to reduce the burden for everyone (the goal of software, imo), maintainer included.
I’m old and cranky enough to want to believe that excluding contributions from VS Code and macOS users is a trivial way to reduce the maintainer’s burden and improve software quality.
That’s completely unfair, of course, and probably false too.
edit: s/maybe/probably/
I don't think you need to fencesit that hard. VS Code and macOS users *that don't know how to double check their commit or ignore their junk files locally will definitely cause extra burden and lower software quality. If they can't check their commits for .vscode, do you really think they tested their code properly or thought hard about the code that they wrote? If they don't know abut local git ignore files, do you think they know the language and libraries well enough? If they didn't read the Git docs, then did they read the docs that said to not use a specific function in this way?
If you want to attract novice contributors, sure. This is as much give-and-take as anything else; if you want these kind of people, then you're going to have to throw a bone to these people.
Now, if you don't want contributors, or at least novice contributors that don't know to proofread their commits or ignore their own IDE files, then this actually helps you screen out the contributors you don't want to engage with early.