Arbital community input

We want to hear what readers and editors have to say! Many great suggestions and future features have come from the community. This is the place for you to speak your mind about what you want to see from Arbital. Anything goes: feature requests, policy suggestions, UI changes, strategy advice, etc…

Recommended use: create a comment or child page.

Another way to submit feedback is privately through the Feedback button in the Quick Menu, or to visit #features on the Arbital Slack.

Comments

Eric Bruylant

Recent Changes / Edit Review system

On traditional wikis the recent changes page is a hub for contributors, often the first visit of the day for an editor checking what's new, or a potential editor checking the pulse/health of a wiki they may get involved in. Alongside it are the patrol systems, essentially checking over various changes which may require attention, and attempting to filter out vandalism.

For arbital to be vandal-resistant, we will need something which fulfils the same functions, most importantly making sure damaging edits don't slip under the radar. Additionally I suspect their systems could be dramatically improved upon. The main changes which come to mind right now are:

Making it easy/natural to give feedback and suggestions to editors, rather than just accepting or rejecting their changes. Social reinforcement is super-important for building a healthy and productive community. Users on WP created barnstars for this, and later it was deemed important enough that thanks were added on, but in the patrol process as an easy to do action seems much more useful place for it if we're designing it from scratch rather than hacking things onto a massive site.
Making it easy to filter recent changes by domain and maybe other more fine-grained things.
Having the review group feel like a team with internal social reinforcement (official private slack channels?) and achievements for doing lots of high quality patrolling. Making it an opt-in usergroup (possibly with a karma requirement) where you're assigned a mentor to help you learn how to handle tricky cases may be a good way of doing this.
(less certain) Having reviewed/not reviewed be less binary, instead allow multiple people to perform the patrol action on an edit. By default display only unreviewed edits, but allow users to search for, say, edits which changed more than 10 lines which only have one review.

Eric Bruylant

Citations

Making citations easy to create and maintain will cause more people to use them. Arbital may be less citation-centric than WP, but they're still very valuable. MediaWiki's system is the only one I know much about and works pretty well, but there are other approaches (blog post on markdown citations).

Eric Bruylant

Transclusion / Template system

Templates and Scribunto power most of the strucured information across Wikimedia (exception: Wikidata), most notably the infoboxes, links to related pages, and notice templates, but also a huge number of other specific functions. They are an incredibly flexible tool which makes it possible for users to create and maintain things that would never be done if each page had to be updated by hand, and hides complexity from less technical users who can easily include them in pages by copying existing examples.

This is not an easy feature to get right, but something which fills their function is essential to attract editors from any existing mediawiki wiki.

MW started off with basic transclusion+parameters, then added various parser functions in a way which turned out to be ugly and inefficient to the point where they were forced to add (limited) lua scripting.

(WIP, will come back to this with more thoughts)

Eric Bruylant

Allow (slightly) more HTML

This engine does allow a subset of HTML, but it's extremely limited. This makes some sense for a QA site, but not being able to use either tables or divs will be really annoying for a blog/wiki, and rules out user-created WP style infoboxes, sortable tables of data, and a lot of other things. I imagine you'd need to alter the whitelist to allow the tags (and certain safe attributes?), perhaps ordinary title would check implementation/advise? And for sortable tables you'd need to pick some table sorting .js. Alternatively there are extensions of markdown which allow tables, but that seems likely to be more complex to implement.

There are other tags which would be nice to have access to such as

and , and having audio/video support would be very good for the long term, but these seem less vital to me than something we can use to make tables.

Eric Bruylant

Posted date on blog pages

It's often important to know when a blog post was made. The originally posted date should be shown somewhere, possibly next to Owner, possibly under the title?

M Yass

Tree-Structured Comment Sections

Currently the comment system seems to be limited to one level of indentation. Although one level of indentation is very good, full nesting would be better. I guess it might be argued that full nesting wont be needed here, but I wouldn't bet on that. Full threading has its own implementation challenges though. Eventually comments will hit the right side of the page and become unreasonably compressed. I can think of two solutions:

The more straightforward solution: render comments at the deepest displayable depth with their subthreads hidden, then serve comment permalinks as separate pages, where the subject comment is rendered as a root thread. To read replies to comments at the depth limit, the user goes to their parent's page.
Something I havn't seen done: Comments just keep going right, but they don't compress. Comment views will have to be horizontally scrollable.

If you were going to increase the depth limit, you'd probably want to rethink the gratuitous consumption of whitespace that's going on in the current style. I'm more partial to the way reddit's material design themes tend to do things https://i.imgur.com/6dHto8n.png . Root threads may be in separate cards, but nested comments are rendered as parts of the whole with implied boundaries.

Eric Bruylant

Uncategorized Pages Page

This, combined with a good way of navigating tagged/categorized content, would make Arbital's content more discoverable. Importantly, it would make it easier to keep track of pages which may otherwise fall through the cracks and not get noticed/interlinked with other content/correctly categorized.

