> 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.
Perhaps this:
Steve Maguire: Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams (1994)
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.
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.
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.
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. :)
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.
> 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.