Open Source and Saying “No” • Hacker News Board

Re: Open Source and Saying “No”

#91

Post by mort96 » Mon, Nov 28, 2022, 5:12 PM UTC

shkkmo wrote: post #88

mort96 wrote: post #60

Earlier quoted context omitted.

Here's a couple possible solutions: * Separate "Issues" and "Requests", give each their own tab in the top-level UI. This creates a relatively clean separation between what requires attention because something is broken and what can be ignored until you want ideas for what features can be added or otherwise improved. Maybe GitHub doesn't need anything more generic than this. * Have a category system, where the mainta…

> Separate "Issues" and "Requests", give each their own tab in the top-level UI. This creates a relatively clean separation between what requires attention because something is broken and what can be ignored until you want ideas for what features can be added or otherwise improved. Maybe GitHub doesn't need anything more generic than this. And then we also need to separate tab for discussions and questions since thos…

> It seems like the problem you are trying to solve is potential users quickly dismissing projects with too many open issues.

No. The issue I am talking about is that there is no clear separation between things which must be addressed (bugs) and things which don't (feature requests). There is no possible way I could have made that more clear. I have repeated this in almost every comment on this topic. You seem to be intentionally misunderstanding me at this point.

Re: Open Source and Saying “No”

#92

Post by nmstoker » Mon, Nov 28, 2022, 5:14 PM UTC

mort96 wrote: post #86

shkkmo wrote: post #78

Earlier quoted context omitted.

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…

Holy shit. You are disagreeing with me about the meaning of a term. That is not about marketing, that is literally what "semantic" means. > 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. Only if yo…

I also disagree with you about how you're treating the term. "Issue" is used more broadly from a user perspective.

As a user it legitimately is an issue, in the commonly used sense, if you cannot do what you need to do with software, even if that software is working exactly as designed and no one has yet flagged some alternate functionality to add with an enhancement.

Re: Open Source and Saying “No”

#93

Post by shkkmo » Mon, Nov 28, 2022, 5:21 PM UTC

mort96 wrote: post #90

shkkmo wrote: post #89

Earlier quoted context omitted.

> Holy shit. You are disagreeing with me about the meaning of a term. I am explaining that you are mistaken about the meaning of the term. I'm backed up by pretty much any dictionary you use to look the word up in. If you don't dispute the literal meaning of the word, but think it carries a negative connotation, that is not a semantic issue. > Only if you want to keep everything about the UI the same except for the w…

Listen, I'm done with this discussion. For the second part of your comment I already linked you to this comment: https://news.ycombinator.com/item?id=33774066 . For the first part, everything I can find on the topic indicates that connotations are part of semantics; it's a part of the word's meaning, after all. If you disagree with that, fine, I don't care, I have made it as clear as I can possibly be that nothing I'…

"meaning" itself is a broad term, but the "literal meaning" AKA the "denotation" is distinct from the "connotation" of a term. Semantics is a broad term that means different things in different disciplines, but generally concerns itself with the denotation more than the connotation. I suppose you could make an argument that the denotation of "semantics" could technically include connotation but that the connotation of "semantics" usually implies that it is denotation that is being discussed.

Re: Open Source and Saying “No”

#94

Post by mort96 » Mon, Nov 28, 2022, 5:24 PM UTC

shkkmo wrote: post #93

mort96 wrote: post #90

Earlier quoted context omitted.

Listen, I'm done with this discussion. For the second part of your comment I already linked you to this comment: https://news.ycombinator.com/item?id=33774066 . For the first part, everything I can find on the topic indicates that connotations are part of semantics; it's a part of the word's meaning, after all. If you disagree with that, fine, I don't care, I have made it as clear as I can possibly be that nothing I'…

"meaning" itself is a broad term, but the "literal meaning" AKA the "denotation" is distinct from the "connotation" of a term. Semantics is a broad term that means different things in different disciplines, but generally concerns itself with the denotation more than the connotation. I suppose you could make an argument that the denotation of "semantics" could technically include connotation but that the connotation o…

Instead of arguing the different definitions of the word "semantic" with me, why not just listen when I say that I'm not talking about marketing. Please.

Re: Open Source and Saying “No”

#95

Post by jasonlotito » Mon, Nov 28, 2022, 5:32 PM UTC

mort96 wrote: post #26

zozbot234 wrote: post #22

Earlier quoted context omitted.

GitHub's issue tracking has tags, which can be used for this.

When you go to a project and see it has 500 open issues, people assume that most or a good chunk of that is bugs. When you as a maintainer go to your repo page on GitHub, you're immediately faced with a huge, insurmountable number of "issues". When you click the Issues tab, GitHub shows you all the feature requests you don't care about until you manually go and filter them out. GitHub doesn't offer great tools to cle…

