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

41–50 of 143 posts

Re: Open Source and Saying “No”

#41

Post by heikkilevanto »

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

Re: Open Source and Saying “No”

#43

Post by asim »

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 always happen. Not all projects can achieve the scale and funding to do it properly but those are the ones that succeed.

Point to the ones that worked and there's the thousands of others that didn't, leaving the maintainers totally burned out. Turns out we're not born managers or project leaders. GitHub and others could do more to improve life for maintainers and users alike. I see sponsorships, but I don't see bounties! Where's the bounty programs? Reward the user for their contribution, reward the maintainer for their long term efforts. The platform needs to do more. Can't put all the pressure on the people using the platforms.

Re: Open Source and Saying “No”

#44

Post by manfre »

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.

Re: Open Source and Saying “No”

#45

Post by willnonya »

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…

"until you manually go and filter them out"

You mean, until you manage your project...gasp. How horrible!

Some projects can rack up that many request quickly and overwhelming the maintainer but that isn't the norm. Warranted or not this kind of buildup is usually a sign of neglect.

Re: Open Source and Saying “No”

#46

Post by jrochkind1 »

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…

Note however that the scenario in the OP that leads to ruin starts with an external contributor contributing a feature. Someone other than the maintainer contributing the PR doesn't really solve the problem; the features still leads to complexity and maintanance burden that inevitably falls on the maintainers.

Re: Open Source and Saying “No”

#47

Post by willnonya »

sodality2 wrote: post #39
vladvasiliu wrote: post #32

Earlier quoted context omitted.

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

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

Re: Open Source and Saying “No”

#48

Post by mort96 »

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?

It's not a marketing problem, it's a semantic problem. Issues are not requests and requests should not be called issues.

Re: Open Source and Saying “No”

#49

Post by mort96 »

willnonya wrote: post #45
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" You mean, until you manage your project...gasp. How horrible! Some projects can rack up that many request quickly and overwhelming the maintainer but that isn't the norm. Warranted or not this kind of buildup is usually a sign of neglect.

I don't understand what you are trying to say. Why is a build-up of feature requests a sign of neglect, if bugs are regularly fixed? Do you consider a build-up of unimplemented feature requests to reflect as poorly on a project as a build-up of unfixed bugs?

Re: Open Source and Saying “No”

#50

Post by vladvasiliu »

mort96 wrote: post #37
vladvasiliu wrote: post #32

Earlier quoted context omitted.

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

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.
Post reply on HN