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

Open Source and Saying “No”

connortumbleson.com

Post reply on HN
Print view View original

111–120 of 143 posts

Re: Open Source and Saying “No”

#111

Post by shkkmo »

nightpool wrote: post #71
RobotToaster wrote: post #69

Earlier quoted context omitted.

>Github isn't really the issue here >requests are redirected to the discussion forums first The fact you're having to hack the forum into a feature request tracker seems like an issue with github?

The forum was built to be a feature request tracker. It's used extensively for that purpose at Github (see e.g. https://github.com/orgs/community/discussions/categories/cod... ). It's the main usecase for the forum (with a secondary use-case being stack-overflow-like q&a). I don't think anybody is hacking anything

> The forum was built to be a feature request tracker.

It was explicitly built to not be a tracker, but a discussion platform. The documentation describes them thus: "Discussions are for conversations that need to be transparent and accessible but do not need to be tracked on a project board and are not related to code, unlike GitHub Issues."

Thus, once a discussion needs to be tracked or linked to code changes, an issue is required. I'm in favor of providing more tools to orgnizations, but in practice I see very few to none of the projects that I depend on or interface with that actually use github discussions (I presume that is because so many discussions eventually need to be tracked or linked to code changes.)

> It's used extensively for that purpose at Github

Yet, when I look at the Discussions discussion, it's full of random junk, much of which looks like poorly written bug reports.

Re: Open Source and Saying “No”

#112

Post by xur17 »

madeofpalk wrote: post #101
ilyt wrote: post #31

Earlier quoted context omitted.

It is an issue here. Passerby looking at main page will see "300 issues open", not "5 bugs and 295 feature requests open"

I have seen projects use Discussions instead for feature requests, and (open) issues for things the maintainers have a pretty solid understanding of things that should be worked on and closed.

This seems like a great way to handle it.

Re: Open Source and Saying “No”

#113

Post by shkkmo »

mort96 wrote: post #49
willnonya wrote: post #45

Earlier quoted context omitted.

"until you manually go and filter them out" You mean, until you manage your project...gasp. How horrible! Some projects can rack up that many request quickly and overwhelming the maintainer but that isn't the norm. Warranted or not this kind of buildup is usually a sign of neglect.

I don't understand what you are trying to say. Why is a build-up of feature requests a sign of neglect, if bugs are regularly fixed? Do you consider a build-up of unimplemented feature requests to reflect as poorly on a project as a build-up of unfixed bugs?

A build up of un-triage feature requests can be a sign of neglect or of maintainer overload (the later will probably lead to the former eventually), but you can't tell if that is the case just by looking at an issue count.

Re: Open Source and Saying “No”

#114

Post by qikInNdOutReply »

eropple wrote: post #63
qikInNdOutReply wrote: post #61

Earlier quoted context omitted.

There is a issue with issues there though. They do not automatically parse for similar issues and suggest adding your case to them.

That would be a nice add-on, but IME, most people just click straight through it.

Then allow them to auto-cluster by similarity for those who have to read the mess, also sort by quality.

Re: Open Source and Saying “No”

#115

Post by xphos »

Kovah wrote: post #17
kreco wrote: post #16

The main issue mentioned in the article is to use Github. The "issues" on Github could be "bugs", "feature request" or even "improvement" (it could be anything actually). If I were to maintain a project by myself I would rather just deal with bugs or performance issue, and allow feature request in a separated queue where people can upvote it and discuss. The feature request queue could sit there forever as it's just…

Github isn't really the issue here, because it offers the tools to make this differentiation. Maintainers just have to use it. At Github, you can use issue templates that have a set of pre-defined questions and add labels to the created issues. Example from my own project: https://github.com/Kovah/LinkAce/tree/main/.github/ISSUE_TEM... Users can only create bugs and have to answer some detailed questions, because I r…

I think this is also an example of bad default options. You should not have to setup a bug report form to get correct tagging. No one writes bugless code it should be a default option to have a bug report or a feature request. I understand the other fluff around separate queues but for something a large as GitHub good default options are really important.

Re: Open Source and Saying “No”

#116

Post by cestith »

