Hacker News Reader

Comment by daurnimator | Hacker News Reader

I did the same thing..... and then the contributor took contributions from others that added security holes, removed cross platform support, and had what I consider to be low code quality. I've now disowned that project.

Therefore, I'm extremely hesitant to hand out "commit bit"s again. To make up for it I try and review PRs the day of submission; even then I don't get a lot of contributions.

There seems to be a inherent trade off between security+quality and how welcoming you are to new contributors.

On the other hand, I have taken over maintainership for some projects; but it was after months of steady contributions.

View on HN

It's always a delicate balance, as there are obviously a fair number of people who don't know what they're doing (yet, if they're learning), as well as some malicious people.

There are ways to deal with that, e.g. force small patches that solve well-identified problems; use CI to test; involve projects' users in testing; and above all, to have other maintainers in the project who can catch such behavior and help you fix it. By yourself, you're rather vulnerable.

Ideally you have a core of 2-4 people you trust from previous projects, and then you can bring unknown people in little by little.

There is no tradeoff as such, but you do need to be more sophisticated than "here are full commit rights."

Wouldn't it have made sense to revert the first subpar commit, pulled aside the contributors and explained to them what is acceptable?

Disowning the project seems like a lose/lose situation.

I'm not the parent, but I've been burned in the same way. In an ideal world, yes - that would be the right way to handle the situation. In a company you'd want to do that, and probably give the programmer a mentor who can do code reviews and whatnot.

Unfortunately thats:

- Thats a complicated conversation to have at the best of times. With volunteers over the internet its much harder to organise 1-on-1s.

- A huge time sink. Usually I could make the changes themselves in less time than it would take me to explain the changes to a junior developer. Its especially hard to justify for projects I have in maintenance mode, where I don't want to spend time working on project features at all. Long term hopefully the time investment will pay off, but they'll probably disappear long before then.

- Honestly, its also not that much fun. I contribute to opensource projects because I like making things. Managing people doesn't rub that itch.

I'm not saying I have a better solution. But faced with a stream of mediocre PRs from an enthusiastic new contributor that you don't have time to review, what do you do? Abandoning the project to the new contributor sounds pretty reasonable to me.

It was a project that I didn't give a lot of love, and hence just gave them commit rights. It was about a year later before I looked again, by which time they had done far too much work on top of their non-cross-platform bits for me to revert.

I still didn't use the project myself; and didn't care enough to fix it, so I just removed myself.

Yeah, that's one of the dangers. Did you start a conversation with them about it, or just move on silently?

I'm trying to think of a good way to start such a conversation... but it sounds tricky. Probably would depend on the personality of the person. ;)

Why not just let them fork the project if they want to take it in a different direction?

Reply on news.ycombinator.com