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

61–70 of 143 posts

Re: Open Source and Saying “No”

#61

Post by qikInNdOutReply »

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…

There is a issue with issues there though. They do not automatically parse for similar issues and suggest adding your case to them.

Re: Open Source and Saying “No”

#62

Post by blitzar »

zozbot234 wrote: post #24
blitzar wrote: 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.

But my fork is better than yours because it has the feature I wanted and you rejected ...

So maybe you should be integrating your work into my project.

Re: Open Source and Saying “No”

#63

Post by eropple »

qikInNdOutReply wrote: post #61
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…

There is a issue with issues there though. They do not automatically parse for similar issues and suggest adding your case to them.

That would be a nice add-on, but IME, most people just click straight through it.

Re: Open Source and Saying “No”

#64

Post by geerlingguy »

manfre wrote: post #44
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…

> Nobody has the insight to build in a modular way on top of that library or system Sometimes it's less to due with lack of ability and more to do with wanting some one else to pay the cost.

And often there is already a modular system ready, but the person requesting a feature is either too lazy or doesn't know the system enough to use it (or sometimes even know it exists).

This seems especially true for drive-by requests where someone on a dev team has a feature they are required to implement in XYZcorp's application. They don't know the platform well, they see the feature isn't provided out of the box, so instead of doing much research, they just hop in the issue queue and request it.

Re: Open Source and Saying “No”

#65

Post by rapnie »

jacooper wrote: post #42

But saying No too much might result in features sorely missing from your Project. For example, Mastodon quote tweets, or viewing accounts follows and followers.

"Sorely missing" really depends.. for you, a particular user, maybe. But e.g. not having quote tweets in Mastodon was a very deliberate decision (I don't have the issue at hand) not to go in the direction of Twitter here. Quote tweets have their downsides too. This was about keeping project direction and doing things the Mastodon way.

Re: Open Source and Saying “No”

#66

Post by magicalhippo »

willnonya wrote: post #47
sodality2 wrote: post #39

Earlier quoted context omitted.

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

So, it's a marketing problem with the default being issues rather than request?

A feature request should have a different life cycle. In that regard it should be more like a PR, where you submit a request, it gets feedback and is resubmitted etc. All with a history that's clearly visualized, so it's easy to compare the different revisions.

I find it quite difficult to follow the discussion around a non-trivial feature request when it's just a regular issue.

Re: Open Source and Saying “No”

#68

Post by otikik »

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…

You can use GitHub discussions for exactly that.

Re: Open Source and Saying “No”

#69

Post by RobotToaster »

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…

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

Re: Open Source and Saying “No”

#70

Post by shkkmo »

mort96 wrote: post #48
willnonya wrote: post #47

Earlier quoted context omitted.

So, it's a marketing problem with the default being issues rather than request?

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 that matches neither current usage, nor historical usage.
Post reply on HN