Meteor-feature-requests: Repo ramp-up

[hwillson]

Hi all - thanks for creating this repo @benjamn, super excited to get the ball rolling on this!

I've taken a crack at breaking out the steps I think we need to address, to get this repo fired up.

Preparation

• [x] 1. Update this repo's README to add a bit more context on what this repo will be used for, and why it exists.
• [x] 2. Update the new issue boilerplate that shows in this repo, to make sure it's very clear this repo is for feature requests only.
• [x] 3. Update the new issue boilerplate on meteor/meteor to mention that feature requests should be opened in this repo instead. (EDIT: This has to be done after this repo is live, so moving it to the section below.)
• [x] 4. Come up with a common message we'll be posting to existing meteor/meteor feature requests (just before closing them), that mentions feature requests should now be moved to this repo.
• [x] 5. Come up with a way to allow anyone interested in having an existing feature request stay active, move that feature request over to this repo. This can either be really simple/not user friendly (e.g. just provide a link to https://github.com/meteor/meteor-feature-requests/issues/new asking people to open a new FR in this repo), or more sophisticated (e.g. provide a link to an external/custom app that when accessed, takes care of moving the issue over to this repo via GH's API). Whatever method we choose it should be added to the common message we add to existing feature requests, just before we close them.
• [x] 6. Migrate over appropriate repo labels.

Good to Go

• [x] 6. Make this repo public.
• [x] 7. Update the new issue boilerplate on meteor/meteor to mention that feature requests should be opened in this repo instead.
• [x] 8. Update meteor/meteor's README, Contributing.md, and IssueTriage.md docs to mention this repo (and adjust any sections discussing feature requests in the meteor/meteor repo).
• [x] 9. Post a message on the forums to give devs a heads up about this change.
• [ ] 10. Start updating/closing current feature requests on meteor/meteor.

Looking at the above, I think the biggest question mark is around how we want to handle #5. Ideally we can just put a link in the close message that when clicked opens the new issue page in this repo, with the title and initial body content pre-filled (initial content would be the original issues's first post content, along with a message saying this issue was migrated from meteor/meteor, and a link back to the original issue). I can't think of any existing products/libs that will do this for us, so I think we'll have to write something custom. Let me know if you guys can think of anything - if not I'm happy to build something quick to do this.

Let me know how the above list looks, and what I've missed. I'm happy to work on all of the items above (I can't wait to get the FR's moved! 🙂). Thanks!

[hwillson]

Relating to #5 above (and as briefly discussed on our last call), another option is to include a link like the following in our "this feature request is being closed" message:

https://github.com/meteor/meteor-feature-requests/issues/new?title=The%20current%20issue%20title&body=Migrated%20from:%20meteor/meteor%231234

So for each existing meteor/meteor feature request we close, we update the above link to include the current issue title and number. This doesn't provide a lot of context in the new issue, but it would at least preserve the title, and provide a link back to the source issue. This approach isn't quite as nice as building out a small script/app to migrate an issue along with more context, but this approach is much easier/faster to implement. I'm leaning towards this - what do you guys think?

[lorensr]

Might be nice to have one open issue on this repo with the full list of currently-open meteor/meteor FRs, so that we/people know which FRs had made it through triage prior to The Switch.

[hwillson]

Hi guys - I've been thinking about the feature request migration process a bit more. Maybe we should consider auto-migrating feature requests that have had recent activity (something like any FR that has been updated in the past 6 months), but require manual migration on FR's that haven't seen any updates in 6 months. So when migrating FR's from meteor/meteor, we would add one of 2 messages to the original FR:

1) FR has had activity in < 6 months:

To help provide a more clear separation between feature requests and bugs, and to help clean up the feature request backlog, Meteor feature requests are now being managed under the https://github.com/meteor/meteor-feature-requests repository.

This feature request has been migrated to meteor/meteor-feature-requests#1234.

2) FR has not had any activity in < 6 months:

