Hoi,
There is a request for a Wikipedia in Ancient Greek. This request has so far
been denied. A lot of words have been used about it. Many people maintain
their positions and do not for whatever reason consider the arguments of
others.
In my opinion their are a few roadblocks.
- Ancient Greek is an ancient language - the policy does not allow for
it
- Text in ancient Greek written today about contemporary subjects
require the reconstruction of Ancient Greek.
- it requires the use of existing words for concepts that did
not exist at the time when the language was alive
- neologisms will be needed to describe things that did not
exist at the time when the language was alive
- modern texts will not represent the language as it used to be
- Constructed and by inference reconstructed languages are effectively
not permitted
We can change the policy if there are sufficient arguments, when we agree on
a need.
When a text is written in reconstructed ancient Greek, and when it is
clearly stated that it is NOT the ancient Greek of bygone days, it can be
obvious that it is a great tool to learn skills to read and write ancient
Greek but that it is in itself not Ancient Greek. Ancient Greek as a
language is ancient. I have had a word with people who are involved in the
working group that deals with the ISO-639, I have had a word with someone
from SIL and it is clear that a proposal for a code for "Ancient Greek
reconstructed" will be considered for the ISO-639-3. For the ISO-639-6 a
code is likely to be given because a clear use for this code can be given.
We can apply for a code and as it has a use bigger then Wikipedia alone it
clearly has merit.
With modern texts clearly labelled as distinct from the original language,
it will be obvious that innovations a writers needs for his writing are
legitimate.
This leaves the fact that constructed and reconstructed languages are not
permitted because of the notion that mother tongue users are required. In my
opinion, this has always been only a gesture to those people who are dead
set against any and all constructed languages. In the policies there is
something vague "*it must have a reasonable degree of recognition as
determined by discussion (this requirement is being discussed by the language
subcommittee <http://meta.wikimedia.org/wiki/Language_subcommittee>)."* It
is vague because even though the policy talks about a discussion, it is
killed off immediately by stating "The proposal has a sufficient number of
living native speakers to form a viable community and audience." In my
opinion, this discussion for criteria for the acceptance of constructed or
reconstructed languages has not happened. Proposals for objective criteria
have been ignored.
In essence, to be clear about it:
- We can get a code for reconstructed languages.
- We need to change the policy to allow for reconstructed and
constructed languages
We need to do both in order to move forward.
The proposal for objective criteria for constructed and reconstructed
languages is in a nutshell:
- The language must have an ISO-639-3 code
- We need full WMF localisation from the start
- The language must be sufficiently expressive for writing a modern
encyclopaedia
- The Incubator project must have sufficiently large articles that
demonstrate both the language and its ability to write about a wide range of
topics
- A sufficiently large group of editors must be part of the Incubator
project
Thanks,
GerardM
Jussi-Ville Heiskanen wrote:
> Erik Moeller wrote:
>> 2009/9/28 Jimmy Wales <jwales(a)wikia-inc.com>:
>>
>>> If the Foundation is bottlenecked at the moment (understandable) then
>>> how can I help, how can we the community help, to take some of the
>>> burden off of them to get done what we need to get done for the sake of
>>> our mission? :-)
>>>
>>
>> The process going forward is pretty clear -
>>
>> a) make sure prototype setup reflects desired behavior as per the
>> en.wp proposal and invite broader testing;
>>
Perfectly reasonable.
>> b) make revisions to extension based on public and internal review
>> with a particular eye to usability;
>>
Absolutely commendable.
>> c) ensure that the extension is fully scalable to en.wp traffic volume;
>>
Why on earth would we like to ensure that, particularly
*before* point d) ?
I can fully understand that there is a contingent
who devoutly hopes that after the current strictly limited
use of FR is tried out and people gain more familiarity
with the interface and the practical way the extension
works, much of the mystique of it will vanish in a puff
of smoke and people will be more amenable to extending
its use.
Nevertheless in reality the current compromise proposal
owes much to people who were able to only accept it with
the proviso that quite the opposite of wanting to see it be
possible to scale up, they required a reasonable assurance
that its use would *not* be escalated without an overwhelming
community consensus.
>> d) deploy on en.wp as per proposal (potentially, per c, initially in
>> some scale-limited fashion).
>>
Not doing d) before being sure of c) seems very much like
putting the cart before the horse to me. Whether c) will be
relevant at all would necessarily be contingent on the
success of d), and the logical order thus should be to just
do d) and see later if there is any relevance to c) at all.
Or to put it more plainly; it is a very remote possibility
indeed that extending the Flagged Revision experiment
in a form that ordinary articles would only display an
approved revision (without very strict restrictions on
which articles to apply this requirement to) for many
people will be something they will accept. So making
it a prerequisite that such an application has to be
functionally available in the extension for uses as large
as the English wikipedia before *any* use of the extension,
is rather silly as a concept.
Yours,
Jussi-Ville Heiskanen
I'd like to share some exciting news with you all... After four awesome
years working for the Wikimedia Foundation full-time, next month I'm
going to be starting a new position at StatusNet, leading development on
the open-source microblogging system which powers identi.ca and other sites.
I've been contributing to StatusNet (formerly Laconica) as a user, bug
reporter, and patch submitter since 2008, and I'm really excited at the
opportunity to get more involved in the project at this key time as we
gear up for a 1.0 release, hosted services, and support offerings.
StatusNet was born in the same free-culture and free-software community
that brought me to Wikipedia; many of you probably already know founder
Evan Prodromou from his longtime work in the wiki community, launching
the awesome Wikitravel and helping out with MediaWiki development on
various fronts. The "big idea" driving StatusNet is rebalancing power in
the modern social web -- pushing data portability and open protocols to
protect your autonomy from siloed proprietary services... People need
the ability to control their own presence on the web instead of hoping
Facebook or Twitter always treat you the way you want.
This does unfortunately mean that I'll have less time for MediaWiki as
I'll be leaving my position as Wikimedia CTO sooner than originally
anticipated, but that doesn't mean I'm leaving the Wikimedia community
or MediaWiki development!
Just as I was in the MediaWiki development community before Wikimedia
hired me, you'll all see me in the same IRC channels and on the same
mailing lists... I know this is also a busy time with our fundraiser
coming up and lots of cool ongoing developments, so to help ease the
transition I've worked out a commitment to come into the WMF office one
day a week through the end of December to make sure all our tech staff
has a chance to pick my brain as we smooth out the code review processes
and make sure things are as well documented as I like to think they are. ;)
We've got a great tech team here at Wikimedia, and we've done so much
with so little over the last few years. A lot of really good work is
going on now, modernizing both our infrastructure and our user
interface... I have every confidence that Wikipedia and friends will
continue to thrive!
I'll start full-time at StatusNet on October 12. My key priorities until
then are getting some of our key software rollouts going, supporting the
Usability Initiative's next scheduled update and getting a useful but
minimally-disruptive Flagged Revisions configuration going on English
Wikipedia. I'm also hoping to make further improvements to our code
review process, based on my experience with our recent big updates as
well as the git-based workflow we're using at StatusNet -- I've got a
lot of great ideas for improving the CodeReview extension...
Erik Moeller will be the primary point of contact for WMF tech
management issues starting October 12, until the new CTO is hired. I'll
support the hiring process as much as I can, and we're hoping to have a
candidate in the door by the end of the year.
-- brion vibber (brion @ wikimedia.org)
CTO, Wikimedia Foundation
San Francisco
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
It seems that I've gotten complaints that both sets of office hours
times are difficult for Europeans. However, in the interest of having
the broadest participation possible, I'm interested to know how people
feel about one of the following:
1) Have the Friday office hours one hour earlier (from 21:30-22:30 UTC)
2) Have the Thursday office hours one hour later (from 17:00-18:00 UTC)
3) Keep two sets of office hours the same, we cannot please everyone
possible!
- --
Cary Bass
Volunteer Coordinator, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkrBLMAACgkQyQg4JSymDYnDcgCePVl4xtOW9DyWPKr7GETgkd8B
ElwAn3zXiBebDJSFySML11qxIAL4BYsp
=uuz/
-----END PGP SIGNATURE-----
In a message dated 9/27/2009 1:29:03 PM Pacific Daylight Time,
wiki-lists(a)phizz.demon.co.uk writes:
> I have a reproduction of Rembrandt's "Toby and Anna" whilst that
> doesn't give the producer of the reproduction the right to stop me
> making copies from it, it also doesn't give me or you some bizarre right
> to demand digital files from the producer.>>
Are we demanding? Or are we just taking without permission?
Hi all, this is a reminder that office hours will be tomorrow, Thursday,
October 1, at 1600 UTC (9:00 AM PDT) and feature Rand Montoya.
The IRC channel that will be hosting Rand's conversation will be
#wikimedia-office on the Freenode network. If you do not have an IRC
client, you can always access Freenode by going to
http://webchat.freenode.net/, typing in the nickname of your choice and
choosing wikimedia-office as the channel. You may be prompted to click
through a security warning. Go ahead.
The channel is also available through the Wikizine site at http://chat.wikizine.org/
and picking one of the two gateways, while choosing "wikimedia-office" from the dropdown on the next page.
--
Cary Bass
Volunteer Coordinator, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Make the following experience:
Go to Gmail and create a new account on Gmail. Does Google tell you
after you have created your new account : We are ready to have a
conflict relationship with YOU ? We have an Abuse Log ready for YOU ?
Now go to meta.wikimedia.org (1), create a new account there and click
on your "My contributions" link. And see what you see on the top line
of Special:Contributions : "Abuse Log". My preference on meta is
French, and it reads ("Journal des abus"). In French "Journal" means
both "Log" and "Newspaper". It sort of says "you are already making
headlines in newspapers for abuse".
It means Wikimedia users are considered as suspects from the first
time they set foot into the wiki. It means that the climate there is a
climate where everyone suspects everybody else, where you are guilty
until proven innocent, and where bad faith is assumed (3).
Jimmy Wales and Michael Snow want to attract new volunteers (2) in
these conditions ?
Can anybody show me the page on meta.wikimedia.org, which shows that a
consensus was reached prior to implementing this Special:AbuseLog
software ?
It is almost the same problem on Commons (my user preference there is
English) where the AbuseLog has been pudically renamed "filter log"
(but the wording with Abuse is still used in the URL).
The French Language Wikipédia is still unaffected by this Abuse thing.
I hope the virus of suspicion will not infect her.
(1) http://meta.wikimedia.org
(2) http://volunteer.wikimedia.org
(3) http://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith
2009/9/16 Samuel Klein <meta.sj(a)gmail.com>:
> Putting aside the unnecessary bad faith and challenges to the
> foundation's integrity: I find this all exciting - planning for
> significant tech budget support, possible major sponsorships (I've
> always hoped we would one day find multiple sources for long-term
> in-kind support of servers and bandwidth), &c. I would simply like to
> see more open discussion of what our perfect-world tech dreams are,
> and how to pursue what sorts of sponsorships.
Thanks, Sam. I find the discussion of the last few days symptomatic of
the problems we've begun to brainstorm about with regard to the
signal/noise ratio, healthiness and openness of this particular forum.
(And by openness I mean that a forum that is dominated by highly
abrasive, high volume, low signal discussions is actually not very
open.) I do want to revisit the post limit question as a possible
answer, but let's do that separately.
The thread did surface some topics which are worth talking about, both
in general and specific terms, and I'm taking the liberty to start a
new thread to isolate some of those topics. For one thing, I think
it's always good to revisit and iterate processes for defining
priorities, and for achieving the highest impact in those identified
areas.
Developing more sophisticated processes both for short-term and
long-term planning has been precisely one of the key focus areas of
the last year. Internally, we've begun experimenting with assessment
spreadsheets and standardized project briefs, drawing from the
expertise of project management experts as well as Sue's specific work
in developing a very well thought-out prioritization system at the
CBC. Publicly, we're engaged in the strategy planning process -- the
associated Call for Proposals is a first attempt to conduct a
large-scale assessment of potential priorities. (I hope that with
future improvements to the ReaderFeedback extension we'll be able to
generate more helpful reports based on that particular assessment.)
Ideally, the internal and public processes will converge sooner rather
than later. For example, I posted a project brief that I developed
internally through the strategy CfP:
http://strategy.wikimedia.org/wiki/Proposal:Volunteer_Toolkit
I believe this one was submitted by Jennifer:
http://strategy.wikimedia.org/wiki/Proposal:Volunteer_Management_practices_…
And this one by Tim:
http://strategy.wikimedia.org/wiki/Proposal:Directed_community_fundraising
The next phase of the strategy planning process, the deep-dive task
forces, will be an interesting experiment in serious community-driven
planning work, complemented by the research conducted with the help of
our partners at The Bridgespan Group. All of this will become part of
the institutional memory of the Wikimedia movement, and hopefully
we'll continue to raise the bar in our thinking, planning, and
collaboration.
- - -
Of course separately from setting priorities, there's the critical
need to improve our ability to execute upon those priorities. This
includes the further development of project pipelines, more systematic
volunteer engagement, additional internal HR support, additional
hiring of staff to address key capacity gaps, etc. I'm thrilled by how
far we've come, and to be able to have supported, and continue to
support, an unprecedented large-scale initiative like the usability
project. I'm well-aware that there continue to be key priorities that
we aren't executing as effectively as we could.
The first thing many partners, donors and friends say when they visit
Wikimedia Foundation is how astonishing it is that an operation of
this scale can function with so little funding and staff. The truth is
that by any reasonable measure of efficiency and money-to-impact
ratio, we're achieving wonderful things together, and that's easy to
forget when looking at issues in isolation. (Yes, it would be
wonderful to have the full-history dumps running ASAP. Hm, it would be
nice to have the full-history dumps for some other top 50 content
websites. Oh, right, they don't provide any.)
But I don't measure our success compared to other organizations. The
most important question to me is whether we are continually raising
the bar in what we're doing and how we do it. The most recent
Wikimania was the most thoughtful and self-aware one I've ever
attended, with deep, constructive conversations and very serious
efforts of everyone involved to re-ignite and strengthen our movement.
There are elements of groupthink, but also very systematic attempts to
break out of it.
There are great opportunities today for anyone to become engaged in
helping to shape the future of what we do, and to accomplish real
change in the world as a result. Ultimately we all have to make a
choice how we spend our time -- how we spend our lives -- but I hope
we're creating a legacy that will fill us with pride and joy, and
inspire others to do the same.
--
Erik Möller
Deputy Director, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Sue,
I sent the below included inquiry to wikitech-l regarding
http://flaggedrevs.labs.wikimedia.org/.
Now almost a month later I still have received no response regarding
the status of
this test deployment. It is is still not active on the test site, —
although this
has literally gone on for months.
As far as I can tell this is one of the most significant initiatives
on English Wikipedia as of lately— in that it has site wide impact and
the design and decision of the configuration was the work of hundreds
of people, including a reworking after the WMF staff refused to
implement the initial decision which only achieved almost a decent
majority support, for lack of sufficient community support. Now that
the plan has been improved and the support is overwhelming a commitment
to roll with this plan was made but no progress appears to be being made.
Inquiries have been met with silence.
I believe the community expects and deserves a greater level of
responsiveness from the staff of Wikimedia.
What I'd like to know—
What is delaying this deployment?
What is a reasonable expectation for the timeline in implement
community chosen decisions?
How can communication be improved so that the communities high
priority implementations aren't ignored for weeks and even months by
wikimedia staff?
How can the people who care about this help see it through to completion?
What does this say about the enormous strategic projects initiate
when Wikimedia is already failing to meet its commitments on high
impact community initiatives?
Thank you for your time and consideration.
---------- Forwarded message ----------
From: Gregory Maxwell <gmaxwell(a)gmail.com>
Date: Tue, Sep 1, 2009 at 7:21 PM
Subject: Re: [Wikitech-l] flaggedrevs.labs.wikimedia.org Status?
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
On Tue, Sep 1, 2009 at 7:17 PM, K. Peachey<p858snake(a)yahoo.com.au> wrote:
> On Wed, Sep 2, 2009 at 7:02 AM, Platonides<Platonides(a)gmail.com> wrote:
>> You know, when you point to a broken page, people^W wikipedians tend to
>> do absurd things like fixing them :)
> I was going to fix some up, but import is restricted and i was too
> lazy to do copy/paste imports.
Ehhh. It don't know that it makes sense to spend effort manually
fixing pages on a test project. If the import procedure is not
working right it should be improved...
In any case, I'm sorry for the tangent. The main intent of my post was
to determine the current status:
Is the import finished?
When will the configuration changes for flagged protection be turned on?