Re: [Wikitech-l] Page display slowness
At 2010-09-09 01:20, Lars Aronsson wrote: > For various reasons, I'm now using the Opera 10.10 browser on Linux. > With the new vector skin, trying to open an edit form takes 4 or 5 > seconds. This is not because the servers are slow, the whole is quite > fast in Firefox, but in Opera time elapses while executing the > JavaScript that adds the toolbar above the main textarea and > rearranges the left menu. During this time, I can sometimes set > the cursor in the textarea, but two seconds later focus is gone, > and I have to set the cursor again before I can start to edit. > > It was not this slow under the old monobook skin. > > I know I can go back to monobook, so don't tell me. I just wanted > to report this. Perhaps there's some part of vector that can be > improved. First of all try 10.60 (or 10.61 to be more exact). Secondly there will be some improvements with load times when the ResourceLoader will be used. See: http://www.mediawiki.org/wiki/ResourceLoader Not sure if this would work for you thou as page rendering time might be actual stopper in your case. But new version of Opera is faster at that. Regards, Nux. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] On decentralized discussions
1 - 0 for Domas 2010/9/9, Domas Mituzas : > >> Why decentralized discussions even more? And is there a reason you >> always seem to spilt your replies to the thread into new treads/topics >> instead of just replying to the original one? > > > Innovation, maybe? > > Domas > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- Regards, Huib "Abigor" Laurens Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] On decentralized discussions
> Why decentralized discussions even more? And is there a reason you > always seem to spilt your replies to the thread into new treads/topics > instead of just replying to the original one? Innovation, maybe? Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
Why decentralized discussions even more? And is there a reason you always seem to spilt your replies to the thread into new treads/topics instead of just replying to the original one? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
On 9/8/10 5:35 PM, Chad wrote: > I think the point was not about hardware, but the OPs > inability to include a single linebreak in the e-mail. I need an open source irony detector. -- Neil Kandalgaonkar ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
On Wed, Sep 8, 2010 at 8:32 PM, Neil Kandalgaonkar wrote: > On 9/8/10 2:26 PM, Domas Mituzas wrote: >> Hi! >> >>> ... there would now be open source hardware >> >> Do you need open source "Enter" key? > > Open source hardware isn't an inherent absurdity... it usually means > that the hardware designs or other precursors (such as code that can > generate circuit designs) are freely available. > > http://en.wikipedia.org/wiki/Open-source_hardware > > -- > Neil Kandalgaonkar > I think the point was not about hardware, but the OPs inability to include a single linebreak in the e-mail. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
On Wed, Sep 8, 2010 at 8:28 PM, David Gerard wrote: > On 9 September 2010 01:25, Chad wrote: > >> Just like wikitext-l, a specialized list :) > > > Careful there, wikitext-l may have come up with something slightly > useful. You never know what might breed in such a swamp. > When it's even remotely usable in MediaWiki, then maybe I'll take notice. I've come to learn that "parser rewrites" are largely vaporware, so pardon me if I'm a little skeptical. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
On 9/8/10 2:26 PM, Domas Mituzas wrote: > Hi! > >> ... there would now be open source hardware > > Do you need open source "Enter" key? Open source hardware isn't an inherent absurdity... it usually means that the hardware designs or other precursors (such as code that can generate circuit designs) are freely available. http://en.wikipedia.org/wiki/Open-source_hardware -- Neil Kandalgaonkar ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
On 9 September 2010 01:25, Chad wrote: > Just like wikitext-l, a specialized list :) Careful there, wikitext-l may have come up with something slightly useful. You never know what might breed in such a swamp. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
On Wed, Sep 8, 2010 at 8:11 PM, Domas Mituzas wrote: > Hi! > >> I created a yahoo group > > Why not Facebook Page?!!? > > Domas > Or a new mailing list! Just like wikitext-l, a specialized list :) -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
Hi! > I created a yahoo group Why not Facebook Page?!!? Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Community vs. centralized development
Hi, I created a yahoo group for people interested in continuing the discussion on "Community vs. centralized development" as well as up to date wiki backups. Please join if you want to help to keep the Wikimedia foundation part of the community or just like chatting about it! Here is the group link: http://tech.groups.yahoo.com/group/wikishare/ "In this group topics are discussed related to the Wikimedia Foundation's relationship to the community of volunteer developers and users, as well as distribution of wiki backups and image backups. Two main goals of the group are to ensure that Wikimedia foundation development is community centered and also to have up to date full history Wikimedia Foundation wiki's and wiki images freely available for download." cheers, Jamie ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Page display slowness
For various reasons, I'm now using the Opera 10.10 browser on Linux. With the new vector skin, trying to open an edit form takes 4 or 5 seconds. This is not because the servers are slow, the whole is quite fast in Firefox, but in Opera time elapses while executing the JavaScript that adds the toolbar above the main textarea and rearranges the left menu. During this time, I can sometimes set the cursor in the textarea, but two seconds later focus is gone, and I have to set the cursor again before I can start to edit. It was not this slow under the old monobook skin. I know I can go back to monobook, so don't tell me. I just wanted to report this. Perhaps there's some part of vector that can be improved. -- Lars Aronsson (l...@aronsson.se) Aronsson Datateknik - http://aronsson.se ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
On 9/8/2010 1:45 PM, Ryan Kaldari wrote: > On 9/7/10 11:23 PM, Robert Leverington wrote: >> This may well be true for the community in general, but this discussion >> is specifically about the volunteer developer community, which is >> clearly being left out of the loop in a large respect - otherwise this >> discussion would not exist. > > I agree that the volunteer dev community is not as in-the-loop as paid > staff, but it's not because the Foundation is trying to keep them out of > the loop. Communicating with the dev community, the broader community, > fellow staff, and keeping up with an aggressive development schedule is > not an easy task! In 90% of of cases, there should be little difference between communicating with staff and communicating with the developer community. Obviously there will be some non-development related staff communication, but there really shouldn't be a difference between communicating with staff and the community. An intentional or incidental separation between staff and community is really the underlying problem. > It doesn't take a conspiracy to not satisfactorily > fulfill all of those requirements. Obviously, we can stand some > improvement, which is why the Foundation is planning on specifically > hiring someone to act as a bugmeister and development coordinator in the > very near future. What we need are helpful (and realistic) suggestions > for how to improve communication, not misguided badgering about "secret > channels". Getting rid of excessive amounts of communication channels isn't a useful suggestion? There are 2 main public mailing lists and 3 main public IRC channels. Then there's about a dozen other "minor" public mailing lists. How many additional ones are needed? Why does the non-staff community need to be excluded from them? A few years ago, there were few staff developers and many worked remotely. There were few of the communication issues we have now. More recently, the WMF hired more staff developers and began concentrating them in the main office and some private channels/lists sprung up to support them. Now we have communication problems. Its possible its just a coincidence, but it certainly doesn't look like one. At the very least, decreasing excessive "bureaucracy" (for lack of a better term) is something that should be considered as a matter of course. -- Alex (wikipedia:en:User:Mr.Z-man) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
On 8 September 2010 23:00, Ryan Kaldari wrote: > I had no idea that usurping an open source project was as easy as not > providing full history back-ups and image dumps. And here I was trying > to replace all the board members with proxies from Wikia! What a waste > of time ;) Neglecting to make it possible to get the data out is an effective way to proprietise a wiki. Making the backups work is important. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
I had no idea that usurping an open source project was as easy as not providing full history back-ups and image dumps. And here I was trying to replace all the board members with proxies from Wikia! What a waste of time ;) Ryan Kaldari On 9/8/10 2:15 PM, Jamie Morken wrote: > Hi, > > I was involved in an open source project that was usurped by one of the main > developers for the sole reason of making money, and that project continues > now to take advantage of the community to increase the profit of that > developer. I never would have thought such a thing was possible until I saw > that happen. If that developer wasn't acting greedy, there would now be open > source hardware for radio transceivers of all types, but instead there is > only open source software for radio of all types. I find it a shame, and > when I was working on that project I could *feel* it being usurped! I > unfortunately may be paranoid as I feel the same thing here with the > wikimedia foundation usurping wikipedia. If you don't believe me, just > consider that it is a very gradual process, like getting people used to not > being able to download image dumps anymore, and ignoring ALL requests to > restore this functionality. Also failing to provide full history backups of > the flagship wiki. These two facts allow the wikimedia foundation to > maintain the control of intellectual property that wasn't created by the > people. If you want the wikimedia foundation to respect you as volunteers, > you will have to DEMAND respect by making sure that they never usurp the > project. I think the best way to do this is to make sure we can all download > up to date full history with images wikipedia's so a fork at any time is > possible. Sure it may be paranoid, but trust me it is worth it to be > paranoid regarding a project as important as wikipedia. I have been in > situations like this before, I wish I had acted before even if I was wrong! > I wouldn't even be speaking now except for reading the heart-felt words of > volunteers in this thread that are unhappy with how the wikimedia foundation > is running. We need to organize to get wikimedia foundation to release > images tarballs, they are only ignoring multiple requests to do so, so far. > > cheers, > Jamie > > > ___ > 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] Community vs. centralized development
On 8 September 2010 22:15, Jamie Morken wrote: > I was involved in an open source project that was usurped by one of the main > developers for the sole reason of making money, and that project continues > now to take advantage of the community to increase the profit of that > developer. I never would have thought such a thing was possible until I saw > that happen. If that developer wasn't acting greedy, there would now be open > source hardware for radio transceivers of all types, but instead there is > only open source software for radio of all types. I find it a shame, and > when I was working on that project I could *feel* it being usurped! I > unfortunately may be paranoid as I feel the same thing here with the > wikimedia foundation usurping wikipedia. If you don't believe me, just > consider that it is a very gradual process, like getting people used to not > being able to download image dumps anymore, and ignoring ALL requests to > restore this functionality. Also failing to provide full history backups of > the flagship wiki. These two facts allow the wikimedia foundation to > maintain the control of intellectual property that wasn't created by the > people. This is something that's been a problem for years now. I do not think there is any sort of deliberate intent. However, keeping the data close is a way to proprietise a wiki even if it's free content, so making it easy to fork is an important attitude to maintain. I realise this is difficult when the devs have to work as hard as possible just to keep everything from falling over ... - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
Hi! > ... there would now be open source hardware Do you need open source "Enter" key? Domas ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Community vs. centralized development
Hi, I was involved in an open source project that was usurped by one of the main developers for the sole reason of making money, and that project continues now to take advantage of the community to increase the profit of that developer. I never would have thought such a thing was possible until I saw that happen. If that developer wasn't acting greedy, there would now be open source hardware for radio transceivers of all types, but instead there is only open source software for radio of all types. I find it a shame, and when I was working on that project I could *feel* it being usurped! I unfortunately may be paranoid as I feel the same thing here with the wikimedia foundation usurping wikipedia. If you don't believe me, just consider that it is a very gradual process, like getting people used to not being able to download image dumps anymore, and ignoring ALL requests to restore this functionality. Also failing to provide full history backups of the flagship wiki. These two facts allow the wikimedia foundation to maintain the control of intellectual property that wasn't created by the people. If you want the wikimedia foundation to respect you as volunteers, you will have to DEMAND respect by making sure that they never usurp the project. I think the best way to do this is to make sure we can all download up to date full history with images wikipedia's so a fork at any time is possible. Sure it may be paranoid, but trust me it is worth it to be paranoid regarding a project as important as wikipedia. I have been in situations like this before, I wish I had acted before even if I was wrong! I wouldn't even be speaking now except for reading the heart-felt words of volunteers in this thread that are unhappy with how the wikimedia foundation is running. We need to organize to get wikimedia foundation to release images tarballs, they are only ignoring multiple requests to do so, so far. cheers, Jamie ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ResourceLoader, now in trunk!
On 09/08/2010 11:25 AM, Roan Kattouw wrote:
> It's defined on a MediaWiki: page, which is accessed by the server to
> generate the Gadgets tab in Special:Preferences. There is sufficient
> server-side knowledge about gadgets to implement them as modules,
> although I guess we might as well save ourselves the trouble and load
> them as wiki pages,
>
We should have an admin global enabled 'gadgets' enable system ( with
support for turning it on per user group ie all users, admin users etc.
Each gadget should define something like:
MediaWiki:Gadget-loader-ImageAnnotator.js where it has the small bit
that is presently stored in free text in MediaWiki:Common.js ie:
/ ImageAnnotator **
* Globally enabled per
*
http://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&oldid=26818359#New_interface_feature
*
* Maintainer: [[User:Lupo]]
/
if (wgNamespaceNumber != -1 && wgAction && (wgAction == 'view' ||
wgAction == 'purge')) {
// Not on Special pages, and only if viewing the page
if (typeof (ImageAnnotator_disable) == 'undefined' ||
!ImageAnnotator_disable) {
// Don't even import it if it's disabled.
importScript ('MediaWiki:Gadget-ImageAnnotator.js');
}
}
Should go into the "gadget loader file" and of course instead of
importScript, some loader call that aggregates all the loader load calls
for a given page ready time. It should ideally also support some sort of
grouping strategy parameter. We should say something like packages that
are larger than 30k or used on a single page should not be grouped. As
to avoid mangled cache effects escalating into problematic scenarios.
As we briefly discussed, I agree with Trevor that if the script is small
and more or less widely used its fine to retransmit the same package in
different contexts to avoid extra requests on first visit.
But it should be noted that separating requests can result in ~less~
requests. ie imagine grouping vs separate request where page 1 uses
resource set A, B and page 2 uses resource set A, C then page 3 uses
A,B,C you still end up doing 3 requests across the 3 page views, except
with 'one request' strategy you resend A. The forth page that just uses
B, C you can pull those from cache and do zero requests, or resend B, C
if you always go with a 'single request'. Of course as you add more
permutations like page 5 that uses just A just B or just C it can get
ugly. Which is why we need to ~strongly recommend~ the less than 30K or
rarely used javascript grouping rules somehow.
The old resource loader had the concept of 'buckets' I believe the
present resource loader just has an option to 'not-group', which is fine
since 'buckets' could be conceptualized as 'meta modules sets' that are
'not-grouped'. Not sure whats conceptually more clear. IMHO buckets is a
bit more friendly to modular extension gadget development since any
module can say its part of a given group without modifying a master or
core manifest.
At any rate, we should make sure to promote either buckets or 'meta
module' option, or it could result in painful excessive retransmission
of grouped javascrpt code.
--michael
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ResourceLoader, now in trunk!
2010/9/8 Michael Dale : > This is of course already supported, just not in 'grouped requests'. > Open up your scripts tab on a fresh load of > http://commons.wikimedia.org/wiki/Main_Page Like 24 or so of the 36 > scripts requests on commons are 'arbitrary wiki pages' requested as > javascript: > > http://commons.wikimedia.org/w/index.php?title=MediaWiki:AjaxQuickDelete.js&action=raw&ctype=text/javascript > Yeah, these should be grouped. > Not gadgets in the php extensions sense. Ie MediaWiki:Common.js does a > lot of loading Yes, this is a good reason why we should support loading of arbitrary wiki pages. > and the gadget set is not defined in php on the server. It's defined on a MediaWiki: page, which is accessed by the server to generate the Gadgets tab in Special:Preferences. There is sufficient server-side knowledge about gadgets to implement them as modules, although I guess we might as well save ourselves the trouble and load them as wiki pages, Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ResourceLoader, now in trunk!
On 09/08/2010 06:28 AM, Roan Kattouw wrote: > I don't believe we should necessarily support retrieval of arbitrary > wiki pages this way, but that's not needed for Gadgets: there's a > gadgets definition list listing all available gadgets, so Gadgets can > simply register each gadget as a module (presumably named something > like gadget-gadgetname). > This is of course already supported, just not in 'grouped requests'. Open up your scripts tab on a fresh load of http://commons.wikimedia.org/wiki/Main_Page Like 24 or so of the 36 scripts requests on commons are 'arbitrary wiki pages' requested as javascript: http://commons.wikimedia.org/w/index.php?title=MediaWiki:AjaxQuickDelete.js&action=raw&ctype=text/javascript Not gadgets in the php extensions sense. Ie MediaWiki:Common.js does a lot of loading and the gadget set is not defined in php on the server. The resource loader should minimally let you group MediaWiki namespace javascript and css. --michael ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
On 9/7/10 11:23 PM, Robert Leverington wrote: > I find > it difficult to believe that this is all the discussion that is going on, > or is everything else in face to face meetings - if so where are the > minutes and notes for these, because MediaWiki.org seems the obvious > place to put them? And furthermore where is all the project > documentation that you say has been produced? > For my work specifically (which isn't even of much interest to the dev community), you can find it documented and discussed at: http://meta.wikimedia.org/wiki/CentralNotice_upgrades http://www.mediawiki.org/wiki/Extension:CentralNotice/Phase_2 http://www.mediawiki.org/wiki/Extension:CentralNotice/Phase_3 http://techblog.wikimedia.org/2010/09/wmf-engineering/#more-1006 And most of those features are discussed in individual Bugzilla requests. > This may well be true for the community in general, but this discussion > is specifically about the volunteer developer community, which is > clearly being left out of the loop in a large respect - otherwise this > discussion would not exist. I agree that the volunteer dev community is not as in-the-loop as paid staff, but it's not because the Foundation is trying to keep them out of the loop. Communicating with the dev community, the broader community, fellow staff, and keeping up with an aggressive development schedule is not an easy task! It doesn't take a conspiracy to not satisfactorily fulfill all of those requirements. Obviously, we can stand some improvement, which is why the Foundation is planning on specifically hiring someone to act as a bugmeister and development coordinator in the very near future. What we need are helpful (and realistic) suggestions for how to improve communication, not misguided badgering about "secret channels". Ryan Kaldari ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
Well, this is probably my last post on this subject for now. I think I've made my points. Those who don't get them yet probably will continue not to get them, and those who get them but disagree probably will continue to disagree. It looks like nothing big is going to change right now, but I hope that when Danese gets up to this, we'll see real improvements and not just attempts to paper over the problem without properly understanding it. I'll just make a few further brief points to reiterate some things I said that seem to still be misunderstood: On Sun, Sep 5, 2010 at 10:27 PM, Tim Starling wrote: > I don't think you really know that. It's hard to see how much work > goes on behind closed doors when you only have a cursory involvement > with the project. It's pretty easy to figure out that there aren't daily (or weekly or monthly) face-to-face meetings among developers who live scattered across the world. > None of the open source projects I've been involved with fit the model > you describe. For instance, Squid makes heavy use of face-to-face > meetings, despite their geographically distributed development team. Just to be clear: face-to-face meetings are great, in moderation. I'm totally in favor of them. But having lots of conferences is not the same as working in an office together. > I think that's a false dichotomy. It is. There's a spectrum of middle ground in between, but the endpoints are perfectly tenable as well. I think that, given Wikimedia's mission as well as practical concerns, moving MediaWiki development significantly further toward openness would be a good thing. >> I can say that despite being a nobody at Mozilla and having gotten >> only one (rather trivial) patch accepted, I feel like I'm taken more >> seriously by most of their paid developers than by most of ours. > > I'm sorry to hear that, and I'd like to know (off list) which paid > developers are making you feel that way. It would be unfair to name anyone, in public or in private. If I've had negative experiences with some paid developers, that should really count in their favor, because it means I have had *some* experience interacting with them, period. If we exclude paid developers who were preexisting community members: * I can think of two who I see with any regularity in #mediawiki. * I can think of maybe three who I've had more than one conversation with on IRC ever. * I don't think I've ever seen a wikitech-l post from the majority of them. I can't think why most of them should even know who I am, except now maybe some disgruntled volunteer who's making trouble for them. Why would I *expect* them to respect me? On Tue, Sep 7, 2010 at 8:29 PM, Ryan Kaldari wrote: > First of all, all this talk of secret listservs and IRC channels is > malarkey. Yes, there are private listservs and IRC channels. All of them > are private for very specific and well-established reasons. Most of them > are only used in very specific circumstances (for example if there was a > security breach that needed to be discussed privately) and tend to be > very low traffic. They are not the places where important decisions are > made. 1) Either paid developers are coordinating someplace where volunteers don't see it, or they're not coordinating at all. The latter is implausible, so it's the former. It makes no difference if it's face-to-face meetings, teleconferences, IRC, or mailing lists, or even a technically public place that volunteers don't know about -- it's hidden. 2) The secret IRC channel is not low-traffic. The 1000th line before now in #wikimedia-tech (excluding parts/joins/etc., also excluding /me for simplicity) was about five days ago: $ grep -v '[^ ]* [^ ]* \*' FreeNode-#wikimedia-tech.log | tail -n 1000 | head -n 1 100903 16:08:55 and if you are only doing those in groups of 10, you need to multiply by at least 3 Doing the same on my log of the secret channel gives 100903 00:03:40, meaning it has roughly the same traffic level as #wikimedia-tech over that period. Anyone who hangs out there can tell you that almost nothing there is secret. I can't speak for private-l, because I'm not on it. > Secondly, the idea that developers here in the office don't interact > with the community is absurd. The developers here interact with the > community constantly. If the goal is to attract volunteers and make them feel part of the community, it doesn't matter whether the paid people think they're doing a good enough job. It matters whether the volunteers think it. I'm pretty sure it's clear by now that practically none of us do. As I said, anyone interested in fixing the problem would do well to start by surveying volunteers rather than looking at the issue from their own perspective, and Danese told me she does plan to do that -- so I'll wait. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ResourceLoader, now in trunk!
2010/9/8 Michael Dale :
> On 09/07/2010 12:19 AM, Roan Kattouw wrote:
>> 2010/9/7 Platonides:
>>
>>> I see. It would have to be a hook into the resource loader.
>>>
>> You don't need a hook in the server-side PHP part of the resource
>> loader, as determining which modules to load on that side is already
>> supported. The Gadgets extension's PHP code could inspect variables
>> like $wgTitle->getNamespace() and determine whether to load a certain
>> gadget or not.
>
> This would of-course result in mangled cache for every page context that
> had a different set of page conditionals. Its better to do as you say
> bellow and have thin loader code check javascript conditionals and then
> fire off the loading of the gadget as needed.
>
I see your argument how separating gadget loading into a separate
request might be better so as to avoid cache mangling, but I hadn't
really considered that and was looking for ways to tack gadget loading
onto the request loading statically requested modules (through
$wgOut), which is possible by a custom loader.
> Is this not what the mediaWiki.load.using() is for?
Yes, that's what you'd use in a thin loader module that then loads
other gadgets as needed, but it'd result in loading the requested
modules in a separate request (which seems to be what you want).
> Are wiki page names
> addressable as loadable modules? Ie can you request
> mediaWiki.load.using(['MediaWiki:MyGadgetDepenency.js',
> 'MediaWiki:MyGadget.js', 'MediaWiki:MyGadget.css' ] , function(){ ...
> MyGadget.doStuff() .. }
>
No, that's not supported.
> This was supported in the old resource loader via special WT: resource
> name pretext, but perhapse could be implemented more cleverly in the new
> resource loader. But would be nice to preserve the basic principal of
> being able to grab multiple wikipages in a single request, as to support
> more module gadget code.
>
I don't believe we should necessarily support retrieval of arbitrary
wiki pages this way, but that's not needed for Gadgets: there's a
gadgets definition list listing all available gadgets, so Gadgets can
simply register each gadget as a module (presumably named something
like gadget-gadgetname).
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
2010/9/7 Robert Leverington : > if so where are the > minutes and notes for these, because MediaWiki.org seems the obvious > place to put them? Indeed, there are lots of face-to-face meetings / teleconferences where minutes are currently captured on EtherPad, but I don't think these are routinely visibly shared. I think it would be great, wherever possible, to post these to MediaWiki.org in standardized places so that folks can follow what's happening (and express interest in participating). And while we've stopped using usabil...@wm, there's still quite a bit of e-mail traffic that could be usefully directed toward wikitech-l or to lists that are, at minimum, publicly archived and have clear processes for joining and leaving. You and Ryan both right -- there's still too much of an in-group/out-group communication pattern, and too little explicit invitation of and collaboration with volunteers. As I hope recent communications demonstrate, that's slowly shifting, but it will take some time. And yes, it takes threads like this one. But, Ryan is correct that there's no pattern of deliberate secrecy here either, and if you developed an open source transparency/collaboration scorecard for WMF, you'd probably get a mixed result today. We're doing well in some areas like general corporate transparency [1], or making sure that all code goes into a public VCS, or granting commit access liberally, or being routinely and openly communicative in countless public spaces and at all levels. But there's no reason we shouldn't be best in every category. ;-) And that ultimately means seeing _everything_ as a shared responsibility. Everyone who works for Wikimedia, as a volunteer or staff member, is passionate about what we're doing, or they won't be here for long. We're here to build wonderfully useful information resources and the open source technologies to sustain and grow them -- and to be excellent at it. If we maintain awareness of the forcing functions that influence how people communicate, then I think that's eminently achievable. This includes, for example: - felt deadline pressure in the original usability project - problems with signal/noise ratio on existing lists / channels - in-group bias created by high proximity / peer relationships among WMF staff This isn't a game of assigning responsibilities or blame. Rather, it's about us collectively breaking out of the in-group/out-group pattern, creating constructive and healthy public spaces of communication and collaboration, remaining flexible about deadlines and targets where possible, reminding ourselves to be inclusive and open in how we work, etc. I'm confident that we can do it. :-) Erik [1] It's a fun exercise to research other organizations, non-profits and for-profits. I do so routinely as part of my work, and there are very, very few similarly funded organizations that even come close to the level of disclosure that WMF is currently at. -- Erik Möller Deputy Director, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