To help provide a more clear separation between feature requests and bugs, and to help clean up the feature request backlog, Meteor feature requests are now being managed under the https://github.com/meteor/meteor-feature-requests repository.

Since this feature request has not had any activity in the past 6 months, it will be closed here without being automatically migrated to the new repository. Anyone interested in migrating this feature request to the new repository however (to make sure it stays active), can click here to start the feature request migration process. This manual migration process is intended to help identify which of the older feature requests are still considered to be of value to the community. Thanks!

What do you think?

[lorensr]

Could also auto-migrate issues tagged with pull-requests-encouraged

On Wed, May 24, 2017 at 12:17 PM, Hugh Willson [e-mail]
wrote:

Hi guys - I've been thinking about the feature request migration process a
bit more. Maybe we should consider auto-migrating feature requests that
have had recent activity (something like any FR that has been updated in
the past 6 months), but require manual migration on FR's that haven't seen
any updates in 6 months. So when migrating FR's from meteor/meteor, we
would add one of 2 messages to the original FR:

1) FR has had activity in < 6 months:

To help provide a more clear separation between feature requests and bugs,
and to help clean up the feature request backlog, Meteor feature requests
are now being managed under the https://github.com/meteor/
meteor-feature-requests repository.

This feature request has been migrated to meteor/meteor-feature-
requests#1234.

2) FR has not had any activity in < 6 months:

To help provide a more clear separation between feature requests and bugs,
and to help clean up the feature request backlog, Meteor feature requests
are now being managed under the https://github.com/meteor/
meteor-feature-requests repository.

Since this feature request has not had any activity in the past 6 months,
it will be closed here without being automatically migrated to the new
repository. Anyone interested in migrating this feature request to the new
repository however (to make sure it stays active), can click here
https://github.com/meteor/meteor-feature-requests/issues/new?title=The%20current%20issue%20title&body=Migrated%20from:%20meteor/meteor%231234
to start the feature request migration process. This manual migration
process is intended to help identify which of the older feature requests
are still considered to be of value to the community. Thanks!

What do you think?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/meteor/meteor-feature-requests/issues/1#issuecomment-303791860,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPVmPsuWOpfg1mmDsQcSeC7oQEr24B4ks5r9GYwgaJpZM4NfO1P
.

[benjamn]

@hwillson I think auto-migrating issues (instead of asking the reporter to migrate them by clicking the link) will mean the original reporter won't be able to modify the new issue description, so let's just stick to asking everyone to click the link?

[benjamn]

For what it's worth, if you sort by most recent activity, I think you'll get quicker and more engaged feedback sooner, as you work your way backwards through the issue list.

[hwillson]

The finalized message we'll be adding to FR's as we close them:

To help provide a more clear separation between feature requests and bugs, and to help clean up the feature request backlog, Meteor feature requests are now being managed under the https://github.com/meteor/meteor-feature-requests repository.

This feature request will be closed here, but anyone interested in migrating this feature request to the new repository (to make sure it stays active), can click here to start the feature request migration process. This manual migration process is intended to help identify which of the older feature requests are still considered to be of value to the community. Thanks!

[benjamn]

Sounds great to me!

[hwillson]

Hi all - here's the message we can post to the forums when ready. Let me know if I should change anything:

---

Upcoming meteor/meteor repository changes

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.

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, 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.

[hwillson]

Just to add - right after https://github.com/meteor/meteor/pull/8764 is reviewed/merged, we should be all set to launch this new repo and get started on the migration process. So after that PR is merged, I'll:

• Close this issue and make this repo public
• Post the previous message to the forums
• Get started on existing feature request closing (with the message / link we've agreed on), doing most recently updated feature requests first (I wrote a small app to help automate some of this).

Let me know if anyone objects to any of this, otherwise full steam ahead! 🙂

[hwillson]

Okay, we're off to the races - closing this issue. Thanks all!