I have to agree with much of what Erik is saying here as well. The key
statement for me is "there are of course areas where open source software cannot
(yet) compete." In response the software package being examined is the most
open of those available which meets the Foundation's specific needs.
For those who are not in the know, these needs are threefold: 1) donor
management, 2) press management, and 3) volunteer management (i.e., building a
database of volunteers with specific skills and circumstances, who can respond
to specific tasks, such as a request to interview someone who specializes in
classical music, or someone who has a flatbed scanner at home). Other needs
will likely be identified over time as well. We need a package that can handle
all of the above--the package being examined can do that--and it is generally
open source. In fact, the propritary part is the privacy component, which
means that confidential information about donors and volunteers will not be
accessible to anyone with an internet connection.
I do not think it lies within the scope of our mission to provide financial
support for the development of free software alternatives, but I generally
accept Erik's other points, particularly that a partially proprietary solution
is preferable to a fully proprietary one. I would add, however, that we
should not compromise on the quality of our solutions.
Danny
In a message dated 6/25/2006 12:58:29 PM Eastern Daylight Time,
eloquence(a)gmail.com writes:
I won't comment on the specific question, but on the underlying
Wikimedia policy issue.
The Board can decide the policy for software use by the Foundation.
What would a sensible policy look like? I think an a priori "open
source[*] only" policy is problematic since there are of course areas
where open source software cannot (yet) compete. For instance, I'm
not aware of a professional open source optical character recognition
(OCR) solution, which is crucial for digitization.
However, we do need to be aware of the risks of proprietary software:
vendor lock-in, company bankruptcy, no code availability for security
auditing, and so on. Aside from that, supporting open source is an
important matter of outside perception for the Foundation.
How about a policy that states:
- when no adequate (as determined by its prospective users) 100% free
software solution for a task can be found, a proprietary solution may
be used.
- such use needs to be reported and documented in a list of
proprietary software used by the Foundation, so that the decision can
be debated and challenged by the community.
- in such cases, a partially proprietary solution is preferable to a
fully proprietary one.
- a migration plan should be made as soon as a realistic fully open
source alternative emerges.
- the Foundation should, within its budget, support the development of
such an alternative.
Does that make sense?
I have made some new toys that might be of interest:
Instead of waiting for the next database dump and downloading the whole
thing, you can now get a XML dump for all articles in a category and its
subcategories:
http://tools.wikimedia.de/~magnus/cat2xml.php?category=History_Version_0.5_…
Sadly, the toolserver is somewhat broken for use on en, so it doesn't
even know "Category:Wikipedia Version 0.5", but that is someone else's
problem (since ages, I might add). So until this is fixed, you can't get
the complete article texts for 0.5 in one swift motion, but then! ;-)
I have also found a web server (Server2Go) which runs directly from CD
(or the main directory of any drive, including USB sticks). I have
managed to integrate MediaWiki into it. While a MySQL variant is
available, I went for a new MediaWiki database type supporting
plain-text files (read-only at the moment). Back to the roots, I guess ;-)
Anyway, I have created what I hope is a standalone, zero-install
"History Wikipedia 0.5" bundle, currently consisting of a pityful 19
articles. This was done by converting the above mentioned
custom-XML-dump into plain-text articles using a script from my wiki2xml
toy.
Categories don't work, and I was too lazy to set up interlanguage links.
No images either.
Still interested? Try
http://tools.wikimedia.de/~magnus/history05.zip (23MB)
Best to burn the whole thing to a CD, as it /has/ to be in the root
directory. I *did* mention that it's currently Windows-only, right?
Magnus
Responding a.o. to Jimmy's
http://mail.wikipedia.org/pipermail/foundation-l/2006-June/007389.html
Jimmy, I know you value the community with whole your heart. But I cannot
follow in your analysis of how things are going: you say the community is
more and more in control, after all board members and other staff are part
of the community, so essentially the community is 100% in control. But my
concern centers around:
* Increasingly decison are taken by the board without too much prior
discussion in the open, at least on places where I would expect it, like on
this mailing list. I just question this when major foundation issues are
concerned. I'm not talking daily affairs, that is what we have
representatives for, but large decisions that define how Wikimedia is
organised and how it interacts with the rest of the world. From the initial
bylaws, to their most recent pending incarnation, from the jurisdiction of
the board, to the mission of the committees and their leading figures, to
the appointment and tasks of a non-CEO.
Jimmy: "And, it should be strongly pointed out: the committee system is a
*community* system, driven by volunteers, staffed by volunteers (#), and the
committees and the chapters make up the heart and soul of Wikimedia."
(#) I might add 'and created and/or sanctioned by the board'. The board
reigns supremely. This does not make the board evil in any way, or its
members less respectable, it does not discredit the committees or their
members, far from it, all names of committee members that I recognize are of
highly valued community members (I'm not even against any of the committees
or their missions, heck I'm going to apply for a committee on invitation and
of course undergo normal co-optation procedure) it is simply a control
monopoly that I would like to see amended, to strenghten Wikimedia as an
organisation.
I'm not sure I would favour to vote on everything, elections can be
manipulated. Perhaps the tried system of discussing major choices until a
consensus is reached would still work, this list is not flooded by hundreds
of trolls, there is still a limited community interested in these issues.
Also on major issues I'd rather sacrifice speed than quality of decision
making, again on major issues only, and of course judicial emergencies taken
aside. Even better I welcomed your idea for a wikicouncil, but as policy
maker not as advisor, thus approaching the ideal of a Trias Politica, but
noone seems to warm to that idea.
* Several board members recently stated their weariness about discussing
things with the larger community (for quotes eee
http://mail.wikipedia.org/pipermail/foundation-l/2006-May/007321.html ),
although I have to say Anthere still does speak up a lot on this list, so
maybe I make too much out of her remarks. Everyone is entitled to an
occasional slip of the tongue.
* Board expansion is not an issue you say, it just will happen. But there
has been talk, albeit not by you, of appointing board members instead of
holding an election. If that would ever happen, how could anyone not see
that the board would be heading towards splendid isolation?
* The idea that a contractor, possibly an outsider (?), is charged with
paving the way for a true CEO, is yet another example of top down
management. Why should an appointed individual, let alone a possible
outsider, lead this debate, or manage it in any way? Incidentally, I would
be less concerned if the final CEO would only supervise administrative
tasks, like paying the bills and refreshing domain subscriptions, but then I
find the term CEO odd, I call that an office manager.
All of this gives me the feeling the board knows best what is good for the
community, and is more and more leaning towards [p|m]aternalism, to put it
mildly, more than it used to in its first year of existence. The number of
people involved in the decision making structure is growing, with all those
committees and chapters, yet the central role of the board and its do's and
don'ts is what really matters.
All in all I see the dicussion we now have on this mailing list as a very
good thing. The debate is somewhat heated at times, with an occasional
sneering remark, but I'd rather see this debate go on for a while with all
distraction and confusion that it brings, if it strenghtens fundaments of
Wikimedia as an organisation.
Erik Zachte
The Native Cherokee Language Translation Project has posted XML dumps
against enwiki 06-19-2006 at
ftp.wikigadugi.org/wiki
Please feel free to download and review. This translation is using
conjugation, and verb stem decomposition and reconstruction.
Translation runs are posted in Sequoyah Syllabary and text phonetics.
This release has improved the XML parser to support
translation and auto-link generation, Image translation parsing, and
templates. Since the English Wikipedia XML dumps appear to
be supporting multilanguage tags, this version of the translator has
been enabled to convert them into English and then Cherokee
for image control statements (right, rucht, etc.).
The www.wikigadugi.org website has been used for XML translation import
testing for the past several weeks while I corrected
and added support for link translations and tuned the AI engine to
compress, conjugate, and decompose and reconstruct verb stems and
tensing, but the site is fully populated and will remain updated from
now on.
The current translation is up to 92% Cherokee with only less than a 20MB
word list left to be translated and tensed.
There have been several enhancements to the translation to detect and
correct language drift between the various dialects.
There are four dialects of the Cherokee Language:
Otali (Overhill) - spoken in Oklahoma, 30,000 native speakers
Giduwa (Keetoowah) - spoken in North Carolina, 5,000 native speakers
Southern - formerly spoken in Southern Alabama, Southern Georgia and
Florida (Extinct)
Ahniyvwiya - spoken in New Mexico and Missouri (AniKutani), 500 native
speakers (this dialect is the ancient written
form of the Cherokee Language which uses the AniKutani Syllabary, and is
used by the religious organization
for record keeping. Since this dialect was written and numerous ancient
texts exist, the modern spoken form has not
experienced language drift. The Otali dialect has drifted due to
English influences and sentence structure in the
Otali dialect more resembles English than any of the other Cherokee
dialects).
Of the four dialects, only the Giduwa and Ahniyvwiya dialects are still
100% mappable to the Sequoyah Syllabary.
The Otali dialect is approximately 98% mappable however, Otali has
contracted verb roots to the point they are
no longer recognizable in their original form in many words due to
language drift and synthesized newer sounds
and hybridization with English.
"do" is now spoken "to" in many words in Otali
"du" is now spoken "tu" in many words in Otali
"l" has replaced "i" and in some words is a new consruct in the language
as a result in Otali
Many original inflections are now contracted and use English sounds
rather than Syllabary constructs.
The Cherokee New Testament translated by Elias Boudinet and his
associates in the early 1800's is one of the
few surviving documents written in the Giduwa dialect and published
before the language drift began in
Oklahoma, and this older dialect is the most common dialect still
understandable by most modern speakers who speak
in Otali. This dialect forms the basis of this translation with common
words from the Otali dialect
which are still mappable to the Syllabary and corrected words with the
original verb roots. This project has an
additional purpose of forcing stnadardization in our immersion efforts
to prevent further language drift by
restandardizing all written works into the Giduwa dialect and conversion of
non-conforming Otali words back to the Sequoyah Syllabary. Most of the
modern
Cherokee Language spoken in Oklahoma now uses an English Phoetics System
devised by Cherokee Linguist
Dr. Durbin Feeling of Oklahoma University in order to be written
properly to reflect the modern spoken form and
no longer are mappable to the Syllabary.
Internal discussions with Dr. Feeling and other members of this project
have resulted in the conclusion that written Cherokee must use
the Sequoyah Syllabary and we are planning to force standardization to
correct this language drift in all translations. There have been
several committees proposing expanding the syllabary to incorporate the
new sounds, but these efforts may not address the issues of
language drift. When a language is written and forced to use a standard
alphabet or syllabary it typically does not drift much.
These translations now provide the following additional files which
address these issues for our project folks and to force
retranslation of Otali words into Ahniyvwiya or Giduwa dialects. Many
of the words have been resynthesized into
their original forms in order to be mapable to the Syllabary:
Each file set corresponds to a translation run of the wikitrans Cherokee
Machine Translator.
cherokee-syntax-errors-<date>.txt.bz2 - words in Otali dialect not
mappable to the syllabary but displayed in text phonetics in the translation
phwiki-<date>-pages-articles.xml - text phonetic translation
sylwiki-<date>-pages-articles.xml - Sequoyah Syllabary translation
untranslated-log-<date>.txt.bz2 - words not yet translated or mapped to
a thesaraus for their Cherokee equivalents
The end goal is to reduce the untranslated log file output to zero and
achieve 100% by the end of the summer. There has been a lot of debate on
the translation and which dialect structure would have the broadest
coverage. Corrected Otali and Giduwa combined which remap to the
syllabary have been chosen as the current standard for this effort.
The Machine translation is a work in progress.
Jeff Merkey
>
>
Despite not being within the bounds of Wikimedia projects, certain things
can still be useful for other non-Wikimedia projects to pick up in the
future. To accomodate such pages, we could start up a "waiting room" wiki
that would reside there until they can be exported somewhere. For example,
let's say someone writes a very crufty article about The Simpsons. However,
if there isn't a Simpsons-Wiki yet, then the page can be exported to the
waiting room wiki in the meantime. This way, when a Simpsons-Wiki comes to
existence, they can search through the waiting room for content they can
use. They can then export it (conserving the edit history) and import it
onto their wiki.
Another example is if someone writes an article, say, "List of sex symbols."
Obviously not within Wikipedia's goals, however may prove useful for someone
else in the future. In the meantime, it can be exported to the lovely
dumping ground that is the Waiting Room Wiki. Once someone starts some sex
symbol project, they can export the page and use it.
Keep in mind that this is not a Wikimedia project like Wikinews and
Wiktionary are, but something more like the Incubator which is used for our
purposes.
Cheers,
MessedRocker.
(Or James Hare)
hi all,
i would like to share with you some thoughts on (re)organization.
i read that there are plans to put a ceo in place to take care of executive
responsibilities. executive responsibilities are very different from those
of responsible wikians within the projects. so far these things have not
been separated at all, that is understandable for a young and growing
organization, but such cannot last or work well forever.
in my opinion:
1. the only way this organization, its projects and mission, its vitality
and appeal, will survive will be if a strict separation be implemented
between volunteer-work, executive tasks and their respective supervision.
2. separation of executive and project-related responsibilities by
installing an elected council of representatives from the projects is
mandatory.
3. the task of an appointed board should be supervising the work of the
executives, it should be a type of board consisting of very professional
people (the kind which in a way of speaking should have "better things to
do", if you get my meaning), and in general not deal with the projects at
all.
4. the council of representatives should supervise the projects, advise the
executive level, and in general not deal with the board at all.
i could be more elaborate in explaining the rationale behind these thoughts,
but i chose to keep things concise. note however, that i spoke of how
specific tasks, responsibilities and work can be organized, avoiding the
who-does-what, which is not of my concern now.
also these things should definitely not be mixed up.
for what it's worth these are my two euros ;-)
oscar
(Product)^RED (RED is in superscript) is a brand name which works with other
well-known brands to produce a product of which at least 1% of the profit
goes to (Product)^RED, and this goes in aid of helping fight AIDS and
related diseases. See http://joinred.com for information
Why not set up a (Wikipedia)^RED which would essentially be a skin through
which the normal Wikipedia is viewed: it would change the colours to red (or
shades thereof), have a different Main Page which explains the scheme and
has inobtrusive advertisements on the side (under the interwiki links) which
generate revenue to do to (Product)^RED (and Wikimedia).
I think that the aim of this is wholly consistent with that of the Wikimedia
Foundation, and I would like to hear your views.
--
-Daniel (meta.wikimedia.org/wiki/User:Dbmag9)
dbmag9.blogspot.com
The board regularly receives some complaints about checkuser activity
and what happened is either that no one look at the case, or look at
them poorly. In 95% of case, the "abuse" is imaginary; but we can not be
sure that one day there will not be a problem.
So, what I suggest is a sort of ombuds-wo-man for checkuser, who will
offer a sympathetic ear to complainers, take charge of investigating
cases for the board in an official manner, mediate between the checkuser
and the complainer when the case is litigious, educate checkuser if
necessary, and will report to the board in case where there IS a problem.
Additionnaly, this person might have a sort of "overview" over the way
the checkuser system works and may give us suggestions of suitable
modifications of policies. Or recommandations of software changes.
We need to have one or two people specifically named, so as to be able
to say "please, talk to xxx" and to be *sure* a case is taken into
consideration (as opposed to "but I thought someone else was taking care
of this").
Any volunteers ?
PS : if necessary, set up a general email address for abuse reporting,
with an OTRS file.
As announced earlier, the Communications committee is coordinating the
use of the site-wide notices on Wikimedia Foundation sites. Right now,
we need to call attention to Wikimania and encourage people to register,
so starting sometime tomorrow we will be putting up a brief project-wide
notice about this. We expect the notice to run for about a week.
When this use of the site notice ends it should be blanked again (except
for any separate notices to anonymous users being used for fundraising).
We don't want these to be overused, so an extended silent period for the
site notice should follow. After that, the next use will probably be for
the fundraiser, assuming that committee is organized and a date settled on.
--Michael Snow