Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Open Source Author's Lament

github.com

Post reply on HN
Print view View original

41–50 of 57 posts

Re: An Open Source Author's Lament

#41

Post by commentzorro »

crusso wrote: post #37
rbanffy wrote: post #36

Is it really that hard to get people don't write open source to solve your problems? What state of mind makes people believe they are entitled to someone else's time? When I write software, I'm solving my problems. When I write open-source software, I'm still solving my problems, but I find whatever I'm writing may be useful to someone else, so, feel free to use it and, perhaps, even join the effort to continue bette…

If you're doing it only to solve your own problems then why open source it? Obviously, the motivation to help others, contribute to something as a community, show off your skills, etc. are drivers besides just solving your own problems. For some developers, solving their own problems has very little to do with why they work on open source projects.

Because it _may_ solve someone else's problem too. And someone else _may_ contribute something back that also solves one of my problems.

Re: An Open Source Author's Lament

#42

Post by rbanffy »

crusso wrote: post #40
rbanffy wrote: post #38

Earlier quoted context omitted.

Contributing to a community or showing off my skills would also fall under "solving my problems". It's perfectly logical to assume I may want better communities and recognition and the lack of either to be problems I may be inclined to solve.

So your original post is meaningless since you decried solving other peoples' problems... but solving other peoples' problems could completely fall under the set of "solving your problems". "Is anything we do truly altruistic?" is a fun question philosophically, but makes for really circular/meaningless HN comments.

I'm not solving someone else's problem unless it either is also my problem or solving it solves another problem I have.

In this case it's obvious adding the requested feature solves no problem of the maintainer.

Re: An Open Source Author's Lament

#43

Post by caipre »

Jare wrote: post #16
guywithabike wrote: post #7

In one message, @humanchimp says: Ok thanks for closing my issue. @humanchimp's very next comment: The sarcasm is not appreciated, [...]

It's the 'my' that rang the alarm bells in my head. Feelings of ownership are often followed by entitlement, and that's never a good mentality.

I guess you don't like Perl much then. ducks

Re: An Open Source Author's Lament

#44

Post by j_s »

Google Code uses stars, Codeplex allows votes... that seems to be the minimum effort to support crowdsourcing bug prioritization. GitHub's issues haven't gotten much love.

Re: An Open Source Author's Lament

#45

Post by Osmose »

rbanffy wrote: post #36

Is it really that hard to get people don't write open source to solve your problems? What state of mind makes people believe they are entitled to someone else's time? When I write software, I'm solving my problems. When I write open-source software, I'm still solving my problems, but I find whatever I'm writing may be useful to someone else, so, feel free to use it and, perhaps, even join the effort to continue bette…

As someone who writes open source software to help solve other peoples' problems, all I can tell you is that it makes me happy to help other people. There's no logical reasoning behind it beyond that I feel good when I've helped someone else accomplish their goals.

Sure, you could analyze the cost and benefits of it, and maybe even find a logical reason as to why it makes me happy, but _I_ didn't. I just enjoy it! :D

Re: An Open Source Author's Lament

#46

Post by Osmose »

rogerbinns wrote: post #9

A big problem with the Github issue tracker is that there are no priorities. Ideally what you want is someone to do the triage of new reports, prioritise them and then have the main team see them. Sorting by priority then gives an idea of outstanding work (or probably sorting by milestone and then by priority). Bug tracking in general in volunteer communities is terrible. There will be languishing items, duplicates,…

It doesn't support priorities natively, but I've seen several projects use labels with unicode stars to prioritize. Then, you can filter by that tag to to see all 5-star issues, 4-star issues, etc.

Re: An Open Source Author's Lament

#47

Post by Heliosmaster »

lifeisstillgood wrote: post #14

We seem to be forgetting the explicit reasons git was created - to remove the technical commit restrictions and make it a social committing ability - that is the social leader of the project only needs accept commits from people he filters And we are forgetting the long lessons of bug tracking in the wild - don't overload the use cases 1. Can github explicitly limit the people able to make a issue to those who have t…

A possible implementation of "delegation" would be:

* coffee-script/coffee-script as the "social" hub, where people put requests, bugs, and so on, filtered by "his trusted people" * jashkenas/coffee-script , where he gets pull requests (and/or) issues from those trusted people

Also interchanging the two repos work.

Re: An Open Source Author's Lament

#48

Post by lifeisstillgood »

Heliosmaster wrote: post #47
lifeisstillgood wrote: post #14

We seem to be forgetting the explicit reasons git was created - to remove the technical commit restrictions and make it a social committing ability - that is the social leader of the project only needs accept commits from people he filters And we are forgetting the long lessons of bug tracking in the wild - don't overload the use cases 1. Can github explicitly limit the people able to make a issue to those who have t…

A possible implementation of "delegation" would be: * coffee-script/coffee-script as the "social" hub, where people put requests, bugs, and so on, filtered by "his trusted people" * jashkenas/coffee-script , where he gets pull requests (and/or) issues from those trusted people Also interchanging the two repos work.

You are still just asking "someone" to read the firehose.

You need to reduce the firehose

1. raise the bar for submitting something a human is expected to read (write a long form proposal, submit a bug with a stacktrace or a test added to the test suite)

2. raise the bar for community supported issues by needing upvotes.

3. ignore some people randomly :-)

Re: An Open Source Author's Lament

#49

Post by derekerdmann »

JonnieCache wrote: post #33

Perhaps contributing.md should be embedded above the new issue form in the same way that readme.md is embedded on the project homepage.

Great idea. Stack Overflow uses the same concept when you're asking a new question on the site, and I believe it helps the quality of answers tremendously. Making contributing.md visible when creating issues would be incredibly helpful.
Post reply on HN