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'.
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
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.
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):
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.
Ah, okay, current arbital deletion already corresponds to this. Good :). (tests), deleting a page in my group made it inaccessible? I can still access the edit screen/reverse if I know the url though. Maybe having deleted pages show a "this page has been deleted, click here to view the edit history" thing would be better?
Also, if all deletion is soft/reversible by everyone, there's no tool to actually remove things from public view, which may be problematic on rare occasions where making it hard to find is not enough (e.g. illegal content), so eventually there would need to be another layer of deletion which renders it visible only to staff. Probably low priority though.
People can already delete their pages on Arbital. You can bring it back by reverting to a previous edit.
We won't make the page appear blank, because there is no reason to reuse an existing id. You can remove the alias from the old page, create a new page, and assign it the alias.
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.
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?
nods, seems pretty similar to MW's CategoryTree? It's good to have, but it could be much more awesome with attention. Especially if tags cause complex trees, it'll allow smoother content discovery with a more optimized setup.
What's the plan for navigation back up the tree? If the top level tags are always exposed things could get very messy (a bunch of layers, and possibly multiple paths back to them, since unlike a file tree each page can have multiple direct ancestors, unless you only include parent/child relations.), and if not you need another way to step back up.
Edit: I asked about the name of the UI I'm talking about on StackExchange. Some possibly helpful comments there.
Edit2: It seems like it's allowing multiple parents that breaks the normal navigation things. Maybe some hybrid would work.. I'll do a mockup of what I'm imagining at some point. The UX people are not familiar with it. Probably complex+no third party drop in, so probably quite far down the wish list, even if it would be awesome.
Funny enough we had something like that in an older version. We'll definitely bring it back. One way it would be super useful is for refactoring tags & parents.
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.
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.
I, for one, am fine with the current, simple comment system. It's close to what's on Stack Overflow (which also has two layers with extra constraints on replies to comments), which seems to work fine.
I'm skeptical of infinite nesting. It does help in some cases, but disrupts the vast bulk of threads visually and adds a complicating decision to replying. Longer chains with branching are horrible to navigate, and the replies get shifted ever rightwards. This puts a limit on the effective number of replies (even if you subthread it like lesswrong, having to click through is clunky inconvenience), which is much worse than the problems caused by lack of nesting imo.
You can gain much of the advantage of infinite nesting without any of the major costs by creating a "reply in new thread" option for those cases where it really is important to reply to different parts of a post separately, which creates a post linking to the new thread.
Having strong norms of "one topic per top level comment" (possibly mod-action splitting posts for a while, or having a way to give feedback suggesting it easily) would also reduce the need for heavy nesting, and organize discussion more neatly.
Thanks for the feedback. :)
Yeah, there is a lot left to do on the comment side. That's going to be the next area of improvement.
Yeah, you can like your own comment and pages. The reason is that indeed it is a valuable signal. We are going to end up treating likes somewhat differently than most platforms, so this will come in handy.
lol I can like my own comments. Dunno if that should be fixed or not. A user liking their own comment.. it is is information, which might mean something, though one gets the sense that it's usually going to be dishonest information, that doesn't mean what it appears to mean, which probably makes it an anti-pattern
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?
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 Em four 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.
After discussion, allowing a few pre-defined classes and adding table to the whitelist would capture most of the value of full styleable tables (though in the long term styling would be good, either as an extension of this editor or in our own editor).
Classes should give the ability to create something akin to this and this (preferably including both optional sorting and colored backgrounds with a decent collection of available colors), as well as handling simple infoboxes and image containers (a border and slightly tinted background is fine).
I think it's inevitable that we'll need to build our own editor. I'm not at all sure what that will look like yet, and it'll be a huge undertaking, so for now we are stuck with hacking on top of the current editor.
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.
(This part was written first, but the conclusion/outline seemed more valuable than this background thought) I realized why I'm struggling to come up with good ideas for this one: I only really know much about MW's system.
So, did a bit of research into how it's done on other software. They mostly do similar things, and all major wiki software includes some form of templating, but many have different takes on the core idea (e.g. Cofluence is clearly optimized for non-technical users).
Misc thoughts/findings:
Some wikis have non-global templates.
This seems mostly bad. It would allow short domain specific templates, but having the same text display differently seems like a much worse problem
However, it does bring up the question of how to handle templates between subdomains. Probably allow templates from the main arbital repository to be called from private groups, with slightly different syntax (a ! at the start of the name or something)?
Templates are generally stored separately from pages, but often use the same edit interface.
Most wikis allow multiple layers of transclusion.
This can be very useful for maintaining consistency and ease of template creation, but can also lead to unreadable mazes with 8 layers of template which are inefficient to unpack every time a page is served (MW gets around this through extensive caching).
*
There are several different attempts to make templates more user friendly. The main approach is having a flexible form which allows you to input variables, rather than doing it directly as text.
The variables are usually stored in page text, but they could be stored separately.
In text has the advantage of being editable from the normal edit window, but the disadvantage of having a lot of scary visual clutter at the top of edit windows (a lot of users would get put off by this, for example).
Separately has the advantage of having structured information stored in a form which invites complex searching and analysis, and would work by having templates show up differently in the edit window, with the option to click on them to edit their variables via popup form.
I suspect separate storage is significantly better, but requires extra UI work. Wikimedia's use of Wikidata rather than adoption of SMW and their creation of the TemplateData extension both feel like attempts at approximating the advantages of it, patching over a bad design decision which got baked in.
Displaying template parameters in the text scales badly, is not a natural way of entering information, and generally scares away editors. My current best idea for solving this is copying TemplateData's method (click on the infobox template, it lets you open a form to edit template parameters), but have the template call code highlighted in source editor (), and make clicking that bring up a form to edit the parameters.
A bonus is storing the parameters separately makes it much easier to reuse the structured information.
What features does it need to be handle the major use cases
PAGENAME, PARENTS, CHILDREN, DOMAIN, some time/date ones?
Would be good:
Multi layer transclusion
Not certain about this, but not having it probably causes more problems than having it.
More flexible scripting for complex templates
The only really good implementation I know of is Scribunto
MW got by with parser functions for a while. It worked, but it was ugly and terrible. Maybe a with some thought a parser function like solution could be made less bad.
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).
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 patrolsystems, 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.
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'.
Feedback system / incentivising valuable criticism and productive response
Partly inspired by Brienne's post (and Eliezer's reply/the thread following it).
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:
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:
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).
Agreed. Blogging will be one of the major areas we focus on after the announcement. (He keeps saying.) Jessica Greenwalt.
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):
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.
Yeah, that's a bug.
Yes, hard delete will be a thing too.
Ah, okay, current arbital deletion already corresponds to this. Good :). (tests), deleting a page in my group made it inaccessible? I can still access the edit screen/reverse if I know the url though. Maybe having deleted pages show a "this page has been deleted, click here to view the edit history" thing would be better?
Also, if all deletion is soft/reversible by everyone, there's no tool to actually remove things from public view, which may be problematic on rare occasions where making it hard to find is not enough (e.g. illegal content), so eventually there would need to be another layer of deletion which renders it visible only to staff. Probably low priority though.
People can already delete their pages on Arbital. You can bring it back by reverting to a previous edit.
We won't make the page appear blank, because there is no reason to reuse an existing id. You can remove the alias from the old page, create a new page, and assign it the alias.
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.
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:
Sounds good, I'd love to see a mockup. Eliezer Yudkowsky, might have ideas about this.
nods, seems pretty similar to MW's CategoryTree? It's good to have, but it could be much more awesome with attention. Especially if tags cause complex trees, it'll allow smoother content discovery with a more optimized setup.
What's the plan for navigation back up the tree? If the top level tags are always exposed things could get very messy (a bunch of layers, and possibly multiple paths back to them, since unlike a file tree each page can have multiple direct ancestors, unless you only include parent/child relations.), and if not you need another way to step back up.
Edit: I asked about the name of the UI I'm talking about on StackExchange. Some possibly helpful comments there.
Edit2: It seems like it's allowing multiple parents that breaks the normal navigation things. Maybe some hybrid would work.. I'll do a mockup of what I'm imagining at some point. The UX people are not familiar with it. Probably complex+no third party drop in, so probably quite far down the wish list, even if it would be awesome.
It's super standard explorer type look (but obviously much larger).
Cool, show me the designs/plans when that moves near the top of your list for feedback?
Funny enough we had something like that in an older version. We'll definitely bring it back. One way it would be super useful is for refactoring tags & parents.
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.
Yes! That's going to be the major priority in the upcoming months.
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.
I, for one, am fine with the current, simple comment system. It's close to what's on Stack Overflow (which also has two layers with extra constraints on replies to comments), which seems to work fine.
I'm skeptical of infinite nesting. It does help in some cases, but disrupts the vast bulk of threads visually and adds a complicating decision to replying. Longer chains with branching are horrible to navigate, and the replies get shifted ever rightwards. This puts a limit on the effective number of replies (even if you subthread it like lesswrong, having to click through is clunky inconvenience), which is much worse than the problems caused by lack of nesting imo.
You can gain much of the advantage of infinite nesting without any of the major costs by creating a "reply in new thread" option for those cases where it really is important to reply to different parts of a post separately, which creates a post linking to the new thread.
Having strong norms of "one topic per top level comment" (possibly mod-action splitting posts for a while, or having a way to give feedback suggesting it easily) would also reduce the need for heavy nesting, and organize discussion more neatly.
Thanks for the feedback. :)
Yeah, there is a lot left to do on the comment side. That's going to be the next area of improvement.
Yeah, you can like your own comment and pages. The reason is that indeed it is a valuable signal. We are going to end up treating likes somewhat differently than most platforms, so this will come in handy.
lol I can like my own comments. Dunno if that should be fixed or not. A user liking their own comment.. it is is information, which might mean something, though one gets the sense that it's usually going to be dishonest information, that doesn't mean what it appears to mean, which probably makes it an anti-pattern
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?
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 Em four 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.
After discussion, allowing a few pre-defined classes and adding table to the whitelist would capture most of the value of full styleable tables (though in the long term styling would be good, either as an extension of this editor or in our own editor).
Classes should give the ability to create something akin to this and this (preferably including both optional sorting and colored backgrounds with a decent collection of available colors), as well as handling simple infoboxes and image containers (a border and slightly tinted background is fine).
I think it's inevitable that we'll need to build our own editor. I'm not at all sure what that will look like yet, and it'll be a huge undertaking, so for now we are stuck with hacking on top of the current editor.
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)
(This part was written first, but the conclusion/outline seemed more valuable than this background thought) I realized why I'm struggling to come up with good ideas for this one: I only really know much about MW's system.
So, did a bit of research into how it's done on other software. They mostly do similar things, and all major wiki software includes some form of templating, but many have different takes on the core idea (e.g. Cofluence is clearly optimized for non-technical users).
Misc thoughts/findings:
Some other links:
Seems like there's main two parts:
How do we make it intuitive for editors
Displaying template parameters in the text scales badly, is not a natural way of entering information, and generally scares away editors. My current best idea for solving this is copying TemplateData's method (click on the infobox template, it lets you open a form to edit template parameters), but have the template call code highlighted in source editor (
), and make clicking that bring up a form to edit the parameters.
A bonus is storing the parameters separately makes it much easier to reuse the structured information.
What features does it need to be handle the major use cases
Essential:
Important
Would be good:
Wishlist:
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).
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: