4 ms·

> Has anybody written a guide on how to survive having a successful open source project? No need for a guide. Close the issue tracker. Only accept pull request

by aikah 8y ago

> Has anybody written a guide on how to survive having a successful open source project? No need for a guide. Close the issue tracker. Only accept pull requests, problem solved.

iofiiiiiiiii 8y ago
I also like the "just give maintainer rights to people who submit good PRs" approach I have heard of. Used it successfully on one of my open source projects that I no longer cared about.
wpietri 8y ago
I don't think that's a very good approach. The contributors I got for my project all first appeared in the issue tracker and we had a few interactions before they decided it was worth their time to write code. That makes sense to me. I would be unlikely to submit a pull request until I was reasonably sure that it was welcome and and that the person receiving it would be a good person to collaborate with.
- aikah 8y ago
  > I would be unlikely to submit a pull request until I was reasonably sure that it was welcome and and that the person receiving it would be a good person to collaborate with. The person you collaborate with do not owe you anything, and it goes both ways. If a PR is rejected, then its author is free to fork the project. But you can't have it both ways, you can't complain about people potentially abusing issues then think there is a special technique to limit the problem, while keeping an issue tracker opened, because there isn't. Closing the issue tracker will ensure only people capable of fixing issues will collaborate to a project.
  - wpietri 8y ago
    I understand the theory you're expressing, I just think it's pretty far from optimal. Closing the issue tracker might have the effect you describe, but will also unnecessarily alienate people who would be excellent contributors with a very moderate investment. I personally didn't "complain about people potentially abusing issues", so I'm not sure where that's coming from. What I'm interested in is helping less experienced project maintainers find healthy ways to cope with having a successful project. But given your confidence on the topic, surely you can show us the successful open source project you are running along these lines?

by aikah 8y ago

> Has anybody written a guide on how to survive having a successful open source project? No need for a guide. Close the issue tracker. Only accept pull requests, problem solved.

iofiiiiiiiii 8y ago

I also like the "just give maintainer rights to people who submit good PRs" approach I have heard of. Used it successfully on one of my open source projects that I no longer cared about.

wpietri 8y ago

I don't think that's a very good approach. The contributors I got for my project all first appeared in the issue tracker and we had a few interactions before they decided it was worth their time to write code. That makes sense to me. I would be unlikely to submit a pull request until I was reasonably sure that it was welcome and and that the person receiving it would be a good person to collaborate with.

aikah 8y ago
> I would be unlikely to submit a pull request until I was reasonably sure that it was welcome and and that the person receiving it would be a good person to collaborate with. The person you collaborate with do not owe you anything, and it goes both ways. If a PR is rejected, then its author is free to fork the project. But you can't have it both ways, you can't complain about people potentially abusing issues then think there is a special technique to limit the problem, while keeping an issue tracker opened, because there isn't. Closing the issue tracker will ensure only people capable of fixing issues will collaborate to a project.
- wpietri 8y ago
  I understand the theory you're expressing, I just think it's pretty far from optimal. Closing the issue tracker might have the effect you describe, but will also unnecessarily alienate people who would be excellent contributors with a very moderate investment. I personally didn't "complain about people potentially abusing issues", so I'm not sure where that's coming from. What I'm interested in is helping less experienced project maintainers find healthy ways to cope with having a successful project. But given your confidence on the topic, surely you can show us the successful open source project you are running along these lines?