Re: [Wikitech-l] Focus on sister projects
Ah, sorry, realized what you mean a second after sending... On Mon, Apr 4, 2011 at 7:07 PM, Magnus Manske wrote: > http://www.mediawiki.org/wiki/WYSIFTW ;-) > > > On Mon, Apr 4, 2011 at 6:09 PM, Ryan Kaldari wrote: >> Maybe my brain just made a leap here, but is there a plan for >> implementing a web-based Javascript editor for MediaWiki?? This would be >> a hugely awesome feature. I've used jsFiddle (http://jsfiddle.net/) >> which is really slick - syntax color-coding, tabbing that works, a Tidy >> button(!), integrated jsLint(!). >> >> If not, hopefully, I've just created a self-fulfilling rumor :) >> >> Ryan Kaldari >> >> On 4/3/11 11:06 AM, Daniel Kinzler wrote: >>> I think the JS editor stuff would also fit well enough with the topics of >>> the >>> Berlin hackathon in May... >>> >>> -- daniel >>> >>> On 03.04.2011 15:30, Sumana Harihareswara wrote: Would any of those be useful project ideas for Google Summer of Code students? If so, please add a bullet point or two: http://www.mediawiki.org/wiki/Summer_of_Code_2011 best, Sumana Harihareswara On 04/01/2011 10:11 PM, Conrad Irwin wrote: > Ok — yes loading speeds are definitely something worth improving. > > WT:PREFS to become gadgets has been discussed ever since gadgets was > released, it will happen one day :). Luckily that code is only loaded > for people who are using WT:PREFS, so it should have minimal impact. > > I'd be pretty interested to — do you have a guideline as to the > expected format. In particular I think the "core" of the editor, which > provides a framework for javascript to load, edit, undo, redo, and > save the page (with edit summaries) would be pretty useful everywhere. > It's documented in the first half of > http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_docs and > there's a tutorial at > http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_tutorial.js — > but it could do with "new-ification" (in particular some jQuery would > be nice, and there's probably a better javascript API wrapper than > JsMwApi :). > > Conrad > > > On Fri, Apr 1, 2011 at 6:40 PM, Ryan Kaldari > wrote: >> Good idea. After the 1.17 deployment, I've been trying to go through and >> clean-up some of the Javascript cruft that has built up on the various >> wikis >> over the years. One of the main goals of 1.17 was improving page loading >> speeds by optimizing Javascript delivery. Of course if all the wikis are >> serving lots of old redundant Javascript, the optimization doesn't >> accomplish that much. On wiktionary specifically, the importScript and >> importExternalScript functions are redundant, and the Wiktionary:PREFS >> system should be retired now that Gadgets are available. I admit I was >> much >> too gung-ho in my clean-up regarding Wiktionary, and I intend to let the >> admins there handle it from here. >> >> 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 >> ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l >>> >>> ___ >>> Wikitech-l mailing list >>> Wikitech-l@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> >> ___ >> Wikitech-l mailing list >> Wikitech-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
http://www.mediawiki.org/wiki/WYSIFTW ;-) On Mon, Apr 4, 2011 at 6:09 PM, Ryan Kaldari wrote: > Maybe my brain just made a leap here, but is there a plan for > implementing a web-based Javascript editor for MediaWiki?? This would be > a hugely awesome feature. I've used jsFiddle (http://jsfiddle.net/) > which is really slick - syntax color-coding, tabbing that works, a Tidy > button(!), integrated jsLint(!). > > If not, hopefully, I've just created a self-fulfilling rumor :) > > Ryan Kaldari > > On 4/3/11 11:06 AM, Daniel Kinzler wrote: >> I think the JS editor stuff would also fit well enough with the topics of the >> Berlin hackathon in May... >> >> -- daniel >> >> On 03.04.2011 15:30, Sumana Harihareswara wrote: >>> Would any of those be useful project ideas for Google Summer of Code >>> students? If so, please add a bullet point or two: >>> >>> http://www.mediawiki.org/wiki/Summer_of_Code_2011 >>> >>> best, >>> Sumana Harihareswara >>> >>> On 04/01/2011 10:11 PM, Conrad Irwin wrote: Ok — yes loading speeds are definitely something worth improving. WT:PREFS to become gadgets has been discussed ever since gadgets was released, it will happen one day :). Luckily that code is only loaded for people who are using WT:PREFS, so it should have minimal impact. I'd be pretty interested to — do you have a guideline as to the expected format. In particular I think the "core" of the editor, which provides a framework for javascript to load, edit, undo, redo, and save the page (with edit summaries) would be pretty useful everywhere. It's documented in the first half of http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_docs and there's a tutorial at http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_tutorial.js — but it could do with "new-ification" (in particular some jQuery would be nice, and there's probably a better javascript API wrapper than JsMwApi :). Conrad On Fri, Apr 1, 2011 at 6:40 PM, Ryan Kaldari wrote: > Good idea. After the 1.17 deployment, I've been trying to go through and > clean-up some of the Javascript cruft that has built up on the various > wikis > over the years. One of the main goals of 1.17 was improving page loading > speeds by optimizing Javascript delivery. Of course if all the wikis are > serving lots of old redundant Javascript, the optimization doesn't > accomplish that much. On wiktionary specifically, the importScript and > importExternalScript functions are redundant, and the Wiktionary:PREFS > system should be retired now that Gadgets are available. I admit I was > much > too gung-ho in my clean-up regarding Wiktionary, and I intend to let the > admins there handle it from here. > > 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 > >>> >>> ___ >>> Wikitech-l mailing list >>> Wikitech-l@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> >> ___ >> Wikitech-l mailing list >> Wikitech-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
Also see the freebase / google acre system inline editor: http://wiki.freebase.com/wiki/Acre What is more impressive than the online editor, is the template and integrated data query system in an seamless sandboxed server / client javascript system. Its not perfect, but definitely includes some ideas that would be interesting to explore long term. --michael On 04/04/2011 10:09 AM, Ryan Kaldari wrote: > Maybe my brain just made a leap here, but is there a plan for > implementing a web-based Javascript editor for MediaWiki?? This would be > a hugely awesome feature. I've used jsFiddle (http://jsfiddle.net/) > which is really slick - syntax color-coding, tabbing that works, a Tidy > button(!), integrated jsLint(!). > > If not, hopefully, I've just created a self-fulfilling rumor :) > > Ryan Kaldari > > On 4/3/11 11:06 AM, Daniel Kinzler wrote: >> I think the JS editor stuff would also fit well enough with the topics of the >> Berlin hackathon in May... >> >> -- daniel >> >> On 03.04.2011 15:30, Sumana Harihareswara wrote: >>> Would any of those be useful project ideas for Google Summer of Code >>> students? If so, please add a bullet point or two: >>> >>> http://www.mediawiki.org/wiki/Summer_of_Code_2011 >>> >>> best, >>> Sumana Harihareswara >>> >>> On 04/01/2011 10:11 PM, Conrad Irwin wrote: Ok — yes loading speeds are definitely something worth improving. WT:PREFS to become gadgets has been discussed ever since gadgets was released, it will happen one day :). Luckily that code is only loaded for people who are using WT:PREFS, so it should have minimal impact. I'd be pretty interested to — do you have a guideline as to the expected format. In particular I think the "core" of the editor, which provides a framework for javascript to load, edit, undo, redo, and save the page (with edit summaries) would be pretty useful everywhere. It's documented in the first half of http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_docs and there's a tutorial at http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_tutorial.js — but it could do with "new-ification" (in particular some jQuery would be nice, and there's probably a better javascript API wrapper than JsMwApi :). Conrad On Fri, Apr 1, 2011 at 6:40 PM, Ryan Kaldari wrote: > Good idea. After the 1.17 deployment, I've been trying to go through and > clean-up some of the Javascript cruft that has built up on the various > wikis > over the years. One of the main goals of 1.17 was improving page loading > speeds by optimizing Javascript delivery. Of course if all the wikis are > serving lots of old redundant Javascript, the optimization doesn't > accomplish that much. On wiktionary specifically, the importScript and > importExternalScript functions are redundant, and the Wiktionary:PREFS > system should be retired now that Gadgets are available. I admit I was > much > too gung-ho in my clean-up regarding Wiktionary, and I intend to let the > admins there handle it from here. > > 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 > >>> ___ >>> Wikitech-l mailing list >>> Wikitech-l@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> ___ >> Wikitech-l mailing list >> Wikitech-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
Maybe my brain just made a leap here, but is there a plan for implementing a web-based Javascript editor for MediaWiki?? This would be a hugely awesome feature. I've used jsFiddle (http://jsfiddle.net/) which is really slick - syntax color-coding, tabbing that works, a Tidy button(!), integrated jsLint(!). If not, hopefully, I've just created a self-fulfilling rumor :) Ryan Kaldari On 4/3/11 11:06 AM, Daniel Kinzler wrote: > I think the JS editor stuff would also fit well enough with the topics of the > Berlin hackathon in May... > > -- daniel > > On 03.04.2011 15:30, Sumana Harihareswara wrote: >> Would any of those be useful project ideas for Google Summer of Code >> students? If so, please add a bullet point or two: >> >> http://www.mediawiki.org/wiki/Summer_of_Code_2011 >> >> best, >> Sumana Harihareswara >> >> On 04/01/2011 10:11 PM, Conrad Irwin wrote: >>> Ok — yes loading speeds are definitely something worth improving. >>> >>> WT:PREFS to become gadgets has been discussed ever since gadgets was >>> released, it will happen one day :). Luckily that code is only loaded >>> for people who are using WT:PREFS, so it should have minimal impact. >>> >>> I'd be pretty interested to — do you have a guideline as to the >>> expected format. In particular I think the "core" of the editor, which >>> provides a framework for javascript to load, edit, undo, redo, and >>> save the page (with edit summaries) would be pretty useful everywhere. >>> It's documented in the first half of >>> http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_docs and >>> there's a tutorial at >>> http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_tutorial.js — >>> but it could do with "new-ification" (in particular some jQuery would >>> be nice, and there's probably a better javascript API wrapper than >>> JsMwApi :). >>> >>> Conrad >>> >>> >>> On Fri, Apr 1, 2011 at 6:40 PM, Ryan Kaldari >>> wrote: Good idea. After the 1.17 deployment, I've been trying to go through and clean-up some of the Javascript cruft that has built up on the various wikis over the years. One of the main goals of 1.17 was improving page loading speeds by optimizing Javascript delivery. Of course if all the wikis are serving lots of old redundant Javascript, the optimization doesn't accomplish that much. On wiktionary specifically, the importScript and importExternalScript functions are redundant, and the Wiktionary:PREFS system should be retired now that Gadgets are available. I admit I was much too gung-ho in my clean-up regarding Wiktionary, and I intend to let the admins there handle it from here. 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 >> >> ___ >> Wikitech-l mailing list >> Wikitech-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
On 2 Apr 2011 at 16:08, Ryan Kaldari wrote: > What do you guys think would be more useful: > > 1. Helping sister projects write up proposals for the Berlin Hackathon If it is going to get selected and have outcome for my favourite wiki, then yes ;-) > 2. Creating "The Complete Idiot's Guide to Writing MediaWiki Extensions" > and "The Complete Idiot's Guide to Writing MediaWiki Gadgets (in jQuery)" To me this has great great value, and I hope that when you say complete you mean "COMPLETE!!!" and I would hope that you would encourage and give examples of good documentation. Some of us are not natural programmers, though we can adapt scripts to suit our needs, and when given I find the explanations very useful. Regards, Andrew > 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 Kaldari > >> Subject: Re: [Wikitech-l] Focus on sister projects > >> To: Conrad Irwin > >> Cc: Wikimedia developers > >> Message-ID:<4d967e70.2080...@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 > > > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
I think the JS editor stuff would also fit well enough with the topics of the Berlin hackathon in May... -- daniel On 03.04.2011 15:30, Sumana Harihareswara wrote: > Would any of those be useful project ideas for Google Summer of Code > students? If so, please add a bullet point or two: > > http://www.mediawiki.org/wiki/Summer_of_Code_2011 > > best, > Sumana Harihareswara > > On 04/01/2011 10:11 PM, Conrad Irwin wrote: >> Ok — yes loading speeds are definitely something worth improving. >> >> WT:PREFS to become gadgets has been discussed ever since gadgets was >> released, it will happen one day :). Luckily that code is only loaded >> for people who are using WT:PREFS, so it should have minimal impact. >> >> I'd be pretty interested to — do you have a guideline as to the >> expected format. In particular I think the "core" of the editor, which >> provides a framework for javascript to load, edit, undo, redo, and >> save the page (with edit summaries) would be pretty useful everywhere. >> It's documented in the first half of >> http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_docs and >> there's a tutorial at >> http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_tutorial.js — >> but it could do with "new-ification" (in particular some jQuery would >> be nice, and there's probably a better javascript API wrapper than >> JsMwApi :). >> >> Conrad >> >> >> On Fri, Apr 1, 2011 at 6:40 PM, Ryan Kaldari wrote: >>> Good idea. After the 1.17 deployment, I've been trying to go through and >>> clean-up some of the Javascript cruft that has built up on the various wikis >>> over the years. One of the main goals of 1.17 was improving page loading >>> speeds by optimizing Javascript delivery. Of course if all the wikis are >>> serving lots of old redundant Javascript, the optimization doesn't >>> accomplish that much. On wiktionary specifically, the importScript and >>> importExternalScript functions are redundant, and the Wiktionary:PREFS >>> system should be retired now that Gadgets are available. I admit I was much >>> too gung-ho in my clean-up regarding Wiktionary, and I intend to let the >>> admins there handle it from here. >>> >>> 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 >>> > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
Would any of those be useful project ideas for Google Summer of Code students? If so, please add a bullet point or two: http://www.mediawiki.org/wiki/Summer_of_Code_2011 best, Sumana Harihareswara On 04/01/2011 10:11 PM, Conrad Irwin wrote: > Ok — yes loading speeds are definitely something worth improving. > > WT:PREFS to become gadgets has been discussed ever since gadgets was > released, it will happen one day :). Luckily that code is only loaded > for people who are using WT:PREFS, so it should have minimal impact. > > I'd be pretty interested to — do you have a guideline as to the > expected format. In particular I think the "core" of the editor, which > provides a framework for javascript to load, edit, undo, redo, and > save the page (with edit summaries) would be pretty useful everywhere. > It's documented in the first half of > http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_docs and > there's a tutorial at > http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_tutorial.js — > but it could do with "new-ification" (in particular some jQuery would > be nice, and there's probably a better javascript API wrapper than > JsMwApi :). > > Conrad > > > On Fri, Apr 1, 2011 at 6:40 PM, Ryan Kaldari wrote: >> Good idea. After the 1.17 deployment, I've been trying to go through and >> clean-up some of the Javascript cruft that has built up on the various wikis >> over the years. One of the main goals of 1.17 was improving page loading >> speeds by optimizing Javascript delivery. Of course if all the wikis are >> serving lots of old redundant Javascript, the optimization doesn't >> accomplish that much. On wiktionary specifically, the importScript and >> importExternalScript functions are redundant, and the Wiktionary:PREFS >> system should be retired now that Gadgets are available. I admit I was much >> too gung-ho in my clean-up regarding Wiktionary, and I intend to let the >> admins there handle it from here. >> >> 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 >> ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
K. Peachey wrote: > On Sun, Apr 3, 2011 at 5:57 PM, Michael Dale > wrote: >> On 04/02/2011 04:08 PM, Ryan Kaldari wrote: >>> 2. Creating "The Complete Idiot's Guide to Writing MediaWiki >>> Extensions" >>> and "The Complete Idiot's Guide to Writing MediaWiki Gadgets (in >>> jQuery)" >> +1 ... Beyond the guide we could win a lot by centralising some of >> the >> scripts and libraries on mediawiki.org and establishing best >> practices >> for things like gadget localisation. >> >> --michael > I believe Krinkle started doing that with gadgets when he was updating > them to jQuery & Resourcelorder compatibility... Although I don't know > how many sites load them remotely (like how many sites do with HotCat > from commons[1]) or just copy and paste them onto their local sites. > > > [1]. http://www.mediawiki.org/wiki/MediaWiki:Gadget-HotCat.js Yep, the most popular ones I've made central by either loading them from Commons, Meta-Wiki or MediaWiki.org (Usually Meta-Wiki for wmf specific, MediaWiki.org for universal ones, although some are on Commons or en.wikipedia for historical reasons[1] ) Gadgets that are very simple in nature (that aren't worth an http- request) I have put into the Snippets directory [2]. This includes popular things that are often in scripts like Common.js such as Main page -tab text fixer[3], redirecting User:Name/skin.js/css to the appropiate place [4], Unwatch from watchlist [5] and much more. -- Krinkle [1] Although they could be moved to Meta, right now I'm not because their developer would no longer be able to update them as they're usually sysop on commons or en.wiki. [2] http://www.mediawiki.org/wiki/Category:All_snippets http://www.mediawiki.org/wiki/Snippets [3] http://www.mediawiki.org/wiki/Snippets/Main_Page_tab MediaWiki 1.18 will make this script redundant. But any wiki running an older version (either wmf or not) will find this useful. [4] http://www.mediawiki.org/wiki/Snippets/Redirect_skin.js Although common.js exists now, skin.js/css is still used a lot. [5] http://www.mediawiki.org/wiki/Snippets/Unwatch_from_watchlist ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
bawolff wrote:
>> The good thing about forgotten/abandoned/unloved/etc. projects is
>> that
>> they probably don't have lots of cruft accumulated in the global
>> CSS/JS
>> files (as they require quite lively tech-savvy community to
>> maintain them).
>>
>> So those sites will not probably require any changes and will survive
>> HTML5 migration without any problems.
>>
>> //Marcin
>
> On the contrary, I find the small language wiki projects to be in much
> worse shape. Often they have syntax errors in their js files, breaking
(..)
>
> -bawolff
I just want to leave a quick reply emphasizing what bawolff is saying.
Because of my "2011 Resource Walker"[1] edition of the Tour de Wiki[2]
I can only say that it's very true. More often than not, the smaller
the wiki
– the worse the local site wide resources are.
Blindly copied mess from one wiki to another, in some cases (the better
ones) messed with until they work. Other administrators have copied
dozens of scripts just to get 1 certain functionality going (they dont
know
how it works, they just know that wiki Foo has it and they don't, so
if you
copy all global css/js, it should work, right ?)
In many cases the contrary was the result, even then the functionality
would still not work (ie. because it was comparing wgPageName to a
hardcoded pagename (such as "Special:Watchlist") which will never
return true on a non-English wiki. Or something else that is dependant
on something. In the end the script would just rot.
A few other random examples:
* Loading scripts (such as pcount.wikimedia.org) that haven't been
around for a long time
* "Temporary" hacks. (ie. someone at en.wikipedia tries something for
a day, which happends to be the day another wiki copies everything.
Then another wiki copies it from there etc.)
* Useless CSS (I've seen styles like #enWikiMP_FooBar on my wiki's
site wide stylesheets, even though it's useless bandwidth for all of
them)
* Redundant JS (Declerations of importScript, window.ta = {}, etc.
you name it)
* And more, much more.
Although it requires integrity and a fair bit of javascript experience,
I can only welcome more people to join the tour. And to just take
1 wiki from the list and:
* Mark it in the table as "checking" and ~~~
* go through the checklist [2]
* go through the migration guide [3] and js deprecation list [4]
* for [Vector|Common|Monobook].css/js
* Check if there's any MediaWiki:Gadget* or MediaWiki:J[q|Q]uery*
prefixes
wich may have to be replaced with mw.loader.load/using [4]
On average it's about 30 minutes for wiki. Some wikis dont have any
global js/css
at all, others are a big fat mess.
--
Krinkle
[1] http://meta.wikimedia.org/wiki/User:Krinkle/Le_Tour_de_Wikí
[2] http://meta.wikimedia.org/wiki/User:Krinkle/Le_Tour_de_Wikí/1-17-allwikis
[3] http://www.mediawiki.org/wiki/RL/MGU
[4] http://www.mediawiki.org/wiki/RL/JD
[5] http://www.mediawiki.org/wiki/RL/MGU#Keep_gadgets_central
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
On Sun, Apr 3, 2011 at 5:57 PM, Michael Dale wrote: > On 04/02/2011 04:08 PM, Ryan Kaldari wrote: >> 2. Creating "The Complete Idiot's Guide to Writing MediaWiki Extensions" >> and "The Complete Idiot's Guide to Writing MediaWiki Gadgets (in jQuery)" > +1 ... Beyond the guide we could win a lot by centralising some of the > scripts and libraries on mediawiki.org and establishing best practices > for things like gadget localisation. > > --michael I believe Krinkle started doing that with gadgets when he was updating them to jQuery & Resourcelorder compatibility... Although I don't know how many sites load them remotely (like how many sites do with HotCat from commons[1]) or just copy and paste them onto their local sites. [1]. http://www.mediawiki.org/wiki/MediaWiki:Gadget-HotCat.js ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
On 04/02/2011 04:08 PM, Ryan Kaldari wrote: > 2. Creating "The Complete Idiot's Guide to Writing MediaWiki Extensions" > and "The Complete Idiot's Guide to Writing MediaWiki Gadgets (in jQuery)" +1 ... Beyond the guide we could win a lot by centralising some of the scripts and libraries on mediawiki.org and establishing best practices for things like gadget localisation. --michael ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
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 Kaldari >> Subject: Re: [Wikitech-l] Focus on sister projects >> To: Conrad Irwin >> Cc: Wikimedia developers >> Message-ID:<4d967e70.2080...@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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
> Message: 2 > Date: Fri, 01 Apr 2011 18:40:00 -0700 > From: Ryan Kaldari > Subject: Re: [Wikitech-l] Focus on sister projects > To: Conrad Irwin > Cc: Wikimedia developers > Message-ID: <4d967e70.2080...@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
Re: [Wikitech-l] Focus on sister projects
> Message: 6 > Date: Sat, 2 Apr 2011 08:23:36 + (UTC) > From: Marcin Cieslak > Subject: Re: [Wikitech-l] Focus on sister projects > To: wikitech-l@lists.wikimedia.org > Message-ID: > Content-Type: text/plain; charset=us-ascii > > >> MZMcBride wrote: > > Ryan Kaldari wrote: > >> Yeah, the local CSS/JS cruft is definitely a problem. I've tried doing > >> clean-up on a few wikis, but I usually just get chewed out by the local > >> admins for not discussing every change in detail (which obviously > >> doesn't scale for fixing 200+ wikis). I would love to hear ideas for how > >> to address this problem. > > > > This caught my eye as Wikimedia has far more than 200 wikis. There seems to > > be a shift happening within the Wikimedia Foundation. The sister projects > > have routinely been ignored in the past, but things seem to be going further > > lately > > The good thing about forgotten/abandoned/unloved/etc. projects is that > they probably don't have lots of cruft accumulated in the global CSS/JS > files (as they require quite lively tech-savvy community to maintain them). > > So those sites will not probably require any changes and will survive > HTML5 migration without any problems. > > //Marcin On the contrary, I find the small language wiki projects to be in much worse shape. Often they have syntax errors in their js files, breaking _all_ js. Other times they have stuff that is just plain wrong. (Like anyone remember the toolserver tool to gather stats before stuff was available at http://dammit.lt/wikistats/ - where projects would put js that pinged the toolserver once every 100 hits. That code is still in many small projects [usually with the project code field set to the wrong project]. I've even seen that code in wikis that were created after said toolserver tool stopped working). On the other hand they probably won't complain, as the js is already fairly broken ;) -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
>> Billinghurst wrote: > Ryan, > > While admins will always be protective of their patch, especially if > something breaks > universally, none of us wishes to impede progress and we want to know how we > can help. > -> Make us do our homework > -> Give us time to marshal resources, and > -> Have expectations that we should be organised to help. > If we cannot do that, then it is somewhat upon our heads if you have to do > what you have > to do. Frankly, from my experience as sysop at plwiki (not a sister project, though, but I did some of the css/js work for pl* sisters), I'd rather recommend to explain a bit (like "say who you are"), but go ahead with the changes. Maybe a single page on meta will do. The problem will be with non-English projects, as some people may not read English at all, like some of the quite MediaWiki-savvy admins in the projects for smaller languages in the former USSR. Giving time and having much discussion serves little point, since from my experience those volunteers who spent lots of time on building those scripts now how little time to re-write them or review them (as many of stuff simply needs to be deleted). Some may react badly, like just reverting changes because "it works". Well, it works in a way, and very often some strange effect appear (mainly because changed loading order of js/css). I am all for opening up extensions for sister projects - [[Extension:Proofread]] improved situation at many wikisources, I would envision we have more sister-project-related extensions in the SVN, even if they are CSS- or JS- only (or mostly). This gives core developers a chance to better understand of the impact they make and gives them the opportunity to fix problems themselves in a cross-repository sweeping commits with proper commit logs. //Marcin ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
>> MZMcBride wrote: > Ryan Kaldari wrote: >> Yeah, the local CSS/JS cruft is definitely a problem. I've tried doing >> clean-up on a few wikis, but I usually just get chewed out by the local >> admins for not discussing every change in detail (which obviously >> doesn't scale for fixing 200+ wikis). I would love to hear ideas for how >> to address this problem. > > This caught my eye as Wikimedia has far more than 200 wikis. There seems to > be a shift happening within the Wikimedia Foundation. The sister projects > have routinely been ignored in the past, but things seem to be going further > lately The good thing about forgotten/abandoned/unloved/etc. projects is that they probably don't have lots of cruft accumulated in the global CSS/JS files (as they require quite lively tech-savvy community to maintain them). So those sites will not probably require any changes and will survive HTML5 migration without any problems. //Marcin ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
Ryan, My thoughts (from a sister project side) It is useful to go through a few bits to manage expectations. * General introductory information around the scope, expected outcomes, summary of what wikis can do and general dates and for this to be placed at the Techblog. This allows local wikis to know and prepare. As the importance rises, I think that a general sitenotice for a week is appropriate. Is it possible to do a site notice for admins only? As that would be most useful. [This lets those who are alert into the playpen and involved] * A place where the detail of the project and outcomes, and how to participate, and where to advise (aka complain) where and when things stop working, or help is needed. If you are planning to go through series of wikis, then if there is a timetable to which people can prepare, or even be available to help, and how they can help. [This empowers people and puts the emphasis on them to get themselves organised for your timetable, your time being the limited factor] * Where you are planning on doing work, having generic information at your local talk page about who you are and that points them to the information pages (general and detail), to the fact that they had been told it was going to happen and to where they should bitch and complain. [Akin to TALK TO THE HAND] While admins will always be protective of their patch, especially if something breaks universally, none of us wishes to impede progress and we want to know how we can help. -> Make us do our homework -> Give us time to marshal resources, and -> Have expectations that we should be organised to help. If we cannot do that, then it is somewhat upon our heads if you have to do what you have to do. Expectations and activities need to be reasonable and practical to both parties. Regards, Andrew <- CSS clueless beyond the basics On 1 Apr 2011 at 17:11, Ryan Kaldari wrote: > Can you possibly get any more hyperbolic? For your information, I've > been trying to clean up the Javascript of en.wiktionary.org this past > week, which is a total nightmare (and it's a sister project!). If you'd > like to help, feel free to join the discussions: > http://en.wiktionary.org/wiki/MediaWiki_talk:Common.js > http://en.wiktionary.org/wiki/Wiktionary_talk:Per-browser_preferences#Proposal_to_migrate_into_a_user_scripts_library > > Ryan Kaldari > > On 4/1/11 4:51 PM, MZMcBride wrote: > > Ryan Kaldari wrote: > >> Yeah, the local CSS/JS cruft is definitely a problem. I've tried doing > >> clean-up on a few wikis, but I usually just get chewed out by the local > >> admins for not discussing every change in detail (which obviously > >> doesn't scale for fixing 200+ wikis). I would love to hear ideas for how > >> to address this problem. > > This caught my eye as Wikimedia has far more than 200 wikis. There seems to > > be a shift happening within the Wikimedia Foundation. The sister projects > > have routinely been ignored in the past, but things seem to be going further > > lately > > > > Personally, I'm in favor of disbanding all of the projects that Wikimedia > > has no intention of actively supporting in the near-future or even mid-range > > future. I think the current situation in which certain sister projects are > > supported in name only is unacceptable to the users and to the public. > > > > MZMcBride > > > > > > > > ___ > > Wikitech-l mailing list > > Wikitech-l@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
Happy-melon wrote: > I would be very interested to hear what criterion you would use to separate > out a group of 200 (or any number other than zero, one or all [1]) wikis > which are "maintained" from the rest which are "unmaintained"; where the > distinction in quality of service, the ratio of Foundation resources to > userbase or readership, or any other meaningful statistic, showed any > obvious jump across the boundary. You would need to be able to show such a > thing in order to make anyone believe that there is any "intention" (or lack > thereof) for the Foundation to do anything with the sister projects. I'm not really sure what you're saying here. Are you trying to argue that the other projects get anywhere near as much attention as Wikipedia? > It's one thing to argue that more of the Foundation's resources should be > directed to particular projects; that's a perfectly reasonable discussion, > but for foundation-l, not here. It's quite another to argue that an > arbitrary number (don't forget that Ryan is referring to the number of wikis > with broken JavaScript which are unable to fix it themselves, not any > attempt to count every wiki in the cluster) represents some freudian slip > into some diabolical scheme or even into a subconscious mindset. Even if > that is what you want to claim, that belongs in foundation-l as well. "Our > shell request workflow could use work" is a time-honoured topic which comes > and goes and seems to be in a relatively successful era at the moment. > Anything more political than that has nothing to do with, and no place on, > wikitech-l. I considered the venue before posting. But the reality is that the tech side (or specifically MediaWiki) is currently at the core of every Wikimedia wiki. Its development, its features, its architecture, etc. all have a fundamental impact on what any Wikimedia site is. The focus of MediaWiki should mirror the focus of the Wikimedia Foundation. Currently MediaWiki tries to do too much, tries to fill too many niches, and ends up not doing very much particularly well. I'd like to see that change. I'd like to see it focused, as I think it would benefit both MediaWiki and the Wikimedia Foundation to a huge extent. If you think that's a topic for foundation-l, I suppose we'll have to agree to disagree. Personally, I think it's a tech topic, given that nearly every change seems to at least begin with code development. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
Ok — yes loading speeds are definitely something worth improving. WT:PREFS to become gadgets has been discussed ever since gadgets was released, it will happen one day :). Luckily that code is only loaded for people who are using WT:PREFS, so it should have minimal impact. I'd be pretty interested to — do you have a guideline as to the expected format. In particular I think the "core" of the editor, which provides a framework for javascript to load, edit, undo, redo, and save the page (with edit summaries) would be pretty useful everywhere. It's documented in the first half of http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_docs and there's a tutorial at http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_tutorial.js — but it could do with "new-ification" (in particular some jQuery would be nice, and there's probably a better javascript API wrapper than JsMwApi :). Conrad On Fri, Apr 1, 2011 at 6:40 PM, Ryan Kaldari wrote: > Good idea. After the 1.17 deployment, I've been trying to go through and > clean-up some of the Javascript cruft that has built up on the various wikis > over the years. One of the main goals of 1.17 was improving page loading > speeds by optimizing Javascript delivery. Of course if all the wikis are > serving lots of old redundant Javascript, the optimization doesn't > accomplish that much. On wiktionary specifically, the importScript and > importExternalScript functions are redundant, and the Wiktionary:PREFS > system should be retired now that Gadgets are available. I admit I was much > too gung-ho in my clean-up regarding Wiktionary, and I intend to let the > admins there handle it from here. > > 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 > > > On 4/1/11 5:53 PM, Conrad Irwin wrote: >> >> Ryan — what is your goal with the cleanup? Part of the reason I think >> you're getting nowhere on Wiktionary is that as far as anyone there >> can tell you're just changing stuff for the fun of changing stuff (and >> breaking it in the process...). If you can tell us what you're trying >> to achieve, then (given that we wrote the code, and have a reasonably >> good idea of how it's used), we can probably help you. >> >> Conrad >> >> On Fri, Apr 1, 2011 at 5:11 PM, Ryan Kaldari >> wrote: >>> >>> Can you possibly get any more hyperbolic? For your information, I've >>> been trying to clean up the Javascript of en.wiktionary.org this past >>> week, which is a total nightmare (and it's a sister project!). If you'd >>> like to help, feel free to join the discussions: >>> http://en.wiktionary.org/wiki/MediaWiki_talk:Common.js >>> >>> http://en.wiktionary.org/wiki/Wiktionary_talk:Per-browser_preferences#Proposal_to_migrate_into_a_user_scripts_library >>> >>> Ryan Kaldari >>> >>> On 4/1/11 4:51 PM, MZMcBride wrote: Ryan Kaldari wrote: > > Yeah, the local CSS/JS cruft is definitely a problem. I've tried doing > clean-up on a few wikis, but I usually just get chewed out by the local > admins for not discussing every change in detail (which obviously > doesn't scale for fixing 200+ wikis). I would love to hear ideas for > how > to address this problem. This caught my eye as Wikimedia has far more than 200 wikis. There seems to be a shift happening within the Wikimedia Foundation. The sister projects have routinely been ignored in the past, but things seem to be going further lately Personally, I'm in favor of disbanding all of the projects that Wikimedia has no intention of actively supporting in the near-future or even mid-range future. I think the current situation in which certain sister projects are supported in name only is unacceptable to the users and to the public. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l >>> >>> ___ >>> Wikitech-l mailing list >>> Wikitech-l@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >>> > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
Good idea. After the 1.17 deployment, I've been trying to go through and clean-up some of the Javascript cruft that has built up on the various wikis over the years. One of the main goals of 1.17 was improving page loading speeds by optimizing Javascript delivery. Of course if all the wikis are serving lots of old redundant Javascript, the optimization doesn't accomplish that much. On wiktionary specifically, the importScript and importExternalScript functions are redundant, and the Wiktionary:PREFS system should be retired now that Gadgets are available. I admit I was much too gung-ho in my clean-up regarding Wiktionary, and I intend to let the admins there handle it from here. 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 On 4/1/11 5:53 PM, Conrad Irwin wrote: > Ryan — what is your goal with the cleanup? Part of the reason I think > you're getting nowhere on Wiktionary is that as far as anyone there > can tell you're just changing stuff for the fun of changing stuff (and > breaking it in the process...). If you can tell us what you're trying > to achieve, then (given that we wrote the code, and have a reasonably > good idea of how it's used), we can probably help you. > > Conrad > > On Fri, Apr 1, 2011 at 5:11 PM, Ryan Kaldari wrote: >> Can you possibly get any more hyperbolic? For your information, I've >> been trying to clean up the Javascript of en.wiktionary.org this past >> week, which is a total nightmare (and it's a sister project!). If you'd >> like to help, feel free to join the discussions: >> http://en.wiktionary.org/wiki/MediaWiki_talk:Common.js >> http://en.wiktionary.org/wiki/Wiktionary_talk:Per-browser_preferences#Proposal_to_migrate_into_a_user_scripts_library >> >> Ryan Kaldari >> >> On 4/1/11 4:51 PM, MZMcBride wrote: >>> Ryan Kaldari wrote: Yeah, the local CSS/JS cruft is definitely a problem. I've tried doing clean-up on a few wikis, but I usually just get chewed out by the local admins for not discussing every change in detail (which obviously doesn't scale for fixing 200+ wikis). I would love to hear ideas for how to address this problem. >>> This caught my eye as Wikimedia has far more than 200 wikis. There seems to >>> be a shift happening within the Wikimedia Foundation. The sister projects >>> have routinely been ignored in the past, but things seem to be going further >>> lately >>> >>> Personally, I'm in favor of disbanding all of the projects that Wikimedia >>> has no intention of actively supporting in the near-future or even mid-range >>> future. I think the current situation in which certain sister projects are >>> supported in name only is unacceptable to the users and to the public. >>> >>> MZMcBride >>> >>> >>> >>> ___ >>> Wikitech-l mailing list >>> Wikitech-l@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> ___ >> Wikitech-l mailing list >> Wikitech-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
Ryan — what is your goal with the cleanup? Part of the reason I think you're getting nowhere on Wiktionary is that as far as anyone there can tell you're just changing stuff for the fun of changing stuff (and breaking it in the process...). If you can tell us what you're trying to achieve, then (given that we wrote the code, and have a reasonably good idea of how it's used), we can probably help you. Conrad On Fri, Apr 1, 2011 at 5:11 PM, Ryan Kaldari wrote: > Can you possibly get any more hyperbolic? For your information, I've > been trying to clean up the Javascript of en.wiktionary.org this past > week, which is a total nightmare (and it's a sister project!). If you'd > like to help, feel free to join the discussions: > http://en.wiktionary.org/wiki/MediaWiki_talk:Common.js > http://en.wiktionary.org/wiki/Wiktionary_talk:Per-browser_preferences#Proposal_to_migrate_into_a_user_scripts_library > > Ryan Kaldari > > On 4/1/11 4:51 PM, MZMcBride wrote: >> Ryan Kaldari wrote: >>> Yeah, the local CSS/JS cruft is definitely a problem. I've tried doing >>> clean-up on a few wikis, but I usually just get chewed out by the local >>> admins for not discussing every change in detail (which obviously >>> doesn't scale for fixing 200+ wikis). I would love to hear ideas for how >>> to address this problem. >> This caught my eye as Wikimedia has far more than 200 wikis. There seems to >> be a shift happening within the Wikimedia Foundation. The sister projects >> have routinely been ignored in the past, but things seem to be going further >> lately >> >> Personally, I'm in favor of disbanding all of the projects that Wikimedia >> has no intention of actively supporting in the near-future or even mid-range >> future. I think the current situation in which certain sister projects are >> supported in name only is unacceptable to the users and to the public. >> >> MZMcBride >> >> >> >> ___ >> Wikitech-l mailing list >> Wikitech-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
"MZMcBride" wrote in message news:c9bbcf19.1056...@mzmcbride.com... > Ryan Kaldari wrote: >> Yeah, the local CSS/JS cruft is definitely a problem. I've tried doing >> clean-up on a few wikis, but I usually just get chewed out by the local >> admins for not discussing every change in detail (which obviously >> doesn't scale for fixing 200+ wikis). I would love to hear ideas for how >> to address this problem. > > This caught my eye as Wikimedia has far more than 200 wikis. There seems > to > be a shift happening within the Wikimedia Foundation. The sister projects > have routinely been ignored in the past, but things seem to be going > further > lately > > Personally, I'm in favor of disbanding all of the projects that Wikimedia > has no intention of actively supporting in the near-future or even > mid-range > future. I think the current situation in which certain sister projects are > supported in name only is unacceptable to the users and to the public. > > MZMcBride I would be very interested to hear what criterion you would use to separate out a group of 200 (or any number other than zero, one or all [1]) wikis which are "maintained" from the rest which are "unmaintained"; where the distinction in quality of service, the ratio of Foundation resources to userbase or readership, or any other meaningful statistic, showed any obvious jump across the boundary. You would need to be able to show such a thing in order to make anyone believe that there is any "intention" (or lack thereof) for the Foundation to do anything with the sister projects. It's one thing to argue that more of the Foundation's resources should be directed to particular projects; that's a perfectly reasonable discussion, but for foundation-l, not here. It's quite another to argue that an arbitrary number (don't forget that Ryan is referring to the number of wikis with broken JavaScript which are unable to fix it themselves, not any attempt to count every wiki in the cluster) represents some freudian slip into some diabolical scheme or even into a subconscious mindset. Even if that is what you want to claim, that belongs in foundation-l as well. "Our shell request workflow could use work" is a time-honoured topic which comes and goes and seems to be in a relatively successful era at the moment. Anything more political than that has nothing to do with, and no place on, wikitech-l. --HM [1] http://en.wikipedia.org/wiki/Zero_One_Infinity ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
Can you possibly get any more hyperbolic? For your information, I've been trying to clean up the Javascript of en.wiktionary.org this past week, which is a total nightmare (and it's a sister project!). If you'd like to help, feel free to join the discussions: http://en.wiktionary.org/wiki/MediaWiki_talk:Common.js http://en.wiktionary.org/wiki/Wiktionary_talk:Per-browser_preferences#Proposal_to_migrate_into_a_user_scripts_library Ryan Kaldari On 4/1/11 4:51 PM, MZMcBride wrote: > Ryan Kaldari wrote: >> Yeah, the local CSS/JS cruft is definitely a problem. I've tried doing >> clean-up on a few wikis, but I usually just get chewed out by the local >> admins for not discussing every change in detail (which obviously >> doesn't scale for fixing 200+ wikis). I would love to hear ideas for how >> to address this problem. > This caught my eye as Wikimedia has far more than 200 wikis. There seems to > be a shift happening within the Wikimedia Foundation. The sister projects > have routinely been ignored in the past, but things seem to be going further > lately > > Personally, I'm in favor of disbanding all of the projects that Wikimedia > has no intention of actively supporting in the near-future or even mid-range > future. I think the current situation in which certain sister projects are > supported in name only is unacceptable to the users and to the public. > > MZMcBride > > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Focus on sister projects
Ryan Kaldari wrote: > Yeah, the local CSS/JS cruft is definitely a problem. I've tried doing > clean-up on a few wikis, but I usually just get chewed out by the local > admins for not discussing every change in detail (which obviously > doesn't scale for fixing 200+ wikis). I would love to hear ideas for how > to address this problem. This caught my eye as Wikimedia has far more than 200 wikis. There seems to be a shift happening within the Wikimedia Foundation. The sister projects have routinely been ignored in the past, but things seem to be going further lately Personally, I'm in favor of disbanding all of the projects that Wikimedia has no intention of actively supporting in the near-future or even mid-range future. I think the current situation in which certain sister projects are supported in name only is unacceptable to the users and to the public. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
