Open Source and Saying “No” • Hacker News Board

Re: Open Source and Saying “No”

#31

Post by ilyt » Mon, Nov 28, 2022, 1:01 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…

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

Re: Open Source and Saying “No”

#32

Post by vladvasiliu » Mon, Nov 28, 2022, 1:02 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…

I think this is fine enough because one way or another, you still have to make sure that the categorization is respected. To me, it's pretty much the same thing if there are multiple top-level tabs (bugs / requests) or sub-tabs (issues -> bugs / requests). The difference seems mainly cosmetic.

The problem is that even if you had multiple top-level distinctions, you would still have to make sure that people opening them are disciplined (and pay attention) enough to file them in the right category. Just because there's a separate "feature request" top-level tab doesn't mean that nobody will ever open a "bug" asking for a "feature". Especially if not everybody is allowed to ask for new features.

And I'm not even going into the difference between "improvement" and "feature" requests.

Re: Open Source and Saying “No”

#33

Post by robertlagrant » Mon, Nov 28, 2022, 1:03 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…

Django is also excellent for this. This isn't a two-horse race :)

Re: Open Source and Saying “No”

#34

Post by ilyt » Mon, Nov 28, 2022, 1:03 PM UTC

slbtty wrote: post #3

Doing exactly the opposite is also a right approach: Absorb as many features as possible, so that more people will be gravitated into a centralized place. For bugs, if the original feature submitter isn't around, potential new maintainers will emerge and fix them.

Kinda depends on project. Accepting features willy nilly can make a mess both ou of codebase and project direction.

Re: Open Source and Saying “No”

#35

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

zozbot234 wrote: post #29

mort96 wrote: post #26

Earlier quoted context omitted.

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…

> 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 are bunched together by default -- that filtering out the issues you don't care about takes any clicks at all -- contributes to that.

Re: Open Source and Saying “No”

#36

Post by acdha » Mon, Nov 28, 2022, 1:08 PM UTC

dncornholio wrote: post #25

Life is too short to care about non issues. If (part) of a package solves your problem, just use that part. I don't see how an opinion of the package features stops you from solving your problem :)

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 or backwards-incompatible changes are required, and you might have to help get changes made upstream or fork something.

Better hope no security exploits are found when you’re in the middle of that process…

Re: Open Source and Saying “No”

#37

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

vladvasiliu wrote: post #32

mort96 wrote: post #26

Earlier quoted context omitted.

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…

I think this is fine enough because one way or another, you still have to make sure that the categorization is respected. To me, it's pretty much the same thing if there are multiple top-level tabs (bugs / requests) or sub-tabs (issues -> bugs / requests). The difference seems mainly cosmetic. The problem is that even if you had multiple top-level distinctions, you would still have to make sure that people opening th…

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

Re: Open Source and Saying “No”

#38

Post by ilyt » Mon, Nov 28, 2022, 1:09 PM UTC

bayindirh wrote: post #10

slbtty wrote: post #3

Doing exactly the opposite is also a right approach: Absorb as many features as possible, so that more people will be gravitated into a centralized place. For bugs, if the original feature submitter isn't around, potential new maintainers will emerge and fix them.

Making this will exponentially increase the glue code required to tie everything together. So, while new developers fix the features, they'll also need to fix that glue layer too, making the work twice or thrice as big. Also things will also even get more complicated as long as things get added into the mix. This is why UNIX philosophy is very important. Keeps software simple, compact and much more easier to maintain…

It can work but you have to have a vision on how to integrate extra features, not just shove them into the codebase.

Consistent plugin API allowing to plug-in code in various parts of the app takes a bunch of effort but now you're magically separated by a wall of code from the contributors, as you're never a blocker for someone's else effort to add features, and the stuff you don't want to maintain can land in contrib repo

Re: Open Source and Saying “No”

#39

Post by sodality2 » Mon, Nov 28, 2022, 1:09 PM UTC

vladvasiliu wrote: post #32

mort96 wrote: post #26

Earlier quoted context omitted.

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…

I think this is fine enough because one way or another, you still have to make sure that the categorization is respected. To me, it's pretty much the same thing if there are multiple top-level tabs (bugs / requests) or sub-tabs (issues -> bugs / requests). The difference seems mainly cosmetic. The problem is that even if you had multiple top-level distinctions, you would still have to make sure that people opening th…

> To me, it's pretty much the same thing if there are multiple top-level tabs (bugs / requests) or sub-tabs (issues -> bugs / requests). The difference seems mainly cosmetic.

The difference is that they're all under the label "issues" implying it's something that needs to be fixed. Sure, you could label it, but that's a workaround and it's still in a category called "issues".

Re: Open Source and Saying “No”

#40

Post by ilyt » Mon, Nov 28, 2022, 1:10 PM UTC

acdha wrote: post #36

dncornholio wrote: post #25

Life is too short to care about non issues. If (part) of a package solves your problem, just use that part. I don't see how an opinion of the package features stops you from solving your problem :)

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...