Comment by peterwwillis | Hacker News Reader

Comment by peterwwillis | Hacker News Reader

I've been involved with open source communities off and on for over a decade, as well as other, non-computer communities. News flash: It's not the community that becomes toxic, it's humanity.

Every community that I've ever witnessed gets toxic at some point. As in-groups grow more insular and people become more involved, they get more toxic. But the solution to this phenomenon doesn't have to be black & white. I have always stayed on the margins of communities, and still dip my toes in the water occasionally to get something done. But do I need to keep private forks of patches to avoid messy interactions? Nope.

It's pretty easy to fire off a pull request or patch set and then forget about it. I'm not investing great deals of effort or emotion. I'm just sharing my crap. If they merge it, fine, if they don't, fine. But I'm certainly not keeping super secret private repos for just the cool kids to use. That would be even more involved than what little I am already.

This guy has the right idea. Do you think it's worth it to send a PR because it's a cool project? Submit a PR. Maybe because you submit a PR more people submit PRs. Keep your fork and pull the changes that you like while giving back things you think are useful. I've never really understood why people actually want to deal with the people on the other side of the code. I just want your code, not you. I really don't care about you. I can hardly expect you to care about me. Your code and what I can do with it are more interesting than you in nearly all circumstances. So, I contribute to the codebase and I take what I want. Your opinions and thoughts are usually useless.

OpenBSD has the proper motto for this: "Shut up and hack". If more oss devs followed the motto then they would be happier as a whole.

With the CoC in most projects, that's changing. See also: the Python Mailing list, where threads are locked and people are being banned for CoC violations.

It's like you only read the end of my post and skipped the rest of it. I'm going to be a dick here when I say this but this is the reason I have my way of dealing with things people... What you just posted is useless. I don't give a damn. If need be I will fork it, work on it, submit a PR if I make something useful and take what's useful that other people have made for my own code, even among the other forks/branches people have made if it's easy enough to find.

My interaction with them is limited to the functionality of the code that I have written and the bare minimum effort needed to let them know of its existence. Anything more is a waste of my time - I have things to build.

I know what you mean, but it's not as clear cut as you think it is.

You don't operate in a vacuum when you work on projects. What if you think someone is wrong? Being direct might be a risk, because then the community might not be seen as "welcoming to newcomers" anymore.

I mean, ideas don't come out of nowhere for projects, and people who care about things, will be passionate about them. What if someone comes in the way of you building things? What then?

>You don't operate in a vacuum when you work on projects.

OP Is exactly describing working in a vacuum. They've got no ego invested in the project and whoever does can decide if they want to use their modifications.

>What if someone comes in the way of you building things? What then?

I don't think you're describing someone getting in the way of you building something. It seems more like, "What if you don't feel validated, by some community, after you built something?" Which is something leadership of any project might choose to evaluate. Does the project benefit more by trying to provide validation to everyone who makes an attempt to contribute or not?

In my experience, providing validation for anyone other than children is an enormous waste of time. Especially when building something.

Not a serious problem with "fire and forget", but an annoyance: say the patch is not up to standards: not well designed, needs tests, or whatever. It worked for the contributor but it can't be merged in its current form.

Now the maintainer has to explain what's wrong to a contributor who isn't going to do anything about it. And then explain again and again to everyone else who wants that feature that no, it needs work and can't be merged yet.

(Yes, I am that maintainer with dozens of open PRs on his repo, none so bad they must be closed, but also not good enough to merge.)

Then again, why should you wait for the original submitter for those modifications? The original contributor published his code, and has not given any indication he's interested in the rest of the process. Why can't anyone else who wants that feature pick up the slack? Maybe you can make that explicit, marking such feature requests as NEEDS_WORK or something?

This is where the behavior of the maintainer is key.

On one hand, if the maintainer asks the contributor to fix up their code, the maintainer can be seen us ungrateful, demanding, dictatorial, and/or pedantic.

On the other hand, if the maintainer makes the changes herself, they can seem impatient, uncooperative, overpowering, and/or power-hungry.

Regardless where on the above spectrum the maintainers behavior falls, they can come across as friendly, neutral, pessimistic, or toxic. That depends on how they communicate. It also depends on the social norms that the maintainer and contributor are used to.

A maintainer must be extremely vigilant and aware of the tone they use and the image they want to portray. The contributor should also be aware of these things. If either side wavers, opportunities for an unhealthy brew arise.

This is compounded by the fact that most people, maintainers and contributors, are doing the work on a volunteer basis. Often there is an unspoken expectations that others should be grateful for the work that they are doing. When these expectations are not met, sour feelings arise.

Yes.

Given how difficult this is, it's no surprise to me that potential contributors might not want to stick their neck out, as expressed in TFA.

Yes, I find it helps to say "here is what is needed, anyone should feel free to take it from here." In my first response, so it's clear I don't expect anything more.

Quite a few PRs were improved and merged this way, and I think the feeling of community is enhanced when a PR goes through multiple revisions by multiple contributors.

"(Yes, I am that maintainer with dozens of open PRs on his repo, none so bad they must be closed, but also not good enough to merge.)"

Go ahead and close them with notes that they can be re-opened if they come up to standards, but that you don't have the time or interest or capability to do it yourself, and that you are not judging them beyond this comment.

Closing a PR doesn't mean as much as people kinda think it does; they can be re-opened. Closing them without comment is harsh, but it correctly represents the current state of the world, which is that without changes, they aren't going in. Closing them with comment is the best compromise between all the issues.

As a maintainer, you need the "open PR" list to be a list of meaningful, actionable items. You don't have all that many tools to use, and the ones you do have need to be kept sharp. It's OK.

This. If you have 20 open PRs and all of them are old, they should be closed. Same for issues if they don't appear to have any resolution or are too stale.

If people keep asking for a feature that isn't ready, you can make an issue that depends on the PR that describes the acceptance criteria for the feature, and send them the link. Or you can edit the top of the PR description with the acceptance criteria/status so new people see it immediately.

A third option is to refuse issues and PRs entirely and just use mailing lists. Less people will ask for a feature because it takes a lot more work to dig through mailing lists, and by that time you've already found the thread and know why it isn't accepted yet.

On a technical level, I think this encourages the contributor to delete the branch, in which case it's gone for good and benefits no one.

If GitHub automatically saved a copy of each PR branch, I would be more receptive to this advice. This would potentially cause a lot of other problems...

> dozens of open PRs on his repo, none so bad they must be closed, but also not good enough to merge

But you've decided to reject them. Isn't that just what 'closed' is for?

They're not rejected. They're just not ready.

If it were something really stupid or wrong, I'd close it, sure.

I like your route. Another thing to point out about just fire-and-don't-care-if-it-hits contributions is you still can take credit for them. You put your effort in, you improved the software as you see it, you benefit from that even if they don't want it, others can benefit from your fork, and (if branding) you can even highlight your improvement in CV or resume.

So, you and/or others might benefit from them taking your contributions. You and/or others might still benefit when they don't. You can't control what they do anyway. So, might as well set it up so you and others can benefit either way.

Fire and forget open source can be fun if you truly forget about it, because then you can be surprised by coming across it in the wild.

I wrote something in the early '90s, entirely for my own use. I thought others might find it useful, so tossed it up on my public FTP space at school, added a notice saying it was public domain, posted a single message to the appropriate Usenet group saying it was available in case anyone might find it useful, but that since it fully satisfied my needs I was not going to do any further work on it nor was I interested in any enhancements, and stopped reading that Usenet group.

I few years later I noticed Red Hat included a package with the same name ("suck"). Curious, I looked to see what it did--and found it was a descendant of mine! Someone looking for something like it found mine, which did a good chunk of what they were looking for, added the parts missing for their needs, and had been maintaining and distributing it.

(And I just checked...it's still in some Linux distros! It's in Debian 9, package name "suck". Too bad I've long since lost my original code. It would be interesting to see if anything of mine has survived in it).

Yeah, this is a great feeling.

Not anywhere near the same scale as proliferating throughout the linux package managers, but in my early teens I played an online text RPG and ended up writing a fairly large amount of code on top for playing / navigating / fighting etc. When my hobbies shifted away I shared it around and promptly forgot it.

I checked in briefly about 10 years later and was happy to find a lot of my stuff still floating around and being maintained/extended in various forms.

Reply on news.ycombinator.com