wiki.koha-community.org

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

wiki.koha-community.org

Galen Charlton-3
Hi,

I am making a proposal for Equinox to host the new koha-community.org wiki.  We will provide a virtual machine, bandwidth, backups, and system administration.  Shell access and wiki administration access will be given to anybody who expresses a desire to help and who is known to me or another Koha project regular, though I reserve the right to boot anybody off in the unlikely event of abuse (i.e., spamming, destructive activity, attempts at network intrusion, or other anti-social behavior).  As with the current wiki, anybody in the world will be able to create an account for themselves to edit the wiki.

Thomas Dukleth has offered to work on the wiki, so he will be one of the people who has shell and wiki admin access to start.  Email me if you want in on the fun.

As part of our hosting proposal, I will do the following to ensure continuity of this wiki:

* a backup of the wiki's data and files will be done nightly and the tarball made available for anybody to download.
* if the wiki moves to a new host in the future, we will give the new host a copy of the Ganeti image of the VM

Thomas has some ideas about the content and organization of the wiki, which I'll leave to him to propose, but I see a couple questions that may be worth answering first:

* Do we want to take this opportunity to switch to MediaWiki (or $some_other_wiki), which can manage multiple languages better than DokuWiki?  I'm personally open to any suggestion, but I'm happy to install the current version of DokuWiki and upgrade to MediaWiki or something else later.

* Do we want to start the wiki's content from scratch?  That would allow us start fresh with a clean organization of the information, and would also allow us to establish the GPL as the license for the new wiki from the get-go.

I'd appreciate feedback on those questions and general feedback about the proposal.  The VM should be up soon.

Regards,

Galen
--
Galen Charlton
VP, Data Services
Equinox Software, Inc. / Your Library's Guide to Open Source
email:  [hidden email]
direct: +1 352-215-7548
skype:  gmcharlt
web:    http://www.esilibrary.com/

_______________________________________________
Koha mailing list
[hidden email]
http://lists.katipo.co.nz/mailman/listinfo/koha
Reply | Threaded
Open this post in threaded view
|

Re: wiki.koha-community.org

Galen Charlton-3
Hi,

On Mar 5, 2010, at 5:09 PM, Galen Charlton wrote:
> The VM should be up soon.

Rather, the VM is up now thanks to the kind offices of Don McMorris.

Regards,

Galen
--
Galen Charlton
VP, Data Services
Equinox Software, Inc. / Your Library's Guide to Open Source
email:  [hidden email]
direct: +1 352-215-7548
skype:  gmcharlt
web:    http://www.esilibrary.com/

_______________________________________________
Koha mailing list
[hidden email]
http://lists.katipo.co.nz/mailman/listinfo/koha
Reply | Threaded
Open this post in threaded view
|

Re: wiki.koha-community.org

Reed Wade
In reply to this post by Galen Charlton-3
On Sat, Mar 6, 2010 at 11:09 AM, Galen Charlton <[hidden email]> wrote:
> Hi,
>
> I am making a proposal for Equinox to host the new koha-community.org wiki.

nice



> As part of our hosting proposal, I will do the following to ensure continuity of this wiki:

very nice

At Catalyst we are preparing to offer to host bugs.koha-community.org.
A part of that will be some mechanism to make it easy for anyone in
the community to collect a complete copy of the data.



> * Do we want to take this opportunity to switch to MediaWiki

I'm a big fan of mediawiki. We use it a lot around here.


Reed Wade
[hidden email]
Catalyst IT
_______________________________________________
Koha mailing list
[hidden email]
http://lists.katipo.co.nz/mailman/listinfo/koha
Reply | Threaded
Open this post in threaded view
|

Re: wiki.koha-community.org

Frédéric Demians
In reply to this post by Galen Charlton-3
Thanks for your proposal.

> * a backup of the wiki's data and files will be done nightly and the
> tarball made available for anybody to download.

If you agree, I propose to mirror daily the wiki via rsync.

> * Do we want to take this opportunity to switch to MediaWiki (or
> $some_other_wiki), which can manage multiple languages better than
> DokuWiki?

DokuWiki manual seems to prove that DokuWiki handles pretty well
multilingual content:

    http://www.dokuwiki.org/manual

> I'm personally open to any suggestion, but I'm happy to install the
> current version of DokuWiki and upgrade to MediaWiki or something else
> later.

 From my perspective DokuWiki has the advantage over MediaWiki to be
lighter, and to store its content in plain text files rather than MySQL.
There is also in DokuWiki the concept of 'namespace' which is
interesting and that Thomas Dukleth has began to use (maybe also
available in MediaWiki).

> * Do we want to start the wiki's content from scratch? That would
> allow us start fresh with a clean organization of the information, and
> would also allow us to establish the GPL as the license for the new
> wiki from the get-go.

+1

What about putting on this wiki parts of the Koha documentation itself,
like tutorials, howtos, videos materials? It would be much easier to add
content than with Docbook current format, and facilitate contributions.
With ACL, portions of this doc could even be locked in if necessary.

Clearly the key will be how Thomas will succeed in organizing
meaningfully the new wiki content!

--
Frédéric

_______________________________________________
Koha mailing list
[hidden email]
http://lists.katipo.co.nz/mailman/listinfo/koha
Reply | Threaded
Open this post in threaded view
|

Re: wiki.koha-community.org

paul POULAIN-3
In reply to this post by Galen Charlton-3
Le 05/03/2010 23:09, Galen Charlton a écrit :
> Hi,
>
> I am making a proposal for Equinox to host the new koha-community.org wiki.
Catalyst for bugzilla, Equinox for wiki, BibLibre for mailing lists,
savannah for downloads, will be a widely spread project ;-)
I vote "yes"

