On the management of fast.ai Github repo issues

For the administrators of the Github repo, if you don’t terribly mind, could you please clarify a bit what it means when an issue is closed? Does it mean that whatever proposed in the issue has already been reviewed by the board and would not be considered now and forever?

I am a bit confused because there are issues that have gained much applause and acceptance by the community, but nevertheless still get closed down. Take this docs generation proposal as an example. The maintainer posted that the idea will be noted for the documentation of fast.ai v1. Yet, what actually happened is that, despite the fully working and functional solution presented by Kai Lichtenberg, who obviously has put a lot of effort into building it, the board again chose to develop a new approach from scratch, most of whose features have already been realized in Kai’s implementation.

@kai mentioned his idea and work again in the forum, but received no reply and no attention. Not even a brief explanation.

This, I believe, is most likely a side effect from closing down issue too early and prematurely. Github by default only displays and searches open issues. So when an issue is closed, most likely it will be forgotten both by the community and the maintainers.

This could be what happened to the above issue, a perfectly functional solution to documentation forgotten, and we rebuild the wheel, one superior in some aspects for sure but also arguably inferior in some other. It is also rather unfriendly and discouraging to the developers eager to contribute, especially who have put in much effort crafting a demo solution before even creating this issue. In some sense, this is no different from saying that we do not value your idea and you are not welcomed here.

It is perfectly fine to keep the issues open, especially those that have much love and support but might not be incorporated in the near future. Issue board is supposed to be a place where people regularly check for what other people are working on and find ideas to join forces with. For other open source projects of a similar scale and popularity, for example, Pandas, there are usually thousands of issues open at a time, all labeled approriately for future discussion and implementation.

High issue count is not a dirty mark of the repo; rather, it shows the liveliness and engagement of the developers around it. If possible, could the maintainer start taking a different approach to issue management, so that it might feel a bit more accommodating and friendly to newcomers? Specifically, maybe we can choose to leave open the issues that people want to implement and could be beneficial to the future of the library?

Thank you again for all the effort that you have put into fast.ai so selflessly. You are all my heroes and examples I aspire to become. I am sure that changing slightly how we manage the issues will make the project grow even better in the near future.

If an issue you like is not accepted, it is absolutely not acceptable to take to the forums to complain about it. It is even less acceptable to try to claim it’s a symptom of some wider problem.

This is the first time this has happened. I very much hope it is the last.

If you create an issue, it should be because you want to help the developers improve the library. When the developers do not need the issue to improve the library, it is closed.