Bryan Mishkin

While we have been making a lot of progress addressing the false positives, it's true that there will always be false positives we cannot address for this rule. I'm open...

Any other thoughts? @gilest @smilland

I'll proceed with merging and releasing this in the next few day unless there are objections. I agree that even more important than the lint rule is for someone to...

@emonroy could you comment? CC: @rwjblue Maybe we can improve the [no-controller-access-in-routes](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-controller-access-in-routes.md) rule documentation.

These changes are looking pretty good so far. Excited to get this in. But I'm a bit unclear on what your questions are asking.

Can you also delete the "Help Wanted" section from the docs for these rules (which I added recently in #669)?

We have [closure-actions](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/closure-actions.md) which disallows `this.sendAction()`. Would it make sense to update that rule to allow disallow `this.send()`?

Agreed with @rwjblue that the name should state of the goal of deprecation avoidance. So `no-deprecated-transition-methods` or possibly `no-deprecated-router-transition-methods` would be even more clear.

In some of my applications, all of our routes extend from our own custom base route, and these would no longer get linted if we changed to only consider routes...

This could either be created as a new rule or as an option on the related rule [require-computed-property-dependencies](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/require-computed-property-dependencies.md).