Follow

I think I'll add a CONTRIBUTING.md to all my repositories, and when you open it'll just read:

"YES! Do it!"

@fribbledom I mean that can be line 1 but you should probably explain how to go about doing 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?

@fribbledom There's room for humor but also for useful information.

@alexbuzzbee

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 me@somewhere.example, 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.

@alexbuzzbee @fribbledom Handwritten in cursive in a sealed wax envelope, delivered by carrier pigeon

@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: github.com/shombando/EmacsVani. 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 😜

@calcifer @fribbledom
👆 this
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.

@fribbledom I sent in a PR before this discussion got all serious... Oops!

@fribbledom
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.

@fribbledom
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.

Sign in to participate in the conversation
Mastodon

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!