Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't be that open-source user, don't be me

jacobtomlinson.dev

Post reply on HN
Print view View original

141–150 of 173 posts

Re: Don't be that open-source user, don't be me

#141

Post by samatman »

dessant wrote: post #89
Aeolun wrote: post #52

Earlier quoted context omitted.

> It's best to conform to the contribution process described by the maintainer to avoid wasting their time as much as possible. It’s not their prerogative to waste my time, just as it’s not mine to waste theirs. If they’re not happy with a PR they’re welcome to reject it, ask me to fix it, or completely ignore it. When they make a project public they’re explicitly condoning the fact they may get a PR (and nothing els…

> When they make a project public they’re explicitly condoning the fact they may get a PR I don't think that's true. It appears you just assume that because pull requests cannot be disabled on GitHub. Sending unsolicited pull requests to people that clearly told you to open an issue first is disrespectful. You don't have to engage with a project or a community, but if you decide to participate by submitting a pull re…

No, I think it's fair to work backward: GitHub doesn't offer a way to disable PRs, the service is explicitly 'social coding', therefore those using it should not be disgruntled about PRs showing up.

The healthy maintainer-side attitude is that these impose no obligation whatsoever to review, apply, or even look at, the fork in question.

Re: Don't be that open-source user, don't be me

#142

Post by kazinator »

Here is the main problem, highlighted by this comment, from user itmecho:

> I'm subscribed to it because I want to know when it gets implemented, not because I want to know every time someone else wants it implemented.

> I'm now unsubscribing because I'm finally fed up of the +1 emails so I'll have to manually check this issue periodically instead. All because people can't just put a reaction on the initial message

Maybe Github should a conditionally shown dialog box which says: "your comment will generate a notification seen by 150 watchers; do you want to proceed?"

Re: Don't be that open-source user, don't be me

#143

Post by a-dub »

this is all true. and yes, one should never be rude and one should always be respectful of others' time and efforts.

but there is indeed another side to the equation: software does not succeed in a vacuum. it is a symbiosis between users and developers that make software great. a software package gains momentum because users invest time and effort into making use of it or building on it. these investments are nontrivial! the maintainers enjoy notoriety and potential financial benefits (sometimes massive) as a result of this notoriety.

so while yeah, entitled attitudes on oss issue trackers are pretty odious, so are illusions that all open source software is built upon a world of altruism. there's money involved, and sometimes quite a lot of it.

that said, we do need better funding models. one thing that open source does teach us is that some people do their best work outside of a classic corporate structure. some of that best work is literally the best work in software. the problem with funding is that it typically comes with hooks which then drive the projects towards what you see coming out of most corporate environments, so the challenge is to figure out how to fund open source software in a way that doesn't actually influence or drive its design.

Re: Don't be that open-source user, don't be me

#144

Post by [deleted] »

prox wrote: post #15
welder wrote: post #5

As an open source maintainer[1], the etiquette tips are great. However, I think +1 and status check comments are ok in certain situations where the issue might have been forgotten or it's a high priority issue. I also like when someone reminds me they're blocked by an issue. It helps me prioritize fixing bugs so I work on things actually affecting people instead of things nobody is using. Just be polite and your comm…

I think when an issue becomes highly ranked by users, it’s important that devs give clear feedback. In communication, acknowledgement is very important. Just say it if it’s not on the current to do list and when you project to be working on it (or not at all) It gives a clear feedback, and allow people to move on, fork it, stick with it, their choice. Politeness should be key.

[deleted]

Re: Don't be that open-source user, don't be me

#145

Post by freedomben »

Aeolun wrote: post #51
welder wrote: post #5

As an open source maintainer[1], the etiquette tips are great. However, I think +1 and status check comments are ok in certain situations where the issue might have been forgotten or it's a high priority issue. I also like when someone reminds me they're blocked by an issue. It helps me prioritize fixing bugs so I work on things actually affecting people instead of things nobody is using. Just be polite and your comm…

> I also like when someone reminds me they're blocked by an issue. As a user, this feels weird to me. If I’m actually blocked by a bug you’ll receive a PR, not a +1. If I have the leisure to +1 I’m clearly not blocked enough for you to consider it pressing.

I think this needs a big qualifier. I feel the same way, when it's a project I'm capable of doing the work for. For example, I recently needed a way to deal with Stripe early fraud warnings and the library I used didn't have those yet, so I added them over a weekend[1].

However, there are tons of dependencies that we use for all sorts of things that are highly complex where very few people would be able to send a PR (openssl for example). Things in highly complex codebases, or deeply unfamiliar languages, etc. I maintain a forked linux driver for a wireless card for example, and I don't expect there's more than a handful of people that could hack on it without introducing tears and devastation.

