What do you guys think would be more useful:
1. Helping sister projects write up proposals for the Berlin Hackathon 2. Creating "The Complete Idiot's Guide to Writing MediaWiki Extensions" and "The Complete Idiot's Guide to Writing MediaWiki Gadgets (in jQuery)"
Whichever one you guys prefer, I'll pitch to my Engineering Project Managers as a project for myself.
Ryan Kaldari
On 4/2/11 12:29 PM, bawolff wrote:
Message: 2 Date: Fri, 01 Apr 2011 18:40:00 -0700 From: Ryan Kaldarirkaldari@wikimedia.org Subject: Re: [Wikitech-l] Focus on sister projects To: Conrad Irwinconrad.irwin@gmail.com Cc: Wikimedia developerswikitech-l@lists.wikimedia.org Message-ID:4D967E70.2080108@wikimedia.org Content-Type: text/plain; charset=windows-1252; format=flowed
[...]
As long as we're on the subject of wiktionary, I notice that there's a lot of custom Javascript there for handling specialized editing tasks like editing glosses, managing translations, etc. It seems like some of this functionality could be improved further and developed into full-fledged extensions (making it easy for other wiktionaries to use as well). Would you have any interest in working up a couple Wiktionary project proposals for the upcoming Hackathon in Berlin?
Ryan Kaldari
This isn't just true of wiktionary. Lots of sister projects have specialized work flow tools in js. Wikinews has review related tools in js and a hack that adds a second "talk" namespace, Wikisource has the proofread page extension, but still much of there workflow is written in js, I'm sure many other projects have specialized stuff that should be in php extensions.
The issue is at the end of the day it is _significantly_ easier to write a js hack, then to manage to get a php extension written, reviewed and deployed.
-bawolff
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l