> Thomas Dukleth has offered to work on the wiki, so he will be one of the people who has shell and wiki admin access to start.  Email me if you want in on the fun.
>  
Huray for Thomas. There's a big need for cleaning/re-organising the
wiki. really big...
> * Do we want to take this opportunity to switch to MediaWiki (or $some_other_wiki), which can manage multiple languages better than DokuWiki?  I'm personally open to any suggestion, but I'm happy to install the current version of DokuWiki and upgrade to MediaWiki or something else later.
>  
I don't have any argument for or against, except I know docuwiki pretty
well (we use it internally), and not mediawiki.
Add that the need for multiple languages on the wiki is secondary (who
will take care of translating pages ? at least for frenchies, i'm sure
no one won't)
> * Do we want to start the wiki's content from scratch?  
mmm... good question. considering the actual wiki is quite disorganized,
i feel it will be easier to start from scratch (and copy-paste
interesting parts) than to reorganise what exist.
> That would allow us start fresh with a clean organization of the information, and would also allow us to establish the GPL as the license for the new wiki from the get-go.
>  
++

--
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08

_______________________________________________
Koha mailing list
[hidden email]
http://lists.katipo.co.nz/mailman/listinfo/koha
Reply | Threaded
Open this post in threaded view
|

Re: wiki.koha-community.org

Zeno Tajoli
In reply to this post by Galen Charlton-3
Hi

>* Do we want to take this opportunity to switch to MediaWiki (or
>$some_other_wiki), which can manage multiple languages better than
>DokuWiki?  I'm personally open to any suggestion, but I'm happy to
>install the current version of DokuWiki and upgrade to MediaWiki or
>something else later.

I think that wiki doesn't need multiple languages.


>* Do we want to start the wiki's content from scratch?  That would
>allow us start fresh with a clean organization of the information,
>and would also allow us to establish the GPL as the license for the
>new wiki from the get-go.

++ on starting from scratch.
A more clear organization is important.
But who does he plan the new organization ?

Bye

Zeno Tajoli
CILEA - Segrate (MI)
tajoliAT_SPAM_no_prendiATcilea.it
(Indirizzo mascherato anti-spam; sostituisci quanto tra AT con @)

_______________________________________________
Koha mailing list
[hidden email]
http://lists.katipo.co.nz/mailman/listinfo/koha
Reply | Threaded
Open this post in threaded view
|

Re: wiki.koha-community.org

Galen Charlton-3
Hi,

On Mar 9, 2010, at 6:57 AM, Zeno Tajoli wrote:
> I think that wiki doesn't need multiple languages.

However, there's been enough Ukrainian, French, Spanish, and Russian work done on the old wiki that I don't believe this to be a universally-held opinion.

>> * Do we want to start the wiki's content from scratch?  That would
>> allow us start fresh with a clean organization of the information,
>> and would also allow us to establish the GPL as the license for the
>> new wiki from the get-go.
>
> ++ on starting from scratch.
> A more clear organization is important.
> But who does he plan the new organization ?

I know Thomas has some ideas.

Regards,

Galen
--
Galen Charlton
VP, Data Services
Equinox Software, Inc. / Your Library's Guide to Open Source
email:  [hidden email]
direct: +1 352-215-7548
skype:  gmcharlt
web:    http://www.esilibrary.com/

_______________________________________________
Koha mailing list
[hidden email]
http://lists.katipo.co.nz/mailman/listinfo/koha
Reply | Threaded
Open this post in threaded view
|

Re: wiki.koha-community.org

Thomas Dukleth-3
Reply inline:

On Tue, March 9, 2010 14:29, Galen Charlton wrote:
> Hi,
>
> On Mar 9, 2010, at 6:57 AM, Zeno Tajoli wrote:
>> I think that wiki doesn't need multiple languages.
>
> However, there's been enough Ukrainian, French, Spanish, and Russian work
> done on the old wiki that I don't believe this to be a universally-held
> opinion.

The Koha Wiki should be a place where anyone can be comfortable
contributing to Koha in whatever language anyone may find useful.  We
should not judge everything by the standard for code development where we
need a common language to cooperate effectively on the code.

The degree of internationalisation of the Koha project is almost as
important to me as the free software aspect of the project.

The possibility of translating content should not be understood as an
obligation to translate anything between different languages.  Even having
some quite distinctive content in different languages as we have now
should be fine.

I treat internationalisation in section 2.1 further below.

[...]

>> ++ on starting from scratch.
>> A more clear organization is important.
>> But who does he plan the new organization ?
>
> I know Thomas has some ideas.

I will in due course make an organisational suggestion for categories
based on the namespaces which had been created based upon the
documentation working group led by Pierrick Le Gall at the KohaCon
Development Week in France 2006.  However, I hope that we will have a
flexible idea of categories described in section 2.2 on navigation further
below.  In future, I might correct some obvious source of confusion, such
as  defining a category in both a singular and plural form if I happen to
notice and have the time to correct something such as that but a wiki is a
wiki and should be used as such and not in an overly rigid manner.  I hope
that we will use the wiki in a manner which helps others find the content
which we add so that everyone can contribute collaboratively.

I agree with Paul Poulain that we should start over and migrate content
selectively.  See section 5 at the end for a copyright issue.  We should
preserve content from the old Koha Wiki which we do not intend to migrate.
 There is no need to delete old content merely because we do not choose to
migrate some old content to a new wiki.  Some content which may be thought
out of date or otherwise obsolete now may have no comparable up to date
equivalent and has some value which someone should still be able to use
whenever someone may choose to create an up to date equivalent for the
topic.

If we had the possibility of easily migrating all the Koha DokuWiki
content to a community controlled subdomain, then we should keep
everything in DokuWiki at the present time merely because that would be
easiest for giving attention to other things such as Koha 3.2.  However,
we lack an automatic way to migrate the current state of the Koha Dokuwiki
content perfectly without the most modest help which may not be
forthcoming from LibLime.  We could attempt to partly automate a mostly
manual process, but the scripting effort might be very significant and the
work would still be mostly manual.

I favour using the difficulty of the situation as an opportunity to
re-evaluate our choice of wiki software and how we would like to implement
it.

For those who lack sufficient time to consider proper reasoning, I present
my brief conclusion before the analysis on which it is based.  I favour
testing a good multi-lingual implementation of MediaWiki modeled largely
on the Wikipedia implementation which I expect to be the best wiki choice
for the long term future of the Koha project, especially in relation to
support for internationalisation.  While the testing is being done, I
suggest either making modest use of DokuWiki at wiki.koha-community.org or
continuing to use DokuWiki at wiki.koha.org.  I hope that we would not
rush to create a large set of new wiki pages which would then need to be
migrated from DokuWiki to MediaWiki with my expectation that MediaWiki
will be seen to be an obviously better choice for the Koha project going
forward.

I have significant experience with DokuWiki administration and modifying
some parts of the code.  I am only just starting to experiment with
MediaWiki.  I would greatly appreciate any information which those
experienced with MediaWiki can provide especially in relation to
multi-lingual support using a wiki family (farm) and multi-lingual
navigation in a manner similar to or better than Wikipedia.

In any case, we should certainly take the opportunity to adopt the
community choice of GPL 2 or later as the copyright license for newly
created wiki content in conformity with the license for Koha itself.
Displaying notice of a GPL 2 or later license for the wiki content
requires modifying the source code of any wiki we may choose.

My reasoning and report of my experience with DokuWiki and current
investigation of MediaWiki follows.


1.  BASIC INFORMATION (FOR ANYONE WHO DOES NOT ALREADY KNOW).

DokuWiki has been designed for supporting the documentation of software
projects.  DokuWiki may have had some features which better supported
software documentation than other wikis historically.  DokuWiki has been
adopted as a wiki for a large number of software projects.

MediaWiki has been designed as the wiki for Wikipedia.  Its features have
been designed to support everything which Wikipedia needs as well as other
wiki projects of the MediaWiki foundation and Wikia.  MediaWiki is the
most widely used wiki because of the success of Wikipedia.  MediaWiki is
also the most widely adopted wiki generally and may also be the most
widely adopted wiki for software projects currently.


2.  SUITABILITY OF WIKI SOFTWARE FOR THE KOHA PROJECT.

I have examined the range of wiki software available in the past and found
that DokuWiki and MediaWiki have been the two wiki programs with the
largest number of essential and useful features.    I had found
WikiMatrix, http://www.wikimatrix.org/ , helpful to roughly compare the
features of different wiki software in the past.  DokuWiki and MediaWiki
are roughly comparable in important and useful features at least with a
suitable set of plug-ins or extensions to both.  I confine my comment to
those two wikis.

For the past few years, MediaWiki has had more features and more
extensions for additional features.  However, having more features which
we may never need nor ever use should not be the basis for choice.


2.1.  INTERNATIONALISATION.

The aspect of the Koha project which I like best after other aspects which
are also true of other free software library systems is the degree to
which Koha's development and use are international.  Any wiki for the Koha
project should support internationalisation well.

Both DokuWiki and MediaWiki have support for UTF-8 which allows characters
for any language to be used.  However, there is more to
internationalisation than mere character set support.

Other issues include the following.  Script orientation support is needed
for some languages such as right to left languages.  Translation of all
the elements of the user interface is needed to allow contribution or
receptive use without a need to understand a default user interface
language.  Navigational interoperability between languages is needed to
coordinate a common set of topics in which content may be localised in
different languages especially where some content will appear in some
languages but not be available in every language.

DokuWiki has some degree of support for 90 languages,
http://translate.dokuwiki.org/ .  A large portion of the 90 have very
little translated.  I am doubtful of the extent to which there is
provision for alternate script orientations if any.

MediaWiki has some degree of support for 324 languages,
http://www.mediawiki.org/wiki/Localisation_statistics .  (347 languages
are listed but 23 languages by my count have no translation.)  A large
portion of the 324 have very little translated.  MediaWiki attempts to
quantitatively evaluate the quality of the translations.

MediaWiki has a much larger number of languages for which the translation
is almost complete.  Arabic for example has nearly 100% translation for
standard Arabic and Egyptian Arabic for MediaWiki, but merely 48%
translation with no Egyptian Arabic translation for DokuWiki.

Given the goal of the MediaWiki Foundation to have a full Wikipedia for
every language, MediaWiki is liable to always be ahead of Koha for
language support.  The narrower scope of DokuWiki is such that it is
liable to be behind the Koha project for language support in future.

Wikipedia provides an example of a mechanism for linking to every other
language in which a wiki article appears.  Such functionality is supported
in MediaWiki using a wiki family (farm) with interwiki linking.  The
Interlanguage extension,
http://www.mediawiki.org/wiki/Extension:Interlanguage , automatically
provides links between pages localised in different language wikis within
the wiki family.  Attempts of which I am aware to provide similar
functionality in DokuWiki in a template or plugin had failed because of
the inefficiency of checking the existence of articles in a set of
languages as part of the DokuWiki page display code.  For the Koha Wiki,
we have used language specific namespaces in DokuWiki but that method does
not allow interface localisation or different script orientations.


2.2.  NAVIGATION.

Perhaps the most difficult problem for every wiki is providing a means for
users to find the existing content treating a particular topic for reading
or to contributing to common content collaboratively.  The general wiki
expectation is that content is found using wiki links.  However, people
often create unlinked pages and then a multiplicity of pages on the same
topic exist without an efficient means of finding them.

One of the first principles of library science is grouping things together
by their similarities.  The task of similarity grouping complicated by the
fact that everything has various aspects on which similarity may be
considered and thus has a multiplicity of similarities.

DokuWiki provides namespaces which if used provide a degree of automated
navigation for traversing up and down a namespace hierarchy,
http://wiki.koha.org/doku.php?id=en:wiki:namespace_tutorial .  Namespace
navigation links are displayed on each page of the Koha Wiki.  Global
navigation throughout all namespaces is provided by a sitemap,
http://wiki.koha.org/doku.php?do=index .  The pageaccueil plugin,
http://www.dokuwiki.org/plugin:pageaccueil , encourages consistent use of
namespaces.

Unfortunately, the DokuWiki namespace implementation is a single rigid
hierarchy based on the file system hierarchy without the benefit of
symlinks.  The Tag plugin, http://www.dokuwiki.org/plugin:tag , allows
linking from a page to multiple namespaces, however, the page can only be
found within the sitemap namespace where the file is actually stored
within a directory on the filesystem.

MediaWiki has namespaces but uses more flexible categories and category
trees for navigation.  See  
http://www.mediawiki.org/wiki/Special:Categories and
http://www.mediawiki.org/wiki/Special:CategoryTree/Top_level .  Category
links appear at the bottom of Wikipedia pages.  The CategoryBreadcrumb
extension, http://www.mediawiki.org/wiki/Extension:CategoryBreadcrumb ,
displays category hierarchies in each page for navigation to any part of
the hierarchy.

The advantage of categories as used in MediaWiki over namespaces as used
in DokuWiki is that they are not rigid hierarchies and any page can be
included in multiple categories.  The disadvantage of categories is that
they are not assigned automatically by contextual default.  Categories
rely to a greater degree than namespaces upon the effort of contributors
to assign them.  The SelectCategory extension,
http://www.mediawiki.org/wiki/Extension:SelectCategory ,  encourages
category assignment and assists users in assigning categories
consistently.  The Semantic MediaWiki extension,
http://semantic-mediawiki.org/ , and associated extensions could be used
to provide some automated contextual assignment of relationships.


2.3.  WIKI READABILITY.

Content is created to be read and used.  The easier it is to optically
read and follow text, the more attention a reader's brain can give to the
meaning of content.  My observations in this subsection may be entirely
lost on those who may notice little difference between the eye / brain
effort required to read a traditional printed book in comparison to the
effort required to read the same text on common contemporary computer
displays.  The possibility that we can become accustomed to working in
adverse conditions is not an argument against improving our conditions.

DokuWiki page design and CSS pleases some aesthetic sense to avoid dark
characters, ragged right edges, and maximise use of screen space.  In
attempting to satisfy an aesthetic choice, readability is compromised
generally and in some special circumstances.

DokuWiki low contrast between the background and text impairs readability.
 I have no claim that the content is actually unreadable, but merely that
readability is impaired.  The low contrast problem is worst in the page
table of contents which uses an especially small font with a similar light
weight to the unusually light weight external links.

