Veritula – Meta
#3074·Dennis HackethalOP, 5 months agoThey could keep read-only access to the discussion but can’t add new ideas or change existing ideas.
Maybe you remove them because you don’t even want them to be able to see anything.
#3073·Dennis HackethalOP, 5 months agoThey could keep access to their own ideas but not see others’.
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.
#3071·Dennis HackethalOP, 5 months agoWhat happens if you add a user to a private discussion, they submit a bunch of ideas, and then you remove them?
Permanent access: once added, you can’t remove them.
#3071·Dennis HackethalOP, 5 months agoWhat happens if you add a user to a private discussion, they submit a bunch of ideas, and then you remove them?
They could keep read-only access to the discussion but can’t add new ideas or change existing ideas.
#3071·Dennis HackethalOP, 5 months agoWhat happens if you add a user to a private discussion, they submit a bunch of ideas, and then you remove them?
They could keep access to their own ideas but not see others’.
#3071·Dennis HackethalOP, 5 months agoWhat happens if you add a user to a private discussion, they submit a bunch of ideas, and then you remove them?
There could be hard cutoff: they lose access to everything, including their own ideas in that discussion.
#2728·Dennis HackethalOP revised 6 months agoFeature idea: private discussions only the creator and invited people can see. This could be a paid feature; $2 per discussion, say.
What happens if you add a user to a private discussion, they submit a bunch of ideas, and then you remove them?
#2669·Dennis HackethalOP, 6 months agoFeature idea: pay people to address criticisms (either revise an idea and check off criticisms or counter-criticize).
Could this feature be unified with #2811 somehow?
#2811·Dennis HackethalOP revised 6 months agoFeature idea: pay people to criticize your idea.
You submit an idea with a ‘criticism bounty’ of ten bucks per criticism received, say.
The amount should be arbitrarily customizable.
There could then be a page for bounties at /bounties. And a page listing a user’s bounties at /:username/bounties.
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 hold on to problematic ideas.
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.
#3002·Dennis HackethalOP revised 6 months agoThe displayed criticism count for a filtered parent can differ from the number of displayed criticisms.
#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 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.
#2008·Dennis HackethalOP revised 7 months agoAny filtered idea should always display only the count of shown criticisms.
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 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.
#3005·Dennis HackethalOP revised 6 months agoI 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.
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.
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.
Bug when cycling through ‘filtered’ revisions: on page render, no matter how many children/criticisms a parent of the highlighted idea has, only the highlighted idea is shown – that’s fine so far – but the displayed criticism count may be higher if there are criticisms that are not being shown. So there’s a mismatch.
The displayed criticism count for a filtered parent can differ from the number of displayed criticisms.
#2999·Dennis HackethalOP revised 6 months agoFor any filtered parent, the criticism badge could be shown without a count.
But users are expecting a count.