Search Ideas

But that sucks. Maybe someone works hard and submits a bunch of ideas only to lose access to them all.

Maybe you remove them because you don’t even want them to be able to see anything.

There’d probably be a bunch of edge cases with this approach. For example, others would still be able to comment on those ideas, and the comments would have to be hidden from OPs. Which begs the question of how that impacts the displayed criticism count… And so on.

If you later realize that adding someone was a mistake, you should be able to correct that mistake.

Permanent access: once added, you can’t remove them.

They could keep read-only access to the discussion but can’t add new ideas or change existing ideas.

They could keep access to their own ideas but not see others’.

There could be hard cutoff: they lose access to everything, including their own ideas in that discussion.

What happens if you add a user to a private discussion, they submit a bunch of ideas, and then you remove them?

Could this feature be unified with #2811 somehow?

Could this feature be unified with #2669 somehow?

Then people could occasionally check the second tab for ideas they think they can rationally hold but actually can’t. And then they can work on addressing criticisms. A kind of ‘mental housekeeping’ to ensure they never accidentally accept problematic ideas as true.

#3014 fixes this. Implemented as of c3247d5.

For all ideas, the total number of pending criticisms (if any) should always be shown, even if they are not all being rendered. For filtered parents, I could put an asterisk behind the count. On hover, explain that some pending criticisms may be hidden due to filtering.

As with #2098, implementing an accurate count of the number of shown criticisms gets very tricky once the user starts submitting new criticisms on filtered parents.

For filtered parents, I could put an asterisk behind the count. On hover, explain that the total number of pending criticisms may be greater on the unfiltered view.

For filtered parents, I could put an asterisk behind the count. On hover, explain that some pending criticisms may be hidden due to filtering.

For filtered parents, I could put an asterisk behind the count. On hover, explain that the total number of pending criticisms may be greater on the unfiltered view.

Still, the count is valuable in that it shows how many criticisms need to be addressed to restore an idea.

I could get rid of the count everywhere, even on unfiltered views. That would have the added benefit that users wouldn’t prefer one problematic idea over another just because it has fewer pending criticisms.

I could get rid of the count everywhere, even on unfiltered views.

The displayed criticism count for a filtered parent can differ from the number of displayed criticisms.

But users are expecting a count.

For any filtered parent, the criticism badge could be shown without a count.

For any filtered parent, the criticism badge could be shown without any count.