Discussion:
[m-dev.] New wiki
Paul Bone
2015-03-14 12:24:42 UTC
Permalink
Hi,

I've setup a wiki for Mercury.

https://www.mercurylang.org/wiki/

I've just completed the installation and verified that it's working, so
things may change a little bit as I finish configuring it. However if you'd
like to add some content now that'd be great.

I will also be putting a link to it on the main website.

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.

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.
--
Paul Bone
Zoltan Somogyi
2015-03-14 13:16:44 UTC
Permalink
Post by Paul Bone
+ 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?
Post by Paul Bone
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.

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.

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

Zoltan.
Paul Bone
2015-03-14 13:36:32 UTC
Permalink
Post by Zoltan Somogyi
Post by Paul Bone
+ 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.
Post by Zoltan Somogyi
Post by Paul Bone
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.
Post by Zoltan Somogyi
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.
Post by Zoltan Somogyi
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.
Post by Zoltan Somogyi
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
wiki.

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

Thanks.
--
Paul Bone
Sebastan Godelet
2015-03-14 14:36:44 UTC
Permalink
Hi,

On Sun, 15 Mar 2015 00:36:32 +1100
Post by Paul Bone
I've wanted to set up a wiki for some time. The main reason is to
Have you looked at the GitHub wiki which is provided with every
repository?
https://help.github.com/articles/about-github-wikis/
To be honest I haven't really done anything bigger with that,
but it might avoid some concerns raised in this thread,
e.g. like having to create yet another login.
Additionally it can be set-up to prevent vandalism, there is full
control who can actively contribute.
I'm not sure where the wiki data then actually resides,
my best guess is at a branch of the repository, which is the way
GitHub repository/organisation web-pages work.
Not that I think hosting a wiki on its own (i.e. wiki.mercurylang.org)
is a bad thing,
just another thing to handle on a security/maintenance/time basis.

greetings,

Sebastian.
Nick Rudnick
2015-03-14 21:03:22 UTC
Permalink
How about

http://en.wikipedia.org/wiki/Gitit_(software) ??

Contrary to ikiwiki, it's written in Haskell instead of Perl, and I think I
know how to disable ID access requirements. Though a little afraid I did
not exactly understand what Zoltan wants to get, it would be worth a try to
see whether I can make this done, too, with Gitit.

