[wpietri]

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]

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

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?