DokuWiki placement of the table of contents to the right of the initial
part of the page text can create an overlap problem with page text in
Mozilla based browsers, such as Firefox.  Fully displayed URLs are part of
good practise for some bibliographic styles.  Mozilla based browsers never
wrap long text strings to the next line which can result in unreadable
overlapping content in some cases which is especially likely for long
URLs.  I used an image placeholder as a workaround to avoid long URLs
overlapping the table of contents for a version of a bibliography which I
contributed to the Koha Wiki,
http://wiki.koha.org/doku.php?id=en:standards:cataloguing_classification:bibliography
.

DokuWiki uses the full width of the screen to present content with almost
no constraint on line width.  Most of the content in the Koha Wiki is
presented in list form for which line length imposes few problems.
Scanning from one line to the next smoothly for material presented in full
paragraphs becomes a difficulty when lines are unusually wide relative to
their height as can now be the case with contemporary wide high resolution
displays.  Having reasonable line width constraints from margins or other
page elements avoids the user needing to adjust his web browser window
width to read DokuWiki content more easily.  Almost no one is liable to
actually adjust his web browser window width for a DokuWiki website when
most web pages constrain line width with navigation or advertising
columns.  There is very little content in the Koha Wiki which uses full
paragraphs in the manner which is the common style in Wikipedia but I have
been a little discouraged from contributing such content to the Koha Wiki
myself in the past with the knowledge that reading such content is
unnecessarily difficult in DokuWiki.

DokuWiki blind right justification of text occasionally results in a line
of text with almost no words each of which is separated by a very large
white space.  This occasional effect breaks the flow of reading and undoes
any advantages of right justification on readability.  Right justification
is not appropriate for web publication with no control over the absolute
window width and font size displayed to the user.  The appropriate
situation for right justification applied with an understanding of
whitespace problems is limited to traditional print material and
electronic file formats designed to reproduce the exact appearance of
printed material, such as the Adobe Acrobat (PDF) format.

Most of the DokuWiki readability problems can be fixed by modifying the
DokuWiki CSS.  I have maintained such a modified DokuWiki CSS for my own
use from 2006.

The MediaWiki monobook skin uses CSS based on the highly regarded Plone
CSS.  Significant work has gone into ensuring that the default Plone CSS
has good cross-browser support and readability.  Plone CSS and the
MediaWiki monobook adaptation are not perfect but they have at least given
attention to the issues where DokuWiki has not.

[It is always possible to modify the default Plone CSS in a manner which
breaks its cross-browser and good readability features.  The untested new
Plone based Koha website demonstrated that fact in May.  One section had
display problems in every web browser and  the main navigation links were
not visible when using default Internet Explorer settings.]


2.4.  WIKI SYNTAX.

There are some differences in wiki markup syntax and what the syntax
supports between DokuWiki and MediaWiki,
http://www.wikimatrix.org/syntax.php .  While there is much in common
between their respective wiki syntaxes, the differences mean that
formatted content cannot necessarily be copied between a DokuWiki and a
MediaWiki installation and expected to work correctly.  There are no
sufficiently debugged conversion scripts which I have been able to find,
although, I would experiment with creating a very simple conversion script
which may be sufficient for most existing Koha Wiki pages.

DokuWiki has been considered to have a syntax with the greatest
differences to other wiki syntaxes.  My favourite DokuWiki syntax feature
is the provision for 5 levels of section headings.  However, I may be the
only contributor to the Koha Wiki who has ever used all 5 levels of
headings.

MediaWiki as the wiki from the Wikipedia project has the wiki syntax which
is most familiar to the largest number of people.  I am disappointed that
MediaWiki only supports 3 levels of section headings.

My own particular concern about the number of levels of MediaWiki section
headings could be addressed by either flattening some of the section
shierarchies in a few of the pages which I have contributed or breaking
some subsections into different linked wiki pages.


2.5.  SOFTWARE PROJECT INTEGRATION.

DokuWiki and MediaWiki support some functionality to integrate the wiki
with other parts of a software project.

DokuWiki provides syntax highlighting of example source code using the
<code> tag.  Some additional plugins extend the syntax highlighting.  The
gitlink2 plugin allows the use of git commit hashes to link to source
code.

MediaWiki has source code syntax highlighting extensions such as
GeSHiHilight, http://www.mediawiki.org/wiki/Extension:GeSHiHighlight .

The BugzillaReports extension,
http://www.mediawiki.org/wiki/Extension:Bugzilla_Reports , provides views
on the state of bugs in Bugzilla.  A link to a bugzilla query would
probably be easier.

The BugSquish extension allows interwiki links to BugZilla which display
the status of a bug.  However, intuitive use is complicated by the need to
avoid using 'bug' as an interwiki link prefix because the 'bug' prefix is
reserved for the  Buginese language.


2.6.  SCALABILTY AND COMPLEXITY.

Frederic Demians is correct in identifying that DokuWiki is much lighter
weight than MediaWiki in terms of system resources and administrative
complexity.  Some increase in complexity is generally required to support
a larger feature set.  A useful question is whether greater complexity is
manageable and scalable.

DokuWiki has some efficiency problems which prevent use in a coordinated
family of fully localised wikis because of  limitations of the file system
based design which helps provide simplicity.  The simplicity has a
corresponding disadvantage for scalability.

Wikipedia has proven that MediaWiki is  scalable as one of the busiest
websites on the internet.  MediaWiki would provide more than enough
scalability for future needs of the Koha project.  As the most widely
adopted wiki, there is no shortage of experienced people who may be able
to answer a question about MediaWiki administration.


3.  DOKUWIKI MODIFICATION.

I have been privately maintaining a modified installation of DokuWiki
which corrects many of the DokuWiki problems which I have found in the
Koha Wiki installation.  From 2006, I have maintained my own modified
version of the monobook template,
http://www.dokuwiki.org/template:monobook .  Monobook is designed to
emulate some features of MediaWiki.  See the current maintainer's site,
http://readm3.org/ , and also http://www.pkuinfo.it/ for examples of
DokuWiki using the Monobook template.

My modifications more closely follow the CSS used in the MediaWiki
monobook skin.  I also fixed several bugs for Internet Explorer and other
web browsers.  Additionally, I modified some core DokuWiki page display
code to better support navigation elements.

I had been working with Joshua Ferraro to test my DokuWiki modifications
in 2006.  At the stage when they seemed to please him and they should have
then been put forward for a community vote, he suddenly lost time to give
any attention to them.  He had mistakenly suspected an authentication bug
in testing where no authentication code had been touched.  Stephen Hedges
was intending to propose to take the time to migrate the Koha Wiki content
to MediaWiki later that year before he obtained a different job which did
not grant him sufficient time for Koha.

I am pleased to see that the Monobook template has a new maintainer after
being abandoned by its author for a long period.  However, when the best
corrections to DokuWiki problems are to model the design more closely on
MediaWiki, then using MediaWiki itself instead of a partial implementation
is liable to be a better solution.


4.  MEDIAWIKI TESTING.

I am working on preparing a test MediaWiki installation following the
interlinked languages wiki family example of Wikipedia.  The suggestion of
the designated easiest method from the wiki family discussion page,
http://www.mediawiki.org/wiki/Manual_talk:Wiki_family#Easiest_way , seems
better than attempting to follow any of the other incompletely documented
methods from the main wiki family page,
http://www.mediawiki.org/wiki/Manual:Wiki_family.  Even the particular
method used by Wikipedia itself is very incompletely documented and
perhaps unnecessarily difficult to maintain.

Wikipedia runs from the current MediaWiki code from the MediaWiki
Subversion source code repository which is maintained as stable for their
own use.  Using the latest MediaWiki code from the Subversion repository
would seem unwise for the Koha project without the resources to devote to
maintaining the wiki code when Koha is the Koha project software, not
MediaWiki.

I am experimenting with the latest stable release version 1.15.1.
Supporting the general functionality of Wikipedia using the extensions
installed for Wikipedia seems important,
http://en.wikipedia.org/wiki/Special:Version .  Some functionality which
may only be available in extensions for version 1.15 may have been
integrated into the core in Subversion and the corresponding extensions
would need to be discovered if there are any.

I also think that adding some of the additional extensions mentioned above
for navigation as well as others is important.  Some extensions such as
Semantic MediaWiki might never actually be used but that would be no
reason not to make them available if some people may have an interest in
trying to make use of them.

As stated above, I would appreciate any information which others may have
to offer for my effort to test MediaWiki, especially as I lack experience
with MediaWiki administration and have other commitments for most all of
my time.


5.  NEW WIKI NEW CONTENT LICENSE.

We have held a vote of significant past wiki contributors about adopting a
new license of GPL 2 or later for wiki content,
http://wiki.koha.org/doku.php?id=relicensing .  Any new wiki should have
our content license choice which requires a minor change to the source
code to display.  An appropriate plugin or extension might also be used to
display a GPL 2 or later license.

Until we have a vote from some who have yet to vote, we should take a
little care to not copy some content from the old wiki which those who
have not voted had contributed.  Rewriting such problematic content should
be relatively easy.  A few of the most important pages in the wiki fall
into that category.  I would prefer that we rewrite such problematic
content instead of marking it as being under the old license.  I hope that
everyone who has contributed to the old wiki and is still doing something
with Koha will eventually make their vote on the question clear.


Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY  10003
USA
http://www.agogme.com
+1 212-674-3783


[...]

_______________________________________________
Koha mailing list
[hidden email]
http://lists.katipo.co.nz/mailman/listinfo/koha
Reply | Threaded
Open this post in threaded view
|

Re: wiki.koha-community.org

MJ Ray-2
Thomas Dukleth wrote:
> For those who lack sufficient time to consider proper reasoning, I present
> my brief conclusion before the analysis on which it is based.  I favour
> testing a good multi-lingual implementation of MediaWiki modeled largely
> on the Wikipedia implementation which I expect to be the best wiki choice
> for the long term future of the Koha project, especially in relation to
> support for internationalisation. [...]

