I think I'll add a CONTRIBUTING.md to all my repositories, and when you open it'll just read:
"YES! Do it!"
@fribbledom Yeah but like should I email you patches? Use git-request-pull? Upload a tarball with my changed version to my FTP server and text you a URL?
In all seriousness: whatever way you feel most comfortable with.
Ideally though: a PR or at least a link to your git repository. I think at lot of these things have gotten a lot more streamlined since the advent of git and GitHub/-Lab/gitea.
@fribbledom Certainly, but that kind of information does belong in CONTRIBUTING.md. Even if you just say "email email@example.com, explain your changes, and include a link to your repository" or "open a pull request," that's a significant improvement in someone's ability to contribute.
@fribbledom for real, though: I appreciate basic guidelines when contributing. It's good to know what maintainers consider a good PR and/or will save them work, to maximize chances of a merge and to minimize work I'm creating for maintainers.
@calcifer @alexbuzzbee I definitely see where you're coming from relative to providing some direction to would be contributors. I was surprised that I had to add a contributing section to my simple repo: https://github.com/shombando/EmacsVanillaChocolateSwirl. Basically it used to just say PRs welcome as soon as there were a couple contributions this was helpful for me and the contributors.
But I still stand by my decision to open a PR on @fribbledom personal bio repo asking for contributions 😜
Every maintainer is different and most people who want to contribute don't know you.
Contributors want to maximize the chances of their contribution being accepted and minimize the time a maintainer has to waste on a contribution.
If you don't have any requirements wrt code style, commit msgs, branches to target a change, etc, that's useful for a (potential) contributor to know as well.
I found it really helpful for my (closed-source, internal) software thingy to give potential contributors some pointers and conventions used in the code (generic style, conventions specific to the project, overview of available methods/data sources, other implicit assumptions in the code...). Maybe also some guidance for less experienced programmers.
It's also really helpful to discuss contributions beforehand, to avoid multiple incompatible changes.
One person once spent 2 days coding up some complicated numerical solution to a mathematical problem because they had overlooked that I had found and implemented an analytical solution before (which took me more than a day, too...), which was just one function call away. I ended up replacing that routine with 3 lines of code, including checking the validity of inputs... so yeah, talking about it first can be a big preventer of disappointment and useless work.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!