[m-dev.] New wiki

Paul Bone paul at bone.id.au
Sun Mar 15 00:36:32 AEDT 2015

On Sun, Mar 15, 2015 at 12:16:44AM +1100, Zoltan Somogyi wrote:
> On Sat, 14 Mar 2015 23:24:42 +1100, Paul Bone <paul at bone.id.au> wrote:
> > The wiki is inteded for:
> >     + A better / more complete FAQ
> >     + Example code that demonstrates how to use some features
> >     + Guides for common tasks
> >     + More detailed description of Mercury features, although these should
> >       be documented properly a more guided style can suplement the reference
> >       manual style.
> Why can't this information be included in our current web pages?

I've wanted to set up a wiki for some time.  The main reason is to encourage
contributions of this kind of information from people outside the core team.
I beleive that this will be especially useful as Mercury users are the best
people to know what kinds of information will be most important to other
Mercury users.

> > I also suggest moving the information that's currently in compiler/notes/*,
> > other developer documentation, the FAQ and possibly the discussions
> > repsitory to the Wiki.
> I would be strongly against moving any information that is currently
> under version control into a wiki that does not have any version control.

The Wiki has version control.  I'm not sure if it's a good idea to expose
it, or how exactly to expose it.  That said it's versioned separately to the
current implementation.  Therefore some things in compiler/notes/* may be
better where they are.

> I also think it it a very bad idea to a use a Google or Yahoo id as the
> sign-in mechanism, as in the current wiki setup. Having grown up under
> communism, I am allergic to any attempt at universal surveillance.
> Since I don't wish to live a stone-age life in the middle of a desert, I may
> not be able to avoid the NSA, but I would like to at least minimize the number
> of organizations that can sell my personal information to bad people,
> a category that I consider to include advertisers and most politicians
> as well as criminals.

That's fair enough.  I should be able to disable that but I haven't tried.
If you click "other" on the sign-in page you should be able to register with
a normal username and password pair.

> 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.

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.

> And for that, we don't strictly
> need a wiki; our usual review and pull-request mechanisms would do.
> The only thing a wiki can do is make it somewhat easier for external
> contributors. That is a worthy objective, but in my opinion less important
> than having this information under version control. Does this wiki
> provide some form of version control, such as a record of past versions?

ikiwiki can use a number of different VCSen, I configured it for git and
I'm currently wondering how I can export/share the repository so that if we
modify it and push our changes, they'll be automatically applied to the

There's also a RecentChanges button on the website that allows you to see a
list of recent modifications.


Paul Bone

More information about the developers mailing list