Principally, there should be few limitations to customizing the code. As
said, it's written in Haskell on top of Pandoc, actually one of the most
popular applications
and
Happstack, which is quite powerful (
http://happstack.com/page/view-page-slug/1/happstack).

In case there's interest, I would be happy to assist.

Cheers, Nick
Post by Sebastan Godelet
Hi,
On Sun, 15 Mar 2015 00:36:32 +1100
Post by Paul Bone
I've wanted to set up a wiki for some time. The main reason is to
Have you looked at the GitHub wiki which is provided with every
repository?
https://help.github.com/articles/about-github-wikis/
To be honest I haven't really done anything bigger with that,
but it might avoid some concerns raised in this thread,
e.g. like having to create yet another login.
Additionally it can be set-up to prevent vandalism, there is full
control who can actively contribute.
I'm not sure where the wiki data then actually resides,
my best guess is at a branch of the repository, which is the way
GitHub repository/organisation web-pages work.
Not that I think hosting a wiki on its own (i.e. wiki.mercurylang.org)
is a bad thing,
just another thing to handle on a security/maintenance/time basis.
greetings,
Sebastian.
_______________________________________________
developers mailing list
https://www.mercurylang.org/lists/listinfo/developers
Paul Bone
2015-03-14 22:23:00 UTC
Permalink
Post by Nick Rudnick
How about
http://en.wikipedia.org/wiki/Gitit_(software) ??
Contrary to ikiwiki, it's written in Haskell instead of Perl, and I think I
know how to disable ID access requirements. Though a little afraid I did
not exactly understand what Zoltan wants to get, it would be worth a try to
see whether I can make this done, too, with Gitit.
Principally, there should be few limitations to customizing the code. As
said, it's written in Haskell on top of Pandoc, actually one of the most
popular applications http://youtu.be/6TBpB-BEiIg and
Happstack, which is quite powerful (
http://happstack.com/page/view-page-slug/1/happstack).
In case there's interest, I would be happy to assist.
Hrm, this seems interesting. I'll take a look.

Thanks.
--
Paul Bone
Nick Rudnick
2015-03-14 22:45:41 UTC
Permalink
Happy to know :-)

Feel free to contact me.
Post by Nick Rudnick
Post by Nick Rudnick
How about
http://en.wikipedia.org/wiki/Gitit_(software) ??
Contrary to ikiwiki, it's written in Haskell instead of Perl, and I
think I
Post by Nick Rudnick
know how to disable ID access requirements. Though a little afraid I did
not exactly understand what Zoltan wants to get, it would be worth a try
to
Post by Nick Rudnick
see whether I can make this done, too, with Gitit.
Principally, there should be few limitations to customizing the code. As
said, it's written in Haskell on top of Pandoc, actually one of the most
popular applications http://youtu.be/6TBpB-BEiIg and
Happstack, which is quite powerful (
http://happstack.com/page/view-page-slug/1/happstack).
In case there's interest, I would be happy to assist.
Hrm, this seems interesting. I'll take a look.
Thanks.
--
Paul Bone
Zoltan Somogyi
2015-03-14 14:01:39 UTC
Permalink
Post by Paul Bone
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.
Post by Paul Bone
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.
Post by Paul Bone
Post by Zoltan Somogyi
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?
Post by Paul Bone
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?
Post by Paul Bone
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.

Zoltan.
Paul Bone
2015-03-15 00:13:45 UTC
Permalink
Post by Zoltan Somogyi
Post by Paul Bone
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.
Post by Zoltan Somogyi
Post by Paul Bone
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.
Post by Zoltan Somogyi
Post by Paul Bone
Post by Zoltan Somogyi
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.
Post by Zoltan Somogyi
Post by Paul Bone
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.
Post by Zoltan Somogyi
Post by Paul Bone
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
Zoltan Somogyi
2015-03-15 06:30:20 UTC
Permalink
Post by Paul Bone
Post by Zoltan Somogyi
Post by Paul Bone
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?
Yes. You want to check for it after each edit. How do you know when an edit
has happened? If there is a script that you can run automatically ever day,
then you set things up so that that script emails you when there is an edit,
and you know by checking your email, which you do every day anyway.
If there is no way to write such a script, you have to visit the site and press
that button every day; that is extra work every day.

Zoltan.
Paul Bone
2015-03-15 06:33:49 UTC
Permalink
Post by Zoltan Somogyi
Post by Paul Bone
Post by Zoltan Somogyi
Post by Paul Bone
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?
Yes. You want to check for it after each edit. How do you know when an edit
has happened? If there is a script that you can run automatically ever day,
then you set things up so that that script emails you when there is an edit,
and you know by checking your email, which you do every day anyway.
If there is no way to write such a script, you have to visit the site and press
that button every day; that is extra work every day.
Such a script is a great idea.

It may also be useful for people who just want to watch changes to the wiki
generally.
--
Paul Bone
Nick Rudnick
2015-03-15 13:58:05 UTC
Permalink
As said, Gitit is built on Happstack, which is a kind of Haskell
application server, which again means it has email sending functionality –
no such script would be needed, the code taking care of the edit can be
modified to do that.

Cheers, Nick
Post by Paul Bone
Post by Paul Bone
Post by Zoltan Somogyi
Post by Paul Bone
There's also a RecentChanges button on the website that allows you
to see a
Post by Paul Bone
Post by Zoltan Somogyi
Post by Paul Bone
list of recent modifications.
Unless that button's functionality is available to a script, that
doesn't help us
Post by Paul Bone
Post by Zoltan Somogyi
very much.
Is this related to fighting vandalism?
Yes. You want to check for it after each edit. How do you know when an edit
has happened? If there is a script that you can run automatically ever day,
then you set things up so that that script emails you when there is an edit,
and you know by checking your email, which you do every day anyway.
If there is no way to write such a script, you have to visit the site and press
that button every day; that is extra work every day.
Zoltan.
_______________________________________________
developers mailing list
https://www.mercurylang.org/lists/listinfo/developers
Paul Bone
2015-03-23 13:14:28 UTC
Permalink
Post by Paul Bone
Hi,
I've setup a wiki for Mercury.
https://www.mercurylang.org/wiki/
To address some of the feedback I've setup a git repository with github that
will mirror the wiki's contents. https://github.com/Mercury-Language/wiki

Changes made in the git repository will be replicated (in about 3.7 seconds)
in the website version. Likewise, changes made via the web interface will
be pushed to github. This solution is convenient but there is a race
condition. If that's ever a problem we'll have to resolve any conflicts
manually.

This is intended to give us a log of changes made in addition to the
RecentChanges button on the website. Zoltan said that it would be useful if
this e-mailed people automatically. It doesn't do that yet however this
change should make it easier to write a script that does that. We can each
write our own scripts that, for example, update a local clone of this
repository and compare it's "git log" output to yesterday's "git log" output
and e-mail us if there is a change, or if there's enough demand I can put
such a script on the webserver and provide a way to subscribe to it.

The git copy of the repository is also intended to address concerns about
being able to moderate or review changes to the repository. It makes it
simple for us to undo any vandalism (by undoing the git revision or applying
a new patch). github's teams also allow us to give other people write
access to this repository if we want more help with mediation.

We can also commit directly to this repository rather than using the web
interface if we prefer.

At a later date I plan to remove the OpenID access to the web interface and
possibly allow anonymous edits. Oh, and I'll add some content.

Cheers.
--
Paul Bone
Ben Schmidt
2015-03-23 20:36:44 UTC
Permalink
Post by Paul Bone
This is intended to give us a log of changes made in addition to the
RecentChanges button on the website. Zoltan said that it would be
useful if this e-mailed people automatically. It doesn't do that yet
however this change should make it easier to write a script that does
that.
Possibly it provides an RSS feed of recent changes/the log that you
could hook up to your email program and see new changes as new articles
which might suit some.

Ben.
Paul Bone
2015-03-24 00:57:18 UTC
Permalink
Post by Ben Schmidt
Post by Paul Bone
This is intended to give us a log of changes made in addition to the
RecentChanges button on the website. Zoltan said that it would be
useful if this e-mailed people automatically. It doesn't do that yet
however this change should make it easier to write a script that does
that.
Possibly it provides an RSS feed of recent changes/the log that you
could hook up to your email program and see new changes as new articles
which might suit some.
Good point.

The current page without any changes includes links to both RSS and Atom
feeds.

https://www.mercurylang.org/wiki/recentchanges/
--
Paul Bone
Loading...