4 ms·

No question, just want to say that I fully understand and support your choice. I run a tiny open source project and literally the first PR was just a terrible e

by jansan 6y ago

No question, just want to say that I fully understand and support your choice. I run a tiny open source project and literally the first PR was just a terrible experience. A one liner that fixed a bug but introduced new issues. So we wrote our own fix and then got insulted to not use the original PR. Yes, being able to switch of external PRs would be a bliss.

lbill 6y ago
Yep, you still have to deal with all kind of people when you do OS, and that isn't always nice. I once made a PR to a project I use a lot at work. The PR was about the documentation of the project, so no change to any feature, no new thing, just an improved version of the tutorial... Or so I thought. The maintainers refused my PR. My first instinct was to be upset about it, but then I thought "this might be a natural reaction because they said 'no', but maybe, just maybe I can avoid acting like a kid and use my brain". So I re-read their reply: it contained a valid reason and provided me with a good solution to my problem, I thanked them and moved on. They were just right to refuse my PR.
hk__2 6y ago
Four years ago I got a PR on a small side-project. It was a nice new feature, although it wasn’t exactly the scope of the project. At that time I thought it would be better to accept the PR since the contributor put some efforts into it, and it would have been rude (or so I thought) to say no. Four years later, I’d say 50% of the burden on that project is due to the feature that PR introduced. I often think about that time, and during these four years I’ve learnt to say no to PRs, mostly after seeing more-experienced open-source leaders doing so. The key aspect is maintainance: contributors come with a feature, they add it to your project, and then the maintenance burden is on you forever. Too much maintainance means you burn out, and the project is dead. It’s important to keep that in mind when deciding to accept or refuse a PR. To avoid misunderstandings and angry people, you should be as neutral as possible: is it a good addition on the long terme? How much maintenance cost does it add? Will it make the project easier/harder to evolve?

by jansan 6y ago

lbill 6y ago

Yep, you still have to deal with all kind of people when you do OS, and that isn't always nice. I once made a PR to a project I use a lot at work. The PR was about the documentation of the project, so no change to any feature, no new thing, just an improved version of the tutorial... Or so I thought. The maintainers refused my PR. My first instinct was to be upset about it, but then I thought "this might be a natural reaction because they said 'no', but maybe, just maybe I can avoid acting like a kid and use my brain". So I re-read their reply: it contained a valid reason and provided me with a good solution to my problem, I thanked them and moved on. They were just right to refuse my PR.

hk__2 6y ago

Four years ago I got a PR on a small side-project. It was a nice new feature, although it wasn’t exactly the scope of the project. At that time I thought it would be better to accept the PR since the contributor put some efforts into it, and it would have been rude (or so I thought) to say no. Four years later, I’d say 50% of the burden on that project is due to the feature that PR introduced. I often think about that time, and during these four years I’ve learnt to say no to PRs, mostly after seeing more-experienced open-source leaders doing so. The key aspect is maintainance: contributors come with a feature, they add it to your project, and then the maintenance burden is on you forever. Too much maintainance means you burn out, and the project is dead. It’s important to keep that in mind when deciding to accept or refuse a PR. To avoid misunderstandings and angry people, you should be as neutral as possible: is it a good addition on the long terme? How much maintenance cost does it add? Will it make the project easier/harder to evolve?