TL;DR: Meteor feature requests are no longer being tracked in the main meteor/meteor repo; all new feature requests should be opened in meteor/meteor-feature-requests. Existing feature requests will be updated with an option to migrate them to the new repo (if anyone in the community chooses to do so), then closed.
Hi all! Over the past long while, both MDG and community members have been working at getting the meteor/meteor open issue count down. While we’ve definitely made some progress, there is still a lot of work to do. There are currently hundreds of open issues, with new issues rolling in every day.
Out of the almost 600 open issues on meteor/meteor, 300+ are currently labelled as feature requests. Unfortunately, this large issue count makes it look like Meteor has a large number of outstanding bugs, when in reality more than half of the current open issues are feature requests, discussions, etc. Ideally GitHub would have a better way to deal with this issue discrepancy (outside of labels), such that feature requests / discussions could be tracked separately from bugs (for those interested, dear-github/dear-github#44 sums up the issue nicely).
Putting aside the bug / feature request open issue count, another problem that has manifested over time, is that there are a large number of open feature requests that no longer have a champion (or interest from the community) to help push them forward. While these feature requests could be closed due to a lack of activity, a large majority of them really are great ideas.
Given the above (and other) issues, moving forward Meteor feature requests will be tracked in a new repository - meteor/meteor-feature-requests. There are definitely pros / cons to tracking feature requests in a separate repository, but in Meteor’s case the pros outweigh the cons:
- A smaller issue count on meteor/meteor shows that the project is being actively maintained, and issues are being dealt with (looks better, especially to newcomers considering the platform).
- Issues on meteor/meteor represent actual issues / bugs. This makes it easier to keep a finger on the pulse of how Meteor is behaving, especially after new releases.
- The large number of meteor/meteor issues is difficult to triage, meaning a lot of older feature requests (that are good ideas) haven’t been touched in quite some time. Splitting bugs from feature requests makes the overall issue count on both repos smaller, which means the smaller lists are easier to manage. We could even consider having triagers focused on each repo; some just on bugs, some just on feature requests.
- Right now the large issue list is daunting to potential and existing contributors. Sure people can filter by pull-requests-encouraged, but having smaller feature request / bug lists could help promote issue visibility (easier to skim through the lists and find something interesting, etc.).
- Migrating existing feature requests from meteor/meteor to meteor/meteor-feature-requests gives us a chance to ask for new champions to take ownership of older feature requests, and see them revived in the new repo.
Effective immediately, please open new Meteor feature requests in meteor/meteor-feature-requests. All existing meteor/meteor feature requests will be closed (over time), but anyone in the community who wants to migrate a specific feature request over to the new repo, will be given a chance to do so (by clicking on a migration link in the feature request that’s being closed). While this migration process could be automated, a more manual approach has been decided upon to help make sure that only the feature requests people really want are migrated over and kept alive.
One last thing to mention - please rest-assured that both the meteor/meteor and meteor/meteor-feature-requests repositories will continue to be monitored by MDG and community issue triagers. The intent of this work is to help make it easier to get Meteor issues resolved, and help the platform excel.
Thanks everyone - if you have any questions/concerns, please post them here.