Eric Bruylant

Navigation for the tree of information

Implementing something like MediaWiki's CategoryTree, but making it a bit more well designed/intuitive/flexible would give a powerful tool for making Arbital's content easy to explore which would be maintained mostly automatically by tags and subtags.

Brainstorm for improvements:

An easy way to move up, as well as down, the category system is important.
Including clickbait or summary would make it much more attractive.
Adjustable filters would be great. Filter by quality, switch between levels of expertise required? Include/exclude blog posts?
Including both tagging and parent/child relationship information in the tree.
Alpha Centauri tech tree style navigation? With extra layers exposed if low branching factor, fading away on the left and right? It's pretty, intuitive, and gives room for the summary, but may not scale well if there is a high branching factor. Clicking on a page in the tree recenters the tree on that page, while loading it below the browsing system.
Or this kind of column structure? Less flexible and neat, but more familiar and easier to find 3rd party implementations?

Eric Bruylant

Import from Mediawiki XML

This would make moving other wikis here significantly easier. It's probably best to do the EA Wiki by hand anyway, so not urgent, but it will be required for bringing larger wikis on board.

Eric Bruylant

Pure Wiki Deletion (page blanking creates redlinks)

Handling deletion on wikis is delicate, since it renders user generated content hidden from the user and the world. Wikipedia handles this poorly, but their users did come up with a beautiful solution (which never got implemented):

Links to blank articles will appear the same as links to non-existent articles

This removes a large part of the need for administrator intervention (providing some barrier to detached bureaucracies forming, and giving editors the power to remove their own content from view without requesting admin intervention), while making deletion transparent, open, and reversible. The normal deletion mechanism would stay, but only be used for illegal or banned content. The page linked has detailed reasoning about pros and cons.

Eric Bruylant

Blog header

Blog pages kind of feel like just normal pages. Having a header which is placed either above page title (and usually large) or below replacing the parent line (and small) would go a good way towards fixing this. Maybe having both available would be best? The header could be defined on the main blog page in a similar way to summaries.

Mockup (includes post authorship), Mockup (text), Mockup (banner).

Eric Bruylant

Feedback system / incentivising valuable criticism and productive response

Partly inspired by Brienne's post (and Eliezer's reply/the thread following it).

The trick to preventing flame wars when stating criticisms publicly is to always provide an alternative method for regaining status.

Or you could just send the message via PM. To first order and with obvious exceptions, you can classify Bad/troll/statusseeker anyone publicly pointing out something in a push-downy way who also publicly claims to only be concerned about you, and classify 'Good' anyone who points out exactly the same thing in a private message.

Some form of negative feedback seems necessary, but most I've seen arguably do significant harm, while not appearing well-optimized for improving users conduct.

Major classes of negative feedback:

Public easy/open (LessWrong, Reddit)
Public with disincentive/barrier (StackOverflow has both a karma threshold for downvotes and a karma penalty)
Public open/free-form feedback (Wikipedia comments on user talk pages)
Private feedback to algorithms (Facebook hiding posts)
Private to staff (most forums, facebook)

All fail to offer a good way of regaining status, and the only options which are private require valuable staff-time to evaluate reports.

We can do better, I think. My first draft proposal is:

Allow feedback on any edit or comment. This is non-public, but viewable by users with sufficiently high karma. Give the user the option to reply (with reply also viewable by high karma users), and mark the feedback as valuable or not valuable. Reward users who give feedback judged as valuable with karma (with limits on how much you get per person to avoid trading feedback). Possibly make feedback marked as valuable (optionally?) viewable to more users, more transparency would help good norms be shared, and it needing to be approved/replied to first means there's less feeling of attack/status hit than otherwise.

This way there's:

No "drive-by-downvoting", only actionable feedback
Little feeling of taking a status hit
Direct, obvious, way to regain status from valid criticism (tag the feedback as useful and reply with what you're going to try to do to improve)
Incentives for users to both optimize for useful feedback, and to read any feedback in a way they can extract useful info from
All feedback is viewable to high-karma users, so serial troublemakers can be identified and harmful patterns of behavior can be confronted
Sorting by users with lots of un-replied to (or rejected) feedback gives a quick way of locating possible points of intervention in the community
Abuse of the feedback system is not significantly harmful to the target's reputation
Algorithms can have access to # negative feedback on a comment/edit/article, and can ignore negative feedback from people who send feedback which is judged unhelpful by too many recipients

Caleb Withers

Is there merit (I imagine the main trade-off would be in UX/added complexity) in allowing two responses: one that accounts for others' views and those that don't? When I respond to a claim, I'll often see people whose views I held in higher esteem than my own initial views, and largely adjust towards them. However, if everyone's doing this, there's a missed opportunity to refine the community's underlying world-models by picking up when someone would strongly diverge from consensus in the absence of 'meta-modesty'.