Remove "show_unanchored_annotations" feature

[nickstenning]

We've discussed this feature and decided that it can't be turned on in its current state. This commit removes it.

Note that the feature flag in h/features.py remains until these changes are deployed out to production.

[dwhly]

Nick is there any reason staff can't continue to use it?

---

Dan / +1 650 274 7647 mobile

On Wed, Nov 25, 2015 at 11:46 AM -0800, "Nick Stenning" notifications@github.com wrote:

We've discussed this feature and decided that it can't be turned on in its current state. This commit removes it.

Note that the feature flag in h/features.py remains until these changes are deployed out to production.

You can view, comment on, or merge this pull request online at:

  #2741

Commit Summary

Remove "show_unanchored_annotations" feature

File Changes

M
h/static/scripts/directive/test/thread-test.coffee
(4)


M
h/static/scripts/directive/thread.coffee
(4)


M
h/static/styles/threads.scss
(8)


M
h/templates/client/thread.html
(5)

Patch Links:

https://github.com/hypothesis/h/pull/2741.patch
https://github.com/hypothesis/h/pull/2741.diff

—
Reply to this email directly or view it on GitHub.

[dwhly]

Nick is there any reason staff can't continue to use it?

---

Dan / +1 650 274 7647 mobile

On Wed, Nov 25, 2015 at 11:46 AM -0800, "Nick Stenning" notifications@github.com wrote:

We've discussed this feature and decided that it can't be turned on in its current state. This commit removes it.

Note that the feature flag in h/features.py remains until these changes are deployed out to production.

You can view, comment on, or merge this pull request online at:

  #2741

Commit Summary

Remove "show_unanchored_annotations" feature

File Changes

M
h/static/scripts/directive/test/thread-test.coffee
(4)


M
h/static/scripts/directive/thread.coffee
(4)


M
h/static/styles/threads.scss
(8)


M
h/templates/client/thread.html
(5)

Patch Links:

https://github.com/hypothesis/h/pull/2741.patch
https://github.com/hypothesis/h/pull/2741.diff

—
Reply to this email directly or view it on GitHub.

[nickstenning]

Nick is there any reason staff can't continue to use it?

If we have no intention of releasing the feature to users, I'd rather we didn't keep it.

Feature flags are intended to be used as a release mechanism, not a way of having different sets of features for different groups of users, so I'd rather we didn't use them that way.

[nickstenning]

Nick is there any reason staff can't continue to use it?

If we have no intention of releasing the feature to users, I'd rather we didn't keep it.

Feature flags are intended to be used as a release mechanism, not a way of having different sets of features for different groups of users, so I'd rather we didn't use them that way.

[dwhly]

Just as a bridge to when we are able to create a permanent home, which hopefully will be soon. Clearly not a long term solution.

---

Dan / +1 650 274 7647 mobile

On Wed, Nov 25, 2015 at 12:20 PM -0800, "Nick Stenning" notifications@github.com wrote:

Nick is there any reason staff can't continue to use it?

If we have no intention of releasing the feature to users, I'd rather we didn't keep it.

Feature flags are intended to be used as a release mechanism, not a way of having different sets of features for different groups of users, so I'd rather we didn't use them that way.

—
Reply to this email directly or view it on GitHub.

[dwhly]

Just as a bridge to when we are able to create a permanent home, which hopefully will be soon. Clearly not a long term solution.

---

Dan / +1 650 274 7647 mobile

On Wed, Nov 25, 2015 at 12:20 PM -0800, "Nick Stenning" notifications@github.com wrote:

Nick is there any reason staff can't continue to use it?

If we have no intention of releasing the feature to users, I'd rather we didn't keep it.

Feature flags are intended to be used as a release mechanism, not a way of having different sets of features for different groups of users, so I'd rather we didn't use them that way.

—
Reply to this email directly or view it on GitHub.

[nickstenning]

I don't see any justification for giving staff one experience and users another. If it's not good enough for users, it's not good enough for staff. If it's good enough for staff, it's good enough for users.

[nickstenning]

I don't see any justification for giving staff one experience and users another. If it's not good enough for users, it's not good enough for staff. If it's good enough for staff, it's good enough for users.

[robertknight]

If it's good enough for staff, it's good enough for users.

I agree with that line of thought but I do find the current implementation useful and, from a completely naive perspective of someone who hasn't seen internal discussions about it, I wondered why we haven't shipped what we have.

[robertknight]

If it's good enough for staff, it's good enough for users.

I agree with that line of thought but I do find the current implementation useful and, from a completely naive perspective of someone who hasn't seen internal discussions about it, I wondered why we haven't shipped what we have.

[nickstenning]

Just in case it's not clear, this isn't me deciding unilaterally to remove this. I discussed it with @judell, who isn't happy shipping what we have.

[nickstenning]

Just in case it's not clear, this isn't me deciding unilaterally to remove this. I discussed it with @judell, who isn't happy shipping what we have.