> When you go to a project and see it has 500 open issues, people assume that most or a good chunk of that is bugs.

That's just changing how GitHub presents the "issues." They could just as easily remove the global number display and simply display the count of each type of issue on the issues page.

> When you click the Issues tab, GitHub shows you all the feature requests you don't care about until you manually go and filter them out.

That's just a UX/UI concern. You can easily link to feature requests only.

None of these are "issues" related, but rather, just how it's displayed. Your concern is with the visuals.

Re: Open Source and Saying “No”

#96

Post by jasonlotito » Mon, Nov 28, 2022, 5:37 PM UTC

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.

> When I hear the word "issue", I hear something roughly similar to "problem"; it certainly has a negative connotation.

That's a you problem.

Ignoring the definition of issue (which also disagrees with your "negative" outlook), GitHub Issues, the product/feature, is clearly defined and encompasses things that deserve discussion, debate, or dispute.

A feature request is very much something that should be discussed.

> Maybe I'm just wrong,

Yes, you are. Rather than push back, accept it and move on.

Re: Open Source and Saying “No”

#97

Post by shkkmo » Mon, Nov 28, 2022, 5:41 PM UTC

mort96 wrote: post #91

shkkmo wrote: post #88

Earlier quoted context omitted.

> Separate "Issues" and "Requests", give each their own tab in the top-level UI. This creates a relatively clean separation between what requires attention because something is broken and what can be ignored until you want ideas for what features can be added or otherwise improved. Maybe GitHub doesn't need anything more generic than this. And then we also need to separate tab for discussions and questions since thos…

> It seems like the problem you are trying to solve is potential users quickly dismissing projects with too many open issues. No. The issue I am talking about is that there is no clear separation between things which must be addressed (bugs) and things which don't (feature requests). There is no possible way I could have made that more clear. I have repeated this in almost every comment on this topic. You seem to be…

Owners of a project have the ability to create clear separations between categories if they want. The 'issues with labels' structure allows each project to setup the categories and level of separation that matches their need. This is important because of the following:

The distinction between "things which must be addressed" and "things which don't" doesn't map cleanly onto the distinction between "bug report" and "feature request" and there are also issues that don't fall cleanly into either category.

Examples:

1) A user opens an issues because a library doesn't work properly on platform X and fails with an error message. The developer of that library closes that issue with a "won't fix" because they don't support the platform. Is this a bug report or a feature request?

2) A user opens an issues because one of the dependencies of a library is no longer being developed so won't support moving to the new version of the language the library is written in. Is this a bug report or a feature request?

3) A project owner opens an issue because a new standard has been released that the library has to support because it is critical to it's ability to interoperate with other parts of the software ecosystem. This could well be much higher priority than many minor edge-case bugs, but is still new functionality.

The answers to these questions can, and should, vary from project to project and issue to issue depending on the larger context. An issue tracking system should be flexible enough to encompass these different needs.

I charitably assumed you were focused on "potential users quickly dismissing projects with too many open issues" since that at least provides a clear reason for why the current methods of categorizing issues isn't good. Since that assumption was incorrect, I still don't understand exactly what exactly your issue is with github issues.

Re: Open Source and Saying “No”

#98

Post by alixanderwang » Mon, Nov 28, 2022, 5:46 PM UTC

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…

Since it's not mentioned, we also use as TODOs/issue-tracker.

https://github.com/terrastruct/d2/issues

We actually switched from Linear to Github Issues because of how nice it is to have the TODOs colocated with PRs and code.

I suspect some users may drive by and be turned away from the sheer number of open Issues, and that's okay to me. I hate projects that try to keep Issues to 0 -- especially the ones that auto-stale. It just makes it harder for me to see if the Issue was actually resolved or not.

Re: Open Source and Saying “No”

#99

Post by mort96 » Mon, Nov 28, 2022, 5:54 PM UTC

shkkmo wrote: post #97

mort96 wrote: post #91

Earlier quoted context omitted.

> It seems like the problem you are trying to solve is potential users quickly dismissing projects with too many open issues. No. The issue I am talking about is that there is no clear separation between things which must be addressed (bugs) and things which don't (feature requests). There is no possible way I could have made that more clear. I have repeated this in almost every comment on this topic. You seem to be…

Owners of a project have the ability to create clear separations between categories if they want. The 'issues with labels' structure allows each project to setup the categories and level of separation that matches their need. This is important because of the following: The distinction between "things which must be addressed" and "things which don't" doesn't map cleanly onto the distinction between "bug report" and "f…

You're displaying that you haven't read this discussion and are bringing up things which don't matter. Stop.

Re: Open Source and Saying “No”

#100

Post by croes » Mon, Nov 28, 2022, 6:27 PM UTC

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…

Your project has 65 issues.

Without looking into the details I could assume these are 65 bugs.