Oops! I've even lacked sufficient time to read this email until now!
Is it proper reasoning if it can't be expressed concisely? ;-)

I'm happy to see that the content licensing might be solved as a
consequence and that people are willing to work on farming the wiki,
but I don't believe that mediawiki is the best (or even a good) solution.

To be clear, I am disappointed with the preselection of mediawiki
apparently mainly on grounds of popularity (which is repeated to argue
for everything from translations to scalability), while ignoring its
many configuration and accessibility problems and that it arguably is
not even a wiki.


I'm not going to Fisk the whole essay, but I'll comment on a few:

Is "a good multi-lingual implementation of MediaWiki" even possible?
If so, why doesn't Wikipedia use one?  Wikipedia's current
wiki-per-language implementation is very frustrating to use.  Have you
tried it?  If you switch language, you can go two clicks on and then
not have a way back to the previous language at all, except by going
back.  Also, if some page does not exist in a language, it often isn't
linked on that language's subdomain, so you probably won't know it
exists in *any* language.  For projects like Koha which are actually
multilingual, where some things might exist in French or Spanish
before English, this is bad.


Popularity: if user numbers decided things, we'd all be using whatever
ILSes dominate our sectors.  They don't and we use Koha.

Configuration problems: most MediaWiki sites have settings which are
fine for wikipedia but are poor for small projects.  My obvious example
is the copyright and terms pages.  Are you sure you can get them all?

Accessibility problems: I often can't add links to wikipedia because
it always wants me to pass an evil eyetest.  If that is switched off,
does it have any proper spam defences?

Not even a wiki: compare
http://www.c2.com/cgi/wiki?TextFormattingRules
http://www.mediawiki.org/wiki/Help:Formatting

Bold, italics and rules are the same, but most of the rest is often
wildly different and usually mediawiki gets much more complex.
Mediawiki often looks better, but the cost is much ease of editing.

> 2.2.  NAVIGATION.

Does everyone realise that most wikis can do categories, through
backlinks of Category pages?

See for example http://www.c2.com/cgi/wiki?CategoryCategory

It's not something anyone has really tried to add to wiki.koha.org
yet, but it's there and ready to use if anyone wants to start linking
pages to Category pages.  No need to junk the wiki software, but maybe
we can do better than dokuwiki.  I really don't see mediawiki as a
step forwards, though.  Is there still time to reconsider?

Regards,
--
MJ Ray (slef)  Webmaster and LMS developer at     | software
www.software.coop http://mjr.towers.org.uk        |  .... co
IMO only: see http://mjr.towers.org.uk/email.html |  .... op
_______________________________________________
Koha mailing list
[hidden email]
http://lists.katipo.co.nz/mailman/listinfo/koha
Reply | Threaded
Open this post in threaded view
|

Re: wiki.koha-community.org

Thomas Dukleth-3
Rely inline:


On Thu, April 15, 2010 10:20, MJ Ray wrote:

> Thomas Dukleth wrote:
>> For those who lack sufficient time to consider proper reasoning, I
>> present
>> my brief conclusion before the analysis on which it is based.  I favour
>> testing a good multi-lingual implementation of MediaWiki modeled largely
>> on the Wikipedia implementation which I expect to be the best wiki
>> choice
>> for the long term future of the Koha project, especially in relation to
>> support for internationalisation. [...]
>


1.  AVAILABLE TIME.

> Oops! I've even lacked sufficient time to read this email until now!

I have mostly not had sufficient time to attend to the mailing list
recently myself.

[I have been collaborating with another programmer on a sadly non-library
related project which must be finished before I turn into a pumpkin.  When
the person with whom I have been collaborating has disappeared for a few
days at a time, then I have had some time for Koha.  Finishing the project
which is keeping me from Koha is a better time availability remedy for me
but that remedy has not been solely dependent upon me.]

I should have some more time for the wiki next week.


2.  CONCISE EXPRESSIONS.

> Is it proper reasoning if it can't be expressed concisely? ;-)

My personal preference is to show reasons, evidence which underlies
reasons, and relevant background to enable people to have an opportunity
to properly understand the strength or mistakes of my reasoning and offer
their own alternatives with common points of reference.  There are some
irreducible complexities in the world which deserve due consideration.  I
always try to avoid easily formed oversimplification.  However, I am
mindful of the helpful preference for concise expression.  I often lack
the time to prepare work which is both thorough and concise.

In the present case, I think that my effort has not progressed quite far
enough for me to be both concise and informative.  I should be able to
give a concise expression of reasons at a later point.

I do not seek obfuscation by trying to give detailed information for those
who care to read at length.  Lack of concisely expressed reasoning should
not be presumed to be the same as reasoning which could not be expressed
concisely.

When I have had the time to test an implementation sufficiently, then I
should also have time to express my reasoning concisely.  I have only
advocated testing the utility of MediaWiki but not formed a necessary
conclusion over a test which has not yet been sufficiently configured and
conducted.


3.  WIKI CONTENT RELICENSING.

>
> I'm happy to see that the content licensing might be solved as a
> consequence

PTFS now controls the uncast LibLime vote for relicensing some significant
wiki content.  I am still hopeful that PTFS will express themselves
favourably on such a minor issue to avoid the need to rewrite some helpful
content contributed by LibLime which would be well worth transferring to
any new wiki.


4.  WIKI FARMING.

> and that people are willing to work on farming the wiki,

I am willing to put much work into a wiki in whatever form people agree
the wiki should take.  Perhaps the reference is to coordinated wiki farms
or families which are used by the Mediawiki foundation for multilingual
wikis, http://www.mediawiki.org/wiki/Manual:Wiki_family .


5.  WIKI CHOICE.

> but I don't believe that mediawiki is the best (or even a good) solution.

I gave some reasons in my previous message about why I think that
MediaWiki is a good choice relative to various problems which I found in
my extensive experience working with DokuWiki,
http://old.nabble.com/Re%3A-wiki.koha-community.org-p27860816.html .  One
of my most significant findings is that plugins which help resolve
problems that I have found with DokuWiki resolve those problems by making
DokuWiki more like MediaWiki.


5.1.  EXERCISING CHOICE.

>
> To be clear, I am disappointed with the preselection of mediawiki

I only just now noticed that the subdomain wiki.koha-community.org
resolves to something.  Thankfully the link from koha-community.org does
not point to the new subdomain.  I have never advocated preselecting a new
wiki.  In my previous message, I had advocated setting up a test
installation of MediaWiki.  I had presumed that after a test would be
fully configured and available for testing for a period of time, we could
then vote on whether such an installation would be a good choice for the
Koha community.

Galen Charleton identified the fact that [aside from the criticism of the
'heaviness' of MediaWiki implementations given by Frédéric Demain] no one
had raised an objection to using MediaWiki.  Obviously, you have now and
any serious objection deserves serious consideration by everyone
interested.  I had raised the issue with Galen that we should have a
formal vote after a suitable test.

Galen suggested to me selecting according to what wiki would actually be
used in practise.  People would vote with their use.  I find Galen's
suggestion of voting according to use appealing, although, I had not
properly considered some possible issues of fairness in how the
alternatives are presented if MediaWiki would be the only new alternative
and the old Koha wiki would be the only DokuWiki alternative presented.
Galen's suggestion has certainly provided me with the motivation to
resolve implementation issues more quickly than I might have otherwise
given my constraint of time from other work.

I have been working on issues which needed to be addressed for the
MediaWiki installation hosted by Equinox.  Galen has done a good job of
starting that installation with daily database dumps and version control
in Git for any modifications of the scripts but a few important initial
configuration issues have been missed.

The MediaWiki database needs to be dropped and reinstalled with the
MediaWiki in a slightly different directory within the home directory for
the wiki to avoid the namespace collision currently preventing the use of
cool short URLs familiar to users of Wikimedia foundation installations of
MediaWiki such as Wikipedia,
http://www.mediawiki.org/wiki/Manual:Short_URL .  There may be a way of
correcting the issue without dropping the database but especially without
any significant content yet dropping the database would be the easiest
remedy.

I think that wiki.koha-community.org should merely direct users to an
appropriately localised wiki similar to what is done from
http://www.wikipedia.org .  A simple change in DNS and Apache
configuration could provide for language specific subdomains.


5.2.  REASONS INVOKING POPULARITY.

> apparently mainly on grounds of popularity (which is repeated to argue
> for everything from translations to scalability),

My appeal to popularity in the reasons which I gave favouring MediaWiki in
my recent previous message merely identified the high demand from users
and that the large MediaWiki development community which followed from the
popularity.  Those two consequences of popularity should help to ensure
that MediaWiki would continue to be an especially scalable and featureful
wiki into the future.  I never favour popularity for its own sake and
usually favour choices which are only popular with the well informed
minority and not the public at large.

I merely want a wiki implementation for Koha is best suited to growing
with the growth of Koha and the growing diversity of the community.


5.3.  ADMINISTRATIVE AND ACCESSIBILTY ISSUES.

> while ignoring its
> many configuration and accessibility problems

Administering MediaWiki has a much heavier administrative burden than
administering DokuWiki.  I am willing to take the time to learn and
implement the most helpful techniques, extensions, and bots to use for
both easing the administrative burden and enabling the features which
would make the greater effort required worthwhile.  Did you mean to refer
to anything else, aside from administrative complexity, in terms of
configuration problems?

We do not need to implement captcha images which lack an audio alternative
in MediaWiki.  Obviously, the fact that no one has written the code for an
audio alternative for the MediaWiki captcha extension is unfortunate but
we can avoid the problem altogether.

Do you know of any other accessibility issues for MediaWiki and are they
any worse than accessibility problems of DokuWiki?  Serious attention
seems to be given to accessibility for MediaWiki,
http://blind.wikia.com/wiki/Mediawiki_and_Accessibility .  Guidelines have
been written for maintaining good accessibility for Wikipedia articles,
http://en.wikipedia.org/wiki/Wikipedia:Accessibility

