[m-dev.] New wiki

[Paul Bone]

On Sun, Mar 15, 2015 at 01:01:39AM +1100, Zoltan Somogyi wrote:
> 
> On Sun, 15 Mar 2015 00:36:32 +1100, Paul Bone <paul at bone.id.au> wrote:
> > The Wiki has version control.  I'm not sure if it's a good idea to expose
> > it, or how exactly to expose it.
> 
> What I think would be ideal is if every edit on the wiki automatically generated
> a diff and a pull request on that diff. We could then approve the ones we like
> and ignore the ones that represent vandalism or someone trying add a link
> farm in an effort to boost the pagerank of some site selling Cialis. Only once
> the diff was approved and merged should the change be visible on the wiki
> to anyone but its creator.

I can see how that would help avoid vandalism.  However I'm concerned that
it would also discourage people from editing.  If a user has to wait for
approval to see their edits (roughly 24 hours given our resources) then the
cannot make further edits until the next day.  By that time they may have
some other obligations or merely be distracted.

I'm also concerned that people are less likely to contribute if they're
aware of a review process.  Whereas they won't mind so much if someone edits
their contribution after the fact.

The main goal of a wiki is to encourage contributions.  I am also concerned
about vandalism and in particular if it occurs significantly the amount of
time required to clean it up and moderate it (and any other forms of abuse,
that's not why I contribute to Mercury).  However I'm not sure that
vandalism will be a significant problem, and when prevention of vandalism is
counter to encouraging contributions, I'd prefer to encourage contributions.

I'd like to proceed and see if vandalism becomes a problem in the future,
and if it does then review how we administer the wiki.

> > That said it's versioned separately to the
> > current implementation.  Therefore some things in compiler/notes/* may be
> > better where they are.
> 
> Everything in compiler/notes is, or at least supposed to be, information
> for developers, not users. I don't think ANY of it belongs on a publicly
> editable wiki.

Okay.  Some of these documents are visible online but we could probably do
more to make the others more visible.  That may be separate to a wiki.

I'd still like to encourage our users to create new documents on these
topics, even if compiler/notes is only writable by developers.

> > > I also don't see the point of such an id system. It does not prevent
> > > vandalism; all it can do is tell us the user-id of the vandal, which we
> > > cannot turn into a real-world id, and even if we could, we couldn't do
> > > anything useful with that information. The only way to prevent vandalism
> > > is to have someone trusted (one of us developers, or someone like Matt Giuca)
> > > check all changes before publishing them.
> > 
> > I think that the goal of OpenID is convenience.  It reduces the number of
> > passwords a user needs to remember.  At least I believe that was the
> > intention when it started, nowadays and for particular groups (Google) I
> > don't know.
> 
> You missed my point, which was: Why have any id at all? No id is even more
> convenient for users than open id. By the way, have you had a look at the long
> list of problems with open id on the open id wikipedia page?

A small bar of entry may help with spam (automated vandalism).  There may
also be cases where we want to know who made a particular edit.  If someone
said something that's hard to believe about parallelism, it's more credible
if it's you, me or Peter W.  But that may also be a solution looking for a
problem.

I've now had a look at the Wikipedia page for OpenID.  I was aware of some
of these issues but not aware of others.

> > If spam becomes a problem we can ask users to contact us and we can sign
> > them up on their behalf.  One thing about this software that annoyed me is
> > that when someone registers it doesn't check if their e-mail address is
> > valid by having them retrieve a code or such from their e-mail.  I searched
> > online but the only reference I found to this missing feature for the
> > ikiwiki software was the author saying that despite the missing feature, he
> > has very little spam on his own wikis.
> 
> If he said "very little", but did not say "none", that is actually a point AGAINST him.
> And has he checked whether the white space on his wikis is actually full of
> "Buy Cialis from Bob's internet pharmacy" written in a white font on a white background?

Hopefully by inspecting the history he would notice this.

If "very little" vandalism is one or two events per year than it's easy to
deal with manually and keep things open.  If it's one or two per day then
something else needs to be done.  So even if there is some abuse, the amount
of abuse may affect how we choose to address it, especially when it's at the
cost of other things such as encouraging contributions.  To that end I'd
also consider making the wiki open, you don't need an account to contribute.

> > There's also a RecentChanges button on the website that allows you to see a
> > list of recent modifications.
> 
> Unless that button's functionality is available to a script, that doesn't help us
> very much.

Is this related to fighting vandalism?  If I know what you want to achieve
then I can more easily find the right solution.  It may be setting up a
script (or cgi script) that runs "git log" or publishing the repository.

Thanks.

-- 
Paul Bone