For the projects I maintain, I would just say, "if you can, please consider a PR. If you're not sure it would be accepted I'm happy to be asked! If you can't send a PR, give as much info as you can and be polite. With that we're good.

[1]: https://github.com/beam-community/stripity_stripe/pull/728

Re: Don't be that open-source user, don't be me

#146

Post by dessant »

samatman wrote: post #141
dessant wrote: post #89

Earlier quoted context omitted.

> When they make a project public they’re explicitly condoning the fact they may get a PR I don't think that's true. It appears you just assume that because pull requests cannot be disabled on GitHub. Sending unsolicited pull requests to people that clearly told you to open an issue first is disrespectful. You don't have to engage with a project or a community, but if you decide to participate by submitting a pull re…

No, I think it's fair to work backward: GitHub doesn't offer a way to disable PRs, the service is explicitly 'social coding', therefore those using it should not be disgruntled about PRs showing up. The healthy maintainer-side attitude is that these impose no obligation whatsoever to review, apply, or even look at, the fork in question.

GitHub is indeed a platform that can be used for social coding, and it is also a service that encourages the use of contribution guidelines. If the maintainer asks you to open an issue to discuss your contribution before submitting a pull request, you are expected to follow their wishes.

https://docs.github.com/en/communities/setting-up-your-proje...

Re: Don't be that open-source user, don't be me

#147

Post by orbital-decay » 

  The biggest thing that I failed to understand was that with every user commenting

    this feature is essential for me to keep using Grafana

  or asking

    why hasn’t this been implemented yet?

  a barrier was being built to stop anyone from ever working on it.
Wait, does the article not explain why, or does my comprehension fails me?

Other points have been reiterated a million times, and still worth to be reiterated. Sure, the most useful attitude for free software is free to contribute to, not free as in beer. Recently I discovered that Photoshop is pretty poor in handling color for the industrial standard it is. Could I suggest an improvement? Nah. In addition to their imaginary "average consumer" (who of course always wants bells and whistles instead of core improvements), Adobe often cater to the requests of large companies, which I am not. Moreover, they have their own business interests such as market segmentation - they had great software called Speedgrade that they butchered and integrated into Premiere, so video folks got everything and photo folks like me got nothing. Meanwhile, Darktable was free to contribute to, which I did.

Re: Don't be that open-source user, don't be me

#148

Post by saila »

mitchdoogle wrote: post #131
gtirloni wrote: post #110

Earlier quoted context omitted.

We're decades into the open source era and people still need to be reminded of this. Incredible.

What? Open source is about giving to the community. It's not about what you get from it. It's about providing something useful to people without expecting something in return. It's a core part of computing that makes it so wonderful to be a part of and so aggravating when people abuse it.

I think what you're describing here is more like free/libre software and not open source, although the lines between those terms have become fuzzy. IMO, open source is pretty much all about expecting something in return.

Re: Don't be that open-source user, don't be me

#149

Post by dewey »

icambron wrote: post #81
dewey wrote: post #26

Earlier quoted context omitted.

> This can be useful to maintainers because they can sort by thumb up and see the most popular ones. TIL, but I also think it's not really clear what a reaction does. Does adding a reaction to a comment in an issue thread bump the whole issue, does it have to be added to the top issue to show up in sorting? I think a global "Vote for this issue" button would make this a bit more clearer than just a reaction within th…

The point here is to not bump the issue. My GitHub notifications are a mess, and bumps cause me to unsub from notifications to issues in my own repository. There’s also a 0% chance a bump is going to cause me to reallocate my evening, so it doesn’t help get the issue moved forward.

Bumping doesn't necessarily mean "sending an email to the maintainer and everyone on the issue", adding a reaction can also "bump" an issue in the sense that it bumps it to the top of the list if sorted by "thumbs up reaction".

Re: Don't be that open-source user, don't be me

#150

Post by nijave »

philliphaydon wrote: post #42
strken wrote: post #31

Sometimes you can just go fix the software yourself. Maintainers always seem to say you should file an issue before working on a PR. However, I find for features you really need, you should just fork the software yourself[0] and implement what you need, then put up a quick PR with your changes. The worst they can do is reject your changes, in which case...well, you're using your fork anyway. [0] Github forks are ligh…

A couple of times I’ve come across issues in OSS and gone to raise a bug report while digging through the code to see if I can fix it or propose a solution. But when I opened the issue and saw it required me to write a novel I’ve just closed it, worked around or patched it and moved on. It’s too much of a hassle.

The ones that demand reproduction always get me. I get it: reproduction instructions make it infinitely easier to repair software. On the other hand, there are many cases like race conditions that can be very hard to reproduce and sometimes you can get enough context from stack traces/logs/debug info to figure out and fix the problem anyway.
Post reply on HN