[HN Gopher] Don't be that open-source user, don't be me
___________________________________________________________________
Don't be that open-source user, don't be me
Author : 1una
Score : 230 points
Date : 2022-06-19 08:15 UTC (14 hours ago)
(HTM) web link (jacobtomlinson.dev)
(TXT) w3m dump (jacobtomlinson.dev)
| WesolyKubeczek wrote:
| I feel like there is a lot of articles lately that call for
| empathy towards oh so ever poor and overworked and burned out
| maintainers. All true, but this is only half of an issue.
|
| The issue is that the concept often brandished in those articles,
| empathy, is a two-way street. There are maintainers on one side
| of this, and there are, on the other hand, users, who often are
| integrating multiple software projects and products to produce a
| solution of some kind. Mind you, those users are not always
| entitled prima donnas at FAANGs making another service to track
| you or something inconsequential like an online game. Sometimes
| they are integrating stuff at your local ISP. Or it's some system
| at a local school. Or they are making systems that are just means
| to an end, like in a hospital, or a bakery, or whatnot. Or it's
| an automotive shop. You get the idea; the world doesn't run on
| cat pics alone, and sometimes a complex software system is just
| an ingredient.
|
| And you know what? When integrating all this stuff, you end up
| not with that small insignificant bug in that one project, but
| with multiple bugs in many pieces of software that have all to
| work together and be reliable. You also deal with not so much
| bugs per se as impedance mismatches that you have to paper over.
| It really ends up bleeding from a thousand cuts.
|
| "Fix it yourself" is possible, but it doesn't scale. Upstream
| doing it scales.
|
| And before you tell me, "well if you're so upset then don't use
| it", or "nobody owes you anything so fuck you", I have to say
| that it works the other way too.
|
| I get a feeling that many open source software maintainers get
| into this business because they think that either a big company
| is going to pay them dearly, or their resume will be stellar, or
| that they will become rockstars and get all the bitches from it.
| And when harsh reality sinks in, they start writing about being
| overworked and burned out. Not every maintainer does it, but many
| do, or at least it looks like it.
|
| And if you get burned out and whatnot, you have an option to just
| stop working on stuff that is deteriorating your health. Walk
| away. If a popular project is hinging on an unhealthy development
| model and is going to die if you walk away, so be it! The market
| will cope, believe you me. The community will find a way around
| it. What is not good, though, is if you, the maintainer, are
| burned out, or overworked, but stubbornly insist on being a
| bottleneck in the project under your inept stewardship
| nevertheless, and just whine and moan about your burnout to get
| internet points and worldwide pity.
| losingom wrote:
| >What is not good, though, is if you, the maintainer, are
| burned out, or overworked, but stubbornly insist on being a
| bottleneck in the project under your inept stewardship
| nevertheless, and just whine and moan about your burnout to get
| internet points and worldwide pity.
|
| The problem is when there are no other maintainers to the
| project, and you quite firmly believe the project itself has a
| future, just that nobody else is able to do so. Yes, you can
| quit, but if people truly do rely on your project (but nobody
| is actually willing to take the reigns) then it can become an
| issue of pride for some. To be clear, I'm not suggesting that
| people burn themselves out (I myself have gone down that road
| before), just that "Walk away" isn't always such an easy option
| for some people.
| WesolyKubeczek wrote:
| > you quite firmly believe the project itself has a future,
| just that nobody else is able to do so.
|
| Looks like some unwarranted feeling of self-importance
| combined with the sunk cost fallacy.
|
| You still have options: make it paid only, stop taking
| contributions at all, hire someone to sort it out or find a
| volunteer to do so. Or walk away and see how quickly Amazon
| will copycat you.
|
| Or accept that that's the cost of having your pride.
|
| Otherwise it's almost a textbook example of emotional
| blackmailing some parents are known for.
| jacobtomlinson wrote:
| Hey HN folks! Author of the post here, wow I didn't expect this
| to make the front page. It's really fun to see all the discussion
| here around this topic. I'd originally written this post to just
| have something up my sleeve to send to folks who were being
| unkind to open source maintainers. I'm enjoying seeing some of
| the counter arguments too.
|
| The general intent of this post is to try and communicate to
| folks that if you consume open source software the authors of
| that software don't owe you anything. However they all contribute
| for a reason, whether that is personal enjoyment, presence in the
| market, user testing, etc. They are excited to have folks use
| their software and they definitely want to hear from you. But
| it's important to remember that this isn't a commercial
| arrangement like when you buy Photoshop. So if you want to
| interact with a maintainer remember to be kind and respectful
| (you probably should be with all humans anyway). It is up to them
| where they focus their effort, and if they have a choice between
| interacting with nice folks or rude folks who do you think they
| will choose?
|
| I also regularly see folks being rude on the most important
| issues, which results in maintainers avoiding them and even more
| folks being rude. It can snowball into having things that are
| critical to the community becoming a low priority to the
| maintainers.
|
| TLDR; Be kind to folks who give you things for free.
| FatalLogic wrote:
| This is a thoughtful and important article for anyone who uses or
| creates open-source software, which is everyone.
|
| But, if we follow this advice? If some more thoughtful and
| considerate users kindly reduce their input into support
| conversations to avoid overwhelming developers, doesn't this mean
| that support conversations will become dominated by users who are
| not thoughtful and considerate?
| jacobtomlinson wrote:
| OP here, thanks for the kind words!
|
| I hear your point. I'm not saying don't make a comment, just
| that folks should try and consider the human on the other side
| more.
| giomasce wrote:
| The point is not reducing input per se, but reducing entitled
| input that doesn't give back anything to the community.
| prox wrote:
| It's a problem everywhere in software, the ones who give back
| the least feel the most entitled. Having a some form of a
| treshold is good, whether that is money, or some sort of on-
| boarding (e.g. can't comment until you are a member for x
| days)
|
| Usually the ones with loudest mouths have the shortest
| attention span and don't bother with those things. I have
| seen this in many communities.
| FatalLogic wrote:
| >The point is not reducing input per se, but reducing
| entitled input that doesn't give back anything to the
| community
|
| That's true, and it's a good goal.
|
| But, my point is that if we try to reduce entitled input by
| simply asking people not to behave entitled, then the result
| may be that we increase entitled input (as a proportion of
| all input), because many 'entitled' users will ignore the
| request, because they feel entitled.
|
| In the common scenario where developers are already
| overwhelmed with suggestions and demands, then they will have
| even less time to separate out the good suggestions from the
| bad.
| jka wrote:
| I don't know what the best answer to that potential problem is:
| I think users should continue to be allowed to comment on any
| issue.
|
| However I do think that the amount of analysis and effort that
| the user has done for each comment is relevant.
|
| Silly hypothetical example: if a project is a Fibonacci
| function that (incorrectly) prints nothing but repeated "1"
| values, then the potential range of comments may include:
|
| - "it's wrong"
|
| - "it's printing the wrong output"
|
| - "expected to see 1 1 2 3 ... but found 1 1 1 1 ..."
|
| - "line two is missing an addition operator near character
| five"
|
| - "please see #3 for a pull request to add an addition operator
| on line two"
|
| (roughly in order of estimated "most frequent" to "least
| common" comment volume -- and not coincidentally, also ordered
| from "least analysis" to "most analysis" performed)
|
| Not all participants have the same level of analysis and
| development ability - and for many projects there's a lot of
| surrounding domain knowledge (and/or history) required to post
| more valuable comments.
|
| Also worth noting: high-frequency, low-analysis comments along
| the lines of "it's broken" can still be useful - they're often
| an indicator that a bug has been introduced, and can be the
| equivalent of comment storms on Twitter asking whether a
| service is down after a website/API has an outage.
|
| Coming back to the problem: it's difficult to scale the ability
| of small groups of maintainers to respond to large volumes of
| comments - as the article alludes to, it can become a kind of
| "time denial of service" attack. I'd guess that problem is most
| pronounced for developer-and-end-user-facing projects (web
| frameworks, for example).
|
| One solution could be tools that help maintainers cluster and
| categorize comments -- customer support tools are often
| designed to do this.
|
| Another idea is whether it'd be possible to challenge the
| commentor gently to check whether they've provided all the
| relevant information. This could theoretically be
| conversational (human or automated) -- and that's similar to
| tech support in traditional IT.
|
| Finally, a structural solution is to attempt to choose software
| architectures that distribute the support load and allow
| clusters of maintainers and developers to develop expertise in
| particular areas. This is, to a large extent, naturally the way
| that open source evolves. If one project becomes too
| heavyweight, then frequently we'll see smaller libraries emerge
| that provide the core functionality elements with a smaller
| code surface. If development slows unacceptably or moves in
| problematic directions, then motivated actors generally step in
| to fork or create an alternative.
|
| In summary: I think that these ticket entitlement issues have
| likely existed in closed environments for a long time, and
| there are patterns and tools for dealing with them that may be
| valuable. Also it's a software-and-organizational architecture
| issue (in an evolutionary environment with no central
| authority).
| [deleted]
| Zenzengele wrote:
| Grafana is a bad example.
|
| They switched to agpl and pushing companies in paying for it.
|
| Which is okay of course but grafana labs is no longer a free open
| source project.
|
| Of course potentially feature request might come in by key
| account manager or other hidden business agreements but I myself
| still comment on the opensource front like GitHub issues.
|
| When my company now pays money for it, my expectation definitely
| changes.
| pengaru wrote:
| > When my company now pays money for it, my expectation
| definitely changes.
|
| Familiarize yourself with the difference between "free beer"
| and "free speech".
|
| The F in FOSS refers to the latter, you're fixating on the
| former.
|
| The FSF has _never_ objected to charging money for Free /GPL
| software. Programmers need to eat too.
| Elinvynia wrote:
| How is AGPL not FOSS as defined by both OSI and FSF?
| pabs3 wrote:
| AGPL has been accepted as libre by all of OSI, FSF and
| Debian.
|
| Some folks and types of companies don't like it due to the
| extra code distribution provisions that trigger for modified
| versions that users interact with over a network.
| andris9 wrote:
| I also run a few popular open-source projects (eg. Nodemailer)
| and what grinds my gears the most are the support requests
| disguised as bug tickets. It takes so much time to handle these -
| first to verify that this in fact is not a bug, and then come up
| with some kind of response.
|
| For example - someone uses Nodemailer and the server they are
| running their code on has the firewall configured to block non-
| HTTP/S ports, including email ports. Now their app gets timeouts
| left and right and the obvious thing to do in that case seems to
| be to go and file the 1000th bug ticket in Github with the same
| "works on my developer machine, but not in the server" subject.
| tommoor wrote:
| Very much the same here. I'm the maintainer of Outline
| (https://github.com/outline/outline) - which uses Nodemailer by
| the way, thanks! - and folks still push through all of the
| GitHub workflows that try and direct self hosting support
| tickets to the discussions board and post them as bugs instead
| . This is much more annoying and time consuming than the +1
| comments which can largely be left without a direct response.
| cube00 wrote:
| _> I also occasionally returned to issues that hadn't been
| resolved to [..] ask if there was an ETA on a fix. I felt I was
| being helpful._
|
| I irrationally get annoyed when someone asks for an ETA like
| this, I'm sure it's a genuine question but it just feels like a
| nag to "hurry the fork up already!"
| nmstoker wrote:
| "If you take anything away from this post I hope it is that these
| costs need to be paid by someone, the maintainer." - there will
| be a minimal cost attending to _any_ interaction but provided the
| efforts made by a reporter are sufficiently well focused then
| that reporter is saving time for the maintainers.
|
| The issue i observe is countless people do such a stunningly bad
| job at reporting problems. I've some sympathy for those whose
| first language is not the same as the maintainers, but putting
| thosr aside, the list of inept/time wasti reports is very very
| long.
|
| - subject only issue with only vague adherence to a complete
| sentence!
|
| - no unambiguous description of the problem
|
| - no indication why it's thought to be deviating from
| (reasonably) expected functionality
|
| - no indication of steps before issue
|
| - nor if it's a one off, repeated, always happened/just
| started/happens to others
|
| -no mention of context (eg system, installation method, any
| reasons it might be expected not to work)
|
| and more!
| softfalcon wrote:
| I understand, agree, and feel for you. It sucks when people are
| vague when asking for something.
|
| From what I can tell though, a lot of folks are vague in
| general. They'll avoid putting in the effort to clarify as long
| as possible, hoping others will do that clarification work for
| them.
|
| The question I then ask is "why?"
|
| I think the answer lies in three categories of people:
|
| - lacking knowledge: to know what's worthwhile to explain
| what's happening (common with non-technical folks)
|
| - lacking time: to take the necessary effort to describe and
| explain something is expensive if you have a very full schedule
|
| - too lazy: can't be bothered to care enough to take the time
| to explain themselves properly.
|
| I'd like to think it's more of points 1 and 2 that are causing
| this problem, but I have a feeling the majority of it is point
| 3 based on my interactions with humanity.
|
| What are your thoughts on this? Ideas for how we could improve
| bug submission given this very clear and arguably difficult
| problem?
| nmstoker wrote:
| You're absolutely right to ask why, and the reasons you give
| do drive the difficulties here.
|
| Although I'm fairly technical, I think I have a fair
| understanding of those in the non-technical camp due to my
| background and general experience, but I sense I sometimes
| expect too much of the average person (not meaning this to
| sound superior!)
|
| Improving bug submission is worth consideration because
| there's value to be unlocked: the people in need of a
| solution have insights the developers etc benefit from and
| they themselves would benefit (one hopes!) from the solution
| but there's a good chance it could apply for others too.
|
| From the little I've read about behavioural science, i
| suspect that a selection of nudges may help but it could take
| time and perseverance to get it right. There are little
| tricks that Github and SO already use to shift things the
| right way. It's important to base these on how they'd work
| for target users, as designing them for how people who design
| such systems or already have well developed problem solving
| serves no one and will fail! It's also important not to be
| overly Draconian or pushy (keeping the nudges reasonable)
| seems important too, and the smartest ones probably lead
| people on to better submissions as much as block bad ones,
| the earlier the better (no one wants to fill in some onerous
| form only to be told off by a computer!)
| rapind wrote:
| It's definitely laziness, but they'll argue it's lack of time
| (and lack of knowledge is really just too lazy to self
| inform). It's not just a problem with open source, but
| commercial product support as well.
|
| I've had customers who invest no effort in a support request
| then get annoyed when we try to politely extract what the
| actual issue is from them.
|
| For open source I'd lean towards a policy of 0 investment
| from you, then 0 investment from me. You can always archive
| low effort issue reports to peruse at a later date when you
| have free time to see if you can discover something
| meaningful in them.
| tennis_80 wrote:
| I agree with this.
|
| In my experience often people want to push the problem to
| someone else - if you can say in your team status update
| "I've opened a ticket with X, waiting on them to solve the
| issue", you can get away with being blocked. If the
| aforementioned ticket is closed for lack of detail, it
| becomes more obvious to others on said team that the person
| needs to do more exploratory work.
| anonred wrote:
| Bug report templates work wonders. Ours is just some
| checkboxes and a few lines for OS version, package manager,
| etc. but it's been effective at filtering out low effort
| reports.
| solatic wrote:
| The naive approach is to have bug submission be part of the
| product you ship to customers. If you run into an issue - "a
| report has already been sent. If you want to follow the
| status of your report, click here <link with bug ID number>".
| If the user runs into an issue that doesn't trigger the
| automated bug report submission, then have a UI with the
| relevant questions, which can automatically attach stuff like
| application version number, OS version, etc.
|
| The problem? a) Pretty expensive to implement. You basically
| need to be FAANG with a huge install base and measurable
| reduction in customer service costs to justify the expense.
| b) This pattern doesn't integrate well into developer
| workflows, i.e. if you try to automatically open a GitHub
| issue with it, then who opened the issue, a bot? How do you
| ensure users stay notified, even if they don't have a GitHub
| account? If the issue is a duplicate of an existing issue,
| how do you auto-subscribe the user to the existing issue?
| What if the repository is private?
|
| You can't really come up with technical solutions to human
| problems. The human problem is that users need to be
| _listened to_ , and you need to _talk with them_. Maybe it 's
| a bug, maybe it's a feature. Maybe the user has an issue with
| their Internet access. Maybe the user didn't RTFM. You run
| into this problem with poor GitHub issues because _GitHub
| issues is not a platform for Product_ , and you should not
| force it or expect it to become one just because it seems
| easier to do so when everything else relating to the open-
| source library is already there on GitHub.
|
| GitHub Discussions is a step in the right direction, but
| GitHub's UI is currently lacking in terms of helping projects
| start to move Product and Customer Support into Discussions
| and creating a consistent user experience across projects for
| doing so.
| nmstoker wrote:
| Interesting you should mention about submitting details
| like app version number, OS version etc.
|
| Although it's not within an app, and only partially
| automated, i tried building a tool to help people gather
| Python environment details etc to help them create richer
| Github issues with less effort:
| https://github.com/nmstoker/gatherup
|
| The demo video needs work to explain it better and as a
| project it didn't really go anywhere but it was interesting
| to work on a few years back.
| pydry wrote:
| I see this almost as a technical problem.
|
| Developers want polite, clear, obvious, deduplicated, fully
| fleshed out bug reports. They want to hear the praise but dont
| want the shit talk.
|
| Users want somebody to talk to who can help fix their problem and
| to lobby for their pet feature requests. They generally dont know
| what to file under bug or support request.
|
| A system with a different UI for both that could be intermediated
| by some low-time-investment support roles filled by enthusiastic
| power users would help immensely.
| orbital-decay wrote:
| 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.
| karmakaze wrote:
| > a barrier was being built to stop anyone from ever working on
| it.
|
| I looked in the grafana github issues, sort by +1's and the top
| one "Templating: Reuse template variable definitions across
| dashboards"[0] opened in 2015 has these comments (and others):
|
| "yea, with Grafana 2.0 and the new backend, it would be
| possible in a future release (maybe next year or this winter),
| to add template variables as independent entities that you can
| reuse across dashboards."
|
| "Torkel, this is exteremely important for us, any chance you
| could prioritize this?" +1 (23x), -1 (1x)
|
| "no, maybe if it would get a lot of +1 :) People have been fine
| without centralized storage of template vars this far, just
| define them for one dashboard and then copy that dashboard. Not
| ideal. [...]"
|
| This is exactly how I expect these interactions to go. I
| suspect the difference is that this is an issue that is on the
| radar and close to where the contributors are working vs many
| of the other 2.2k issues that are not.
|
| July 2021 comment "[...] we do plan on tackling this issue as
| part of our evolution of Library Panels. We don't have a
| timeframe to communicate yet, but consider it 'on the
| roadmap'." So even ones that are on the radar don't necessarily
| get immediate attention.
|
| What may be missing is clear up-front communication to set
| expectations for those creating, commenting, or up/down-voting
| on issues. We as a community can also default to interpreting a
| non-response as being 'lower priority or relevance than
| contributor bandwidth allows'.
|
| [0] https://github.com/grafana/grafana/issues/1959
| rwmj wrote:
| I'm an open source developer (and user of course), and I don't
| like people acting entitled. However I don't mind people
| commenting on bugs that they're also have the bug, because it
| gives some indication about which bugs are affecting lots of
| people and which are rare. I also have a rule of thumb that for
| every user who comments on a bug, probably another 9 are
| affected.
|
| Also please file bug reports that I have some hope of reproducing
| locally, or if not, include all the information you have, such as
| the full commands and errors, the versions of everything that
| might be relevant etc.
| paulcarroty wrote:
| I like "business first" approach:
| https://drewdevault.com/2021/03/03/To-make-money-in-FOSS-bui...
|
| Yeah, it can be very hard depending on the case, at least some
| premium features/merch/books/guides should be used to keep an
| open source project alive.
| vegetablepotpie wrote:
| Reminds me of the wiring pi debacle. Gordon got tired of
| supporting novice users for free and stopped publishing updates
| to his project in 2019.
|
| > I've had over 10,000 emails from people who upgraded their Pi
| and found that code stopped working because they were reliant on
| a system, which had statically linked an older version. This
| sheer incompetence on their part has saddened and depressed me
| hugely.
|
| https://www.i-programmer.info/news/136-open-source/13036-wir...
| a-dub wrote:
| 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.
| floor_ wrote:
| I feel like this is the end result of giving away hard work for
| free when it should have been charge for all along. When you give
| your work no value, people will perceive no value in your work.
| mproud wrote:
| I think the wrong message is getting made.
|
| The takeaway I am getting is: don't interact or communicate with
| open source projects you use.
| pella wrote:
| the other part: https://polite.technology/preview
| strken wrote:
| 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 lightweight, easy(ish) to keep up to date,
| and integrated into a lot of package managers.
| mid-kid wrote:
| > The worst they can do is reject your changes, in which
| case...well, you're using your fork anyway.
|
| Actually the worst result is ignoring the PR for years. I've
| seen this happen quite a lot, and it puts me in an uneasy spot
| where I don't know whether it's something with the PR or the
| way I communicated it or what.
|
| After having this experience one too many times, I've started
| opening issues and if I'm really serious about getting it into
| the project, disucssing with people in the related
| IRC/forum/whatever before starting to work on it. This helps
| notify people that hey, I'm doing a bit of effort and I'd love
| to at least get a "sorry I'm too busy/uninterested in this
| feature to look at your PR".
| yxhuvud wrote:
| Or even ignoring it for a year and then automatically close
| it for inactivity. Feedback, even negative feedback, I better
| than that.
| strken wrote:
| It doesn't matter if they ignore the PR. You've got a working
| fork. Merging your changes back into the upstream is a happy
| side effect.
| vegetablepotpie wrote:
| We'll, maybe. It depends on what kind of project it is.
| What happens when your fork introduces hard to reproduce
| bugs? What happens when there are security updates to the
| project that cause merge conflicts with your fork? What
| happens when the project makes architectural changes that
| require reimplementing your feature? What happens when you
| leave the company, and your former coworkers have the
| responsibility to maintain your fork?
| dessant wrote:
| Your quick PR becomes the maintainer's burden, and rejecting a
| pull request can also come with a substantial time cost. It's
| best to conform to the contribution process described by the
| maintainer to avoid wasting their time as much as possible.
| Aeolun wrote:
| > 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 else).
| dessant wrote:
| > 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 request, you
| should follow their contribution guidelines.
| Aeolun wrote:
| > Sending unsolicited pull requests to people that
| clearly told you to open an issue first is disrespectful.
|
| You do you. I do not think it is, and so far nobody has
| made an issue out of it.
|
| > It appears you just assume that because pull requests
| cannot be disabled on GitHub.
|
| It's more that people that make a public repo on Github
| and expect no pull requests on even mildly popular
| software are living in fairyland. Don't make a repo on
| Github when you know PR's can't be disabled. Or I dunno,
| install a bot that automatically rejects everything.
| dessant wrote:
| It's one thing to stumble upon a repository that does not
| have contribution guidelines and submit a pull request,
| that is obviously fine. But you're advocating against
| respecting the wishes of strangers, and disregard their
| request to coordinate with them before submitting your
| work.
|
| You have the option to walk away and not contribute if
| you don't like the rules for interaction that have been
| set by the people that manage the project. Or just follow
| the rules. Those are your only two sane options, unless
| you become a maintainer yourself at that project, and
| modify the contribution guidelines.
|
| To be very clear, you have to understand what NO means in
| this context, and realize that "I don't like bureaucracy"
| is not a valid reason to push forward on your own terms.
| [deleted]
| samatman wrote:
| 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.
| dessant wrote:
| 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...
| jrochkind1 wrote:
| I assume the PR describes the thing you are fixing anyway?
| (It better if you want it to have a chance of getting
| reviewed/merged!)
|
| I don't see why you couldn't just file an issue with the
| copy-paste of that description, and then immediately file
| the PR too with a proposed solution.
|
| I don't understand this issue/dispute. I don't understand
| the problem with filing an Issue to correspond to the PR,
| it doesn't seem to be any significant extra work or change
| to the desired workflow of the person who "just" wants to
| file a PR.
|
| Am I misunderstanding the issue?
| Aeolun wrote:
| > I don't understand the problem with filing an Issue to
| correspond to the PR
|
| I positively detest pointless bureaucracy?
|
| I can live with it when someone is paying me 200k/year
| for it. Not when I'm trying to give my work away for
| free.
|
| I'm honestly a bit surprised about how strongly I feel
| about this.
| jrochkind1 wrote:
| OK, I wasn't missing anything.
|
| As a favor for the the person giving you free labor who
| finds it easier to organize things that way, even if to
| you it seems like pointless beurocracy, we all have
| different organizational styles and they find it useful
| to make sure bugs/scopes/requirements are in Issues with
| the solutions in Projects?
|
| Yeah, I think you're being unreasonably weird, and on
| further reflection I don't think this is even a
| generalizable enough problem to be worth talking about,
| it's just some weird idiosyncracy of yours to refuse on
| principle to do trivial organizational work that the
| maintainers of the project you'd like to contribute to
| have said makes it easier for them to deal with your
| contribution. ( _trivial_ work; you aren 't even saying
| it would be a burden in terms of time/energy, just that
| it's a weird principle you have not to do anything you
| don't want to do even if it makes things easier on other
| people).
|
| It's kind of just a true-ism of any kind of work we do
| collaboratively (and submitting a patch to a project that
| others maintain is such) that you need to do sometimes do
| things out of consideration for what works for the other
| people.
|
| I guess I am curious why you are insisting on sending a
| PR that you know doesn't follow the process the
| maintainers have asked for -- instead of just not
| submitting the PR at all though? If you're worried about
| your time being wasted, wouldn't it be best not to submit
| the PR at all? Make your own fork that meets your
| purposes, don't interact with them at all. Now you don't
| risk wasting the 30 seconds it took to make the PR, when
| they just close it for not following their procedure
| since you didn't want to waste the 30 more seconds it
| might take to do so.
| strken wrote:
| The best thing is to fork it, use your fork, get as far as
| you can through their process, but give up quickly if it
| looks too hard. That way you don't have to deal with overly
| complicated processes and you still get to use working
| software.
| rglullis wrote:
| Yes, and when for the times that you can't fix yourself should
| work as a reminder that you should be paying to support those
| who can.
| philliphaydon wrote:
| 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.
| nijave wrote:
| 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.
| jmull wrote:
| My general advice on this is to never rely on other people
| reading your mind. It's a path to frustration for you and the
| other people.
|
| In this article I see a lot of phrases where OP is hoping other
| people share the same perspective. Like, "Hopefully we agree
| that...", "I want to argue here...", "Users... shouldn't
| expect..."
|
| It's just not going to happen like that automatically, though.
|
| I suggest that if, as an open source author, you're seeing seeing
| potential for broad usage of your project, spend some time to
| think about what you're willing (and able) to give, and make an
| explicit statement to that effect (and put it somewhere that
| potential new users will see it).
|
| I suggest that if you're considering using an open source project
| in something, spend a few minutes to think about what you will do
| if you get no more support than what is explicitly promised
| and/or paid for (which means no support in most cases). If that's
| not acceptable for your project, then don't use it.
|
| (Oh, and sadly, I think this the purpose of this article is a bit
| hopeless. I think there are thoughtful people that will read this
| and take it to heart, but those people are probably only causing
| a tiny fraction of the unpleasantness that open source
| maintainers experience.)
| jacobtomlinson wrote:
| Author of the article here. Thanks for this comments, really
| great points and sadly I agree with everything you've said.
|
| Although I would say many projects snowball into something
| bigger than the creator imagined so upfront planning about how
| much time you can put into something is hard.
|
| I wrote this post with the intention of directly sharing it
| with folks in issues when situations flare up from time to time
| in the projects I work on. I never imaged it getting shared on
| HN.
| [deleted]
| gumby wrote:
| > ...I was one of those open source users who had service
| expectations despite never paying for anything.
|
| Brian Fox had a default reply for these messages back in the
| early 90s: "Please return bash for a full refund".
| welder wrote:
| 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 comments are welcome.
|
| [1] https://github.com/alanhamlett/pip-update-requirements
| II2II wrote:
| The author followed up by stating:
|
| > As time went on the wording of the +1s got stronger, people
| demanded that it be implemented and expected it to be scheduled
| into future milestones.
|
| I don't think they thought the +1 was an issue with respect to
| prioritization. Rather, it is an issue because it is a form of
| confirmation for users to behave in entitled ways.
| no_circuit wrote:
| I'm not so sure +1's or emojis are useful, except for maybe a
| few cases like you have a very large audience and they all send
| a thumbs-down emoji to protest a bad product or design decision
| -- recent c#/dotnet for example. Or the reminder ping from an
| affected user who is still interested in and using your
| project.
|
| The problem I believe is that a +1 or another reaction to an
| issue is simply a sample from all developers that viewed the
| project that bothered to leave a note. Chances are people are
| not using an open source project if they see a reasonably filed
| issue a long time ago that either was not addressed in any
| fashion whether it be a principled statement on why it can't be
| addressed yet, or that the project isn't interested in working
| on it. That obviously only works for small projects without a
| product manager.
|
| The issue persists on the large projects as well. The issue
| reactions set is just a sample of the all developers set that
| used or looked at the project. The only way to really know what
| is going on is telemetry and crash reports.
|
| Larger companies with thousands of crash reports, bug reports,
| and features requests can cluster them and figure out what to
| work on, along with a touch of good taste. Good taste is
| unfortunately important too.
|
| Unfortunately for telemetry a lot of people think it is a
| privacy issue... which it can be if the developer implements it
| poorly. And looks like GitHub only exposes traffic overall to
| your site [1] so you never know the population size is for
| people that are possibly affected by that issue -- so the
| relative +1 count is not reflective of reality. You might have
| a fighting chance if you use self-hosted GitLab or something
| with which you can grab granular traffic stats.
|
| [1] https://docs.github.com/en/repositories/viewing-activity-
| and...
| plorkyeran wrote:
| It's often not immediately obvious if a request is something
| a lot of people want but only one person took the time to
| write up, or if it's a very niche thing that only that person
| cares about. People who +1 an issue are not a great data set,
| but it's a lot better than nothing and it's basically zero
| effort to check. If I'm looking for something to work on and
| there's two issues that look like they'll take similar
| amounts of time, both seem like good ideas to implement, and
| I'm not sure which is more valuable, the number of +1s is a
| pretty decent tiebreaker.
| matkoniecz wrote:
| For me (participating in a small open source project) upvotes
| are useful - it is a confirmation that anyone else cares
| about that idea and that someone read what is being proposed
| and at least is not protesting.
|
| Multiple times I have no preference between two issues and
| worked on one with more reactions.
| jlkuester7 wrote:
| This exactly! I am a solo maintainer on a very small Android
| app. I find it very useful when users vote for issues with the
| :thumbsup: emoji. Otherwise I have no real way of knowing which
| new features are popular with the community.
|
| Comments that add nothing to the issue but just create noise in
| the notification feed are annoying.
| Aeolun wrote:
| > 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.
| freedomben wrote:
| 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
| pastage wrote:
| I guess the "be excellent to each other" note at the end of the
| post is basically be polite. Often there is a reason why simple
| request take time. It can be hard to describe why.
| pabs3 wrote:
| Prioritisation often becomes harder the closer you become to
| being an open source maintainer, since you're often more
| focused on software maintenance/internals than on using the
| software in real-life contexts. I feel like creating systems
| for open prioritisation is going to be an important "next step"
| in open source project management. Igalia did an experiment in
| open prioritisation in web browser development, but they tied
| it to funding, which helps with project viability but
| introduces a prioritisation bias towards people who have money
| to donate.
|
| https://www.igalia.com/open-prioritization/
| 2Gkashmiri wrote:
| >Prioritisation often becomes harder the closer you become to
| being an open source maintainer, since you're often more
| focused on software maintenance/internals than on using the
| software in real-life contexts
|
| i contribute to a FOSS project. I am not a dev nor can i hire
| someone to do dev work so i assist the actual dev team into
| giving them real life use cases which brings out a lot of
| bugs which get fixed along the way.
|
| That way, instead of trying to achieve some sort of tangent
| "idea" of what a software is going to be and it becomes
| something the users can actually use and relate to.
|
| the software in question, when people are going to use it and
| will face "normal workflow bugs" for example, we can forget
| about adding new features. right? maybe they can go side by
| side but unless you are working on the bleeding edge software
| and do not expect anyone to use in production it can work but
| not otherwise.
|
| Also, by pointing out edge cases, the present software itself
| would become what would be called "battle tested" because
| most if not all the issues are fixed.
|
| that said, if a project had a good budget, a good roadmap, a
| thriving developer community and users who are using it,
| reporting bugs and people volunteering to fix stuff, we can
| think about experimenting but otherwise not
| prox wrote:
| Doesn't monetization also indirectly help the other issues?
| pabs3 wrote:
| Usually the maintainer's work is more money than they would
| ever get from monetization. Also the maintainer is one
| person, they can only do so much, eventually more people
| need to step up and do code/etc contributions.
| prox wrote:
| 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]
| tgsovlerkhgsel wrote:
| One pattern I've noticed that leads to low quality bug reports is
| that high quality bug reports take time, and bug reports, even if
| they're high quality, are often ignored if they're not an
| absolutely critical issue.
|
| After spending an hour of time writing the perfect bug report a
| couple of times, and each time receiving no reward (= fix), often
| not even seeing a sign that anyone _looked_ at the report, this
| gets incredibly frustrating, and creates a temptation to not put
| in the effort anymore.
|
| Which results in low quality bug reports, which exacerbates the
| issue (makes work harder for the maintainers, makes bugs less
| likely to get looked at/fixed, makes it more likely that the user
| encounters more such frustration).
|
| I see the pattern, but I don't have a solution. One thing I've
| started to do is filing an initial low-quality bug report and
| offering to follow up (and actually doing it) once anyone shows
| any amount of interest, but that still leaves a crappy and non-
| actionable bug report.
| Jiro wrote:
| >After spending an hour of time writing the perfect bug report
| a couple of times, and each time receiving no reward (= fix),
|
| Something that may be happening in that case is that the demand
| for making the bug report high quality is not sincere, but is
| just meant to kill it by filibuster. The developers won't fix
| the bug regardless, but by making it easy to say "you didn't
| follow all these steps in submitting the bug", they can put the
| blame on the user rather than just admitting they won't fix it.
| encryptluks2 wrote:
| I can partially agree but we live in a day and age where asking
| someone their name may be considered offensive. I think there is
| a lot more value in teaching people self-worth and to not be so
| easily offended by people asking questions and then they run sway
| and hide and say that you hurt their feelings by asking them.
|
| A simple disclaimer that says they don't have any obligation, or
| heck most open source licenses indicate that. Who cares it people
| +1 something. If open source developers want to focus on
| perfecting their code to be a haiku there is nothing wrong with
| that.
|
| However, if they don't get around to implementing important
| features or merging PRs then they shouldn't be surprised nor
| offended when people abandon their projects either.
|
| Sometimes people can be demanding and rude, but the key to get
| anything accomplished is learning how to interact and deal with
| people. If you can't handle people asking questions or +1 or
| +2'ing your public GitHub issues then you're probably not cut out
| for software development even as someone who is an unpaid open
| source contributor.
| nicbou wrote:
| This goes both ways. It's also fine to ignore your open source
| users, or refuse their requests. What will they do, fire you?
| Stop paying you? If they don't like it, it's on them.
| mooreds wrote:
| > However I now see that my use of the tool provided no value to
| the company, and I was not a paying customer of any of their
| services, so why should they provide me with free support.
|
| That is not true. If the use of the tool provides "no value" to
| the company, then why on earth are they making the tool
| available. Yes, there is no money exchanging hands, but there is
| definitely some value.
|
| Here's some value a company gets when someone uses a tool/piece
| of software without paying money (source: my company has a full
| feature free tool that competes with our paid offering, and often
| wins).
|
| * awareness of the solution in the marketplace
|
| * developer attention (way way easier to get a developer to try a
| free tool vs one that costs $0.01)
|
| * bug finding (often in environments that would be hard to stand
| up for the company)
|
| * user testing (related to bug finding, but often users will give
| feedback about feature direction)
|
| * market share (if they are picking your free tool, they aren't
| paying for a competitor)
|
| At my current job, we often leverage this (our GitHub issues repo
| and forum are main sources of our roadmap).
|
| That's not to say that you should expect the same kind of service
| when you are a free user as when you are paying money. But
| attention is valuable too, esp of developers.
|
| And it's not like if you pay money, a product company jumps to
| build whatever you ask for. Unless you pay a large amount
| compared to their current revenue and even then, if what you want
| conflicts with their long term vision, wise leaders won't.
| gtirloni wrote:
| We're decades into the open source era and people still need to
| be reminded of this. Incredible.
| mitchdoogle wrote:
| 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.
| mooreds wrote:
| I took the comment to mean "there's more to value than pure
| $$$, and that open source has been a prime example of this
| truth".
| saila wrote:
| 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.
| sigg3 wrote:
| Free software isn't not commercial software. The GPL
| _encourages you_ to get paid for software. Free software
| is not good because of charitable reasons, or any
| contingent historical artefact. Counterfactually you can
| imagine a world without patents and software licenses,
| but the GPL would still be needed as a philosophical
| concept.
|
| Free software (in FSF / libre sense) is traditional
| Kantian philosophy, viz. everyone takes part of the whole
| by attending to their own needs, the Kingdom of Ends.
| What's not Good -- and in software what the GPL intends
| to prevent -- is any action that superficially might
| benefit the actor but undermines the whole (and ipso
| facto the actor) in the long run.
|
| Making money with proprietary software is a Wrong because
| proprietary software undermines the activity of writing
| software at all.
|
| This is my understanding of it anyway YMMV.
| bbarnett wrote:
| Quite.
|
| I find this doubly troubling, when someone using Linux for
| a desktop, learned how to code via free websites, with free
| software, builds a product using OSS libraries, etc, etc,
| and then wants to be compensated handsomely for _their_
| product.
|
| Which is, of course, a tiny tiny little thing, compared to
| everything it depends upon.
|
| OK. Fine. Did you compensate every part of the chain you
| used?
|
| So weird.
|
| AWS seems paricularly bad here. So does anyone who doesn't
| contribute back.
|
| Ah well.
| [deleted]
| laurent123456 wrote:
| Regarding adding +1 to issues - rather than doing this, up-vote
| the issue on GitHub (thumb up). This can be useful to maintainers
| because they can sort by thumb up and see the most popular ones.
|
| Adding a +1 comment really does nothing - it's just one more
| useless notifications for everyone, and it won't allow filtering
| or sorting issues. People might even unwatch the issue because of
| this and thus missing useful comments.
| welder wrote:
| Edit: Nevermind, we're saying the same thing since you're
| talking about commenting with a +1 not reactions.
|
| > Adding a +1 comment really does nothing - it's just one more
| useless notifications for everyone
|
| I don't think reactions trigger notification emails.
| praptak wrote:
| It's bad either way. "Me too" should not be mixed with "I got
| a reliable reproduction, here's how".
|
| Edit: I mean people probably want a notification on the
| second one but not the first.
| dewey wrote:
| They are talking about a literal comment saying something
| like "+1", which is very common. Not a thumbs up reaction.
| welder wrote:
| Thanks, I must have missed that.
| ximm wrote:
| The thumbs up was added only a few years ago. +1 is quite
| common in older treads.
| dewey wrote:
| > 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 the issue.
|
| I was always under the impression that just adding a reaction
| wouldn't actually give the issue a bump. Maybe it would be good
| if Github actually guides people towards it by either saying
| something like "You added a comment reflecting a +1, do you
| want to add a vote for the issue instead".
| icambron wrote:
| 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.
| dewey wrote:
| 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".
| laurent123456 wrote:
| > 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?
|
| Yes it needs to be added to the top post. It's not really an
| official thing I guess, but for popular projects these
| reactions add up, and it helps getting a clearer picture of
| what matters to users.
| davidmurdoch wrote:
| It is "official" in the sense that GitHub lets you sort by
| these reactions.
| droidist2 wrote:
| Then again, adding a comment may prevent a bot from auto-
| closing the issue.
| MereInterest wrote:
| I've never really understood the point of these bots. I could
| understand if an issue had a test case attached to it, and
| the bot was auto-closing the issue if/when the test passes.
| That way, if it is resolved when fixing some other bug, or
| when refactoring, the issue is closed. But closing an issue
| due to inactivity gives the false impression that the issue
| has been resolved.
| jrochkind1 wrote:
| I think they are basically an attempt at form of
| "issues/tracker bankruptcy" -- we have too many open things
| here, leaving them all open like we're going to get to them
| all eventually is a fantasy, and is overwhelming and makes
| it harder to find the ones we might actually address, so
| trying to algorithmically close the ones least likely to be
| actionable is just trying to make the situation more
| manageable.
|
| I think it's a desperate measure -- if any maintainers are
| seeing it as reasonable management technique rather than
| desparate measure, I think they're making a mistake. It has
| a lot of downsides, some of which you outline, I agree with
| you. It also generally raises user frustration, leading to
| even more adversorial relationship between users and
| maintainers, which is what the OP is about and I think part
| of what's going on in this "issue bankruptcy" situations
| too.
|
| Notably, Rails just turned off their auto-closer for Pull
| Requests (not sure about Issues), with this commit message
| from a maintainer:
|
| > While the idea of cleaning up the the PRs list by nudging
| reviewers with the stale message and closing PRs that
| didn't got a review in time cloud work for the maintainers,
| in practice it discourages contributors to submit
| contributions.
|
| > Keeping PRs open and not providing feedback also doesn't
| help with contributors motivation, so while I'm disabling
| this feature of the bot we still need to come up with a
| process that will help us to keep the number of PRs in
| check, but celebrate the work contributors already did
| instead of ignoring it, or dismissing in the form of a
| "stale" alerts, and automatically closing PRs.
|
| https://github.com/rails/rails/commit/acf48169943011834c4c8
| 8...
| jrochkind1 wrote:
| Reading over the Rails committer message there... So
| Rails, decided that they did not want to discourage code
| PR contributors (despite getting some poor quality ones,
| I'm sure).
|
| But other projects may actually _want_ to discourage PR
| 's, or especially Issues, so consider this a plus not a
| minus. Of course, you can just turn off Issues/PR's, or
| only allow maintainers to make them, if you really don't
| want them. But sometimes I'm guessing someone really
| don't want them but doesn't really want to say so...
| johannes1234321 wrote:
| It depends a bit in the project and maintainers motivation.
|
| However: Many projects swim in a sea of open tickets. Too
| many for the maintainers to keep an overview. By auto
| closing you make it clear to observers that currently this
| thing likely won't change and by forcing to reopen the
| maintainers can get users to tell them whether the issue
| still persists without having to try themselves. Generally
| there is little worth in keeping many years old tickets
| open, hiding recent issues while probably not being an
| issue anymore for whatever reason.
| yorwba wrote:
| How do old tickets hide recent issues? The default is to
| show the newest ones first, isn't it?
| jlkuester7 wrote:
| Same, I find these bots really annoying. I guess they might
| be necessary/useful for popular projects where a small team
| of maintainers is trying to stay on top of a massive pile
| of incoming issues. But for the most part they seem
| misguided. (Especially the ones with a really short (like
| 30 days) activity window.) If an issue still exists in the
| project, why should it be closed? That will just require
| the next person who notices the issue to open a new one...
| Also, no activity on an issue can just mean that folks are
| waiting patiently for someone to get around to implementing
| it (or, more commonly, for some project dependency to
| release the patch that is necessary for fixing the issue
| ..).
| [deleted]
| matkoniecz wrote:
| Project with autoclose bots is not worth wasting any time by
| contributing to it, even by making an issue.
| pcthrowaway wrote:
| Perhaps I misunderstood the author, I assumed '+1' in this
| context meant the thumbs-up reaction. I'm certainly feeling
| much more charitable towards the OP if they literally meant
| people commenting "+1" (which is unfortunately a thing), but I
| think in a lot of contexts "+1", "thumbs-up", "like" are
| interchangable.
| jacobtomlinson wrote:
| OP here. Thumbs up is great, commenting with the string "+1"
| is not great, commenting with "Why this this not done yet,
| this is very important to me. I might switch to another
| project if you don't implement this." is terrible.
| kayodelycaon wrote:
| It's literally people commenting. There's a subset of users
| that haven't noticed or haven't understood the reaction
| buttons.
| samatman wrote:
| I agree with you, but old habits die hard. Reacts are a late
| addition to the GitHub interface, and in ye olde days adding a
| +1 comment was what you had to work with.
|
| Just something to keep in mind in encouraging contributors to
| use the upvote and reacts.
| eCa wrote:
| > As time went on the wording of the +1s got stronger
|
| I think a +1 (as a thumbs up reaction, or similar) can't be a bad
| thing. Comments that turn more passive/agressive (or just
| agressive) most certainly can. I don't think the later should be
| mixed up with the former.
| danieldk wrote:
| _I think a +1 (as a thumbs up reaction, or similar)_
|
| If you refer to +1 comments (which the second sentence seems to
| imply), these are a bad thing, since it sends a notification to
| everyone who is subscribed to an issue. If you are maintaining
| a popular open source project, useful comments (reproducers,
| potential solutions) get buried between all useless +1
| comments.
| [deleted]
| bsder wrote:
| I kinda blame Github for all this.
|
| In the past, there was just a bit of friction before filing a bug
| or dropping a comment on a project.
|
| You had to sign up for bugzilla. You had to sign up for the
| mailing list. Something. Anything.
|
| It was just enough friction that you had to _want_ to post that
| comment or file that bug. You weren 't going to waste your time
| just to be a shit.
|
| With everything on Github, it's simply too easy to quickly slap a
| thoughtless comment on a project (guilty as charged--sadly).
|
| I know that if I were releasing a project today, I would make
| sure to use anything other than Github.
| throwaway0129u wrote:
| > With everything on Github, it's simply too easy to quickly
| slap a thoughtless comment on a project
|
| THIS! The UI really encourages drive-by comments from anybody.
|
| Like social networks, it's designed to maximize views and
| clicks instead of building communities.
| danieldk wrote:
| I see what you are saying. But on the other hand, I definitely
| neglected to report bugs in the past because I had to subscribe
| to a mailing list or sign up for another yet another bugzilla
| account (combined with bugzilla often being terribly slow).
|
| I think GitHub has provided a net improvement because many
| smaller project get bug reports now (whereas they usually
| didn't in pre-GitHub times), while they usually do not have to
| deal with frivolous comments. I have many smaller projects that
| do get issues filed, but never useless comments.
| dom96 wrote:
| This is actually a fair point and shouldn't be getting
| downvotes. Github has decreased the barrier to entry and sadly
| that has its disadvantages.
| Kwpolska wrote:
| If you want to do some harm, you'll jump through any hoops,
| including signing up for mailing lists. But if you want to make
| a meaningful contribution, and you're faced with too many
| absurd requirements, you might just give up.
| witcher wrote:
| Amazing write up! Something I would add as open source
| maintainer:
|
| * Feedback is needed. After years I built up a filter to annoying
| users, and I would simply ignore their feedback, but +1 and
| mentioning the feature would be useful is invaluable (and why you
| cannot use workarounds). Please do that in a nice, productive way
| (:
|
| * It might be that the feature you and others are asking for was
| in paid version of the project, thus maintainers actively ignored
| it. Not the healthiest thing to do, but this happens, business
| matters, especially if governance is poor (single vendor behind
| the project).
|
| * I think it would be useful to mention that if it's just a work
| needed and not other blocker, anyone would be welcome to create
| PR for the needed feature or at least moving it forward 10%.
| Sometimes faster that motivating your rights in issues (:
| davedx wrote:
| Counterpoint: you have a successful open source project and you
| even "branded and marketed" it (like Grafana). You obviously want
| it to be successful? Then _listen to your users and respond to
| their questions_.
|
| Entitlement is a two way street.
| jeroenhd wrote:
| The company Grafana and the open source project Grafana have
| different customers with different requirements and requests.
|
| If BigCorp wants purple widgets for their next massive
| migration towards Grafana and a bunch of free users are asking
| for the Foobars to be yellow then I don't see why it would make
| any sense for Grafana to take widget purplelization manpower
| away from their paying customer to yellowify foobars.
|
| You've placed your upvote, your request has been noted and
| noticed. Next time there's dev capacity free there will be an
| evaluation of the most pressing open source issues and your
| concerns will probably be taken into account.
|
| If you really need or want a feature, either build it yourself
| and send a PR or pay someone (probably the Grafana devs) to
| build it for you. Don't expect Grafana to solve your problems
| for you if you're not an important, paying customer, because
| they're a business; the focus should be on what keeps the
| lights on, not on which issue attracts the most vocal crowd on
| Github.
|
| Maybe Grafana doesn't want what you want. Some features should
| not be in some products or implemented in some ways. Maybe
| something is of such little influence that you can be
| reasonably sure that only the free users will ever use a
| feature (i.e. features that compete with your paid offering).
|
| I agree that entitlement is a two way street, but not in the
| way you probably think about it. If your users act entitled to
| support and attention, you're entitled to some kind of
| compensation.
| nijave wrote:
| Not sure if Grafana operates this way but some companies make
| it doubly confusing by running all their feature requests
| through public issue trackers. It's unclear if there are
| users replying to issues that already pay but don't pay
| enough to get exclusive dev team access (which can still be a
| pretty hefty fee--you could pay $10k/mon but still pale in
| comparison to the customer with a $1m/year contract)
|
| Azure, AWS, GCP, and Okta all have products I've used with
| shared issue trackers (for at least some of their software)
| projektfu wrote:
| This jumped out at me. Software has always had grandiose
| marketing and I figure that a successful large-business image
| usually works better than mom & pop imagery. But it probably
| encourages people to see the person or team behind an OSS
| product as at least a cog in a big machine, if not a successful
| entrepreneur.
|
| I'm reminded of the scene in Cinderella Man where Jim's wife
| Mae goes to tell off Joe Gould calling him rich and entitled,
| basically, and they invite her into the big apartment and
| they've sold all the furniture except a table and two chairs.
| Barrin92 wrote:
| that's not necessarily a recipe for success. As the (admittedly
| over-quoted) Ford quip goes."if I had asked them what they
| wanted, they'd have said faster horses".
|
| Software development requires a solid amount of confidence to
| ,at times, be willing to disappoint users to keep a project on
| track. If you listen to what is likely an incredibly scattered
| and unfocused sea of requests you're going to lose control
| quickly. Torvalds and Linux are one positive example of someone
| who has maintained control often against demands.
| throwaway0129u wrote:
| True.
|
| If someone clearly describes their project as an experiment or
| a hobby project then no responsibility should be attached to
| it.
|
| But if they advertise it as something production-ready or
| secure they are capturing user's trust, attention and time.
|
| Some company-driven projects even use open source as a foot in
| the door to get user's data or corner a market and charge money
| later on.
|
| As a developer your time is valuable and users should not be
| demand it.
|
| As a user your trust, attention and time are valuable and not
| every random project on github should get it.
| tbwriting wrote:
| Wrote about this several months ago, and specifically the vastly
| larger scale on which corporations do it:
| https://tylerberbert.substack.com/p/cooperation
| andresp wrote:
| For better or worse, open source software is competing with paid
| software, so expectations for basic support and maintenance need
| to exist. If there is not enough capacity for this, the
| maintainers should make it clear upfront in very visible ways so
| people can use that information when deciding what to use.
| fellellor wrote:
| Reading all this, I realise it's very hard not to piss people off
| on the Internet. Mostly avoidable by not coming off as entitled,
| and being patient.
|
| ... to be honest, I never thought the +1 emoji would make someone
| mad.
| rurban wrote:
| Looks more like the new US youngsters becoming more like
| brainwashed Chinese or Russian apostates, who need to make public
| apologies before being allowed into society again. mea culpa, mea
| maxima culpa. What's wrong with you? Seriously.
|
| There's nothing wrong in these tickets to apologize for. Issues
| are for public discussions of issues. If maintainers cannot deal
| with public issues, they cannot be maintainers. Problems don't
| come with silverspoons, And this case there were not even
| problems at all.
| jlkuester7 wrote:
| People mature and the way they interact with others can change.
| I see this post not as a public self-shaming, but as the output
| of a personal retrospective that the author felt would be
| helpful to others to learn from instead of having to repeat the
| same mistakes...
|
| IMHO, content like this is very useful to my development as a
| person and a member of a community. (Not as a rule-set that
| must be blindly adhered to, but as an opportunity for self-
| reflection on my actions and how they impact others...)
| UncleEntity wrote:
| So... guessing you have never contributed to an open source
| project in any meaningful fashion?
|
| I somewhat agree with you though, try to work on a project that
| has artists as the primary users sometime if you _really_ want
| to see entitlement. Not that I have anything against artists in
| general but they usually have no clue how much work goes into
| their "simple" feature request from a demo video they saw from
| siggraph and now they absolutely have to have or they will quit
| using the free software -- after completely spamming the
| mailing list and bug tracker to get other users behind this
| must have feature to show the devs how important it is to
| implement.
|
| Makes me kind of miss working on that program.
|
| --edit--
|
| And there were the occasional _rewrite it in Java_ people, now
| they were really fun. There was one who actually machine
| translated the entire C codebase into Java and wanted the whole
| project to fork on that. Loved the Java ones.
| deepsun wrote:
| > While some open source projects are created by large companies
| in a structured and planned way I think it is fair to say that
| most grow organically.
|
| > Coming back to the Grafana example, I was one of those open
| source users
|
| Well, Grafana is definitely a large company. They recently
| devoured Prometheus community, that was really open source
| before.
| ocdtrekkie wrote:
| One thing I've done from time to time is just say "hey, I would
| like this a lot, I'd put a $100 bounty on it". Probably wouldn't
| work in the corporate case described here, and certainly is below
| the "actually paying for a developer's time" level.
|
| But I've thrown a bonus in there for doing it. Maybe if it's
| already something they wanted to do, it moves the needle into
| "sure, let me give it a shot".
| YmiYugy wrote:
| Rude and entitled behavior is of course unacceptable. That said I
| think the project developers and maintainers often share a large
| portion of the blame. Most projects are very keen on telling you
| about their amazing new features and the awesome stuff you can
| build with it. What they don't do is properly document
| limitations of their software or honest comparisons with
| competing solutions. Additionally many developers overhype the
| status of their project. They'll call it production ready,
| mature, claim it has a vibrant community and ecosystem and so on,
| when these things really bend the truth. That builds expectations
| and running into critical, well known bugs that don't get fixed
| can be extremely frustrating.
| 13415 wrote:
| My solution to this problem is to avoid libraries and projects
| that have one of those darkmode Web 3.0 scrolling pages as home
| that tell you in countless ways with lots of graphics why their
| project is so great. They usually aren't, and they are nearly
| always unfinished. In contrast, I've never had any problems
| with libraries whose home page is text only + links generated
| from Emacs org mode.
|
| Good programmers don't waste their time making fancy web pages.
| badrabbit wrote:
| Don't be entitled but at the same time nothing wrong with
| respectfully asking for support. User support is the whole point
| of maintainance. Replying to issues to add "weight" allows
| maintainers to prioritize fixes.
| kevincox wrote:
| I think asking for support is fine unless it is against the
| project guidelines.
|
| I think reporting bugs is almost always great.
|
| But I think that few if any projects and maintainers appreciate
| adding just "weight" in a comment. These comments just add load
| to whatever channel the maintainer uses to follow these things.
| If the comment has more valuable, like explaining a new use
| case that is affected by the issue then I think it has value.
| Otherwise just use the reactions feature.
| badrabbit wrote:
| Mostly agree, but personally I comment when it is a bug
| impacting production stuff(outage for me). I don't know how
| else to get support, if they have a paid support option my
| company would be all over it for most of these projects. But
| therein lies the usability issue of OSS. With commercial
| software I can open a ticket and at least get some response
| that will help me make plans on how to deal with the issue.
|
| There really needs to be some org that simply lets devs get
| paid for supporting paying customers and let customers
| procure such support.
|
| For personal stuff I don't care but after fighting many
| battles to sell OSS when I have some issue what other
| recourse do I have than to politely explain my situation and
| hope I get therir attention. I literally beg for help! I am
| sorry if that annoys devs, but it is either that or I give up
| on OSS and be permanently pessimistic about anything related
| to it.
| layer8 wrote:
| I see this a bit more nuanced. On the one hand I believe it's
| important that users communicate what they'd like the software to
| be, and also when they are frustrated about a lack of progress,
| but on the other hand they shouldn't act like entitled assholes
| about it and/or constantly complain about the same thing over and
| over again. It's possible to express dissatisfaction with the
| software while still being respectful towards the maintainers.
| And the number of "me too"s (+1) can be useful information.
|
| With regard to time and attention, that's more a matter of
| tooling and push vs. pull. As a maintainer, I'm responsible to
| not let my time and attention be strained too much, just as with
| any other communication. For example, by auto-filtering issue
| tracker notifications into a dedicated folder and only looking
| into it at scheduled, time-boxed intervals.
| gigatexal wrote:
| If you don't pay for something and that something is written by a
| volunteer and shared for free then sit down and shut up and wait
| for that volunteer to maybe get to your feature request. One can
| always propose a PR implementing that feature. Or wait.
|
| Even more egregious is if you're a company making money on this
| free software and yelling about a missing feature and not willing
| to sponsor its development then you're even further behind in the
| line.
| lmeyerov wrote:
| As a maintainer of a graph OSS project with an optional
| commercial tier, we are 100% fine with his original approach.
|
| A clearly written issue or a +1 vote (not comment, which causes
| an alert) is definitely appreciated. We get to learn usage
| patterns to optimize, bugs to fix, etc, before they hit users in
| our paid tiers. Sometimes feedback isn't well thought out, so we
| added templates to steer users, and that worked pretty well.
| Various tricks like that have helped over time.
|
| Likewise, when there is a commercial tier or outside funding, as
| in his case of Grafana, _much_ less expectation of code giveback.
| Typically the maintainers have blown the path to open governance,
| and through that, significant OSS community It 's freemium, and
| the interactions are more about issues vs PRs. Yes it's better
| when a true OSS community, not just license, but that's just not
| how most big ones work nowadays. So a helpful ticket is fine.
| jmull wrote:
| > we added templates to steer users
|
| I think this is great.
|
| Often, by the time someone gets to the point of figuring out
| how to comment at all, they have a real _need_ and are more
| than willing to spend some time... but they have no idea what
| would help and you end up with an annoying demand or "+1"
| comment. A template directs the energy on a useful path (and
| implicitly balances/settles things a little bit... the user has
| to stop, think, and contribute a little bit back and a
| maintainer hears it in response)
| bambax wrote:
| > _If you were to develop a closed source iOS app and charge for
| it in the Apple App Store your user base will have certain
| expectations._
|
| What's weird is that paying users have lower expectations and are
| much nicer than those who don't pay. Why do free users feel
| entitled? It's a bit of a mystery, yet can be observed often.
| politelemon wrote:
| This is not my observation at all. I encounter the exact
| opposite with paying users, and much prefer interactions with
| free users who are very understanding and empathetic.
| stevewatson301 wrote:
| Then again, it depends on the prices that you pay.
|
| If you have customers paying somewhat decent prices for your
| service/product, they interact in an empathetic manner.
| However, if you price your services too low, you'll get a
| bunch of entitled people who want things to be done "right
| now" and throw a tantrum if their demands aren't met
| immediately.
| tommoor wrote:
| free - medium support
|
| $1 - high support
|
| $100,000 - low support (after the initial deal)
|
| Choose which you want to build :)
| djbebs wrote:
| Paying users are often not the ones using and making reports of
| the software.
|
| In companies you're told "use this software that we have a
| license for" and that's that. You don't get a choice to use it
| or not, and so you gotta roll with it.
|
| If the device were the ones making the decision to use or not,
| you'd see a different attitude
| lifeisstillgood wrote:
| Just a thought (vaguely connected here) but voting on features to
| be implemented is ... pretty much same as voting IRL on policies
| not parties.
|
| I have often wondered what would be the thing to trigger
| companies to stop being totalitarian dictatorships and become
| democratic to their (employees / stakeholders) - is it crazy to
| say voting on features to build would be the one?
| xiaq wrote:
| The word you are looking for is consumers' co-operative
| (https://en.wikipedia.org/wiki/Consumers%27_co-operative).
| lifeisstillgood wrote:
| Oh I am not so sure.
|
| Socialism is basically about public _ownership_.
|
| But the history of capitalism seems to show you don't need to
| own something to control it.
|
| So this is about control. such as regulation. not necessarily
| ownership.
|
| conflicts might arise !
| UncleEntity wrote:
| Unless you have an absolute monopoly market position you are a
| democratic institution where the 'votes' are people giving you
| their hard earned money in exchange for whatever you're
| selling.
|
| Where things go wrong is 'stakeholders' (aka non-paying
| people/customers) demanding influence for whatever is important
| to them like savings baby seals or whatever. They know they
| can't influence the company by 'voting with their wallet' so
| seek out other means to change the company's direction. Like,
| as a totally random example, wanting voting rights to the
| future plans of the company as an outsider with no knowledge of
| internal goals and/or if the proposal would even be profitable.
| lifeisstillgood wrote:
| Oh there are so many ways to play this game - kickstarter is
| basically voting in advanace with your money.
| solar-ice wrote:
| I'm pretty sure that as a society we realised a very long
| time ago that for things that matter, tying votes to money is
| a really bad idea.
| kazinator wrote:
| 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?"
| nijave wrote:
| Yeah or the ability to subscribe to status/tag updates. I have
| a few issues I've been tracking and get spammed with meaningful
| discussion when I mostly just want to know if it gets
| implemented.
| svrtknst wrote:
| Something I believe is overlooked that is relevant here is the
| effect of large volumes of feedback, even positive. Sara Chipps
| wrote about it in her blog post on Stack Overflow[1].
|
| I don't believe we as people are desgined to handle feedback and
| opinions from a large number of people, and it's very easy for
| even neutral or benign questions ("is this planned for a
| release?", "any news on this?") to become grating.
|
| Kinda similar to when kids go "Mom, mom, mom, mom" - nothing
| harmful is being said, but the cumulative effect is exhausting.
|
| IMO it's a good idea to question, has someone else asked this?
| has someone else already stated this opinion? before posting on
| forums.
|
| 1. https://stackoverflow.blog/2019/07/18/building-community-
| inc...
| dom96 wrote:
| Thank you to the author for writing this.
|
| Entitlement in open source is a massive problem, I have
| experienced it first-hand many times. The problem is that it
| discourages contributions not only from the existing maintainers
| but also from people who may volunteer to fix issues in the
| future. Would you be willing to contribute if most of the issues
| are just asking for things (often rudely) and not even saying
| thanks when an issue is resolved?
|
| Unfortunately I have seen far worse examples than the one linked
| in the article[1]. I would encourage people to not only think
| twice before acting this way but to also call out people that are
| acting entitled in open source to discourage such actions.
|
| 1 -
| https://github.com/dom96/httpbeast/pull/35#issuecomment-7218...
| jacobtomlinson wrote:
| OP here, glad you enjoyed this post. Sorry that you've also
| experienced the bad side of things.
| allarm wrote:
| I'm not sure what you mean by this example. From what I see,
| somebody submitted a bug fix that hadn't been approved/merged
| by you for 6 months. Then some quite rude conversation happened
| "Don't act as my free time is owned by you". I mean both sides
| look quite ugly in this particular case to be honest.
| dom96 wrote:
| > From what I see, somebody submitted a bug fix that hadn't
| been approved/merged by you for 6 months.
|
| From my perspective the PR was reviewed and was stuck on a
| test case being created. The author of the PR even stated
| "I'll try to make a simple test case." so as far as I'm
| concerned the ball was in their court.
|
| But you know, reviewing PRs takes time too. Acting entitled
| about a review taking a long time shouldn't be done either.
| allarm wrote:
| > But you know, reviewing PRs takes time too.
|
| I agree. I'm just saying you were rude too.
| abnry wrote:
| He was rude, but he didn't initiate it. Frankly, he
| openly communicated his priorities (other things are on
| the list) and then got snark. So he responded in kind.
| Very little to blame the maintainer here.
___________________________________________________________________
(page generated 2022-06-19 23:01 UTC)