Open Source and Saying “No” • Hacker News Board

Re: Open Source and Saying “No”

#51

Post by Octabrain » Mon, Nov 28, 2022, 1:56 PM UTC

orf wrote: post #19

robertlagrant wrote: post #18

Low dependency analysis is one of the reasons I like Flask[0]. [0] https://github.com/pallets/flask/blob/main/setup.py

Weird, I dislike Flask because it quickly becomes a dependency soup the moment you want to add something simple like forms or a DB. Django has less dependencies[1] - one "real" one (asgiref), one to work around a sqlite issue ("sqlparse"), and up to two timezone related backports depending on your OS (tzcata, zoneinfo). Plus obviously a library for your db backend, if you're not using sqlite. And with that you get a…

I understand what you say and the appeal for it. However, I have to admit that one of the reasons I like Golang over Python (Although I develop in both frequently and enjoy them) is because of the language mentality of libraries over frameworks. I prefer many explicit different dependencies glued together from one's own logic than a batteries included Framework where big part of the magic happens under the hood and ways of doing things must follow an specific path that does not always applies for your specific business case. I think this approach gives a better flexibility (and can cause annoying paralysis by decision too).

Re: Open Source and Saying “No”

#52

Post by vladvasiliu » Mon, Nov 28, 2022, 1:59 PM UTC

mort96 wrote: post #35

zozbot234 wrote: post #29

Earlier quoted context omitted.

> until you manually go and filter them out. Filtering by tag only takes a single click. It's not hard.

Filtering takes two clicks with potential scrolling in between actually, not that it makes a big difference. You probably have multiple kinds of issues you care about, and multiple kinds you don't care about, which takes significantly more work. But this whole discussion about how many clicks it takes to do what is really off topic, the issue is with the lack of a clear separation, and the fact that all the issues ar…

> the issue is with the lack of a clear separation

But if you want to implement a clear separation, you have to actually find a way of defining the separate categories, documenting how they are different, which to use when, and once you're done, it's a not a given that whatever categorization you've settled upon for your project would work for mine.

I think it's a fine trade-off to have something generic, and let each project add whatever tags work for it.

I wouldn't be against renaming "issues" to something more "generic". Maybe "change requests"?

Re: Open Source and Saying “No”

#53

Post by wpietri » Mon, Nov 28, 2022, 2:03 PM UTC

It seems like there's an implicit theory here: if one maintainer says no, then some other competent maintainer will pop up to handle the excluded bit of functionality in a separate library. Why would that be the case? And what about the alternative of getting that person to participate in expanding the existing project?

Re: Open Source and Saying “No”

#54

Post by kreco » Mon, Nov 28, 2022, 2:04 PM UTC

heikkilevanto wrote: post #41

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…

A simple solution is to close all feature requests with a tag that lists is as a request, and a comment that explains that you may go through the requests some day when you don't have many bugs to fix. Or if a customer is willing to pay for an extra feature. Maybe even add a tag to indicate that this feature would be a good place for new contributors to start. Of course, you then get the same feature requests multipl…

While I understand and agree to the solution you provide, I would dare to call it a workaround.

Since Github default culture is to use issues in a certain way, in which the maintainers are actually the bottleneck, most people will keep using it thinking it's the standard and correct way to do it.

Unrelated to the above, you mentioned the paid extra feature, I really wish to see this implemented in a source forge to see how it goes.

Re: Open Source and Saying “No”

#55

Post by mort96 » Mon, Nov 28, 2022, 2:11 PM UTC

vladvasiliu wrote: post #50

mort96 wrote: post #37

Earlier quoted context omitted.

Maintainers obviously have to go through and re-label or move issues as appropriate. The situation is the same now; if someone creates an issue labelled "bug" where they ask for a new feature, you have to go in there and change the label to "feature request". I'm not sure I understand why you think that matters in this discussion

That matters because it shows that there still is a need for the maintainer to go and make sure the labeling is correct. So having multiple top-level categories doesn't help with the maintenance burden.

I assume you know that reading a bug report, realizing that it's actually a feature request, and changing the label accordingly, is significantly less work than implementing the requested feature. So I still don't understand what sort of point you're trying to make. A healthy project probably has the resources to go through incoming bug reports and fix labelling or categorization mistakes, but not enough resources to implement every good idea which comes in through feature requests.

Re: Open Source and Saying “No”

#56

Post by acdha » Mon, Nov 28, 2022, 2:12 PM UTC

