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

71–80 of 143 posts

Re: Open Source and Saying “No”

#71

Post by nightpool »

RobotToaster wrote: post #69
Kovah wrote: post #17

Earlier quoted context omitted.

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…

>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

Re: Open Source and Saying “No”

#72

Post by mort96 »

shkkmo wrote: post #70
mort96 wrote: post #48

Earlier quoted context omitted.

It's not a marketing problem, it's a semantic problem. Issues are not requests and requests should not be called issues.

It is not a semantic problem. "Issue" was an very broad term far before it was used in software development / project management. It's meaning easily encompasses far more than just bug reports. This is why we have labels to break issues down into other categories. Some issues are purely discussion topics, some are change requests, some are bug reports. You seem to be trying to restrict the meaning of 'issue' in a way…

You may disagree that it's a problem, but what I'm referring to has nothing to do with marketing and everything to do with the semantic meaning of the word.

Re: Open Source and Saying “No”

#73

Post by shkkmo »

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…

I don't see how moving the categorization of "feature request" vs "bug" outside of labels helps anything. That must makes it harder to do the inevitable re-categorization that will always be required since the line between "feature request" and "bug" can get subjective and fuzzy depending on how one views the purpose / spec / scope of a project.

If all you are saying is that it is a UI issue to mix those two categories when you open the issues page for the first time, it is pretty easy to bookmark or link to a list of issues filtered by label.

Re: Open Source and Saying “No”

#74

Post by shkkmo »

mort96 wrote: post #72
shkkmo wrote: post #70

Earlier quoted context omitted.

It is not a semantic problem. "Issue" was an very broad term far before it was used in software development / project management. It's meaning easily encompasses far more than just bug reports. This is why we have labels to break issues down into other categories. Some issues are purely discussion topics, some are change requests, some are bug reports. You seem to be trying to restrict the meaning of 'issue' in a way…

You may disagree that it's a problem, but what I'm referring to has nothing to do with marketing and everything to do with the semantic meaning of the word.

The actual semantic meaning of the word "issue" is broad and doesn't support any of your arguments. You seem to think "issue" means something different from how the rest of the world uses it or has used it.

Re: Open Source and Saying “No”

#75

Post by mort96 »

shkkmo wrote: post #74
mort96 wrote: post #72

Earlier quoted context omitted.

You may disagree that it's a problem, but what I'm referring to has nothing to do with marketing and everything to do with the semantic meaning of the word.

The actual semantic meaning of the word "issue" is broad and doesn't support any of your arguments. You seem to think "issue" means something different from how the rest of the world uses it or has used it.

Ok, so? That means you disagree about me on whether it's a problem, which is fine.

When I hear the word "issue", I hear something roughly similar to "problem"; it certainly has a negative connotation. Maybe I'm just wrong, maybe I'm the only person in the world who associates "issue" with something negative. And even if I'm wrong, it still has nothing to do with marketing.

Re: Open Source and Saying “No”

#76

Post by mort96 »

shkkmo wrote: post #73
mort96 wrote: post #58

Earlier quoted context omitted.

"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…

I don't see how moving the categorization of "feature request" vs "bug" outside of labels helps anything. That must makes it harder to do the inevitable re-categorization that will always be required since the line between "feature request" and "bug" can get subjective and fuzzy depending on how one views the purpose / spec / scope of a project. If all you are saying is that it is a UI issue to mix those two categori…

I don't know what more I can say to make it clear that "there are workarounds or workflows which make it possible to separate bugs and feature requests" doesn't respond in any way to what I'm saying, so I'll just step out of the conversation now.

Re: Open Source and Saying “No”

#77

Post by fullstackchris »

Ah, the author has found the infamous (in my opinion, much much worse than average) state of React Native packages and libraries. For some reason it seems especially React Native packages have a horrible bug rate, low maintenance frequency, and worse... (as an example of what I've seen more than once now, critical bugs are introduced in between minor version changes!) Perhaps it's the ecosystem itself (needing to have native code AND javascript code for BOTH iOS and Android), or the pace of React Native changes itself, but I'm not sure.

Anyway, wholeheartedly agree with the author that one should audit and research packages very carefully before deciding to add them to your codebase. And in React Native, small, "do one thing and do it right" packages would be an unbelievable breath of fresh air.

Re: Open Source and Saying “No”

#78

Post by shkkmo »

mort96 wrote: post #75
shkkmo wrote: post #74

Earlier quoted context omitted.

The actual semantic meaning of the word "issue" is broad and doesn't support any of your arguments. You seem to think "issue" means something different from how the rest of the world uses it or has used it.

Ok, so? That means you disagree about me on whether it's a problem, which is fine. When I hear the word "issue", I hear something roughly similar to "problem"; it certainly has a negative connotation. Maybe I'm just wrong, maybe I'm the only person in the world who associates "issue" with something negative. And even if I'm wrong, it still has nothing to do with marketing.

Concern about the negative emotional connotation of a word instead of that word's semantic meaning is a classic "marketing" concern, but whether or not we call your concern one about "marketing" (which is itself a very broad term) seem irrelevant to that actual substance of your concern.

Since you don't like the connotations of word "issue", what word would you suggest to replace it? Keep it mind that it needs to be similarly broad and encompass not just bug reports and feature requests, but also documentation improvements, design discussions and more.

Re: Open Source and Saying “No”

#79

Post by greggman3 »

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…

this sounds like an engineer fighting against reality. If there is a way to file bugs people will use it to file feature requests. It will be up to you to filter them. It doesn't matter what system you use

Re: Open Source and Saying “No”

#80

Post by avg_dev »

i believe that software design is really hard. it seems appropriate to mention "conceptual integrity" which is a term i believe was coined by the (recently) late great fred brooks. his book "the design of design" talks about it a lot and i really found the discussion helpful. here is a very brief summary from his earlier book: https://en.wikipedia.org/wiki/The_Mythical_Man-Month#Concept...

sometimes saying no is the right thing to do.

as an aside, i find it a little distasteful that the author of this blog post chose to call projects out by name. these people are putting their efforts out for free and they are, to my eyes, taking flak for doing so.

Post reply on HN