[Wikitech-l] Flagged Reviews default by quality levels
Hi, in the introduction to the Help page for the Flagged Reviews extension, it says the following: It is possible, however, to configure pages so that only revisions that are flagged to a certain level are visible when the page is viewed by readers (http://www.mediawiki.org/wiki/Help:Extension:FlaggedRevs). This would indeed seem to be one of the most basic functions of the extension. At he.wikisource the community has decided to change the installation so that only pages approved at the the highest level of quality will be shown as the default view, while all pages flagged at lower quality levels will show the current version as default. Can anyone tell us if such functionality is indeed possible? Dovi ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Notification bubble system
Le 13/08/12 19:18, Daniel Friesen a écrit : So I spent a night implementing a fully featured notification bubble system. Something that should work for watchlists, VisualEditor, and perhaps some other things like LQT, and perhaps anything we want to start making more dynamic. Same goes for anyone with a good Gadget idea that could use better notifications. Here's a demo video of the new notification system: https://www.mediawiki.org/wiki/File:Mw-notification.ogv Well done :) -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimania-l] Looking for Wikimania Materials on Wikipedia Infrastructure
Tomasz Ganicz, 27/08/2012 13:27: Detailed information regarding Wikimedia Foundation's server's and network can be found here: http://wikitech.wikimedia.org/ Which is completely useless for any kind of high-level information, in particular [[Server roles]] which is dead and has no replacement and https://meta.wikimedia.org/wiki/Wikimedia_servers is outdated. But you might dig http://wikitech.wikimedia.org/view/Presentations , it's also possible that some Wikimania presentations have been added already. Nemo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimania-l] Looking for Wikimania Materials on Wikipedia Infrastructure
While this isn't a wikimedia talk, this might have some information that would be helpful: http://www.youtube.com/watch?v=6r4qHVawVNQ Matthew Bowker http://en.wikipedia.org/wiki/User:Matthewrbowker On Aug 27, 2012, at 5:47 AM, Federico Leva (Nemo) nemow...@gmail.com wrote: Tomasz Ganicz, 27/08/2012 13:27: Detailed information regarding Wikimedia Foundation's server's and network can be found here: http://wikitech.wikimedia.org/ Which is completely useless for any kind of high-level information, in particular [[Server roles]] which is dead and has no replacement and https://meta.wikimedia.org/wiki/Wikimedia_servers is outdated. But you might dig http://wikitech.wikimedia.org/view/Presentations , it's also possible that some Wikimania presentations have been added already. Nemo ___ Wikimania-l mailing list wikimani...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikimania-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] translatewiki.net configuration and scripts in Git
Dear all, Over the past few months, we have moved the configuration of translatewiki.net over to the translatewiki repository in Git/Gerrit[1,2]. Recently we also added maintenance scripts to that. So in case you're wondering how the magic of supporting the localisation of 20 or so open source projects with MediaWiki and the Translate extension is done, the veil is now lieften and you can see (almost[3]) everything we have set up. If you see anything that could use improvement, we would be happy to see your suggestions in the form of patches ;). Cheers! [1] https://gerrit.wikimedia.org/r/gitweb?p=translatewiki.git;a=shortlog;h=HEAD [2] https://gerrit.wikimedia.org/r/#/q/project:translatewiki,n,z [3] https://translatewiki.net/wiki/Configuration -- Siebrand Mazeland Product Manager Localisation Wikimedia Foundation M: +31 6 50 69 1239 Skype: siebrand 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
Re: [Wikitech-l] Wikimedians are rightfully wary
On Thu, Aug 23, 2012 at 7:02 AM, Strainu strain...@gmail.com wrote: 2012/8/23 Tilman Bayer tba...@wikimedia.org: On Thu, Aug 23, 2012 at 4:27 AM, Strainu strain...@gmail.com wrote: ... You guys (and by that I mean anybody who doesn't regularly edit a text-producing project[1], but needs to make announcements from time to time; this includes most of the WMF employees) seem to have a problem with village pumps and instead invent all kind of alternative communication methods, like mailing lists, IRC meetings, Meta, WMF wiki etc., with the sole excuse being they're hundreds of them. ... It also sucks because the vast majority of contributors don't know/don't want to use IRC, mailing list or even other wikis [2]. Yes, that's true, it has been a major learning for WMF in recent years that while all these (and also the Wikimedia blog) can be useful channels, many Wikipedians don't leave their home wikis and expect really important announcements to be delivered there in some form. In our Wikimania talk, MZMcBride and I gave an overview of the mechanisms that are currently available to do so. Can you please point me to the location of the slides (if available)? They're linked from the abstract: https://wikimania2012.wikimedia.org/wiki/Submissions/Movement_Broadcasting_-_%27Stop_Spamming%27_vs._%27Nobody_Told_Me%27 -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code ideas thread
Hoi, I have re-read the Wikipedia article about OpenID and OpenAuth. OpenAuth while nice in many ways is NOT the same as OpenID. User authentication is one easy and obvious requirement and I have already said too much about its need. It is NOT clear at all to me why OpenAuth should be regarded over OpenID. The use case for OpenID is obvious. In contrast the case for OpenAuth is not clear at all. What practical things will it solve? Thanks, GerardM On 27 August 2012 01:48, Tyler Romeo tylerro...@gmail.com wrote: If there are issues with the old standard, there is no significant advantage to use of the old spec (besides the case that it already exists, etc...), and you are intending to actually use the standard rather than just throw it out for people to use. Then that's really a valid situation to write a new standard in. But the problem is that it already exists is in fact a valid reason to use a protocol. There are numerous libraries out there (including a PHP extension) that allow people to use OAuth to authenticate with services. Making our own protocol just makes it more difficult for application developers since, in addition to developing their application, they have to make their own client side functionality to fulfill our custom protocol. Furthermore, as I said before, OAuth 1 isn't bad. It provides for secure authentication and authorization of the client while protecting against replay attacks. Furthermore, I'd like to at least put some faith in the IETF, considering they are quite intelligent people, and not just toss out their protocol because it isn't perfect (quotes are intentional). If somebody wants to go ahead and make an extension for a custom authentication protocol, feel free to do so, but I still believe OAuth support should be our ultimate goal in terms of third-party application security. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Sun, Aug 26, 2012 at 2:38 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: 2012/8/26 Mark A. Hershberger m...@everybody.org: On 08/24/2012 01:33 PM, Nabil Maynard wrote: - Persona: Previously called BrowserID. It's come a LONG way in the past few months, and provides another fairly clean identity/authentication system. As a bonus, there is already a BrowserID extension for Bugzilla that Mozilla is using. Maybe integrating MW and BrowserID would solve the identity problem in Bugzilla. +[[Crore]]. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ 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] Wikimedians are rightfully wary
On Tue, 2012-08-21 at 15:29 -0700, Ryan Lane wrote: The really difficult thing here is that every time a bad idea is WONTFIX'd it makes a community member feel that they are being ignored. Do it too many times and you have a lot of community members that feel this way. My naïve hope is that you can make people feel slightly better by elaborating on decisions (which might take a minute of the developers' or triagers' time though), even on a rather generic level. As an example, when I close exotic enhancement requests as WONTFIX in projects I'm active in, I try to add a comment in the style of Thanks for sharing your idea. Unfortunately there are currently no plans to provide this in the native application, as your idea likely would only be useful to a smaller amount of users. However it could become an extension which could be provided by third party developers, but not by the core developers themselves. Hence closing as WONTFIX for the native application. My two cents, andre -- Andre Klapper (maemo.org bugmaster GNOME Bugsquad) http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code ideas thread
OpenID is an identity management system. It allows users to authenticate to one site using another site as their identity. A use case for this is, for example, using your Facebook account to log in to Wikipedia. This may be useful, as it would allow users to more easily register for Wikipedia. OAuth is a third-party authentication and authorization system that allows outside applications to do stuff on behalf of a user. The reason for this is because currently toolserver applications, etc. authenticate to Wikipedia using a plaintext username and password, which is extremely insecure for a number of reasons I will not elaborate on here. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Mon, Aug 27, 2012 at 9:52 AM, Gerard Meijssen gerard.meijs...@gmail.comwrote: Hoi, I have re-read the Wikipedia article about OpenID and OpenAuth. OpenAuth while nice in many ways is NOT the same as OpenID. User authentication is one easy and obvious requirement and I have already said too much about its need. It is NOT clear at all to me why OpenAuth should be regarded over OpenID. The use case for OpenID is obvious. In contrast the case for OpenAuth is not clear at all. What practical things will it solve? Thanks, GerardM On 27 August 2012 01:48, Tyler Romeo tylerro...@gmail.com wrote: If there are issues with the old standard, there is no significant advantage to use of the old spec (besides the case that it already exists, etc...), and you are intending to actually use the standard rather than just throw it out for people to use. Then that's really a valid situation to write a new standard in. But the problem is that it already exists is in fact a valid reason to use a protocol. There are numerous libraries out there (including a PHP extension) that allow people to use OAuth to authenticate with services. Making our own protocol just makes it more difficult for application developers since, in addition to developing their application, they have to make their own client side functionality to fulfill our custom protocol. Furthermore, as I said before, OAuth 1 isn't bad. It provides for secure authentication and authorization of the client while protecting against replay attacks. Furthermore, I'd like to at least put some faith in the IETF, considering they are quite intelligent people, and not just toss out their protocol because it isn't perfect (quotes are intentional). If somebody wants to go ahead and make an extension for a custom authentication protocol, feel free to do so, but I still believe OAuth support should be our ultimate goal in terms of third-party application security. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Sun, Aug 26, 2012 at 2:38 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: 2012/8/26 Mark A. Hershberger m...@everybody.org: On 08/24/2012 01:33 PM, Nabil Maynard wrote: - Persona: Previously called BrowserID. It's come a LONG way in the past few months, and provides another fairly clean identity/authentication system. As a bonus, there is already a BrowserID extension for Bugzilla that Mozilla is using. Maybe integrating MW and BrowserID would solve the identity problem in Bugzilla. +[[Crore]]. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ 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] Section numbering
What are you referring to here? The following definitely does NOT work: #REDIRECT [[Article title#Section name]] Timwi It does, kinda: you need to use an underscore in the Section_name, to reflect the fact that the ID in question has that underscore (and has done for the past couple of years). Harry -- Harry Burt (User:Jarry1250) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code ideas thread
I have re-read the Wikipedia article about OpenID and OpenAuth. OpenAuth while nice in many ways is NOT the same as OpenID. User authentication is one easy and obvious requirement and I have already said too much about its need. It is NOT clear at all to me why OpenAuth should be regarded over OpenID. The use case for OpenID is obvious. In contrast the case for OpenAuth is not clear at all. What practical things will it solve? OAuth will solve more practical problems than OpenID. Toolserver has had a need for this for years. Labs has the same need. Tools need to act on behalf of users. We can't let these tools request or store the credentials of our users, because that's insecure and gives the tool author access to the credentials. OAuth allows the tool to store a token, rather than the user's password. Of course, this goes past just tools. Beta Labs has this problem too. Bots could also benefit from this greatly. OpenID would be helpful, and really a combination of OpenID and OAuth would be the best thing, but the priority of implementing these definitely leans in favor of OAuth. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code ideas thread
Bots could also benefit from this greatly. Indeed. In fact, it could (possibly) even change the way bots are done altogether. Right now bots are put on separate bot accounts so that if they are compromised the main user account is still secure (and also so that the permissions are separated). OAuth could change this by allowing bots to operate directly under the user's account. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Mon, Aug 27, 2012 at 12:57 PM, Ryan Lane rlan...@gmail.com wrote: I have re-read the Wikipedia article about OpenID and OpenAuth. OpenAuth while nice in many ways is NOT the same as OpenID. User authentication is one easy and obvious requirement and I have already said too much about its need. It is NOT clear at all to me why OpenAuth should be regarded over OpenID. The use case for OpenID is obvious. In contrast the case for OpenAuth is not clear at all. What practical things will it solve? OAuth will solve more practical problems than OpenID. Toolserver has had a need for this for years. Labs has the same need. Tools need to act on behalf of users. We can't let these tools request or store the credentials of our users, because that's insecure and gives the tool author access to the credentials. OAuth allows the tool to store a token, rather than the user's password. Of course, this goes past just tools. Beta Labs has this problem too. Bots could also benefit from this greatly. OpenID would be helpful, and really a combination of OpenID and OAuth would be the best thing, but the priority of implementing these definitely leans in favor of OAuth. - Ryan ___ 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] Code ideas thread
On Mon, Aug 27, 2012 at 1:04 PM, Tyler Romeo tylerro...@gmail.com wrote: Bots could also benefit from this greatly. Indeed. In fact, it could (possibly) even change the way bots are done altogether. Right now bots are put on separate bot accounts so that if they are compromised the main user account is still secure (and also so that the permissions are separated). OAuth could change this by allowing bots to operate directly under the user's account. I don't think that's something we really want to do. Granting bot permissions hides someone from RecentChanges by default, which you wouldn't want as a normal user (well you might, but I don't think communities would). -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code ideas thread
On Mon, Aug 27, 2012 at 1:08 PM, Chad innocentkil...@gmail.com wrote: On Mon, Aug 27, 2012 at 1:04 PM, Tyler Romeo tylerro...@gmail.com wrote: Indeed. In fact, it could (possibly) even change the way bots are done altogether. Right now bots are put on separate bot accounts so that if they are compromised the main user account is still secure (and also so that the permissions are separated). OAuth could change this by allowing bots to operate directly under the user's account. I don't think that's something we really want to do. Granting bot permissions hides someone from RecentChanges by default, which you wouldn't want as a normal user (well you might, but I don't think communities would). Indeed. Communities also want separate bot accounts so it's easy to tell what contributions are automated and so bots can be blocked without blocking their operators. -Madman ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code ideas thread
I don't think that's something we really want to do. Granting bot permissions hides someone from RecentChanges by default, which you wouldn't want as a normal user (well you might, but I don't think communities would). Indeed. Communities also want separate bot accounts so it's easy to tell what contributions are automated and so bots can be blocked without blocking their operators. Well, with OAuth, it might be possible to mark actions as bot actions. It would also be possible to revoke just the OAuth key that allows the bot to operate, thus avoiding blocking the user. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Bugzilla workflow: keywords
Hello, Recently I noticed that keywords in bugzilla get updated more and more often, mostly with keywords like patch, patch-need-review, etc. I am wondering what to do in the following situations (like https://bugzilla.wikimedia.org/show_bug.cgi?id=39635 for example): - user A posts a patch - the bug gets patch, patch-need-review - user B posts a patch that is different and says he does not like patch of A - user B submits change to gerrit When need-review should be removed? What are replacements if any? What if I believe that core ideas behind the patch are wrong? What if I just think the implementation should be improved? What it it's more or less okay? I see only patch-reviewed in the keywords - which can be both negative and positive. Before I open a whole can of worms by asking a question how do I relate those keywords to the Gerrit workflow we have, maybe the current bugmeisters could explain how they use those keywords and how we can help? //Saper * ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code ideas thread
Well, with OAuth, it might be possible to mark actions as bot actions. It would also be possible to revoke just the OAuth key that allows the bot to operate, thus avoiding blocking the user. It would still be easier though for an end user to look at a username and see the bot. The user pages for Bots usually include quite a bit of information on them as well. Definitely think replacing Bot accounts with OAuth is the wrong way to go. I like the idea of using it for the toolserver though. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code ideas thread
It would still be easier though for an end user to look at a username and see the bot. The user pages for Bots usually include quite a bit of information on them as well. Definitely think replacing Bot accounts with OAuth is the wrong way to go. I like the idea of using it for the toolserver though. Yeah, likely best to continue to use bot accounts. It avoids the problem of bots being compromised in Labs from other users, though. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code ideas thread
I agree that bot accounts should still be separate, I just wanted to make the point that, theoretically, since the permissions are separated, you could do it that way if so desired. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Mon, Aug 27, 2012 at 2:11 PM, Ryan Lane rlan...@gmail.com wrote: It would still be easier though for an end user to look at a username and see the bot. The user pages for Bots usually include quite a bit of information on them as well. Definitely think replacing Bot accounts with OAuth is the wrong way to go. I like the idea of using it for the toolserver though. Yeah, likely best to continue to use bot accounts. It avoids the problem of bots being compromised in Labs from other users, though. - Ryan ___ 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] Using ORM patterns in core
Hi, It's recently come up in some of the Wikidata changes proposed to core to start using some ORM-like interfaces for accessing this data[0]. Since we don't use ORM-style access anywhere else in core, I figured it warranted some wider discussion before we begin introducing the pattern. Personally, I'm a big fan of consistency and since we don't use ORM anywhere else, I'm hesitant to begin using a new design pattern here (and I'm not entirely convinced why it's *needed*). On a more philosophical level, I personally don't like ORM because I think it needlessly abstracts data access in a more confusing way--but my personal feelings can be forgotten if people think this actually makes more sense. However, I may be in the minority here, and my fears are unfounded. I would love some feedback from everyone about whether ORM in the sites code (and more generally, in core) is a good idea. Thoughts? -Chad [0] https://gerrit.wikimedia.org/r/#/c/14295/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Appreciation thread
Thank you to Sumana for all your hard work, including GSoC administration and much, much more -- and obviously for starting this thread. This is exactly the kind of positive community spirit we need! Also thanks to the admin tools development team (Chris Steipp, Tim Starling, James Alexander, Guillaume Paumier) for all writing much needed new tools and making sure that they work and that communication between the team and the rest of the world happens. :-) Also thanks to Rob Lanphier for giving me the opportunity to act as the Product Manager for the admin tools development project, despite the fact that I lacked previous experience in the field. MZMcBride definitely deserves to be thanked for saying out loud a lot of difficult and potentially controversial things, on-wiki as well as on various different mailing lists. It's important that the community has critical members who dare to question the current state of things, as well as the future direction of things and the reasoning behind those. The above names are in no particular order and a lot of people who have worked on, are working on and plan to work on MediaWiki deserve a lot more praise than what they've gotten so far. So, thanks to everyone who ever has worked with MediaWiki in some way (not necessarily in software development) -- you folks make the Internet not suck. Thanks and regards, -- Jack Phoenix MediaWiki developer ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Using ORM patterns in core
From what I can tell, MediaWiki is trying more and more to reduce code re-use and move toward an easy MVC design, where the models are handled by ORM, the controllers are either Actions or SpecialPages, and the views are handled by Skin/Message/HTMLForm. And while ORMTable and FormAction, etc. are not used everywhere in the code, I believe this is a good direction to move in, primarily because it makes everything easier on developers. For example, I am making an extension for SSL authentication (because the current one is pretty dated), and I used FormSpecialPage with ORM to make the entire extension, and development was so easy it was beautiful. What would have otherwise been implemented using custom DatabaseBase calls and random functions is now made vastly simpler with standard interfaces. Also, I believe in MediaWiki's case ORM is the right way to go rather than the alternative raw SQL method. I say this because the primary reason people argue against ORM is because you have more freedom over the database and can focus on the data rather than the functionality. In MediaWiki, because of various compatibility reasons, there's only so much SQL we can use. For example, stored procedures are thrown out the window because Sqlite doesn't support them. Because of this limitation, the usual disadvantages of ORM do not apply. And while I'm sure an argument could still be made against ORM, I think the arguments in favor are a lot stronger. On that note, I'd just like to say that our ORM interfaces still have room for improvement. It would be good to have ORM handle instantiation of various internal types without bothering the end developer about it. For example, if ORMRow could automatically make User objects or Revision objects, etc from a row result where the indicated field is a reference to such an object. Also, there are weird quirks, such as the fact that ORMRow forces you to have an id field in your table, even if that doesn't necessarily apply to the model you are developing. Another quirk is the fact that fallbacks don't exist. The User object, for example, will try and load from the database or session, but if it doesn't find anything, it will default to an anonymous user. ORMTable, however, will return false when calling selectRow() rather than creating a default object, forcing the outer layers of code to load defaults manually. The easy way to fix this would be to change loadFields() so that rather than use the ID, just use any indexed fields in the object to load the fields. That way you can use newRow() to load defaults and then call loadFields() in an attempt to get from the database. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Mon, Aug 27, 2012 at 4:53 PM, Chad innocentkil...@gmail.com wrote: Hi, It's recently come up in some of the Wikidata changes proposed to core to start using some ORM-like interfaces for accessing this data[0]. Since we don't use ORM-style access anywhere else in core, I figured it warranted some wider discussion before we begin introducing the pattern. Personally, I'm a big fan of consistency and since we don't use ORM anywhere else, I'm hesitant to begin using a new design pattern here (and I'm not entirely convinced why it's *needed*). On a more philosophical level, I personally don't like ORM because I think it needlessly abstracts data access in a more confusing way--but my personal feelings can be forgotten if people think this actually makes more sense. However, I may be in the minority here, and my fears are unfounded. I would love some feedback from everyone about whether ORM in the sites code (and more generally, in core) is a good idea. Thoughts? -Chad [0] https://gerrit.wikimedia.org/r/#/c/14295/ ___ 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] Using ORM patterns in core
Hey, I'm a big fan of the pattern (or at least parts of it), which is the reason I spend quite some effort getting a generic interface into MediaWiki. This is the ORMTable class mentioned by Tyler. Documentation of this class, together with a rationale and some implementation notes can be found here: https://www.mediawiki.org/wiki/Help:ORMTable I ended up creating this because I found myself having to do the same scaffolding work again and again in different extensions, which was really tedious, and caused inconsistency all over the place. The end result is something very light compared to full object relational mappers while it still manages to take away most of the pains of doing such mappings. @Tyler can you place any suggestions you have on the talk page? Then we can discuss further without hijacking this tread :) Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Using ORM patterns in core
Le 27/08/12 22:53, Chad wrote: It's recently come up in some of the Wikidata changes proposed to core to start using some ORM-like interfaces for accessing this data[0]. Since we don't use ORM-style access anywhere else in core, I figured it warranted some wider discussion before we begin introducing the pattern. I originally thought we should reuse an existing ORM engine, Jeroen eventually convinced me his code would be easier to maintain for us. He wrote ton of online documentation on mediawiki.org. ORM would make our code hopefully a bit more concise and avoid us to duplicate logic in all our classes. We can do the migration as we usually do, by slowly refactoring our code over several releases. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Wikimania-l] Looking for Wikimania Materials on Wikipedia Infrastructure
On Mon, Aug 27, 2012 at 4:47 AM, Federico Leva (Nemo) nemow...@gmail.com wrote: http://wikitech.wikimedia.org/ Which is completely useless for any kind of high-level information, in particular [[Server roles]] which is dead and has no replacement and https://meta.wikimedia.org/wiki/Wikimedia_servers is outdated. http://wikitech.wikimedia.org/view/Category:Servers http://noc.wikimedia.org/dbtree/ http://ganglia.wikimedia.org/latest/ -- Choose a source -- Daniel Zahn dz...@wikimedia.org Operations Engineer ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Using ORM patterns in core
On 08/27/2012 04:53 PM, Chad wrote: Hi, It's recently come up in some of the Wikidata changes proposed to core to start using some ORM-like interfaces for accessing this data[0]. Since we don't use ORM-style access anywhere else in core, I figured it warranted some wider discussion before we begin introducing the pattern. Personally, I'm a big fan of consistency and since we don't use ORM anywhere else, I'm hesitant to begin using a new design pattern here (and I'm not entirely convinced why it's *needed*). On a more philosophical level, I personally don't like ORM because I think it needlessly abstracts data access in a more confusing way--but my personal feelings can be forgotten if people think this actually makes more sense. However, I may be in the minority here, and my fears are unfounded. I would love some feedback from everyone about whether ORM in the sites code (and more generally, in core) is a good idea. Thoughts? -Chad [0] https://gerrit.wikimedia.org/r/#/c/14295/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Could you give an example of how ORM looks like / would look in MW code? —Victor. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC Project Update (ConventionExtension)
Thanks the explain in-depth about why storing configuration in articles is a good thing. Keep up the good work. On Aug 26, 2012 2:11 PM, akshay chugh chughaksha...@gmail.com wrote: -1 On Sun, Aug 26, 2012 at 11:34 PM, John Du Hart compwhi...@gmail.com wrote: On Wed, Aug 22, 2012 at 8:40 AM, akshay chugh chughaksha...@gmail.com wrote: 6. Parser tags, Magic Words (Variables) and a parser function parser tags -- conference, page, account, registration,passport,author,submission,event,organizer and location This is a disgusting way to store data. -- John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Thanks, Akshay Chugh skype- chughakshay16 irc - chughakshay16(#mediawiki) [[User:Chughakshay16]] on mediawiki.org ___ 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] Using ORM patterns in core
There are some examples linked from the documentation here: https://www.mediawiki.org/wiki/Help:ORMTable Note that these are not clean examples as they contain unrelated code as well. And of course this is just one example of how you can go about implementing an ORM pattern, while this tread is about the pattern in general. Sent from my Android phone. On 28 Aug 2012 01:10, Victor Vasiliev vasi...@gmail.com wrote: On 08/27/2012 04:53 PM, Chad wrote: Hi, It's recently come up in some of the Wikidata changes proposed to core to start using some ORM-like interfaces for accessing this data[0]. Since we don't use ORM-style access anywhere else in core, I figured it warranted some wider discussion before we begin introducing the pattern. Personally, I'm a big fan of consistency and since we don't use ORM anywhere else, I'm hesitant to begin using a new design pattern here (and I'm not entirely convinced why it's *needed*). On a more philosophical level, I personally don't like ORM because I think it needlessly abstracts data access in a more confusing way--but my personal feelings can be forgotten if people think this actually makes more sense. However, I may be in the minority here, and my fears are unfounded. I would love some feedback from everyone about whether ORM in the sites code (and more generally, in core) is a good idea. Thoughts? -Chad [0] https://gerrit.wikimedia.org/**r/#/c/14295/https://gerrit.wikimedia.org/r/#/c/14295/ __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l Could you give an example of how ORM looks like / would look in MW code? —Victor. __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://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] GSoC Project Update (ConventionExtension)
On 12-08-27 04:10 PM, John Du Hart wrote: Thanks the explain in-depth about why storing configuration in articles is a good thing. Keep up the good work. See this is also unnecessary. Your original message might have been better stated as Hey, I love this idea, but is there a reason you decided to use articles instead of a database structure to store the data? Thanks in advance for the no doubt interesting answer. Instead, you antagonized Ashkay and didn't get an answer. And now here we are. Wasn't there a thread about conduct? Where did that end up? :) Ashkay, incidentally, I would also love to hear more about why you decided this, if you have a minute to answer! Thanks all, -- Mark Holmquist Contractor, Wikimedia Foundation mtrac...@member.fsf.org http://marktraceur.info ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] $( 'div' ) vs. $( 'div /') in coding conventions
I ran into our coding conventions for creating elements in JS:
https://www.mediawiki.org/wiki/Manual:Coding_conventions/JavaScript#Creating_elements
var $hello = $('div').text( 'Hello' );
// Not 'div/'
// Not 'div/div'
This looks like some really bad advice.
This dates back to an issue I ran into with jQuery 3 years ago:
https://forum.jquery.com/topic/ie-issue-with-append#1473700469433
https://forum.jquery.com/topic/ie-issue-with-append#1473700469445
Basically $( 'span class=foo' ) will break completely in IE7/IE8.
jQuery supports / on all elements (eg: $( 'span class=foo /' ))
intentionally. It does internal replacements to support it as a syntax for
specifying elements. But besides that special case jQuery wants anything
passed to it to be valid markup. It just leaves the parsing of it up to
the browser and all the quirks the browser may have.
jQuery does special case attribute-less $( 'div /' ) but this is a
performance enhancement. The fact that $( 'div' ) does not break in
IE7/IE8 is an unintentional side effect of jQuery's lazy support of
special cases like $( 'img' ) where the tag is self closing and the
browser will not require a /. This is the ONLY case where jQuery
intentionally supports leaving out a closing tag or a self-closing /.
When devs consider `$( 'div' )` ok they typically believe that `$( 'div
class=foo' )` should be ok to. It looks like a special cased way to
define an element, attributes et. all. However the former is a performance
enhancement side effect, and the later while it will look like it works in
Chrome and Firefox actually relies entirely on quirky error correction
behavior which differs between engines and breaks in IE7/IE8 engine.
The jQuery documentation also does not state that `$( 'div' )` for
non-selfclosing elements is supported:
http://api.jquery.com/jQuery/#jQuery2
Hence, I think we should change our coding conventions to always use `$(
'div /' )`.
((And for anyone that suggests that developers should know they should add
a / or /div to div when they add any attributes to it. I bring up the
fact that our code style requires {} blocks and does not allow implicit
`if ( foo ) foo();`. This is the same thing.))
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Evaluating Google Summer of Code
(Splitting this off from John's critique of ConventionExtension.) Hi. MediaWiki has participated in several (Google) Summer of Code iterations now (https://www.mediawiki.org/wiki/Summer_of_Code) and I'm wondering how this partnership program is evaluated. Whenever this program wraps up at the end of the (Northern Hemisphere's) summer, I always sense a worrying amount of frustration and annoyance from all parties involved. The projects are usually overly large and complex and from what I understand, nearly all of the projects from Google Summer of Code don't end up in production environments. If the projects are lucky, they end up in a MediaWiki extension; if they're unlucky, they rot away in a code repo branch somewhere or behind a configuration variable set to false by default. The end result being that: * the people who worked on these projects are frustrated and annoyed because they didn't get their code deployed [to Wikimedia wikis, a wide audience, or anyone at all in some cases]; * the people who mentored these students are frustrated and annoyed for similar reasons; and * the people (end-users) who wanted to see these projects successfully completed are frustrated and annoyed that these features still don't exist. So I'm left wondering how the cost v. benefit equation works out for this program. How do you evaluate the program and whether MediaWiki ought to remain a continued participant? And, of course, should MediaWiki decide not to participate in Google Summer of Code in 2013, are there other [better] ideas for getting people involved in MediaWiki development? MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] $( 'div' ) vs. $( 'div /') in coding conventions (and methods for building DOMs with jQuery)
Hence, I think we should change our coding conventions to always use `$( 'div /' )`. +1 for valid XHTML. Considering that bytes are cheap and validity is good, this seems like a good idea. I also tried to get an answer about the better between $( 'div class=a-class /' ) and $( 'div /' ).addClass( 'a-class' ), but apparently there's little difference. At least when creating dynamic interfaces, I'd like to have some guidance and consistency if anyone is interested in chatting about it. My preference is the latter, because it avoids extensive HTML inside of JavaScript. But I'd be interested to hear other thoughts. -- Mark Holmquist Contractor, Wikimedia Foundation mtrac...@member.fsf.org http://marktraceur.info ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] $( 'div' ) vs. $( 'div /') in coding conventions (and methods for building DOMs with jQuery)
$( 'div' ) is the way to go. - Trevor On Mon, Aug 27, 2012 at 4:37 PM, Mark Holmquist mtrac...@member.fsf.orgwrote: Hence, I think we should change our coding conventions to always use `$( 'div /' )`. +1 for valid XHTML. Considering that bytes are cheap and validity is good, this seems like a good idea. I also tried to get an answer about the better between $( 'div class=a-class /' ) and $( 'div /' ).addClass( 'a-class' ), but apparently there's little difference. At least when creating dynamic interfaces, I'd like to have some guidance and consistency if anyone is interested in chatting about it. My preference is the latter, because it avoids extensive HTML inside of JavaScript. But I'd be interested to hear other thoughts. -- Mark Holmquist Contractor, Wikimedia Foundation mtrac...@member.fsf.org http://marktraceur.info __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://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] Evaluating Google Summer of Code
MZMcBride wrote: MediaWiki has participated in several (Google) Summer of Code iterations now (https://www.mediawiki.org/wiki/Summer_of_Code) and I'm wondering how this partnership program is evaluated. After I posted this, Sumana pointed out that MaxSem has done a great evaluation here: https://www.mediawiki.org/wiki/User:MaxSem/GSoC_analysis. There's also a good overview of past projects at https://www.mediawiki.org/wiki/Summer_of_Code_Past_Projects. And, of course, should MediaWiki decide not to participate in Google Summer of Code in 2013, are there other [better] ideas for getting people involved in MediaWiki development? Perhaps a better model: https://www.mediawiki.org/wiki/UCOSP_Spring_2012? MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] $( 'div' ) vs. $( 'div /') in coding conventions (and methods for building DOMs with jQuery)
On Monday, August 27, 2012 at 4:40 PM, Trevor Parscal wrote: $( 'div' ) is the way to go. Yeah. Mark Pilgrim's overview of the sordid history of XHTML is useful background: http://diveintohtml5.info/past.html -- Ori Livneh o...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Evaluating Google Summer of Code
Most software projects fail (for some definition of fail). Even for highly skilled and highly experienced companies and shops, most software projects fail. I'm not going to look up the Gartner and Forrester and Chaos reports this late on a Monday night, but google away. GSoC is an investment that is not intended to have a short-term payoff. The fact that ANY GSoC code makes to production is fantastic. GSoC is an investment in the long term. It is intended to provide real concrete experience to promising students in real environments, including all the frustrations and annoyances that everyone on a software team experiences in the real world all the time. Schools simply do not provide that experience. Some fraction of those participants will take those experiences into the future of software development, to make real improvements, both to code and to process. Furthermore, considering GSoC solely in terms of benefit to Mediawiki/Wikipedia is short-sighted. Take a look at the organizations participating: http://www.google-melange.com/gsoc/projects/list/google/gsoc2012 . What would your opinion be if WMF were not on that list? On Mon, Aug 27, 2012 at 5:32 PM, MZMcBride z...@mzmcbride.com wrote: (Splitting this off from John's critique of ConventionExtension.) Hi. MediaWiki has participated in several (Google) Summer of Code iterations now (https://www.mediawiki.org/wiki/Summer_of_Code) and I'm wondering how this partnership program is evaluated. Whenever this program wraps up at the end of the (Northern Hemisphere's) summer, I always sense a worrying amount of frustration and annoyance from all parties involved. The projects are usually overly large and complex and from what I understand, nearly all of the projects from Google Summer of Code don't end up in production environments. If the projects are lucky, they end up in a MediaWiki extension; if they're unlucky, they rot away in a code repo branch somewhere or behind a configuration variable set to false by default. The end result being that: * the people who worked on these projects are frustrated and annoyed because they didn't get their code deployed [to Wikimedia wikis, a wide audience, or anyone at all in some cases]; * the people who mentored these students are frustrated and annoyed for similar reasons; and * the people (end-users) who wanted to see these projects successfully completed are frustrated and annoyed that these features still don't exist. So I'm left wondering how the cost v. benefit equation works out for this program. How do you evaluate the program and whether MediaWiki ought to remain a continued participant? And, of course, should MediaWiki decide not to participate in Google Summer of Code in 2013, are there other [better] ideas for getting people involved in MediaWiki development? 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] Nightly tarballs?
Daniel Friesen wrote: I wonder if we should turn this into a special page on MW.org. I'm not sure about a Special page, but I created a very short page on MediaWiki.org: https://www.mediawiki.org/wiki/Nightlies. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla workflow: keywords
On 08/27/2012 01:59 PM, Marcin Cieslak wrote: - user A posts a patch - the bug gets patch, patch-need-review - user B posts a patch that is different and says he does not like patch of A - user B submits change to gerrit When need-review should be removed? User B should remove need-review. Code in gerrit has its own review process and it shouldn't be necessary to keep the keywords in Bugzilla up to date. User B should make sure that the bug has a comment referring to his gerrit submission. What if I believe that core ideas behind the patch are wrong? Leave a comment with your thoughts. You could also remove the need-review keyword and, optionally, mark the patch as obsolete. Marking it as obsolete is a pretty strong statement, though. What if I just think the implementation should be improved? Remove the need-review and leave a comment with your suggestions. Directing the submitter to gerrit for future submissions is a good idea, too, but that might add another step that that makes future submissions improbable. What it it's more or less okay? Remove the need-review keyword and direct the submitter to gerrit or submit it to gerrit on their behalf. Make sure you refer to the bug number in first line of the commit message (see https://gerrit.wikimedia.org/r/#/c/13855/ for an example). Other people will then have a chance to review it and it may be merged. If you don't have a gerrit account, apply for one or find someone who does to apply the patch. Before I open a whole can of worms by asking a question how do I relate those keywords to the Gerrit workflow we have Oops! I guess I opened the can and not you! Mark. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] MediaWiki Foundation (was Re: CentralAuth API access)
On 08/27/2012 12:04 AM, Daniel Friesen wrote: We need some sort of think tank (well some thing with a better name) non-profit that people donate to. To have it hire people to crank out MediaWiki features outside of just the stuff WMF wants. I'd love to spend 80% of my time cranking out fringe MediaWiki features where what the community wants and what my specialties are intersect. To borrow from the great Amir: +[[Crore]] -- http://hexmode.com/ Human evil is not a problem. It is a mystery. It cannot be solved. -- When Atheism Becomes a Religion, Chris Hedges ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] $( 'div' ) vs. $( 'div /') in coding conventions (and methods for building DOMs with jQuery)
On Mon, 27 Aug 2012 16:57:52 -0700, Ori Livneh o...@wikimedia.org wrote: On Monday, August 27, 2012 at 4:40 PM, Trevor Parscal wrote: $( 'div' ) is the way to go. Yeah. Mark Pilgrim's overview of the sordid history of XHTML is useful background: http://diveintohtml5.info/past.html -- Ori Livneh o...@wikimedia.org Can we not just jump into making this a HTML5 vs. XHTML topic? Because if you want to make this HTML5 vs. XHTML 'div' is NOT valid HTML5. If you don't like the XHTML-ish shortcut that jQuery provides, then our coding conventions should be to use `$( 'div/div' );`. Either way $( 'div' ) is NOT something officially supported by jQuery and makes it easy for developers to accidentally write broken code. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki Foundation (was Re: CentralAuth API access)
Mark A. Hershberger wrote: On 08/27/2012 12:04 AM, Daniel Friesen wrote: We need some sort of think tank (well some thing with a better name) non-profit that people donate to. To have it hire people to crank out MediaWiki features outside of just the stuff WMF wants. I'd love to spend 80% of my time cranking out fringe MediaWiki features where what the community wants and what my specialties are intersect. To borrow from the great Amir: +[[Crore]] Yes, what the world needs is another horribly confusingly named foundation. After we establish the MediaWiki Foundation, we can start work on the MikiWedia Foundation and the WediaMiki Foundation. ;-) In all seriousness, this has come up a few times before (on wikitech-l and mediawiki-l, I believe) and it deserves thoughtful consideration. I think the first step is to write a draft somewhere on MediaWiki.org detailing: * what you view as the current deficiencies of the Wikimedia Foundation owning/operating MediaWiki; and * what possible problems might be solved (or created!) by the establishment of a MediaWiki Foundation. A discussion of some analogous organizations (such as Mozilla) might be good as case studies to include in such a page as well. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Evaluating Google Summer of Code
Chris McMahon wrote: Most software projects fail (for some definition of fail). Even for highly skilled and highly experienced companies and shops, most software projects fail. I'm not going to look up the Gartner and Forrester and Chaos reports this late on a Monday night, but google away. GSoC is an investment that is not intended to have a short-term payoff. The fact that ANY GSoC code makes to production is fantastic. GSoC is an investment in the long term. It is intended to provide real concrete experience to promising students in real environments, including all the frustrations and annoyances that everyone on a software team experiences in the real world all the time. Schools simply do not provide that experience. Some fraction of those participants will take those experiences into the future of software development, to make real improvements, both to code and to process. Thank you for this. You make some good points. So I guess it might just be a matter of better managing expectations of all parties involved? The disappointment factor is serious and dangerous, in my opinion. It can be mitigated by setting appropriate expectations for the students involved, the mentors involved, and the end-users involved, many of whom desperately want to see some of these features live. Furthermore, considering GSoC solely in terms of benefit to Mediawiki/Wikipedia is short-sighted. Take a look at the organizations participating: http://www.google-melange.com/gsoc/projects/list/google/gsoc2012 . What would your opinion be if WMF were not on that list? Personally, I don't care very much about being a participant for the sake of being a participant (and I imagine many others feel similarly). I think for a lot of people who watch these Summer of Code projects, it _is_ about benefit to MediaWiki/Wikimedia, particularly as getting involved in these projects can detract from already painfully finite mentoring and reviewing resources. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] i18n attention needed: Performer's username is shown twice in page move entries on the history
https://bugzilla.wikimedia.org/34961 Niklas and Siebrand have already weighed in on this bug back in Mar, and, indeed, it went away for a while. Niklas said We could make it the same as how it is in Special:Logs, removing the first Username and not the username that is part of the message. It seems like that would be better than the current situation. Is there a reason that isn't done? It seems like this is turning into one of those little paper-cut bugs[1] that annoy long-time Wikipedia editors. Could someone update the bug? [1] https://wiki.ubuntu.com/PaperCut -- http://hexmode.com/ Human evil is not a problem. It is a mystery. It cannot be solved. -- When Atheism Becomes a Religion, Chris Hedges ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] $( 'div' ) vs. $( 'div /') in coding conventions (and methods for building DOMs with jQuery)
On Monday, August 27, 2012 at 5:50 PM, Daniel Friesen wrote: If you don't like the XHTML-ish shortcut that jQuery provides, then our coding conventions should be to use `$( 'div/div' );`. Either way $( 'div' ) is NOT something officially supported by jQuery and makes it easy for developers to accidentally write broken code. By Jove, you're right. The jQuery docs confirm. Retracted! -- Ori Livneh o...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] $( 'div' ) vs. $( 'div /') in coding conventions
On 28/08/12 09:26, Daniel Friesen wrote:
jQuery does special case attribute-less $( 'div /' ) but this is a
performance enhancement. The fact that $( 'div' ) does not break in
IE7/IE8 is an unintentional side effect of jQuery's lazy support of
special cases like $( 'img' ) where the tag is self closing and the
browser will not require a /.
The performance special case supports both div and div/:
rsingleTag = /^(\w+)\s*\/?$/,
...
ret = rsingleTag.exec( selector );
if ( ret ) {
selector = [ doc.createElement( ret[1] ) ];
I think that we should use that special case, and then extend the
resulting elements with attr() rather than hitting the innerHTML case.
When you specify longer HTML fragments as strings, they tend to get
polluted with user input, leading to XSS.
But it's important to establish conventions which lead the developer
down a path where they're less likely to run into trouble, even if
they do try to take a few shortcuts. So let's add the slash.
(There is one important case where it's good to use innerHTML: when
there are thousands of elements to create in a batch.)
-- Tim Starling
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] MediaWiki tarballs
A while back[1], I started a discussion about moving tarball maintenance out of the Foundation. I have spent a little time since then talking to Sam Reed about what is actually involved, but we're coming up on the 6 month mark since the last release and I need to start doing something if I'm actually going to follow through. I've started https://www.mediawiki.org/wiki/Requests_for_comment/Tarball_maintenance to help drive this. I would really like to get the next version of the tarball out the door by November (6 months from the last release in May). [1] http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/61638 -- http://hexmode.com/ Human evil is not a problem. It is a mystery. It cannot be solved. -- When Atheism Becomes a Religion, Chris Hedges ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla workflow: keywords
See also https://www.mediawiki.org/wiki/Thread:Talk:Git/Workflow/Bugzilla Best regards, Helder ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Nested database transactions
I'd have to see what you are doing to see if rollback is really needed. -- View this message in context: http://wikimedia.7.n6.nabble.com/Nested-database-transactions-tp4983700p4984075.html Sent from the Wikipedia Developers mailing list archive at Nabble.com. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Flagged Reviews default by quality levels
That text should be removed from the help page. Only the current or the latest reviewed version can be the default. You cannot have pages use the latest quality version as the default version. This would create a very confusing interface that takes a mouth full to explain. Also, it's hard enough to keep checked versions up to date, even hard for quality ones. You don't won't to end up with people having their edits take weeks (sometimes months) to show to readers because they haven't been highly proofed yet. -- View this message in context: http://wikimedia.7.n6.nabble.com/Flagged-Reviews-default-by-quality-levels-tp4983993p4984076.html Sent from the Wikipedia Developers mailing list archive at Nabble.com. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] $( 'div' ) vs. $( 'div /') in coding conventions (and methods for building DOMs with jQuery)
On Mon, Aug 27, 2012 at 4:37 PM, Mark Holmquist mtrac...@member.fsf.org wrote: I also tried to get an answer about the better between $( 'div class=a-class /' ) and $( 'div /' ).addClass( 'a-class' ), but apparently there's little difference. At least when creating dynamic interfaces, I'd like to have some guidance and consistency if anyone is interested in chatting about it. I'm going to try and put some guidelines for secure javascript code together soon, but it's a much better habit to use .addClass( 'a-class' ) and the other functions to add attributes. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Using ORM patterns in core
I was just looking through those classes again. I think ORMRow is generally OK, since it's mostly a simple CRUD wrapper to deal with some of the busy-work of making data access objects. I don't really get the summary (updateSummaries/inSummaryMode) stuff though. I guess the callers/subclasses do most of the summary work there or something. I'm not really fond of ORMTable/ORMResult. A lot of functions are just wrappers around DB calls that don't really abstract much. Also, singleton() has one table instance per table, making foreign wiki access trickier than with the regular LBFactory/DatabaseBase classes. This kind of stuff makes me hesitant to use the classes (since ORMRow depends on the table class). I guess what I'd really like out of those table classes is the support for base API and Pager classes and the minimum needed for ORMRow (fields/types), with foreign wiki support. I like the idea of getAPIParams() and an API base class for making quick API classes. The idea of some base classes for CRUD and API/Pager table listings is fine. It can obviously avoid inconsistency among the DAOs. If these classes are called ORM*, I guess that's OK too, as longs as they don't scope creep into a complex system that coupled to everything and hard to change. -- View this message in context: http://wikimedia.7.n6.nabble.com/Using-ORM-patterns-in-core-tp4984036p4984074.html Sent from the Wikipedia Developers mailing list archive at Nabble.com. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
