4 ms·

> 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

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

kleinsch 11y ago
Did you read the article? https://github.com/dear-github/dear-github 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...
- phasmantistes 11y ago
  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.
jarek 11y ago
> Get someone to join the team who wants to fill in a PM role. That sounds simple. You're volunteering, then?
- daok 11y ago
  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.
  - jarek 11y ago
    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.
    - phasmantistes 11y ago
      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.
      - jarek 11y ago
        > 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 https://github.com/kennethreitz/records/issues/10 though.
alexwebb2 11y ago
Never heard the analogy of PMs to APIs, but that's the kind of thing that immediately gets stuck in your brain. Nicely put.
- cpeterso 11y ago
  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.
  - SmkyMt 11y ago
    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-Practical-Strategies/dp/1556156502 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-Practices/dp/1572316217 http://www.amazon.com/Software-Project-Survival-Developer-Pr...
cwkoss 11y ago
"I'm a people person, dammit. I have people skills. What the hell is WRONG WITH YOU PEOPLE!"

kleinsch 11y ago

Did you read the article? https://github.com/dear-github/dear-github 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...

phasmantistes 11y ago
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.

jarek 11y ago

> Get someone to join the team who wants to fill in a PM role. That sounds simple. You're volunteering, then?

daok 11y ago
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.
- jarek 11y ago
  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.
  - phasmantistes 11y ago
    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.
    - jarek 11y ago
      > 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 https://github.com/kennethreitz/records/issues/10 though.

alexwebb2 11y ago

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

cpeterso 11y ago
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.
- SmkyMt 11y ago
  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-Practical-Strategies/dp/1556156502 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-Practices/dp/1572316217 http://www.amazon.com/Software-Project-Survival-Developer-Pr...

cwkoss 11y ago

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