ilyt wrote: post #40

acdha wrote: post #36

Earlier quoted context omitted.

This works best if you don’t care about security and aren’t planning to stick around at the same job. If that’s not the case, there is a real cost to a regular stream of updates required for features you don’t use - especially when there’s some kind of major upgrade like Node has had a couple of times which forces everything to update, and you get some period where not all of those dependencies have shipped updates o…

That's probably bad example because if you decided that node is a security problem you're fucked as you'd have to change the language you use...

I wasn't saying that Node itself is a security problem but rather that the community is biased towards rapid upgrades, trading long-term API stability for the ability to use new things quickly. That's a valid trade-off which a lot of people have enjoyed but it does mean that you need to think about whether you have the resources to keep surfing that wave when adding new dependencies. It does seem like the community is reconsidering that balance, too, after years of things like leftpad or worse have been highlighting how exposed most projects are to a single compromised maintainer.

Re: Open Source and Saying “No”

#57

Post by vladvasiliu » Mon, Nov 28, 2022, 2:16 PM UTC

mort96 wrote: post #55

vladvasiliu wrote: post #50

Earlier quoted context omitted.

That matters because it shows that there still is a need for the maintainer to go and make sure the labeling is correct. So having multiple top-level categories doesn't help with the maintenance burden.

I assume you know that reading a bug report, realizing that it's actually a feature request, and changing the label accordingly, is significantly less work than implementing the requested feature. So I still don't understand what sort of point you're trying to make. A healthy project probably has the resources to go through incoming bug reports and fix labelling or categorization mistakes, but not enough resources to…

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.

Re: Open Source and Saying “No”

#58

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

vladvasiliu wrote: post #57

mort96 wrote: post #55

Earlier quoted context omitted.

I assume you know that reading a bug report, realizing that it's actually a feature request, and changing the label accordingly, is significantly less work than implementing the requested feature. So I still don't understand what sort of point you're trying to make. A healthy project probably has the resources to go through incoming bug reports and fix labelling or categorization mistakes, but not enough resources to…

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 things contribute to burn-out through the purely psychological effects of being told by the UI that there are 100 things which need to be solved when there may in fact only be 5, it's a public perception thing when the stat that's prominently placed on the repo page is the number of open issues.

And yes, it's vague. It's not the technical lack of a good enough labelling and search system. And maybe different people react differently to this stuff, maybe some people have no trouble dealing with the lack of a clean separation. But given the fact that burn-out in open source is such a huge issue, maybe conflating the stuff which must be fixed and the stuff which doesn't have to be fixed isn't such a great idea.

Re: Open Source and Saying “No”

#59

Post by indymike » Mon, Nov 28, 2022, 2:31 PM UTC

asim wrote: post #43

Feature creep in open source is almost always because of user pressure "add this or I'm going elsewhere". Nobody has the insight to build in a modular way on top of that library or system, ironically despite being programmers! Sigh. Yet. The things that truly succeed find a way to evolve, scale and grow by learning to include contributors in a way that make them owners of their new contribution and more. It does not…

> Feature creep in open source is almost always because of user pressure "add this or I'm going elsewhere".

Easy response: "OK... to going elsewhere."

Re: Open Source and Saying “No”

#60

Post by mort96 » Mon, Nov 28, 2022, 2:35 PM UTC

vladvasiliu wrote: post #52

mort96 wrote: post #35

Earlier quoted context omitted.

Filtering takes two clicks with potential scrolling in between actually, not that it makes a big difference. You probably have multiple kinds of issues you care about, and multiple kinds you don't care about, which takes significantly more work. But this whole discussion about how many clicks it takes to do what is really off topic, the issue is with the lack of a clear separation, and the fact that all the issues ar…

> the issue is with the lack of a clear separation But if you want to implement a clear separation, you have to actually find a way of defining the separate categories, documenting how they are different, which to use when, and once you're done, it's a not a given that whatever categorization you've settled upon for your project would work for mine. I think it's a fine trade-off to have something generic, and let eac…

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 maintainer can create their own issue categories. Put these categories, with the number of entries in each category, in the sidebar, so that that's what people see rather than the one "Issues" number.

Maybe both of those solutions are bad and a good UX designer (not a random commenter on HN who has thought about this for 2 minutes) can think of something better. Maybe both of those solutions are bad and there is no good solution and the current approach is the best possible. I don't know. Notably though, "there is no solution to the problem that's not worse than the problem itself" does not mean the same as "there is no problem".