Veritula – Meta
#3951·Dennis HackethalOP, 18 days agoDone as of
cc1ab95.Ruby example:
rubydef criticized? ideapending_criticisms(idea).any?enddef pending_criticisms ideacriticisms(idea).filter { |c| pending_criticisms(c).none? }enddef criticisms ideachildren(idea).filter(&:criticism?)endJS example (h/t ChatGPT):
javascriptfunction criticized(idea) {return pendingCriticisms(idea).length > 0;}function pendingCriticisms(idea) {return criticisms(idea).filter(c => pendingCriticisms(c).length === 0);}function criticisms(idea) {return children(idea).filter(c => c.isCriticism);}
There needs to be more of a padding on the right, inside the code block.
The diff view can’t handle the removal/replacement of entire code blocks yet. The removed block looks broken, the new block doesn’t show at all.
The diff view can’t handle the removal/replacement of entire code blocks yet. The removed block looks broken, the new block doesn’t show at all. See activity 3207 in dev.
#3951·Dennis HackethalOP, 18 days agoDone as of
cc1ab95.Ruby example:
rubydef criticized? ideapending_criticisms(idea).any?enddef pending_criticisms ideacriticisms(idea).filter { |c| pending_criticisms(c).none? }enddef criticisms ideachildren(idea).filter(&:criticism?)endJS example (h/t ChatGPT):
javascriptfunction criticized(idea) {return pendingCriticisms(idea).length > 0;}function pendingCriticisms(idea) {return criticisms(idea).filter(c => pendingCriticisms(c).length === 0);}function criticisms(idea) {return children(idea).filter(c => c.isCriticism);}
Would be nice if the copy button was sticky-top so that it scrolled with the user.
#4016·Dennis HackethalOP, 13 days agoThere’s an issue with horizontal scroll for overflowing code blocks in the activity feed on mobile. Can’t scroll all the way to the right.
Fixed as of e49cd8d.
#3951·Dennis HackethalOP, 18 days agoDone as of
cc1ab95.Ruby example:
rubydef criticized? ideapending_criticisms(idea).any?enddef pending_criticisms ideacriticisms(idea).filter { |c| pending_criticisms(c).none? }enddef criticisms ideachildren(idea).filter(&:criticism?)endJS example (h/t ChatGPT):
javascriptfunction criticized(idea) {return pendingCriticisms(idea).length > 0;}function pendingCriticisms(idea) {return criticisms(idea).filter(c => pendingCriticisms(c).length === 0);}function criticisms(idea) {return children(idea).filter(c => c.isCriticism);}
There’s an issue with horizontal scroll for overflowing code blocks in the activity feed on mobile. Can’t scroll all the way to the right.
#1867·Dennis HackethalOP revised 5 months agoThe red ‘Criticized’ label could be a link leading to a filtered version of
ideas#show.
Yeah or see #2628.
#2886·Benjamin Davies, 3 months agoI am currently unable to zoom out to the full width when accessing Veritula on mobile.
Give this another shot. Should be fixed as of 6c7e74b.
For very deeply nested discussions, you may still need to scroll sideways to see some ideas. But you should now be able to zoom out far enough to always fit any idea into the viewport.
#3951·Dennis HackethalOP, 18 days agoDone as of
cc1ab95.Ruby example:
rubydef criticized? ideapending_criticisms(idea).any?enddef pending_criticisms ideacriticisms(idea).filter { |c| pending_criticisms(c).none? }enddef criticisms ideachildren(idea).filter(&:criticism?)endJS example (h/t ChatGPT):
javascriptfunction criticized(idea) {return pendingCriticisms(idea).length > 0;}function pendingCriticisms(idea) {return criticisms(idea).filter(c => pendingCriticisms(c).length === 0);}function criticisms(idea) {return children(idea).filter(c => c.isCriticism);}
There’s a small issue related to previewing changes in code blocks: even when there are no changes yet, if the code overflows horizontally, the scroll shadow is shown through DOM manipulation, which in turn triggers the diffing library into thinking the user made a change.
So then the same code block is shown without any changes, under the ‘Changes’ tab, which is confusing. It should still just say ‘No changes’.
#3951·Dennis HackethalOP, 18 days agoDone as of
cc1ab95.Ruby example:
rubydef criticized? ideapending_criticisms(idea).any?enddef pending_criticisms ideacriticisms(idea).filter { |c| pending_criticisms(c).none? }enddef criticisms ideachildren(idea).filter(&:criticism?)endJS example (h/t ChatGPT):
javascriptfunction criticized(idea) {return pendingCriticisms(idea).length > 0;}function pendingCriticisms(idea) {return criticisms(idea).filter(c => pendingCriticisms(c).length === 0);}function criticisms(idea) {return children(idea).filter(c => c.isCriticism);}
The diff view can’t handle the removal/replacement of entire code blocks yet. The removed block looks broken, the new block doesn’t show at all.
#3986·Benjamin Davies, 13 days agoBounties should be clear about what currency they are being paid out in.
Valid. As of 7af3c7b, the site uses ‘USD’ throughout.
#3107·Dennis HackethalOP, 3 months agoPreview links of discussions should show the name of the discussion being linked.
See eg https://x.com/agentofapollo/status/1991252721618547023
h/t @benjamin-davies
I implemented this a while back.
X caches link previews, so old previews remain the same. But new previews feature the discussion title, see eg https://www.opengraph.xyz/url/https%3A%2F%2Fveritula.com%2Fdiscussions%2Fcriticisms-of-zcash.
Feature idea: pay people to criticize your idea.
You start a ‘criticism bounty’ of 100 bucks, say, which is prorated among eligible critics after some deadline.
The amount should be arbitrarily customizable (while covering transaction costs). Minimum of $5.
There could then be a page for bounties at /bounties. And a page listing a user’s bounties at /:username/bounties.
When starting a bounty, the user indicates terms such as what kinds of criticism they want. This way, they avoid having to pay people pointing out typos, say.
Anyone can start a bounty on any idea. There can only be one bounty per idea at a time.
To ensure a criticism is worthy of the bounty, the initiator gets a grace period of 24 hours at the end to review pending criticisms. Inaction automatically awards the bounty to all pending criticisms at the end of the grace period.
Feature idea: pay people to criticize an idea.
You start a ‘criticism bounty’ of 100 bucks, say, which is prorated among eligible critics after some deadline.
The amount should be arbitrarily customizable (while covering transaction costs). Minimum of $5.
There could then be a page for bounties at /bounties. And a page listing a user’s bounties at /:username/bounties.
When starting a bounty, the user indicates terms such as what kinds of criticism they want. This way, they avoid having to pay people pointing out typos, say.
Anyone can start a bounty on any idea. There can only be one bounty per idea at a time.
To ensure a criticism is worthy of the bounty, the initiator gets a grace period of 24 hours at the end to review pending criticisms. Inaction automatically awards the bounty to all pending criticisms at the end of the grace period.
Feature idea: pay people to criticize your idea.
You start a ‘criticism bounty’ of ten bucks, say, per pending criticism received by some deadline.
The amount should be arbitrarily customizable (while covering transaction costs). The user also indicates a ceiling for the maximum amount they are willing to spend.
There could then be a page for bounties at /bounties. And a page listing a user’s bounties at /:username/bounties.
When starting a bounty, the user indicates terms such as what kinds of criticism they want. This way, they avoid having to pay people pointing out typos, say.
Anyone can start a bounty on any idea. There can only be one bounty per idea at a time.
To ensure a criticism is worthy of the bounty, the initiator gets a grace period of 24 hours at the end to review pending criticisms. They may even award a bounty to problematic criticisms, at their discretion. Inaction automatically awards the bounty to all pending criticisms at the end of the grace period. If doing so would exceed the ceiling, more recent criticisms do not get the bounty.
Feature idea: pay people to criticize your idea.
You start a ‘criticism bounty’ of 100 bucks, say, which is prorated among eligible critics after some deadline.
The amount should be arbitrarily customizable (while covering transaction costs). Minimum of $5.
There could then be a page for bounties at /bounties. And a page listing a user’s bounties at /:username/bounties.
When starting a bounty, the user indicates terms such as what kinds of criticism they want. This way, they avoid having to pay people pointing out typos, say.
Anyone can start a bounty on any idea. There can only be one bounty per idea at a time.
To ensure a criticism is worthy of the bounty, the initiator gets a grace period of 24 hours at the end to review pending criticisms. Inaction automatically awards the bounty to all pending criticisms at the end of the grace period.
#3912·Dennis HackethalOP, 22 days agoBeen trying a slight modification of bounties in prod for a couple of weeks or so. Working well so far.
@dirk-meulenbelt recently offered to chip in for a bounty I want to run. That got me thinking: multiple people should be able to fund bounties.
This is now a feature, see the ‘Funding’ section of a bounty.
I notice that when I amend a criticism I have made, I’m not able to see what I am criticising. It would be good if the edit screen showed the comment I am disagreeing with similar to how it does when I first go to write a criticism.
When I revise a criticism, I can’t see what it criticises. The edit screen should show the parent idea, similar to when I write a new criticism.
#2717·Dennis HackethalOP revised 3 months agoFeature to collapse all criticized ideas of a discussion? Useful for todo lists.
Archiving covers this.
Bounties should be clear about what currency they are being paid out in.
There’s still an issue on ideas#show. When an idea has nothing but a code block, there’s too much of a margin at the bottom, between the block and the border of the highlight.
When an idea has nothing but a code block, there’s too much of a margin at the bottom, between the block and the border of the highlight.
#3953·Dennis HackethalOP, 18 days agoThere’s still an issue on ideas#show. When an idea has nothing but a code block, there’s too much of a margin at the bottom, between the block and the border of the highlight.
This issue didn’t only occur on ideas#show.