FYI. The first Wikipedia meetup / workshop in Sri Lanka is a
milestone for the entire movement. :)
Yours sincerely,
Anirudh Bhati
00 91 9328712208
Skype: anirudhsbh
---------- Forwarded message ----------
From: Ravishankar <ravidreams(a)gmail.com>
Date: Wed, Dec 29, 2010 at 11:45 AM
Subject: [Wikimediaindia-l] Tamil Wiki workshop in Eastern University, SriLanka
To: "Discussion list on Indian language projects of Wikimedia."
<wikimediaindia-l(a)lists.wikimedia.org>
Hi,
Tamil Wikipedians from SriLanka conducted a Tamil Wikipedia Workshop
at Eastern University of Srilanka on 28th December.
Around 55 people including lecturers, employees, students, visitors
from nearby institutions participated.
This is the first organized Wiki meetup / workshop in SriLanka and we
plan to conduct more such workshops in near future.
Photos from the event:
http://www.facebook.com/album.php?aid=269877&id=647387355&l=b22c36a4a6
Ravi
_______________________________________________
Wikimediaindia-l mailing list
Wikimediaindia-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimediaindia-l
Not only is the current markup a barrier to participation, it's a barrier to
development. As I argued on Wikien-l, starting over with a markup that can
be syntacticly validated, preferably one that is XML based would reap huge
rewards in the safety and effectiveness of automated tools - authors of
tools like AWB have just as much trouble making software handle the corner
cases in wikitext markup as new editors have understanding it.
It's no wonder really, as the current markup is the result of bolting on
feature after feature, often to handle various corner cases, basically a
really undisciplined approach to development. I honestly wouldn't
be surprised if there were security issues waiting to be found in the
parser, because of the way it's been thrown together.
The switching cost to a new markup and the development cost for an editor
for it would probably be comparable to that of writing a WYSIWYG editor that
understands the current one. A new markup gives us some huge advantages. A
new parser could potentially handle different output formats (print, web,
mobile, pdf, etc) seamlessly, could largely eliminate accessibility issues
that currently are created from ad-hoc formatting capabilities, and would
enable tools that actually understand the markup to start being employed.
Making that parser XML based would mean we can reuse the existing ecosystem
of libraries and tools for manipulating and parsing XML text, and would have
a truly seamless transition into any future markup changes, thanks to XSLT.
XML also gives us the benefit of being able to do validation, possibly at
the time an edit is saved, allowing us to stop broken markup, rather than
having to fix it later, and it allows us to completely remove presentation
from the hands of casual editors - the presentation of articles could be
controlled at site level, with existing consensus processes similar to that
used to change major templates being required to get changes to the site
templates (the article template basically becomes part of the interface at
this stage.)
Transition will be ugly regardless of whether we keep the current parser or
replace it. There are a lot of complex features in the current markup that
need to go because a WYSIWYG editor wouldn't understand them, and it would
also be ideal going forward to "flatten" the formatting capabilities into a
subset that assures consistency - ad-hoc HTML and CSS formatting would
likely have to go.
I honestly think WYSIWYM is a more realistic target once the more
problematic features in the current markup are gone. The editing experience
is largely the same, with the key difference being that what you see in the
editor doesn't have to look exactly like what you see in the rendered
article. By aiming for WYSIWYM, some things would render in the editor in a
way that makes them easier to understand and edit. For example, templates
could render in the editor as tables or as a block that loads the template
parameters into a sidebar when clicked. The same could be done for
references. This has a very shallow learning curve, and a tremendous
advantage over WYSIWYG in that elements that don't lend well to editing in a
WYSIWYG environment are presented in the manner easiest to edit, rather than
in the manner in which they appear. It may take one or two "second looks" to
figure out what's happening, but after that, it's smooth sailing, and by
doing it this way, we avoid the downsides of editing complicated parts of a
page with a minimum cost of initial confusion. WYSIWYM editors can be
friendly to both experienced and new users alike - take LyX as a good
example of such an editor - being WYSIWYM, things that are naturally complex
and unwieldy in WYSIWYG mode become easy because the interface is built to
provide a visual understanding of what is going on rather than 1:1 fidelity
with the final document - as a result, you spend more time editing and less
time worrying about pixel perfect formatting, because you can trust that the
underlying formatting engine will handle things right when you do go to
render the finished document.
As far as current markup goes, a creative solution would be a fork of the
parser into three parts, with a corresponding fork in namespaces as well.
The resulting parts would be an article parser, a template parser, and a
parser for a new layout namespace. Initially, the existing parser is lumped
into the article parser, and class inheritance is used so that the template
parser inherits all markup from the article parser, and in turn, the layout
parser inherits all markup from the template parser. (I'll get more into
layouts below.) This gives us a framework to do several things that improve
usability and consistency. Once the initial "split" is set up, we begin to
move markup features from the article parser into the template and layout
parsers to remove ugly markup from general use, and to restrict formatting
capabilities to a subset that both allows a WYSIWYG or WYSIWYM editor to
work correctly, and allows some level of consistency to be enforced at a
site level. Layouts would be a new form of template, designed to apply as a
block-level outline to an article, providing both a framework to build a
particular type of article, and defining the formatting for that article in
a manner that templates and article markup would no longer be permitted to
do. It's likely that layouts would be treated like highly used templates and
the interface itself, with the ability to create and change a layout
restricted by a permission bit. Layouts would be one to an article, so the
interface to select one would probably be just selecting it from a dropdown
or typing it's name. Every layout would have at least an article body, and
would have one or more additional "blocks" defined - so for basics you could
have the default layout (a flat article), an article with infobox layout,
and a list layout. The end result of this solution is that ad-hoc formatting
using HTML and CSS is gone as far as most editors are concerned, complicated
or easily misused markup features that might cause problems are removed from
the parser that most users will interact with, and the most problematic of
markup is effectively reserved for experienced editors. A new interface can
then be built at a fraction of the development cost, because the "hard
stuff" is out of article space. This both makes sense for usability now, as
well as makes sense as a possible first step if we are ever going to change
parsers, because the things that we probably couldn't convert would be
"contained" rather than spread across articles.
-Steph
Reply
Date: Fri, 24 Dec 2010 12:06:34 +0100
From: Huib Laurens <sterkebak(a)gmail.com>
Subject: Re: [Foundation-l] Fw? About WM private policy
To: Wikimedia Foundation Mailing List
<foundation-l(a)lists.wikimedia.org>
Message-ID:
<AANLkTi=aJpxkJ7E3G6vCHtdG_VAKP7fOYj12=RvJ51Ks(a)mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
The question should be: IS "EDIT" EQUAL TO "CREATE"?
Thanks.
HW
Is WMF approved that???
________________________________
寄件人﹕ Liangent <liangent(a)gmail.com>
收件人﹕ 中文维基百科邮件列表/中文維基百科郵件列表/Mailing list for <wikizh-l(a)lists.wikimedia.org>
傳送日期﹕ 2010/12/24 (五) 2:40:23 PM
主題： Re: [Wikizh-l] About WM private policy
Note that creating page without logging in is also banned in enwiki.
On Fri, Dec 24, 2010 at 10:19 AM, HW <waihorace(a)yahoo.com.hk> wrote:
> A recent discussion on zh Wikipedia is talking about the WMF private policy
> which is on http://wikimediafoundation.org/wiki/Privacy_policy . Some IP user
> says that in the sentence "The Foundation does not require editors to register
> with a project. Anyone can edit without logging in with a username, in which
> case they will be identified by network IP address." , createpage is a edit,
so
> the wiki should not disable IP's createpage and allowed only user to
> createpage.
>
> The question is: IS CREATEPAGE MUST NOT BE DISABLE TO IP USER?
>
> Please WMF staff answer this question and it is related to a recent discussion
> on
>http://zh.wikipedia.org/wiki/Wikipedia:%E4%BA%92%E5%8A%A9%E5%AE%A2%E6%A0%88…
>
>
>
> Thanks.
> HW - user of zhwiki.
>
>
>
> _______________________________________________
> Wikizh-l 邮件列表
> Wikizh-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikizh-l
>
_______________________________________________
Wikizh-l 邮件列表
Wikizh-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikizh-l
*re-sent due some problem on foundation-l*
A recent discussion on zh Wikipedia is talking about the WMF private policy
which is on http://wikimediafoundation.org/wiki/Privacy_policy . Some IP user
says that in the sentence "The Foundation does not require editors to register
with a project. Anyone can edit without logging in with a username, in which
case they will be identified by network IP address." , createpage is a edit, so
the wiki should not disable IP's createpage and allowed only user to
createpage.
The question is: IS CREATEPAGE MUST NOT BE DISABLE TO IP USER?
Please WMF staff answer this question and it is related to a recent discussion
on http://zh.wikipedia.org/wiki/Wikipedia:%E4%BA%92%E5%8A%A9%E5%AE%A2%E6%A0%88…
Thanks.
HW - user of zhwiki.
This is so exciting! To Steven's point: we've also started a page
where folks can add bits of interesting information as they excavate
the files [1]. Can't wait to dig in!
Congrats, Tim!
[1] http://ten.wikipedia.org/wiki/Wikipedia_in_the_Beginning
Date: Tue, 14 Dec 2010 08:20:10 -0800
From: Steven Walling <steven.walling(a)gmail.com>
Subject: Re: [Foundation-l] Old Wikipedia backups discovered
To: Wikimedia Foundation Mailing List
<foundation-l(a)lists.wikimedia.org>
Message-ID:
<AANLkTin9CjXR1S_eCfR3nR6Xmt6C4o=6oHDhTXP4JPzL(a)mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
This is fantastic, and the timing could not be better.
If anyone finds anything noteworthy, please add it to the timeline of
Wikipedia that we're building at the 10th anniversary wiki,[1] as well as
the other tools for cataloging interesting tidbits from our history.[2]
1. http://ten.wikipedia.org/wiki/Wikipedia_timeline
2. http://ten.wikipedia.org/wiki/Share
On Tue, Dec 14, 2010 at 8:11 AM, Chad <innocentkiller(a)gmail.com> wrote:
> On Tue, Dec 14, 2010 at 10:54 AM, Tim Starling <tstarling(a)wikimedia.org>
> wrote:
> > I was looking through some old files in our SourceForge project. I
> > opened a file called wiki.tar.gz, and inside were three complete
> > backups of the text of Wikipedia, from February, March and August 2001!
> >
> > This is exciting, because there is lots of article history in here
> > which was assumed to be lost forever.
> >
> > I've long been interested in Wikipedia's history, and I've tried in
> > the past to locate such backups. I asked various people who might have
> > had one. I had given up hope.
> >
> > The history of particularly old Wikipedia articles, as seen in the
> > present Wikipedia database, is incomplete, due to Usemod's policy of
> > deleting old revisions of pages after about a month. The script which
> > Brion wrote to import the article histories from UseMod to MediaWiki
> > only fetched those revisions which hadn't been purged yet.
> >
> > I didn't want to believe that those revisions had been lost forever,
> > and I even opened the UseMod source code and stared forlornly at the
> > unlink() call. What I (and Brion before) missed is that UseMod appends
> > a record of every change made to two files, called diff_log and rclog.
> > In these two files is a record of every change made to Wikipedia from
> > January 15 to August 17, 2001.
> >
> > I've put the two log files up on the web, at:
> >
> > http://noc.wikimedia.org/~tstarling/wikipedia-logs-2001-08-17.7z
> >
> > The 7-zip archive is only 8.4MB -- much more manageable than today's
> > backups.
> >
> > rclog contains IP addresses. The Usemod software made IP addresses of
> > logged-in users public, so the people who made these edits had no
> > expectation that their IP address would be kept private. That, coupled
> > with the passage of time, makes me think that no harm to user privacy
> > can come from releasing these files.
> >
> > -- Tim Starling
> >
>
> I have to say this is super cool. It's like digging up a time capsule
> right before the 10th anniversary. One of my favorite early edits:
>
> "This is the new WikiPedia! The idea here is to write a complete
> encyclopedia from scratch, without peer review process, etc.
> Some people think that this may be a hopeless endeavor, that
> the result will necessarily suck. We aren't so sure. So, let's get
> to work!"
>
> -Chad
>
> _______________________________________________
> foundation-l mailing list
> foundation-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Hello All!
I'm pleased to announce that the Wikimedia Foundation has hired it's first Director of Technical Operations. CT Woo began work at WMF on December 1st and will be reporting to our CTO, Danese Cooper.
As Director of Technical Ops, his primary responsibility will be working to provide for a stable, secure, documented, scalable and responsive systems environment. He'll be working with the rest of the Operations team to assess the current state process of technical projects, short and long term risk to the technical infrastructure and work towards providing solutions and systems for failsafes and redundancy. He will also be a great resource for guidance and mentorship for the operations team. For a full description of the role, please visit - http://wikimediafoundation.org/wiki/Job_openings/Director_of_Technical_Oper….
CT Woo comes to us with a strong background in Technical Operations and Software Development. He is joining us from Freshbrain.org where he was a founding member and was running the Engineering and IT functions. Freshbrain is a non-profit entity with the mission to enhance the education and the enrichment of teens in the areas of business and technology through its community building website. Prior to that, CT worked at SurfControl Plc, an Internet Security Company, where he was in-charge of IT as well as Internet Infrastructure Engineering. CT also spent a number of years at Sun Microsystems, holding various Engineering and IT positions including Director of Software Development, Director of IT as well as Director of IT Operations. CT was educated in Malaysia, UK and US and has worked in several countries outside of US. He was an active Boys Scout in his teens and now continues with working as a volunteer in the local scout troop.
We're very fortunate to have CT join us. He's going to be extremely instrumental as we build out the Tech department, specifically General Ops. He's joining us at a time of growth of the Foundation, the projects and their reach. We're excited he accepted our offer and the challenge we placed in front of him. Normally we'd get this announcement out prior to the start date and unfortunately that wasn't possible this time with everyone's extensive travel schedules. So hopefully many of you have gotten a chance to know more about CT in person and for those of you who have not, I really encourage you to take some time and meet him.
Please join me in welcoming CT to the Tech Department and to WMF. We are very extremely happy to have him join us.
Cyn Skyberg
CTCO, Wikimedia Foundation
--
Cyn Skyberg
Chief Talent and Culture Officer
Wikimedia Foundation
Skype: cynskypell
AIM: cynaim
Tel +1 (415) 839-6885 x 6691
Mobile +1 (408) 410-2849
Fax +1 (415) 882-0495
SL: Cyn Skyberg
"Imagine a world in which every single human being can freely share in the sum of all knowledge."
Cross-posting.
Begin forwarded message:
> From: Steven Walling <swalling(a)wikimedia.org>
> Date: December 22, 2010 4:46:20 PM PST
> To: wikix-l(a)lists.wikimedia.org
> Subject: [WikiX-l] Deadline approaching to get merchandise
> Reply-To: Planning for WP 10th anniversary <wikix-l(a)lists.wikimedia.org>
>
> Hi everyone,
>
> Just wanted to make a quick announcement: the deadline to receive a shipment of merchandise (ten.wikipedia.org/wiki/Design/Merchandise) from the Foundation is rapidly approaching. For the couple dozen event organizers who have sent me their shipping and contact information, thank you.
>
> For those who haven't, if we don't ship at least 10 business days before the 15th, then it may not get to you in time for the anniversary, so let's make it happen so you can have awesome merchandise for your parties, conferences, and other meetups.
>
> Feel free to forward this message as necessary.
>
> Steven Walling
> Fellow at Wikimedia Foundation
> wikimediafoundation.org
>
>
>
>
> _______________________________________________
> WikiX-l mailing list
> WikiX-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikix-l
Steven Walling
Fellow at Wikimedia Foundation
wikimediafoundation.org