Historically I have had problems with JavaScript in both MediaWiki and
DokuWiki but I have not had such problems in the past couple of years.


5.4.  WIKI DEFINITION.

> and that it arguably is
> not even a wiki.

How is MediaWiki not a wiki?  Do you mean that MediaWiki does not support
camel case links without an extension?

Camel case wiki links can be activated in MediaWiki if we need them.  I do
not find it helpful that referring to BibLibre, BnF, ByWater, ePUB, or
LibLime in DokuWiki produces perhaps unintended wiki links automatically
but not the use of other names not containing Camel case.  Camel case wiki
links can be turned off in DokuWiki.  People should express their
preference for or against camel case.

I presume that a design providing for collaboration in creating and
editing content and a simple markup syntax relative to HTML would be
criteria for identifying a wiki.

The first wiki created does not seem to have the one and only canonical
syntax which may be good for the development of wikis.  Perhaps there
should be a W3C standard for wiki syntax but I do not know of any effort
to create a truly common standard amongst wikis.

>
>
> I'm not going to Fisk the whole essay, but I'll comment on a few:
>


5.5.  MULTILINGUAL IMPLEMENTATION.

> Is "a good multi-lingual implementation of MediaWiki" even possible?
> If so, why doesn't Wikipedia use one?  Wikipedia's current
> wiki-per-language implementation is very frustrating to use.  Have you
> tried it?  If you switch language, you can go two clicks on and then
> not have a way back to the previous language at all, except by going
> back.

We can have persistent navigation links in addition to page content
specific links in a MediaWiki implementation.

I have created a DNS configuration file which maps every language listed
at http://translate.koha.org/ to a language specific subdomain using the
familiar two letter ISO 639-1 language code where available and the less
familiar three letter ISO 639-2 code where no two letter code is
available.  I have interpolated a code with a hyphen for some language
dialects or other variants which may need separate localisation for
linguistic or cultural reasons and for which no ISO 639-2 code exists.

Configuring a MediaWiki family well is a little tricky and I prefer to
leave English as the only wiki until I have had time to test an
implementation on my own server to have confidence that my first attempted
multilingual implementation will not break MediaWiki on the Equinox
server.

I have been studying the Wikimedia Foundation configuration files,
http://noc.wikimedia.org/conf/ , not to slavishly copy them but to learn
who they are used to manage such large wikis.

> Also, if some page does not exist in a language, it often isn't
> linked on that language's subdomain, so you probably won't know it
> exists in *any* language.

Searching can be configured to function globally for all MediaWiki wikis
in a wiki family which would consequently work across different languages.

> For projects like Koha which are actually
> multilingual, where some things might exist in French or Spanish
> before English, this is bad.

We should encourage users to create at least an empty page in the English
wiki for any content which they are creating in a localised wiki alone.  A
bot might be used to correct the problem.

Much MediaWiki administration is accomplished using bots.  I created a
page at mediawiki.org correcting for some deficiency in identifying
helpful bots, http://meta.wikimedia.org/wiki/Lists_of_bots .


5.6.  REVIEW OF REASONING ISSUES.

>
>
> Popularity: if user numbers decided things, we'd all be using whatever
> ILSes dominate our sectors.  They don't and we use Koha.

I agree that mere general popularity should not govern individual choice.
Where collaboration is required for a wiki to serve its intended purpose
and we cannot switch wikis with a simple system preference, then we need
to take a choice as a community.  After we have been able to run a
suitable test, then we should be able to have a vote.  I like Galen's idea
of voting by use over time but I have some concern that a comparison may
not be sufficiently fair without multiple competing community
implementations.

>
> Configuration problems: most MediaWiki sites have settings which are
> fine for wikipedia but are poor for small projects.  My obvious example
> is the copyright and terms pages.  Are you sure you can get them all?
>
> Accessibility problems: I often can't add links to wikipedia because
> it always wants me to pass an evil eyetest.  If that is switched off,
> does it have any proper spam defences?

There are many extensions which provide spam protection in MediaWiki.  We
should not use an extension which causes accessibility problems.
MediaWiki installations are reported to be  popular spam targets, however,
without having the popularity of Wikimedia foundation sites such as
Wikipedia, the Koha community should not need to use spam defences which
are not implemented reasonably.

We once solved spam problems on the Koha wiki by simply imposing an
htaccess password form with the password embedded in the form information
label for easy entry by humans.  Spam problems later subsided as a
consequence and we later removed the htaccess form without adverse
consequence.

>
> Not even a wiki: compare
> http://www.c2.com/cgi/wiki?TextFormattingRules
> http://www.mediawiki.org/wiki/Help:Formatting
>
> Bold, italics and rules are the same, but most of the rest is often
> wildly different and usually mediawiki gets much more complex.
> Mediawiki often looks better, but the cost is much ease of editing.

People are not required to use the full expressive complexity of a
particular syntax.  However, I recognise that inconsistencies in MediaWiki
syntax for links are unfortunate.  Every syntax has some oddities which
are a point of difficulty.  DokuWiki syntax for namespace creation is a
difficulty in DokuWiki.

Here is a point where popularity ought to matter because MediaWiki syntax
is most familiar to the largest numbers of people.  Spanish is simpler and
easier to use than English but English is understood by more people in
common and thus more suitable as a global common communication language.

I note in that reference that the advantage which DokuWiki once had over a
syntax issue which is of importance to me is now an advantage for
MediaWiki.  DokuWiki provides for 5 levels of section headings while
MediaWiki now provides for 6.  As I had stated in my previous message I
may be the only one who has created content in the Koha wiki which used 5
levels of section headings.

New feature elements for reducing complexity in editing the most complex
content on MediaWiki pages have been announced for implementation on
Wikimedia Foundation sites such as Wikipedia from the development branch
of MediaWiki.  I suspect that it would take several months before such new
features for reducing the complexity in complex content to be included in
a stable release of MediaWiki.

[...]

> Does everyone realise that most wikis can do categories, through
> backlinks of Category pages?
>
> See for example http://www.c2.com/cgi/wiki?CategoryCategory

Every wiki certainly has some means for creating categories.  The issue
which I treated at length in my previous message is the range of features
which help the user make use of categories to find content.  Please see my
previous message for that discussion,
http://old.nabble.com/Re%3A-wiki.koha-community.org-p27860816.html .

>
> It's not something anyone has really tried to add to wiki.koha.org
> yet, but it's there and ready to use if anyone wants to start linking
> pages to Category pages.

As I have documented in my previous post their are means of implementing
categories in DokuWiki particularly with some plugins.  However, the
support for the use of categories in MediaWiki particularly with a larger
set of extensions seems much better to me for serving the purpose of
enabling users to find relevant content.


6.  TAKING DECISIONS.

>  No need to junk the wiki software, but maybe
> we can do better than dokuwiki.  I really don't see mediawiki as a
> step forwards, though.  Is there still time to reconsider?

Firstly, no decision has clearly been taken other than the start of a
mostly yet unconfigured MediaWiki implementation provided by Equinox.  I
identified a problem for URLs further above for which we should drop the
database and start again in a new subdirectory on the file system before
anyone adds any significant content.

My significant experience with DokuWiki and what I have learnt from
studying MediaWiki persuades me that DokuWiki is only the second best
choice.  However, I suspend a proper conclusion until concluding proper
testing.  I have investigated other options but we should all be open to
good suggestions.

Do you object to testing in use as Galen had suggested?  I am willing to
spend the time to move any content created in a wiki implementation tested
in use to whatever wiki implementation the community would choose.

We should always have time to reconsider any decision once a decision once
a decision would actually be taken.

[...]


Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY  10003
USA
http://www.agogme.com
+1 212-674-3783



_______________________________________________
Koha mailing list
[hidden email]
http://lists.katipo.co.nz/mailman/listinfo/koha
Reply | Threaded
Open this post in threaded view
|

Re: wiki.koha-community.org

