Live data from Hacker News

Open Source and Saying “No”

connortumbleson.com

21–30 of 143 posts

Re: Open Source and Saying “No”

#21
post #17
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's still categorized under "issues" clogging them up. I would definitely want a feature that enables me to split issues into "bug reports" and "feature requests"

Re: Open Source and Saying “No”

#22
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…

It's still categorized under "issues" clogging them up. I would definitely want a feature that enables me to split issues into "bug reports" and "feature requests"

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

Re: Open Source and Saying “No”

#23
post #20

"All in all I'm being much more careful when researching dependencies and libraries before bringing them in." - As everyone should be. Folks are too blasé about importing bloated dependancies.

It's pretty easy to end up with one even if you tried to pick some popular and supported library, as they might not be a discerning as you in their dependencies

Re: Open Source and Saying “No”

#26

Earlier quoted context omitted.

It's still categorized under "issues" clogging them up. I would definitely want a feature that enables me to split issues into "bug reports" and "feature requests"

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 clearly separate bug reports, improvement suggestions and feature requests.

Re: Open Source and Saying “No”

#27
post #12

I know it is fantasy land, but a healthy fork -> reintegrate way down the line cycle would benefit all parties. However, humans being humans egos etc get in the way.

You can just fork and then ask for your changes to be pulled into their own tree.

That's called contributing via a pull request isn't it?

Re: Open Source and Saying “No”

#28
post #19

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…

Ditto. I liked Flask years ago but unless you’re doing very contained microservices it always ends up feeling like you’re building your own framework. This isn’t a slam on Flask but rather, I think, a reminder that we’re so prone to think about the fun of being able to customize everything without thinking about the maintenance trade-offs.

Re: Open Source and Saying “No”

#29
post #26

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…

> until you manually go and filter them out.

Filtering by tag only takes a single click. It's not hard.

Re: Open Source and Saying “No”

#30

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

you are conflating the size of the codebase with the number of dependencies

Django has fewer dependencies than Flask.

(though in all fairness the dependencies Flask has were developed by the same author, thus in that sense, it is more like Django)

Post reply on HN