* When a question, I try to reply until sorted (often by other users) and then close it as soon as possible.
* I always leave feature requests open (when I like them), even when they imply huge refactorings. That is actually annoying as I lose track, and here I kinda like your suggestion.
* Sometimes people don’t come back. I close them then.

I guess a problem is Github’s issue tracker itself. I would like to have different “channels” (as you called them) in there, so I could categorize stuff into

* Questions/Support
* Feature Request
* Bug!!!!

Thanks again guys and keep rockin’!!!

I guess this really comes down to each maintainer preferences. I know that by no means my little OSS projects get much activities like the projects you maintain, so of course I have no idea how I would deal with tickets if I were maintaing some largely used software.

But currently, I simply don’t stress if my projects have many open issues and I avoid closing any issue until the discussion is over or until I’m already decided on not to accept some feature request cause I don’t think it fits the project goals and then I state that when closing the tickets.

My take is that GitHub’s issues is usually used even by large projects, like Rails, when it probably shouldn’t as it lacks some interesting features.

For my private projects we use Redmine and we have a few subprojects as well and I can easily filter the open tickets by priority, type (bug, feature, etc) or basically anything I need.

I find it very helpful to concentrate discussions on the tickets rather than on mailing lists or StackOverflow. But I realize that this is my personal take on it and that you probably prefer a simpler issue tracker like GitHub’s one and only handle bugs there.

For my private projects we have tons of feature requests and I don’t feel stressed about that. I work on them by priority order or some other criteria but it simply doesn’t stress me if I can’t get all of them down to zero until the end of the week or the year.

“The issues tracker should focus on *actionable issues*.”

The two examples I pointed out (and I could point others as well if you prefer) were actionable in my opinion. And yes, after posting the comment I noticed one of them was still open… I just got confused by other “closed” mentions while reading the ticket.

With regards to incomplete bug reports, I’d give some time for the reporter to fill out the missing information and after a while without feedback I’d then close the ticket. Just not immediately. When that happens for my private projects, I check such issues with the “Feedback” status so that I don’t look at them again until it changes or when I’m doing some clean-up on old tickets…

I feel most of the reasons for the guideline you suggest in this article comes from the lacking of the GitHub issues system. Also they seem to be required by large projects, but maybe not at all for smaller ones. Maybe the reasons wouldn’t apply for other projects using more feature-complete issues tracker systems.

Rodrigo, that depends on the team, but in my opinion the issues tracker is not the place to have a discussion about features in project of the size of Rails. It has very low visibility (mostly because only the project maintainers receive notifications) so it always end-up being a decision in between the maintainers of the project and the contributor.

That is exactly the point of the blog post. The issues tracker should focus on *actionable issues*. The point is not to remove all discussions but to *move discussions to the appropriate medium*. It is much healthier for an open source project to have its bugs clearly laid out in the tracker than in a mixture of personal feature requests, questions and incomplete bug reports.

Note the second issue you linked has not been closed but still there is no discussion. Why aren’t other people being part of the conversation and answering your questions? Maybe in part because there are other 600 open issues? And once you reach this point, it is much harder to improve because the maintainer motivation decreases and the response time gets even worse. Many projects today resort to expiring issues with no comments after 3 months or even resetting the whole issues tracker by declaring bankruptcy! How is that better for the community?

There was simply no discussion around it. “I don’t like it” -> “Yeah, me too” -> “closed”.

I simply don’t see how this is good for the community…

This is yet another example where the discussion has ended prematurely by closing the ticket: https://github.com/rails/rails/pull/11071

And those are not exceptions from what I’ve seen with regards to tickets handling in Rails at least. Also, the way the Rails core team approaches the issues and bug requests are mostly the reason why I stopped trying to contribute to Rails long ago.

I sincerely hope other OSS projects don’t follow this guidelines…