geerlingguy wrote: post #64
manfre wrote: post #44

Earlier quoted context omitted.

> Nobody has the insight to build in a modular way on top of that library or system Sometimes it's less to due with lack of ability and more to do with wanting some one else to pay the cost.

And often there is already a modular system ready, but the person requesting a feature is either too lazy or doesn't know the system enough to use it (or sometimes even know it exists). This seems especially true for drive-by requests where someone on a dev team has a feature they are required to implement in XYZcorp's application. They don't know the platform well, they see the feature isn't provided out of the box,…

Sometimes the modular system is very flexible and straightforward. Other times the system really is modular, but makes many assumptions which make little sense to and are even difficult to foresee by someone less familiar with the overall system. See all the years of discussion over libraries vs frameworks vs complete code ecosystems. If I have a three week deadline and it takes three months to come up to speed with your system's docs and code, I'm going to ask for something without an up-front PR before I take it on myself.

Re: Open Source and Saying “No”

#117

Post by lliamander »

that_guy_iain wrote: post #102

I say this nearly every time something like this is posted. The isn't isn't so much open source, it's that no one is getting paid. We're constantly relying on projects that we get for free where in esscence we're relying on goodwill. So much so, that people say don't add new features because you're depending on the goodwill of that contributor and they may disappear. Which is basically the same was the open source ma…

> I say this nearly every time something like this is posted. The isn't isn't so much open source, it's that no one is getting paid. We're constantly relying on projects that we get for free where in esscence we're relying on goodwill. So much so, that people say don't add new features because you're depending on the goodwill of that contributor and they may disappear. Which is basically the same was the open source maintainer may disappear.

I have no problems with open source maintainers charging for software, but I think the bigger problem is people having incorrect expectations of the open source model.

The main point of the open source is that if the software isn't doing what you need, then you can fix it yourself. Developers often act so helpless when it comes to dealing with bugs or missing features in their open source dependencies. Obviously that involves work, as you can't rely on some third party to maintain the software (or at least your fork) for you. On the other hand, you can't always rely on the vendor of proprietary software either. But at least in the open source model you can rely on yourself, and you can still incorporate any upstream improvements that do come along.

In my view, if you are releasing software as open source then it should have "paid for itself" in some way. Perhaps it was internal software that is used at your company, or perhaps it was written to scratch your own itch. In either case, the work is done and the cost is paid, and you are just sharing it because there's no added cost to you and maybe someone else will benefit from having the source code.

As a final note, it's not just the goodwill of open source maintainers that we are relying on - we also depend upon their desire for status. Being a maintainer of a popular open source project is high status, and something many people covet. That's why many maintainers will put in so much uncompensated time and put up with demanding users: they want the status that comes with having an "important" open source project. Smart maintainers will either learn how to profit from that status or learn how to tell demanding users (politely) to "fork off".

Re: Open Source and Saying “No”

#119

Post by sghosh2 »

I wonder if having some sort of dependency scanner giving more upfront visibility would help clear things up. Then you'd be able to get a sense of what the composition of issues might look like. Seems like there's so many scanners out there that something must solve this.

Re: Open Source and Saying “No”

#120

Post by witrak »

mort96 wrote: post #58
vladvasiliu wrote: post #57

Earlier quoted context omitted.

So, your issue with the current implementation is purely cosmetic / "semantic"? As in seeing there are 1000 "issues", when 999 of these are actually "improvement / feature requests"? Because when you go in the issues tab, you then choose to only see "bugs", which will show you the one that needs handling, and you can ignore the 999 others.

"Cosmetic" and "semantic" aren't synonyms, saying "this project has 100 issues" has a different meaning from "there are 100 features which users want to see implemented". But no, the wording isn't the only/main issue IMO, it's the lack of a clean separation between problems which should be fixed and non-problems which don't need to ever be resolved. It's a cognitive thing for maintainers, I believe mixing up those th…

Perhaps other people may have another opinion but I'm afraid that most people seeing 200 issues think that the product is in the phase of intensive development so is not mature (what can be true) or that its development is stale (what also can be true). Their first thought isn't "it's a mature but still well-maintained product"...
Post reply on HN