nengard
I'm bumping this back up since it came up in today's meeting and I had
to leave.  The new wiki is ready for content and I have been adding
some (as have others).  I know that using namespaces seems important,
but it's just too time consuming and too hard for people (as we can
see by the mess that was the old wiki).  I recommend that we create
subdomains for each different language and let people write content in
their own languages.  Page names
(http://wiki.koha-community.org/wiki/index.php/Special:AllPages)
should be clear and easy to understand and ease to find via search.
To keep things organized I have created a few categories and we can
all keep adding categories
(http://wiki.koha-community.org/wiki/index.php/Special:Categories) as
we think of them.  This way we can browse the wiki if we want.

The most important thing right now is making the move to the new wiki
and this is the quickest way to do that.

Thanks,
Nicole

On Thu, Apr 22, 2010 at 5:13 PM, Thomas Dukleth <[hidden email]> wrote:

> Rely inline:
>
>
> On Thu, April 15, 2010 10:20, MJ Ray wrote:
>> Thomas Dukleth wrote:
>>> For those who lack sufficient time to consider proper reasoning, I
>>> present
>>> my brief conclusion before the analysis on which it is based.  I favour
>>> testing a good multi-lingual implementation of MediaWiki modeled largely
>>> on the Wikipedia implementation which I expect to be the best wiki
>>> choice
>>> for the long term future of the Koha project, especially in relation to
>>> support for internationalisation. [...]
>>
>
>
> 1.  AVAILABLE TIME.
>
>> Oops! I've even lacked sufficient time to read this email until now!
>
> I have mostly not had sufficient time to attend to the mailing list
> recently myself.
>
> [I have been collaborating with another programmer on a sadly non-library
> related project which must be finished before I turn into a pumpkin.  When
> the person with whom I have been collaborating has disappeared for a few
> days at a time, then I have had some time for Koha.  Finishing the project
> which is keeping me from Koha is a better time availability remedy for me
> but that remedy has not been solely dependent upon me.]
>
> I should have some more time for the wiki next week.
>
>
> 2.  CONCISE EXPRESSIONS.
>
>> Is it proper reasoning if it can't be expressed concisely? ;-)
>
> My personal preference is to show reasons, evidence which underlies
> reasons, and relevant background to enable people to have an opportunity
> to properly understand the strength or mistakes of my reasoning and offer
> their own alternatives with common points of reference.  There are some
> irreducible complexities in the world which deserve due consideration.  I
> always try to avoid easily formed oversimplification.  However, I am
> mindful of the helpful preference for concise expression.  I often lack
> the time to prepare work which is both thorough and concise.
>
> In the present case, I think that my effort has not progressed quite far
> enough for me to be both concise and informative.  I should be able to
> give a concise expression of reasons at a later point.
>
> I do not seek obfuscation by trying to give detailed information for those
> who care to read at length.  Lack of concisely expressed reasoning should
> not be presumed to be the same as reasoning which could not be expressed
> concisely.
>
> When I have had the time to test an implementation sufficiently, then I
> should also have time to express my reasoning concisely.  I have only
> advocated testing the utility of MediaWiki but not formed a necessary
> conclusion over a test which has not yet been sufficiently configured and
> conducted.
>
>
> 3.  WIKI CONTENT RELICENSING.
>
>>
>> I'm happy to see that the content licensing might be solved as a
>> consequence
>
> PTFS now controls the uncast LibLime vote for relicensing some significant
> wiki content.  I am still hopeful that PTFS will express themselves
> favourably on such a minor issue to avoid the need to rewrite some helpful
> content contributed by LibLime which would be well worth transferring to
> any new wiki.
>
>
> 4.  WIKI FARMING.
>
>> and that people are willing to work on farming the wiki,
>
> I am willing to put much work into a wiki in whatever form people agree
> the wiki should take.  Perhaps the reference is to coordinated wiki farms
> or families which are used by the Mediawiki foundation for multilingual
> wikis, http://www.mediawiki.org/wiki/Manual:Wiki_family .
>
>
> 5.  WIKI CHOICE.
>
>> but I don't believe that mediawiki is the best (or even a good) solution.
>
> I gave some reasons in my previous message about why I think that
> MediaWiki is a good choice relative to various problems which I found in
> my extensive experience working with DokuWiki,
> http://old.nabble.com/Re%3A-wiki.koha-community.org-p27860816.html .  One
> of my most significant findings is that plugins which help resolve
> problems that I have found with DokuWiki resolve those problems by making
> DokuWiki more like MediaWiki.
>
>
> 5.1.  EXERCISING CHOICE.
>
>>
>> To be clear, I am disappointed with the preselection of mediawiki
>
> I only just now noticed that the subdomain wiki.koha-community.org
> resolves to something.  Thankfully the link from koha-community.org does
> not point to the new subdomain.  I have never advocated preselecting a new
> wiki.  In my previous message, I had advocated setting up a test
> installation of MediaWiki.  I had presumed that after a test would be
> fully configured and available for testing for a period of time, we could
> then vote on whether such an installation would be a good choice for the
> Koha community.
>
> Galen Charleton identified the fact that [aside from the criticism of the
> 'heaviness' of MediaWiki implementations given by Frédéric Demain] no one
> had raised an objection to using MediaWiki.  Obviously, you have now and
> any serious objection deserves serious consideration by everyone
> interested.  I had raised the issue with Galen that we should have a
> formal vote after a suitable test.
>
> Galen suggested to me selecting according to what wiki would actually be
> used in practise.  People would vote with their use.  I find Galen's
> suggestion of voting according to use appealing, although, I had not
> properly considered some possible issues of fairness in how the
> alternatives are presented if MediaWiki would be the only new alternative
> and the old Koha wiki would be the only DokuWiki alternative presented.
> Galen's suggestion has certainly provided me with the motivation to
> resolve implementation issues more quickly than I might have otherwise
> given my constraint of time from other work.
>
> I have been working on issues which needed to be addressed for the
> MediaWiki installation hosted by Equinox.  Galen has done a good job of
> starting that installation with daily database dumps and version control
> in Git for any modifications of the scripts but a few important initial
> configuration issues have been missed.
>
> The MediaWiki database needs to be dropped and reinstalled with the
> MediaWiki in a slightly different directory within the home directory for
> the wiki to avoid the namespace collision currently preventing the use of
> cool short URLs familiar to users of Wikimedia foundation installations of
> MediaWiki such as Wikipedia,
> http://www.mediawiki.org/wiki/Manual:Short_URL .  There may be a way of
> correcting the issue without dropping the database but especially without
> any significant content yet dropping the database would be the easiest
> remedy.
>
> I think that wiki.koha-community.org should merely direct users to an
> appropriately localised wiki similar to what is done from
> http://www.wikipedia.org .  A simple change in DNS and Apache
> configuration could provide for language specific subdomains.
>
>
> 5.2.  REASONS INVOKING POPULARITY.
>
>> apparently mainly on grounds of popularity (which is repeated to argue
>> for everything from translations to scalability),
>
> My appeal to popularity in the reasons which I gave favouring MediaWiki in
> my recent previous message merely identified the high demand from users
> and that the large MediaWiki development community which followed from the
> popularity.  Those two consequences of popularity should help to ensure
> that MediaWiki would continue to be an especially scalable and featureful
> wiki into the future.  I never favour popularity for its own sake and
> usually favour choices which are only popular with the well informed
> minority and not the public at large.
>
> I merely want a wiki implementation for Koha is best suited to growing
> with the growth of Koha and the growing diversity of the community.
>
>
> 5.3.  ADMINISTRATIVE AND ACCESSIBILTY ISSUES.
>
>> while ignoring its
>> many configuration and accessibility problems
>
> Administering MediaWiki has a much heavier administrative burden than
> administering DokuWiki.  I am willing to take the time to learn and
> implement the most helpful techniques, extensions, and bots to use for
> both easing the administrative burden and enabling the features which
> would make the greater effort required worthwhile.  Did you mean to refer
> to anything else, aside from administrative complexity, in terms of
> configuration problems?
>
> We do not need to implement captcha images which lack an audio alternative
> in MediaWiki.  Obviously, the fact that no one has written the code for an
> audio alternative for the MediaWiki captcha extension is unfortunate but
> we can avoid the problem altogether.
>
> Do you know of any other accessibility issues for MediaWiki and are they
> any worse than accessibility problems of DokuWiki?  Serious attention
> seems to be given to accessibility for MediaWiki,
> http://blind.wikia.com/wiki/Mediawiki_and_Accessibility .  Guidelines have
> been written for maintaining good accessibility for Wikipedia articles,
> http://en.wikipedia.org/wiki/Wikipedia:Accessibility
>
> Historically I have had problems with JavaScript in both MediaWiki and
> DokuWiki but I have not had such problems in the past couple of years.
>
>
> 5.4.  WIKI DEFINITION.
>
>> and that it arguably is
>> not even a wiki.
>
> How is MediaWiki not a wiki?  Do you mean that MediaWiki does not support
> camel case links without an extension?
>
> Camel case wiki links can be activated in MediaWiki if we need them.  I do
> not find it helpful that referring to BibLibre, BnF, ByWater, ePUB, or
> LibLime in DokuWiki produces perhaps unintended wiki links automatically
> but not the use of other names not containing Camel case.  Camel case wiki
> links can be turned off in DokuWiki.  People should express their
> preference for or against camel case.
>
> I presume that a design providing for collaboration in creating and
> editing content and a simple markup syntax relative to HTML would be
> criteria for identifying a wiki.
>
> The first wiki created does not seem to have the one and only canonical
> syntax which may be good for the development of wikis.  Perhaps there
> should be a W3C standard for wiki syntax but I do not know of any effort
> to create a truly common standard amongst wikis.
>
>>
>>
>> I'm not going to Fisk the whole essay, but I'll comment on a few:
>>
>
>
> 5.5.  MULTILINGUAL IMPLEMENTATION.
>
>> Is "a good multi-lingual implementation of MediaWiki" even possible?
>> If so, why doesn't Wikipedia use one?  Wikipedia's current
>> wiki-per-language implementation is very frustrating to use.  Have you
>> tried it?  If you switch language, you can go two clicks on and then
>> not have a way back to the previous language at all, except by going
>> back.
>
> We can have persistent navigation links in addition to page content
> specific links in a MediaWiki implementation.
>
> I have created a DNS configuration file which maps every language listed
> at http://translate.koha.org/ to a language specific subdomain using the
> familiar two letter ISO 639-1 language code where available and the less
> familiar three letter ISO 639-2 code where no two letter code is
> available.  I have interpolated a code with a hyphen for some language
> dialects or other variants which may need separate localisation for
> linguistic or cultural reasons and for which no ISO 639-2 code exists.
>
> Configuring a MediaWiki family well is a little tricky and I prefer to
> leave English as the only wiki until I have had time to test an
> implementation on my own server to have confidence that my first attempted
> multilingual implementation will not break MediaWiki on the Equinox
> server.
>
> I have been studying the Wikimedia Foundation configuration files,
> http://noc.wikimedia.org/conf/ , not to slavishly copy them but to learn
> who they are used to manage such large wikis.
>
>> Also, if some page does not exist in a language, it often isn't
>> linked on that language's subdomain, so you probably won't know it
>> exists in *any* language.
>
> Searching can be configured to function globally for all MediaWiki wikis
> in a wiki family which would consequently work across different languages.
>
>> For projects like Koha which are actually
>> multilingual, where some things might exist in French or Spanish
>> before English, this is bad.
>
> We should encourage users to create at least an empty page in the English
> wiki for any content which they are creating in a localised wiki alone.  A
> bot might be used to correct the problem.
>
> Much MediaWiki administration is accomplished using bots.  I created a
> page at mediawiki.org correcting for some deficiency in identifying
> helpful bots, http://meta.wikimedia.org/wiki/Lists_of_bots .
>
>
> 5.6.  REVIEW OF REASONING ISSUES.
>
>>
>>
>> Popularity: if user numbers decided things, we'd all be using whatever
>> ILSes dominate our sectors.  They don't and we use Koha.
>
> I agree that mere general popularity should not govern individual choice.
> Where collaboration is required for a wiki to serve its intended purpose
> and we cannot switch wikis with a simple system preference, then we need
> to take a choice as a community.  After we have been able to run a
> suitable test, then we should be able to have a vote.  I like Galen's idea
> of voting by use over time but I have some concern that a comparison may
> not be sufficiently fair without multiple competing community
> implementations.
>
>>
>> Configuration problems: most MediaWiki sites have settings which are
>> fine for wikipedia but are poor for small projects.  My obvious example
>> is the copyright and terms pages.  Are you sure you can get them all?
>>
>> Accessibility problems: I often can't add links to wikipedia because
>> it always wants me to pass an evil eyetest.  If that is switched off,
>> does it have any proper spam defences?
>
> There are many extensions which provide spam protection in MediaWiki.  We
> should not use an extension which causes accessibility problems.
> MediaWiki installations are reported to be  popular spam targets, however,
> without having the popularity of Wikimedia foundation sites such as
> Wikipedia, the Koha community should not need to use spam defences which
> are not implemented reasonably.
>
> We once solved spam problems on the Koha wiki by simply imposing an
> htaccess password form with the password embedded in the form information
> label for easy entry by humans.  Spam problems later subsided as a
> consequence and we later removed the htaccess form without adverse
> consequence.
>
>>
>> Not even a wiki: compare
>> http://www.c2.com/cgi/wiki?TextFormattingRules
>> http://www.mediawiki.org/wiki/Help:Formatting
>>
>> Bold, italics and rules are the same, but most of the rest is often
>> wildly different and usually mediawiki gets much more complex.
>> Mediawiki often looks better, but the cost is much ease of editing.
>
> People are not required to use the full expressive complexity of a
> particular syntax.  However, I recognise that inconsistencies in MediaWiki
> syntax for links are unfortunate.  Every syntax has some oddities which
> are a point of difficulty.  DokuWiki syntax for namespace creation is a
> difficulty in DokuWiki.
>
> Here is a point where popularity ought to matter because MediaWiki syntax
> is most familiar to the largest numbers of people.  Spanish is simpler and
> easier to use than English but English is understood by more people in
> common and thus more suitable as a global common communication language.
>
> I note in that reference that the advantage which DokuWiki once had over a
> syntax issue which is of importance to me is now an advantage for
> MediaWiki.  DokuWiki provides for 5 levels of section headings while
> MediaWiki now provides for 6.  As I had stated in my previous message I
> may be the only one who has created content in the Koha wiki which used 5
> levels of section headings.
>
> New feature elements for reducing complexity in editing the most complex
> content on MediaWiki pages have been announced for implementation on
> Wikimedia Foundation sites such as Wikipedia from the development branch
> of MediaWiki.  I suspect that it would take several months before such new
> features for reducing the complexity in complex content to be included in
> a stable release of MediaWiki.
>
> [...]
>
>> Does everyone realise that most wikis can do categories, through
>> backlinks of Category pages?
>>
>> See for example http://www.c2.com/cgi/wiki?CategoryCategory
>
> Every wiki certainly has some means for creating categories.  The issue
> which I treated at length in my previous message is the range of features
> which help the user make use of categories to find content.  Please see my
> previous message for that discussion,
> http://old.nabble.com/Re%3A-wiki.koha-community.org-p27860816.html .
>
>>
>> It's not something anyone has really tried to add to wiki.koha.org
>> yet, but it's there and ready to use if anyone wants to start linking
>> pages to Category pages.
>
> As I have documented in my previous post their are means of implementing
> categories in DokuWiki particularly with some plugins.  However, the
> support for the use of categories in MediaWiki particularly with a larger
> set of extensions seems much better to me for serving the purpose of
> enabling users to find relevant content.
>
>
> 6.  TAKING DECISIONS.
>
>>  No need to junk the wiki software, but maybe
>> we can do better than dokuwiki.  I really don't see mediawiki as a
>> step forwards, though.  Is there still time to reconsider?
>
> Firstly, no decision has clearly been taken other than the start of a
> mostly yet unconfigured MediaWiki implementation provided by Equinox.  I
> identified a problem for URLs further above for which we should drop the
> database and start again in a new subdirectory on the file system before
> anyone adds any significant content.
>
> My significant experience with DokuWiki and what I have learnt from
> studying MediaWiki persuades me that DokuWiki is only the second best
> choice.  However, I suspend a proper conclusion until concluding proper
> testing.  I have investigated other options but we should all be open to
> good suggestions.
>
> Do you object to testing in use as Galen had suggested?  I am willing to
> spend the time to move any content created in a wiki implementation tested
> in use to whatever wiki implementation the community would choose.
>
> We should always have time to reconsider any decision once a decision once
> a decision would actually be taken.
>
> [...]
>
>
> Thomas Dukleth
> Agogme
> 109 E 9th Street, 3D
> New York, NY  10003
> USA
> http://www.agogme.com
> +1 212-674-3783
>
>
>
> _______________________________________________
> Koha mailing list
> [hidden email]
> http://lists.katipo.co.nz/mailman/listinfo/koha
>
_______________________________________________
Koha mailing list
[hidden email]
http://lists.katipo.co.nz/mailman/listinfo/koha
Reply | Threaded
Open this post in threaded view
|

Re: wiki.koha-community.org

Galen Charlton-3
In reply to this post by Thomas Dukleth-3
Hi,

On Apr 22, 2010, at 5:13 PM, Thomas Dukleth wrote:
> The MediaWiki database needs to be dropped and reinstalled with the
> MediaWiki in a slightly different directory within the home directory for
> the wiki to avoid the namespace collision currently preventing the use of
> cool short URLs familiar to users of Wikimedia foundation installations of
> MediaWiki such as Wikipedia,
> http://www.mediawiki.org/wiki/Manual:Short_URL .  There may be a way of
> correcting the issue without dropping the database but especially without
> any significant content yet dropping the database would be the easiest
> remedy.

I've implemented shorter URLs; e.g., the link to the IRC meetings page is now

http://wiki.koha-community.org/wiki/IRC_Meetings

I note that it was not necessary to drop the database; MediaWiki's database schema does not bake the URL prefix into its notion of a page.

Regards,

Galen
--
Galen Charlton
VP, Data Services
Equinox Software, Inc. / Your Library's Guide to Open Source
email:  [hidden email]
direct: +1 352-215-7548
skype:  gmcharlt
web:    http://www.esilibrary.com/

_______________________________________________
Koha mailing list
[hidden email]
http://lists.katipo.co.nz/mailman/listinfo/koha
Reply | Threaded
Open this post in threaded view
|

Re: wiki.koha-community.org

Galen Charlton-3
In reply to this post by MJ Ray-2
Hi,

On Apr 15, 2010, at 6:20 AM, MJ Ray wrote:
> Configuration problems: most MediaWiki sites have settings which are
> fine for wikipedia but are poor for small projects.  My obvious example
> is the copyright and terms pages.  Are you sure you can get them all?

Yes.  The GPL banner is in place and the on the editing form updated to specify that the default license for new content is GPL 2 or later.  The default MediaWiki installation does not otherwise pre-populate pages like the copyright and privacy policies; they can be readily edited.

> Accessibility problems: I often can't add links to wikipedia because
> it always wants me to pass an evil eyetest.  If that is switched off,
> does it have any proper spam defences?

I propose to use the ConfirmEdit extension and its SimpleCaptcha option [1], which presents a text-based addition or subtraction math problem, for new account registrations and edits that add external URLs.  If (well, when) spam presents itself as a problem, we'll deal with it as it occurs.

[1] http://www.mediawiki.org/wiki/Extension:ConfirmEdit

Regards,

Galen
--
Galen Charlton
VP, Data Services
Equinox Software, Inc. / Your Library's Guide to Open Source
email:  [hidden email]
direct: +1 352-215-7548
skype:  gmcharlt
web:    http://www.esilibrary.com/

_______________________________________________
Koha mailing list
[hidden email]
http://lists.katipo.co.nz/mailman/listinfo/koha
Reply | Threaded
Open this post in threaded view
|

Re: wiki.koha-community.org

MJ Ray-2
In reply to this post by Thomas Dukleth-3
Thomas Dukleth wrote:

> On Thu, April 15, 2010 10:20, MJ Ray wrote:
> > Is it proper reasoning if it can't be expressed concisely? ;-)
>
> My personal preference is to show reasons, evidence which underlies
> reasons, and relevant background to enable people to have an opportunity
> to properly understand the strength or mistakes of my reasoning and offer
> their own alternatives with common points of reference.  There are some
> irreducible complexities in the world which deserve due consideration.  I
> always try to avoid easily formed oversimplification.  However, I am
> mindful of the helpful preference for concise expression.  I often lack
> the time to prepare work which is both thorough and concise.

At the moment, it feels to me that this discussion is falling between
two stools:
 - it's too long/complex for most of the community to participate;
 - it contains unreferenced incorrect/incomplete claims (English/Spanish
below, for example).

Given the choice, I'd go for quick non-repeated points with references
in a short discussive post, then summarise comprehensively before
checking for consensus if needed.

> [...]  Perhaps the reference is to coordinated wiki farms
> or families which are used by the Mediawiki foundation for multilingual
> wikis, http://www.mediawiki.org/wiki/Manual:Wiki_family .

Sorry, WikiFarmer is a less offensive-to-some name for
http://c2.com/cgi/wiki?WikiFaeries
but I didn't realise it wasn't known widely.

> > but I don't believe that mediawiki is the best (or even a good) solution.
>
> I gave some reasons in my previous message about why I think that
> MediaWiki is a good choice relative to various problems which I found in
> my extensive experience working with DokuWiki,
> http://old.nabble.com/Re%3A-wiki.koha-community.org-p27860816.html .  One
> of my most significant findings is that plugins which help resolve
> problems that I have found with DokuWiki resolve those problems by making
> DokuWiki more like MediaWiki.

I replied in
http://old.nabble.com/Re%3A-wiki.koha-community.org-p28253661.html to
give reasons why those findings looked to me to contain confusion
about how other wikis do most of those tasks.  I suggest this is due to
over-exposure to mediawiki and lack of familiarity with quicker wikis.

We can re-cite previous messages from this thread but it doesn't help
make progress.  I'm trimming a lot because the email looked like
it was repeating the same few reasons many time.

> My appeal to popularity in the reasons which I gave favouring MediaWiki in
> my recent previous message merely identified the high demand from users
> and that the large MediaWiki development community which followed from the
> popularity.  Those two consequences of popularity should help to ensure
> that MediaWiki would continue to be an especially scalable and featureful
> wiki into the future. [...]

Why?  As someone who used to study time series statistics, I've seen
many times when the past doesn't help predict the future.  The
conditions around the project don't suggest the stability for such
predictions to be useful, such as the continuing appeal for donations
by the project host and its strategic plan looking fairly short-term.

Why would those features be right for us?  MediaWiki development
appears to be dominated by encyclopaedias, which have rather different
aims to project development documentation.  Are there things on
http://www.mediawiki.org/wiki/MediaWiki_roadmap
which we actually need?

Need we even care about upstream development much if the features we
need now are already present and new ones are easy for us to develop?

Wikis should be quick.  It's what wiki means, after all.  MediaWiki
complicates a simple idea and tries to bend it into a CMS.  If we want
a fuller CMS, the community knows other ones better already (Kete,
drupal, django-blocks).

> [...] Did you mean to refer to anything else, aside from
> administrative complexity, in terms of configuration problems?

I don't remember if there was anything else after this time, but
administrative complexity was the main concern.

> We do not need to implement captcha images which lack an audio alternative
> in MediaWiki.  Obviously, the fact that no one has written the code for an
> audio alternative for the MediaWiki captcha extension is unfortunate but
> we can avoid the problem altogether.

Audio alternatives are not a solution: a higher proportion (40% IIRC)
fail typical web hearing tests than eyetests, so there is a
significant overlap who will fail both.

Please do not call eyetests and hearing tests CAPTCHA.  The "CHA" bit
stands for "tell Computers and Humans Apart" and ability tests cannot
do that, because not all humans have those abilities.

> Do you know of any other accessibility issues for MediaWiki and are they
> any worse than accessibility problems of DokuWiki?

If we can agree that the default stylesheets for both are poor and would
need replacement, then it's mainly the eyetest.

> Serious attention
> seems to be given to accessibility for MediaWiki,
> http://blind.wikia.com/wiki/Mediawiki_and_Accessibility [...]

Is that serious attention, last modified over a year ago?

> 5.4.  WIKI DEFINITION.
>
> > and that it arguably is
> > not even a wiki.
>
> How is MediaWiki not a wiki?  Do you mean that MediaWiki does not support
> camel case links without an extension?

It's not quick and uses something much more complex than the
TextFormattingRules.

> Camel case wiki links can be activated in MediaWiki if we need them.  I do
> not find it helpful that referring to BibLibre, BnF, ByWater, ePUB, or
> LibLime in DokuWiki produces perhaps unintended wiki links automatically
> but not the use of other names not containing Camel case. [...]

Shouldn't the wiki have pages defining those terms, even if just as a
quick pointer?  Accidental links aren't necessarily bad.

> 5.5.  MULTILINGUAL IMPLEMENTATION.
>
> > Is "a good multi-lingual implementation of MediaWiki" even possible?
> > If so, why doesn't Wikipedia use one?  Wikipedia's current
> > wiki-per-language implementation is very frustrating to use.  Have you
> > tried it?  If you switch language, you can go two clicks on and then
> > not have a way back to the previous language at all, except by going
> > back.
>
> We can have persistent navigation links in addition to page content
> specific links in a MediaWiki implementation.  [...]

If persistent navigation links would simply link to the top pages of
those other languages, then that seems less helpful than going back.

So I am really doubtful that DNS is better than the Accept-Language
HTTP request header, possibly overridden by URL path or cookie.

As I understand it, using DNS means that they are distinct wikis,
increasing the wiki administration and management problems by some
multiple of the number of languages.

> > Also, if some page does not exist in a language, it often isn't
> > linked on that language's subdomain, so you probably won't know it
> > exists in *any* language.
>
> Searching can be configured to function globally for all MediaWiki wikis
> in a wiki family which would consequently work across different languages.

How would a reader know in what language to enter the search term?

> > For projects like Koha which are actually
> > multilingual, where some things might exist in French or Spanish
> > before English, this is bad.
>
> We should encourage users to create at least an empty page in the English
> wiki for any content which they are creating in a localised wiki alone.  A
> bot might be used to correct the problem.
>
> Much MediaWiki administration is accomplished using bots.  I created a
> page at mediawiki.org correcting for some deficiency in identifying
> helpful bots, http://meta.wikimedia.org/wiki/Lists_of_bots .

Most bots seem like a crutch to overcome poor design decisions.  Poor
internationalisation is one such decision.

How many of the 1100 bots active on wikipedia would we need?
http://en.wikipedia.org/wiki/Category:Wikipedia_bots_by_name

Also, historically, the project has struggled to provide stable hosting
for simple IRC bots.  How confident are we that we can host and manage
the subset of bots that we need?

> > Not even a wiki: compare
> > http://www.c2.com/cgi/wiki?TextFormattingRules
> > http://www.mediawiki.org/wiki/Help:Formatting
> >
> > Bold, italics and rules are the same, but most of the rest is often
> > wildly different and usually mediawiki gets much more complex.
> > Mediawiki often looks better, but the cost is much ease of editing.
>
> People are not required to use the full expressive complexity of a
> particular syntax.  However, I recognise that inconsistencies in MediaWiki
> syntax for links are unfortunate.  Every syntax has some oddities which
> are a point of difficulty.  DokuWiki syntax for namespace creation is a
> difficulty in DokuWiki.
>
> Here is a point where popularity ought to matter because MediaWiki syntax
> is most familiar to the largest numbers of people.  Spanish is simpler and
> easier to use than English but English is understood by more people in
> common and thus more suitable as a global common communication language.

As you might expect from a multi-language user, I disagree with that
conclusion about suitability.  There's a lot of other factors besides
popularity to consider when choosing a language.

Moreover, English may be understood by more people than Spanish, but
that's misleading by omission: Ethnologue.org puts the number of
native Chinese [zho] speakers higher than the highest *combined*
native+second-language English speakers estimate I've seen (1.2bn v
0.48bn from the rather controversial
http://www.andaman.org/BOOK/reprints/weber/rep-weber.htm ) so that
argument logically leads to switching the wiki to primarily Chinese.

Of course, that would ignore our project history and probable future,
in a similar way to switching to MediaWiki syntax.

> I note in that reference that the advantage which DokuWiki once had over a
> syntax issue which is of importance to me is now an advantage for
> MediaWiki.  DokuWiki provides for 5 levels of section headings while
> MediaWiki now provides for 6.  As I had stated in my previous message I
> may be the only one who has created content in the Koha wiki which used 5
> levels of section headings.

I hate to criticise someone who's done so much good documenting things,
but I suggest section headings 5-levels deep isn't good wiki style.
At work, we rarely go beyond 3 deep before splitting the topic.

> [...]
> > Does everyone realise that most wikis can do categories, through
> > backlinks of Category pages?
> >
> > See for example http://www.c2.com/cgi/wiki?CategoryCategory
>
> Every wiki certainly has some means for creating categories.  The issue
> which I treated at length in my previous message is the range of features
> which help the user make use of categories to find content.  Please see my
> previous message for that discussion,
> http://old.nabble.com/Re%3A-wiki.koha-community.org-p27860816.html .

I replied in
http://old.nabble.com/Re%3A-wiki.koha-community.org-p28253661.html
that no-one has really tried to add this to wiki.koha.org yet.  I
suggest it's an organisational limitation and not a feature one.

> > It's not something anyone has really tried to add to wiki.koha.org
> > yet, but it's there and ready to use if anyone wants to start linking
> > pages to Category pages.
>
> As I have documented in my previous post their are means of implementing
> categories in DokuWiki particularly with some plugins.  However, the
> support for the use of categories in MediaWiki particularly with a larger
> set of extensions seems much better to me for serving the purpose of
> enabling users to find relevant content.

The search is the way most people find things on wikipedia.  It even
out-ranks the front page.  Even though our community will probably use
classifications more than most, plugin-based category support is
over-complicating a lightweight core feature.  Can we try implementing
categories in the simple WikiWay before playing with plugins, templates
and other similar complications?

> 6.  TAKING DECISIONS.
>
> >  No need to junk the wiki software, but maybe
> > we can do better than dokuwiki.  I really don't see mediawiki as a
> > step forwards, though.  Is there still time to reconsider?
>
> Firstly, no decision has clearly been taken other than the start of a
> mostly yet unconfigured MediaWiki implementation provided by Equinox.
[...]
> Do you object to testing in use as Galen had suggested?  [...]

Well, testing in use sounds like a popularity contest by another name.
I predict at least two large disturbances in this choice:
  1. familiarity of mediawiki sites;
  2. the TEAM effect, where many vote for the glossier-looking option
and few have to work with it (TEAM = "Toll! Ein anderer macht's", or
"great! Someone else will do it").

How can we structure the choice to minimise the effects of those?

Thanks,
--
MJ Ray (slef)  Webmaster and LMS developer at     | software
www.software.coop http://mjr.towers.org.uk        |  .... co
IMO only: see http://mjr.towers.org.uk/email.html |  .... op

_______________________________________________
Koha mailing list
[hidden email]
http://lists.katipo.co.nz/mailman/listinfo/koha
Reply | Threaded
Open this post in threaded view
|

Re: wiki.koha-community.org

Reed Wade
[ lot's of words deleted ]

What's the downside of making a wrong decision?

What can be done to make a decision is quickly as possible so we can
move forward?

-reed
_______________________________________________
Koha mailing list
[hidden email]
http://lists.katipo.co.nz/mailman/listinfo/koha