Comment by phasmantistes | Hacker News Reader

Comment by phasmantistes | Hacker News Reader

Parent Full thread

> If we move off GitHub, we will immediately eliminate the random noise we get through issues.

> At the same time, we'll eliminate drive-by pull requests that also need reviewing.

I don't think these are good reasons to move away from GitHub. If your project is truly popular, then the people who are filing these issues will follow you to your new home. You'll get a short period of respite, and then you'll be back where you were before. If your project is only popular because you're on GitHub... then moving off will not only give you a respite, it will also destroy your user base.

This is why full-time software engineering teams have PMs. They act as an API for the engineers: helping others understand what sorts of requests can be made, what kinds of responses can be expected, and turning away abusive/malformed traffic.

It simply sounds like this project is popular enough (and >5000 issues in just over 2 years certainly qualifies as popular in my book) that it needs non-engineering attention. Get someone to join the team who wants to fill in a PM role.

Never heard the analogy of PMs to APIs, but that's the kind of thing that immediately gets stuck in your brain. Nicely put.

There was a book about "team APIs" that provided a framework for negotiating how teams will interact with each other.

Of course, I can't find the book online now. I thought it was a Microsoft Press book by Steve McConnell or Steve Maguire.

Perhaps this: Steve Maguire: Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams (1994)

http://www.amazon.com/Debugging-Development-Process-Practica...

edit: Or maybe it was Steve McConnell's you recommend?:

Software Project Survival Guide (Microsoft, 1997)

http://www.amazon.com/Software-Project-Survival-Developer-Pr...

"I'm a people person, dammit. I have people skills. What the hell is WRONG WITH YOU PEOPLE!"

> Get someone to join the team who wants to fill in a PM role.

That sounds simple. You're volunteering, then?

I never understood that kind of comment. It's not because someone is suggesting something that he must fill the position. Same thing about bug, it's not because something is wrong that it means that the one who report it must go in the source and fix it. Your comment doesn't provide values at all.

No, I'm not actually suggesting that he should volunteer.

But saying "surely someone can just volunteer" is pointless in the absence of evidence that someone actually wants to volunteer. If anything the evidence points to not enough volunteer triage PMs - the OSS world is not short on projects that could use a triager.

Oh, that's absolutely true. There are far too few people stepping forward to fill non-technical roles in OSS. And that's a shame, because I think it would really help get some projects off the group, and help others keep their communities together.

But I didn't say "surely someone can just volunteer". I said that they should "get someone to join". There are a lot of ways to do that, and many of them involve the current team members being proactive about going out and trying to recruit someone to fill that role. The OSS communities can't just rely on the "if you build it they will come" philosophy -- if you really want your project to grow, you have to be willing to put yourself forward and actively get people to help you.

> There are a lot of ways to do that, and many of them involve the current team members being proactive about going out and trying to recruit someone to fill that role.

Orrrr the current team members can be proactive and do something that will reduce the number of bad bug reports they get.

Without Github Issues you might miss out on useful input such as https://github.com/kennethreitz/records/issues/10 though.

It's the old "OH you have a problem or a request with some open source project? Then how about YOU write the code/solve the problem! It's open source you know!"

It's a canned response that people roll out whenever anything is raised about an open source project.

"Just find a volunteer" is the canned non-solution people roll out whetnever they are unsatisfied with work they've been given for free.

"Find a volunteer" is a useless suggestion to make to a volunteer organization.

Believe it or not, there are professional PMs who are just as interested in open source in their free time as some professional software engineers are. I'm not one of them -- I'm an engineer -- but I know some.

How many of the PMs you know have you contacted suggesting that they volunteer in such a capacity? What were their reactions?

It would be a good opportunity for people who would like to contribute to an open source project who might have less technical experience or time. Mozilla has many indispensable volunteers who help triage and "groom" Firefox bugs in Bugzilla. They are a huge help. :)

http://www.codetriage.com/

Did you read the article? https://github.com/dear-github/dear-github

Github issues is missing features that would vastly reduce the amount of work they'd have to do. So they can either switch to another issue system or find someone willing to do all that manual grunt work for free. One of those seems easier than the other...

Yes, I've read both the full comment thread in the OP and the dear-github letter.

GitHub adding those features would be a huge boon for teams like this. And honestly, it may be that switching to a different system is the best move for this team. If their motivation is "we need features which GitHub has been unwilling or unable to provide", that's a great reason to move.

But, as I quoted, they also say that they want to move to another system because it will put up artificial walls and isolate them from the people that are currently inundating them with issues. I think that's a bad reason to move. Both because I think it will be ineffective, and because I think it represents bad faith towards their users and community.

Reply on news.ycombinator.com