Live data from Hacker News

An Open Source Author's Lament

github.com

31–40 of 57 posts

Re: An Open Source Author's Lament

#31
post #20

Many developers would be glad to have 75 pull requests a day on their open source projects, it doesn't seem to make sense to complain about it. I can understand his frustration but maybe he just needs to delegate more work, give commit access, find reliable moderators, etc. it shouldn't be that hard with so much interest in the project.

While these are excellent suggestions, if you check out the links he makes to other posts there is a LOT of noise in there that he has to wade through, weigh (open/close/discuss) and take action on. My interpretation of it is that he is lamenting how the issues list has become a catch-all for everything from bug fixes (which are fine) to random non-Backbone related development questions, and looking at the issues at…

Honestly, this all comes back to the issue "Why is the person who does the majority of the programming also doing the majority of the customer support?"

Let someone else close issues that are offtopic or a bad idea. He insists that this means that 'you have more people who have to read everything' but it absolutely does not. It means you need to learn to trust that if so-and-so closed it, it should be closed.

Re: An Open Source Author's Lament

#32

Many developers would be glad to have 75 pull requests a day on their open source projects, it doesn't seem to make sense to complain about it. I can understand his frustration but maybe he just needs to delegate more work, give commit access, find reliable moderators, etc. it shouldn't be that hard with so much interest in the project.

Indeed. For me as open source developer, the most frustrating issues are the ones that demand functionality without code attached. Especially if they are worded in a way that the creator is somehow entitled to have his issue solved (without offering any compensation). Then again, I have never been in a project that got 75 new pull requests per day...

The issue in question had no code attached, it was a vague request for a syntax change.

Re: An Open Source Author's Lament

#34

Issues need a priority/voting system a lá reddit. People who run the project could set a minimum for getting notifications about issues. Different maintainers could have different minimums.

Issues 1.0 had voting, but it was removed in Issues 2.0

Re: An Open Source Author's Lament

#35
post #22

Earlier quoted context omitted.

I upvoted the original submission because I think this is an interesting and important problem for maintainers of large OSS projects. It would be nice for Github to provide some administrative tools or interface changes to make maintainers' lives easier. However, I am tentatively in agreement with the posters who suggest that this is largely a management problem. I've read the examples you linked, Jeremy, but I don't…

That's entirely right. This is more of a problem with the current workflow of the current implementation of GitHub Issues, for large projects -- it's absolutely something that can be solved.

Maybe a kinda "Flag for close" button on the github interface would help with this. Than the community would be able to flag issues and the core devs could de-prioritize the flagged ones or if there are flags from enough members they can just close it without reading it assuming that many member is probably right?

Re: An Open Source Author's Lament

#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 better solving our problems. I will not solve your problems for you.

What's wrong with these people?

Re: An Open Source Author's Lament

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

Re: An Open Source Author's Lament

#38
post #37
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.

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.

Re: An Open Source Author's Lament

#39
In your .md file, specify that issues should be researched, follow a certain formatting and include certain key words.

The formatted research should include the search terms used when looking for previous issues and list the results found, including a short reason for why those issues didn't apply.

Any issues submitted that didn't include the formatting, research, and key words are put into a bin where volunteer users can go through them and correct the problems.

Basically, I'm saying to demand better from the people you're looking to help, automate as much as you can, and delegate some of the work to those who can't code but can contribute in some way.

Re: An Open Source Author's Lament

#40
post #38
post #37

Earlier quoted context omitted.

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.

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.

Post reply on HN