[Wikitech-l] Bugzilla for Extensions
Hey, I was wondering what the qualifications are for getting a Bugzilla section for a MediaWiki extension, and how it can be set up? (It's difficult having to memorize or write down on notepads what things need to be fixed, and I don't want to have to set up my own Bugzilla instance.) *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla for Extensions
File a bug under Wikimedia/Bugzilla for it. Only pre-req is that you are heavily involved in the dev of it (eg: maintainer) and you want it. On Wed, May 8, 2013 at 5:01 PM, Tyler Romeo tylerro...@gmail.com wrote: Hey, I was wondering what the qualifications are for getting a Bugzilla section for a MediaWiki extension, and how it can be set up? (It's difficult having to memorize or write down on notepads what things need to be fixed, and I don't want to have to set up my own Bugzilla instance.) *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ 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] Bugzilla for Extensions
On Wed, May 8, 2013 at 3:09 AM, K. Peachey p858sn...@gmail.com wrote: File a bug under Wikimedia/Bugzilla for it. Only pre-req is that you are heavily involved in the dev of it (eg: maintainer) and you want it. OK, thanks! *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla for Extensions
Link me to bug and I will create it right now! On Wed, May 8, 2013 at 9:27 AM, Tyler Romeo tylerro...@gmail.com wrote: On Wed, May 8, 2013 at 3:09 AM, K. Peachey p858sn...@gmail.com wrote: File a bug under Wikimedia/Bugzilla for it. Only pre-req is that you are heavily involved in the dev of it (eg: maintainer) and you want it. OK, thanks! *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ 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] Bugzilla for Extensions
On Wed, May 8, 2013 at 4:44 AM, Petr Bena benap...@gmail.com wrote: Link me to bug and I will create it right now! Here's the link: https://bugzilla.wikimedia.org/show_bug.cgi?id=48252 Much appreciated. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla for Extensions
Hi, On Wed, 2013-05-08 at 03:01 -0400, Tyler Romeo wrote: I was wondering what the qualifications are for getting a Bugzilla section for a MediaWiki extension Basically none, though I highly appreciate if maintainers *themselves* ask for the creation of a Bugzilla component for their extension (so I know that s/he is aware of it and plans to take a look at reports). , and how it can be set up? See https://www.mediawiki.org/wiki/Bug_management/Project_Maintainers (where I also try to document anything else you never wanted to know). Cheers, andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] [RFC] Update our code to use RDFa 1.1 instead of RDFa 1.0
I was going through our code contemplating dropping XHTML 1.1 support and ran into the RDFa support stuff and realized how out of date and limited it is. I've put together an RFC for replacing our code that appears to be based on the RDFa 1.0 from 2008 with RDFa 1.1 and expanding support for RDFa. https://www.mediawiki.org/wiki/Requests_for_comment/Update_our_code_to_use_RDFa_1.1_instead_of_RDFa_1.0 -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] OPW Browser Test Automation - Proposal Summary
On Tue, Apr 30, 2013 at 2:25 PM, Indrani Sen i@se12.qmul.ac.uk wrote: I am summarizing here my proposal idea for OPW MediaWiki projects. I have noticed that you did not provide the link to your proposal[1]. In addition to the comments that I have posted here, I have left a few comments on the talk page[2]. Željko -- 1: http://www.mediawiki.org/wiki/User:Indranisen 2: http://www.mediawiki.org/wiki/User_talk:Indranisen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] OPW browser test automation for Visual Editor
On Tue, Apr 30, 2013 at 5:45 PM, Rachel Thomas rachelthomas...@yahoo.comwrote: Here is my proposal for OPW: https://www.mediawiki.org/wiki/User:Rachel99/OPW_proposal Hi Rachel, I have left a couple of comments on the talk page[1]. Željko -- 1: https://www.mediawiki.org/wiki/User_talk:Rachel99/OPW_proposal ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] APIStrat conference, San Francisco, October 23, 24, 25
On 05/07/2013 05:33 PM, Juliusz Gonera wrote: Seems interesting. Is there anyone who'd be interested in giving a talk or participating in a panel there? Given that it's very close to me, and that I have quite a bit of experience with the API, this is something I could do. I actually had an API talk planned for WM 2012 that I never got a chance to present, I could dust it off and see how well it fits in their scope. Do you know when their CFP opens? -- Marc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] How to get permission to view deleted revision information via API?
Hi all,
I don't know whether this is the correct mailing list to ask such question but
it is the one I am reading regularly…
Does anyone know about the adequate procedure to get permission to request
deleted revision information from the MediaWiki API?
I just stumbled over this problem...
{
servedby: mw1140,
error: {
code: drpermissiondenied,
info: You don't have permission to view deleted revision information
}
}
Many thanks.
Best, Claudia
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to get permission to view deleted revision information via API?
On Wed, May 8, 2013 at 9:35 AM, Claudia Müller-Birn
c...@inf.fu-berlin.de wrote:
Hi all,
I don't know whether this is the correct mailing list to ask such question
but it is the one I am reading regularly…
Does anyone know about the adequate procedure to get permission to request
deleted revision information from the MediaWiki API?
I just stumbled over this problem...
{
servedby: mw1140,
error: {
code: drpermissiondenied,
info: You don't have permission to view deleted revision
information
}
}
For a personal wiki, this means you need the 'deletedhistory' and 'deletedtext'
permissions (which is by default assigned to the admin group).
On WMF wikis, this requires being an administrator (although I think there's
some exception for researchers handed out via Meta).
-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC / OPW mentors README
On 05/03/2013 04:22 PM, Matthew Flaschen wrote: On 04/27/2013 07:58 PM, Quim Gil wrote: SELECTING CANDIDATES After the deadline we will meet to prioritize GSoC and OPW candidates. When is this meeting? It seems that we won't need a meeting to discuss candidates. So far the discussions of the proposals in Google Melange are enough. What we will do is a hangout for mentors next week to discuss anything except candidates: questions about the program and your work, expectations, tips tricks... And some questions that came from a student: 1. May I know how selection of the most suitable candidate for each GSoC project will be like? It is described at https://www.mediawiki.org/wiki/Mentorship_programs/Selection_process but if anybody has more specific questions just ask. 2. Would it depend on technical knowledge and research? It's a combination of many factors. There is a short term question (do we trust this candidate can complete this project) and a mid term question (do we believe this candidate will stick around, contributing after the internship?). There is no scientific way to predict the answers. Own initiative, social/communication skills or personal context may play a role as important as the declared technical knowledge (which in many cases we can't even evaluate properly because on many cases there is not much code and history to look at - which is relatively expected in these types of internship programs. 3. Will there be more than one successful candidate for one specific project or is it strictly the best (only one) candidate for the specific project? GSoC / OPW allow this, but we are aiming to have only one candidate per project. The main motivation is to give more chances to more projects. We try to define project ideas that can be accomplished by one person during the internship. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] APIStrat conference, San Francisco, October 23, 24, 25
Le mercredi 08 mai 2013 à 09:09 -0400, Marc A. Pelletier a écrit : On 05/07/2013 05:33 PM, Juliusz Gonera wrote: Seems interesting. Is there anyone who'd be interested in giving a talk or participating in a panel there? Given that it's very close to me, and that I have quite a bit of experience with the API, this is something I could do. I actually had an API talk planned for WM 2012 that I never got a chance to present, I could dust it off and see how well it fits in their scope. Do you know when their CFP opens? -- Marc Will the event be recorded and broadcasted? This may be an interesting document to add on meta where efforts are done to make developers involvement more attractive. ___ 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] GLAM Wiki Toolset code review
On 04/17/2013 02:51 AM, Mathieu Stumpf wrote: Le 2013-04-16 18:25, Geer Oskam a écrit : Hi all, the GLAM Wiki Toolset-code is ready for its initial review. It can be found at: https://gerrit.wikimedia.org/r/#/c/59405/ Please help us by taking a look at it. Cheers, Geer Oskam Europeana For those like me which are wondering what is it?, here is an informative copy of the README: GWToolset = A MediWiki extension that allows GLAMs the ability to mass upload content based on an xml file conta ining respective metadata about the content. The intent is to allow for a variety of xml schemas; se e the [extension page]( http://www.mediawiki.org/wiki/Extension:GWToolset ) for further information. (All apologies if this was obvious to all other readers of this list) Thanks to Siebrand, Reedy, and Peachey88 for their reviews. There's a new patchset up as of today in case anyone wants to take a fresh look. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Git for idiots
Hi, Long time ago when I started learning with git I decided to create a simple guide (basically I was just taking some notes of what is needed). I never thought that it could be useful to anyone so I never announced it anywhere. However I got some feedback to it, so I decided to inform you too. The basic idea is to create a TOTALLY SIMPLE guide that git illiterates like me can understand and thanks to which they would find out how to do stuff in wikimedia git / gerrit. Link is here: www.mediawiki.org/wiki/User:Petrb/Git_for_idiots It doesn't contain so much and there are some mistakes / feel free to fix them. Since wikimedia switched to gerrit from svn I have yet met a tons of people who had problems adapting to it, so this could eventually help some. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Git for idiots
On Wed, May 8, 2013 at 12:34 PM, Petr Bena benap...@gmail.com wrote: Hi, Long time ago when I started learning with git I decided to create a simple guide (basically I was just taking some notes of what is needed). I never thought that it could be useful to anyone so I never announced it anywhere. However I got some feedback to it, so I decided to inform you too. The basic idea is to create a TOTALLY SIMPLE guide that git illiterates like me can understand and thanks to which they would find out how to do stuff in wikimedia git / gerrit. Link is here: www.mediawiki.org/wiki/User:Petrb/Git_for_idiots It doesn't contain so much and there are some mistakes / feel free to fix them. Since wikimedia switched to gerrit from svn I have yet met a tons of people who had problems adapting to it, so this could eventually help some. We've got [[Git/Workflow]], [[Git/Tutorial]] and [[Git/Getting started]] (in decreasing order of complexity/depth), so I would be hesitant to add yet another howto page. Considering this is supposed to be quick-and-easy docs, I'd suggest folding any unique content into the getting started doc. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Git for idiots
I was using these tutorials in past, and they were pretty complicated for me to understand git. I don't say it should be considered some official documentation, rather something what desperate people could use. Git/Workflow and such are written by people who already understand git - they don't see what seems complicated to newbies or what is really hard and makes git evil to new users. I think some far, far simpler guide like git for dummies or whatever similar, could be useful for many new contributors who have no idea about git. On Wed, May 8, 2013 at 6:37 PM, Chad innocentkil...@gmail.com wrote: On Wed, May 8, 2013 at 12:34 PM, Petr Bena benap...@gmail.com wrote: Hi, Long time ago when I started learning with git I decided to create a simple guide (basically I was just taking some notes of what is needed). I never thought that it could be useful to anyone so I never announced it anywhere. However I got some feedback to it, so I decided to inform you too. The basic idea is to create a TOTALLY SIMPLE guide that git illiterates like me can understand and thanks to which they would find out how to do stuff in wikimedia git / gerrit. Link is here: www.mediawiki.org/wiki/User:Petrb/Git_for_idiots It doesn't contain so much and there are some mistakes / feel free to fix them. Since wikimedia switched to gerrit from svn I have yet met a tons of people who had problems adapting to it, so this could eventually help some. We've got [[Git/Workflow]], [[Git/Tutorial]] and [[Git/Getting started]] (in decreasing order of complexity/depth), so I would be hesitant to add yet another howto page. Considering this is supposed to be quick-and-easy docs, I'd suggest folding any unique content into the getting started doc. -Chad ___ 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] Git for idiots
Well, that was the point of [[Git/Getting started]] because the Workflow document sucks. -Chad On Wed, May 8, 2013 at 12:41 PM, Petr Bena benap...@gmail.com wrote: I was using these tutorials in past, and they were pretty complicated for me to understand git. I don't say it should be considered some official documentation, rather something what desperate people could use. Git/Workflow and such are written by people who already understand git - they don't see what seems complicated to newbies or what is really hard and makes git evil to new users. I think some far, far simpler guide like git for dummies or whatever similar, could be useful for many new contributors who have no idea about git. On Wed, May 8, 2013 at 6:37 PM, Chad innocentkil...@gmail.com wrote: On Wed, May 8, 2013 at 12:34 PM, Petr Bena benap...@gmail.com wrote: Hi, Long time ago when I started learning with git I decided to create a simple guide (basically I was just taking some notes of what is needed). I never thought that it could be useful to anyone so I never announced it anywhere. However I got some feedback to it, so I decided to inform you too. The basic idea is to create a TOTALLY SIMPLE guide that git illiterates like me can understand and thanks to which they would find out how to do stuff in wikimedia git / gerrit. Link is here: www.mediawiki.org/wiki/User:Petrb/Git_for_idiots It doesn't contain so much and there are some mistakes / feel free to fix them. Since wikimedia switched to gerrit from svn I have yet met a tons of people who had problems adapting to it, so this could eventually help some. We've got [[Git/Workflow]], [[Git/Tutorial]] and [[Git/Getting started]] (in decreasing order of complexity/depth), so I would be hesitant to add yet another howto page. Considering this is supposed to be quick-and-easy docs, I'd suggest folding any unique content into the getting started doc. -Chad ___ 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] Git for idiots
I guess the viewpoint and perspective from the more experienced users may be different. The veterans may start to take some knowledge for granted, as a given knowledge that they may thing people would already know. For example, the underlying concept of git commit is something that I now take for granted. But it's something that I have to really visit and talk about when I'm teaching a friend to use git. Perhaps we need contributions from people who have only just learned how to properly use git, rather than only having veterans write the guide up. People who still have the learning experience fresh in their minds. And perhaps we also need contributions from people who routinely teach their friends about git. On Thu, May 9, 2013 at 12:54 AM, Chad innocentkil...@gmail.com wrote: Well, that was the point of [[Git/Getting started]] because the Workflow document sucks. -Chad On Wed, May 8, 2013 at 12:41 PM, Petr Bena benap...@gmail.com wrote: I was using these tutorials in past, and they were pretty complicated for me to understand git. I don't say it should be considered some official documentation, rather something what desperate people could use. Git/Workflow and such are written by people who already understand git - they don't see what seems complicated to newbies or what is really hard and makes git evil to new users. I think some far, far simpler guide like git for dummies or whatever similar, could be useful for many new contributors who have no idea about git. On Wed, May 8, 2013 at 6:37 PM, Chad innocentkil...@gmail.com wrote: On Wed, May 8, 2013 at 12:34 PM, Petr Bena benap...@gmail.com wrote: Hi, Long time ago when I started learning with git I decided to create a simple guide (basically I was just taking some notes of what is needed). I never thought that it could be useful to anyone so I never announced it anywhere. However I got some feedback to it, so I decided to inform you too. The basic idea is to create a TOTALLY SIMPLE guide that git illiterates like me can understand and thanks to which they would find out how to do stuff in wikimedia git / gerrit. Link is here: www.mediawiki.org/wiki/User:Petrb/Git_for_idiots It doesn't contain so much and there are some mistakes / feel free to fix them. Since wikimedia switched to gerrit from svn I have yet met a tons of people who had problems adapting to it, so this could eventually help some. We've got [[Git/Workflow]], [[Git/Tutorial]] and [[Git/Getting started]] (in decreasing order of complexity/depth), so I would be hesitant to add yet another howto page. Considering this is supposed to be quick-and-easy docs, I'd suggest folding any unique content into the getting started doc. -Chad ___ 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] RFC: New approach to release notes
On May 7, 2013, at 8:56 PM, Bartosz Dziewoński matma@gmail.com wrote: On Tue, 07 May 2013 20:51:07 +0200, Krinkle krinklem...@gmail.com wrote: It is the duty of repository co-owners to make wise decisions beyond just code quality. About what changes go in what release (if at all), whether the introduced features are in the best interest of the users and that we can maintain them and are willing to support them. And to be aware of whether a change is breaking or not, and if so if whether the change should still go in the current release or a the next (e.g. don't remove/break without deprecation first, if possible). So in other words, this puts more burden on reviewers, making it harder to get changes merged, especially for new users? Because that's what this sounds like. Changes are already rotting in gerrit for a year (see the recent watchlist thread), and this certainly will not help. The current process for release notes is fine; we just need someone to write a custom merge driver for JGit to avoid the merge conflicts. This is a technical issue, not a policy one. How does this make anything harder for new users? If anything, it makes it easier by not having to worry about which file to edit, what to put in it etc. As for more burden on reviewers, I disagree. It might inspire them to give more care to proper commit subjects (and edit them liberally as needed) because if you leave it in bad shape, it needs to be fixed later in the notes. And here again, it simplifies things by maintaining release notes centrally and away from inside the tight development loop. Some of the same people will be doing both, but in the right frame of mind, instead of when you don't want to. The current process for release notes is not fine. It hasn't been fine for at least 2 or 3 releases. It is missing a lot, and what's there is (imho) poor quality (my own notes included). Improving that doesn't require moving the process, but I think this is an opportunity to fix a mess the right way at once. -- Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Git for idiots
On 05/08/2013 09:41 AM, Petr Bena wrote: I was using these tutorials in past, and they were pretty complicated for me to understand git. Have you checked recently these pages? http://www.mediawiki.org/wiki/Gerrit/Getting_started http://www.mediawiki.org/wiki/Gerrit/Tutorial I'm a git-idiot and they were useful even before we went through the Git/Gerrit a couple of months ago. You are encouraged to improve these pages. Thank you! As Chad says we are not going to push a 3rd reference document. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Git for idiots
On Wed, May 8, 2013 at 8:34 PM, Petr Bena benap...@gmail.com wrote: Hi, Long time ago when I started learning with git I decided to create a simple guide (basically I was just taking some notes of what is needed). I never thought that it could be useful to anyone so I never announced it anywhere. However I got some feedback to it, so I decided to inform you too. The basic idea is to create a TOTALLY SIMPLE guide that git illiterates like me can understand and thanks to which they would find out how to do stuff in wikimedia git / gerrit. Link is here: www.mediawiki.org/wiki/User:Petrb/Git_for_idiots I love it! I've written something similar for myself as well: just a bunch of copy+paste commands for those who use Git once in two months. It doesn't contain so much and there are some mistakes / feel free to fix them. Since wikimedia switched to gerrit from svn I have yet met a tons of people who had problems adapting to it, so this could eventually help some. ___ 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] GLAM Wiki Toolset code review
It's a big one. I took a crack at PS2. 32 more comments. On Wed, May 8, 2013 at 6:23 PM, Sumana Harihareswara suma...@wikimedia.orgwrote: On 04/17/2013 02:51 AM, Mathieu Stumpf wrote: Le 2013-04-16 18:25, Geer Oskam a écrit : Hi all, the GLAM Wiki Toolset-code is ready for its initial review. It can be found at: https://gerrit.wikimedia.org/r/#/c/59405/ Please help us by taking a look at it. Cheers, Geer Oskam Europeana For those like me which are wondering what is it?, here is an informative copy of the README: GWToolset = A MediWiki extension that allows GLAMs the ability to mass upload content based on an xml file conta ining respective metadata about the content. The intent is to allow for a variety of xml schemas; se e the [extension page]( http://www.mediawiki.org/wiki/Extension:GWToolset ) for further information. (All apologies if this was obvious to all other readers of this list) Thanks to Siebrand, Reedy, and Peachey88 for their reviews. There's a new patchset up as of today in case anyone wants to take a fresh look. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Siebrand Mazeland Product Manager Language Engineering 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] RFC: New approach to release notes
On Wed, 08 May 2013 19:24:48 +0200, Krinkle krinklem...@gmail.com wrote: How does this make anything harder for new users? If anything, it makes it easier by not having to worry about which file to edit, what to put in it etc. You're either not reading what I wrote or intentionally pulling my words out of context. I said harder to get changes merged, which is also precisely what I meant - the more actions a reviewer has to perform, the lesser the chance of a changeset being merged (I can provide detailed examples if you want, but I'm sure you know it just as well as I do). And please don't try to convince me figuring out which one of the two files with release notes is hard for anyone with their mind in order. What to put in is trivial for simple changes - you're right that the commit message will do. And for complex ones, well, I would expect that anybody making them is already knowledgeable enough to know what a good release note is; and your proposed workflow more complicated than what we have now anyway. (On a side-note, the 1.21 release notes file should have been killed a long time ago when we branched REL1_21; I have no idea what is it still doing in master.) As for more burden on reviewers, I disagree. It might inspire them to give more care to proper commit subjects (and edit them liberally as needed) because if you leave it in bad shape, it needs to be fixed later in the notes. Liberally editing commit subject is an extremely annoying thing when the threads in your mail client get split and when the items on your dashboard change. If the message has to be fixed, please point it out or just fix it properly *once*. And here again, it simplifies things by maintaining release notes centrally and away from inside the tight development loop. Some of the same people will be doing both, but in the right frame of mind, instead of when you don't want to. This is a fallacy; we just need to get gerrit to merge them properly. I have already worked on prototyping a solution (https://github.com/MatmaRex/mediawikireleasenotes-driver), but, being a volunteer, I am unable to spend as much time on it as I'd like. And if switching the merging mode will help as Chad says, then the point is moot anyway. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Git for idiots
Biggest disadvantage I see on the official documents is they don't contain the hypothetical situation when something is wrong, they are relying on the fact that everything is as it's supposed to be - perfect. That user has perfectly configured system, that user doesn't accidentally break repository or get lost in some process and stuck as they can't continue for whatever reason. The guide should count on that and display some alternative commands or reasons why some error messages are showing up (especially gerrit is making stuff very hard, sometimes it reject the commit with cryptic reasons) - or git-review is missing the .gitreview file sometimes and doesn't work. These newbie guides should count on that. The expert on git never get in such a situation because they are doing everything correct. So they naturally can't expect this to happen. I know I can edit the current documents but I have no idea how to merge them with document I wrote. We could eventually insert a FAQ into beginner guide that contain Why am I getting error X, Y etc with explanation why it happens and how to fix it. On Wed, May 8, 2013 at 7:49 PM, Yury Katkov katkov.ju...@gmail.com wrote: On Wed, May 8, 2013 at 8:34 PM, Petr Bena benap...@gmail.com wrote: Hi, Long time ago when I started learning with git I decided to create a simple guide (basically I was just taking some notes of what is needed). I never thought that it could be useful to anyone so I never announced it anywhere. However I got some feedback to it, so I decided to inform you too. The basic idea is to create a TOTALLY SIMPLE guide that git illiterates like me can understand and thanks to which they would find out how to do stuff in wikimedia git / gerrit. Link is here: www.mediawiki.org/wiki/User:Petrb/Git_for_idiots I love it! I've written something similar for myself as well: just a bunch of copy+paste commands for those who use Git once in two months. It doesn't contain so much and there are some mistakes / feel free to fix them. Since wikimedia switched to gerrit from svn I have yet met a tons of people who had problems adapting to it, so this could eventually help some. ___ 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] Git for idiots
Also note that in my document I have some hints like this: Sometimes it's needed to use following, should you know why, feel free to explain it: git push origin HEAD:refs/publish/master which I was told to use by someone else, and it works! So I noted it somewhere in case I would get into same issue again BUT I have no idea why it works. I just know it works and I don't know why. These things should be explained by expert, not me. But every notes of beginner in git or questions would greatly contribute to improve the documents On Wed, May 8, 2013 at 9:02 PM, Petr Bena benap...@gmail.com wrote: Biggest disadvantage I see on the official documents is they don't contain the hypothetical situation when something is wrong, they are relying on the fact that everything is as it's supposed to be - perfect. That user has perfectly configured system, that user doesn't accidentally break repository or get lost in some process and stuck as they can't continue for whatever reason. The guide should count on that and display some alternative commands or reasons why some error messages are showing up (especially gerrit is making stuff very hard, sometimes it reject the commit with cryptic reasons) - or git-review is missing the .gitreview file sometimes and doesn't work. These newbie guides should count on that. The expert on git never get in such a situation because they are doing everything correct. So they naturally can't expect this to happen. I know I can edit the current documents but I have no idea how to merge them with document I wrote. We could eventually insert a FAQ into beginner guide that contain Why am I getting error X, Y etc with explanation why it happens and how to fix it. On Wed, May 8, 2013 at 7:49 PM, Yury Katkov katkov.ju...@gmail.com wrote: On Wed, May 8, 2013 at 8:34 PM, Petr Bena benap...@gmail.com wrote: Hi, Long time ago when I started learning with git I decided to create a simple guide (basically I was just taking some notes of what is needed). I never thought that it could be useful to anyone so I never announced it anywhere. However I got some feedback to it, so I decided to inform you too. The basic idea is to create a TOTALLY SIMPLE guide that git illiterates like me can understand and thanks to which they would find out how to do stuff in wikimedia git / gerrit. Link is here: www.mediawiki.org/wiki/User:Petrb/Git_for_idiots I love it! I've written something similar for myself as well: just a bunch of copy+paste commands for those who use Git once in two months. It doesn't contain so much and there are some mistakes / feel free to fix them. Since wikimedia switched to gerrit from svn I have yet met a tons of people who had problems adapting to it, so this could eventually help some. ___ 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] Git for idiots
On Wed, May 8, 2013 at 3:04 PM, Petr Bena benap...@gmail.com wrote: Also note that in my document I have some hints like this: Sometimes it's needed to use following, should you know why, feel free to explain it: git push origin HEAD:refs/publish/master which I was told to use by someone else, and it works! So I noted it somewhere in case I would get into same issue again BUT I have no idea why it works. I just know it works and I don't know why. These things should be explained by expert, not me. But every notes of beginner in git or questions would greatly contribute to improve the documents That's easy to explain, actually. This is what you're doing every time you submit stuff to Gerrit (and what the official Gerrit docs say to do). `git push origin HEAD:refs/for/master` So what this is saying is Push to origin my HEAD commit, with the destination of refs/for/master. refs/for/foobar is the magic Gerrit ref for This change is FOR the branch FOOBAR. HEAD doesn't have to be HEAD (it's just a pointer), you could just as easily refer to a random tag or sha1 in the same command. For example, let's say you wanted to push the change just before HEAD for review (but your HEAD wasn't ready), you could do: `git push origin HEAD~1:refs/for/master` git-review is nothing more than a wrapper around these commands (and a couple of other things) since people like less typing :) Just for comparison, when you're doing a `git push origin master` (a la Github), you're actually just typing the shorthand version of `git push origin refs/heads/master:refs/heads/master.` -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Git for idiots
Le mercredi 08 mai 2013 à 18:34 +0200, Petr Bena a écrit :
Hi,
Long time ago when I started learning with git I decided to create a
simple guide (basically I was just taking some notes of what is
needed). I never thought that it could be useful to anyone so I never
announced it anywhere. However I got some feedback to it, so I decided
to inform you too.
The basic idea is to create a TOTALLY SIMPLE guide that git
illiterates like me can understand and thanks to which they would find
out how to do stuff in wikimedia git / gerrit.
Link is here: www.mediawiki.org/wiki/User:Petrb/Git_for_idiots
Interesting idea. Probably you should also put a part for those who
don't know svn, just like you go with everything is ok/wrong. I
didn't read the whole thing, so maybe in practice it doen't matter, but
if you want something accessible to total newbies, you shouldn't expect
them to know svn. Also you may have more contributors using {{empty}}
than if you say I don't know windows, look at this and move along.
Aprart from that, nice job.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] OPW browser test automation for Visual Editor
Zeljiko, I have updated my proposal with your suggestions, plus added a timeline and more info under About Me. Let me know if you have other suggestions. Here is my update proposal for OPW: https://www.mediawiki.org/wiki/User:Rachel99/OPW_proposal Thank you. -Rachel On Tue, Apr 30, 2013 at 5:45 PM, Rachel Thomas rachelthomas...@yahoo.comwrote: Here is my proposal for OPW: https://www.mediawiki.org/wiki/User:Rachel99/OPW_proposal Hi Rachel, I have left a couple of comments on the talk page[1]. Željko -- 1: https://www.mediawiki.org/wiki/User_talk:Rachel99/OPW_proposal From: wikitech-l-requ...@lists.wikimedia.org wikitech-l-requ...@lists.wikimedia.org To: wikitech-l@lists.wikimedia.org Sent: Wednesday, May 8, 2013 12:38 PM Subject: Wikitech-l Digest, Vol 118, Issue 34 Send Wikitech-l mailing list submissions to wikitech-l@lists.wikimedia.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.wikimedia.org/mailman/listinfo/wikitech-l or, via email, send a message with subject or body 'help' to wikitech-l-requ...@lists.wikimedia.org You can reach the person managing the list at wikitech-l-ow...@lists.wikimedia.org When replying, please edit your Subject line so it is more specific than Re: Contents of Wikitech-l digest... Today's Topics: 1. Re: OPW Browser Test Automation - Proposal Summary (Željko Filipin) 2. Re: OPW browser test automation for Visual Editor (Željko Filipin) 3. Re: APIStrat conference, San Francisco, October 23, 24, 25 (Marc A. Pelletier) 4. How to get permission to view deleted revision information via API? (Claudia Müller-Birn) 5. Re: How to get permission to view deleted revision information via API? (Chad) 6. Re: GSoC / OPW mentors README (Quim Gil) 7. Re: APIStrat conference, San Francisco, October 23, 24, 25 (Mathieu Stumpf) 8. Re: GLAM Wiki Toolset code review (Sumana Harihareswara) 9. Git for idiots (Petr Bena) 10. Re: Git for idiots (Chad) -- Message: 1 Date: Wed, 8 May 2013 14:42:22 +0200 From: Željko Filipin zfili...@wikimedia.org To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] OPW Browser Test Automation - Proposal Summary Message-ID: cabfbeaohs5ruweptarpz6yu1aorkvoqhaxenzhva2wlggyc...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 On Tue, Apr 30, 2013 at 2:25 PM, Indrani Sen i@se12.qmul.ac.uk wrote: I am summarizing here my proposal idea for OPW MediaWiki projects. I have noticed that you did not provide the link to your proposal[1]. In addition to the comments that I have posted here, I have left a few comments on the talk page[2]. Željko -- 1: http://www.mediawiki.org/wiki/User:Indranisen 2: http://www.mediawiki.org/wiki/User_talk:Indranisen -- Message: 2 Date: Wed, 8 May 2013 14:57:10 +0200 From: Željko Filipin zfili...@wikimedia.org To: Rachel Thomas rachelthomas...@yahoo.com, Wikimedia developers wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] OPW browser test automation for Visual Editor Message-ID: CABfBeArREv5M6y22igQYCnNXB9GWjh=dswo-etzk0scb0+5...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 On Tue, Apr 30, 2013 at 5:45 PM, Rachel Thomas rachelthomas...@yahoo.comwrote: Here is my proposal for OPW: https://www.mediawiki.org/wiki/User:Rachel99/OPW_proposal Hi Rachel, I have left a couple of comments on the talk page[1]. Željko -- 1: https://www.mediawiki.org/wiki/User_talk:Rachel99/OPW_proposal -- Message: 3 Date: Wed, 08 May 2013 09:09:17 -0400 From: Marc A. Pelletier m...@uberbox.org To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] APIStrat conference, San Francisco, October 23, 24, 25 Message-ID: 518a4e7d.6000...@uberbox.org Content-Type: text/plain; charset=UTF-8 On 05/07/2013 05:33 PM, Juliusz Gonera wrote: Seems interesting. Is there anyone who'd be interested in giving a talk or participating in a panel there? Given that it's very close to me, and that I have quite a bit of experience with the API, this is something I could do. I actually had an API talk planned for WM 2012 that I never got a chance to present, I could dust it off and see how well it fits in their scope. Do you know when their CFP opens? -- Marc -- Message: 4 Date: Wed, 8 May 2013 15:35:19 +0200 From: Claudia Müller-Birn c...@inf.fu-berlin.de To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: [Wikitech-l] How to get permission to view deleted revision information via API? Message-ID: 63f3f3f4-938c-49ba-8bfd-8c5156c0a...@inf.fu-berlin.de Content-Type: text/plain; charset=windows-1252 Hi all, I don't know whether this is the correct mailing list to ask such question but it is the one I am reading regularly… Does
Re: [Wikitech-l] Git for idiots
Quim Gil qgil at wikimedia.org writes: On 05/08/2013 09:41 AM, Petr Bena wrote: I was using these tutorials in past, and they were pretty complicated for me to understand git. Have you checked recently these pages? http://www.mediawiki.org/wiki/Gerrit/Getting_started http://www.mediawiki.org/wiki/Gerrit/Tutorial I'm a git-idiot and they were useful even before we went through the Git/Gerrit a couple of months ago. You are encouraged to improve these pages. Thank you! As Chad says we are not going to push a 3rd reference document. I also had troubles with the existing tutorials, and for me it's even worse, since I am (shriek!) a Windows user. I actually started drafting a Gerrit/Git for Windows Dummies page with the solutions I found to be easiest for myself, and some of them are already up in Petr's page (Yay!) For example, one of the biggest issues for me was the SSH public key. Creating a pair isn't a problem (the explanation in the tutorial is from GitHub, and is fairly straight forward) but finding where to *submit it* was tricky. The SSH Key submission appears as an option in two places - the wikitech site (where we ask for dev account) and the gerrit settings. It's really confusing. Also, where the tutorial/quickstart said something like git clone ssh://usern...@gerrit.wikimedia.org:29418/mediawiki/core.git In effect, it means TOKEN (the shell token we chose when registering for development account) and not (as it looks) the username we use to log into gerrit. These are small comments and they probably sound silly to people who are experienced and do this a lot, but for people who aren't so well versed with Git and Gerrit (or even linux and command-line work) they can get you stuck for hours. I know that it's recommended we edit the existing tutorials, but in this case, I think that it might be a good idea to add another tutorial for complete newbies. The Getting Started tutorial is more of a reference -- it didn't completely help me when I started from scratch, but I use it a lot now to make sure I remember the procedure correctly. (I might add the 'fetch/reset' reference there in case someone wants to reset their changes from scratch, which happens to us newbies a lot ;) The Advanced Usage is meant for advanced stuff and if something goes wrong -- it assumes you already have git going, and that you're on a GNU/Linux system for the most part. Adding another page for a complete walkthrough for either windows users and/or people who aren't versed in git/gerrit can help newbies without ruining the references that experienced users use right now. Moriel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Coding style: Language construct spacing
Hi, Since there appears to have been a little bit of trivia around fixing these phpcs warnings, I'll open a thread instead. Both in javascript and PHP there are various keywords that can be used as if they are functions. In my opinion this is a misuse of the language and only causes confusion. I'm referring to code like this (both javascript and php): delete( mw.legacy ); new( mw.Title ); typeof( mw ); echo( $foo . $bar ); print( $foo . $bar ); return( $foo . $bar ); … and, wait for it.. require_once( $foo . $bar ); I think most experienced javascript developers know by now that using delete or new like it is a function is just silly and looks like you don't know what you're doing. To give a bit of background, here's why these work at all (they aren't implemented both keywords and functions, just keywords). Though I'm sure the implementation details differ between PHP and javascript, the end result is the same: Keywords are given expressions which are then evaluated and the result is used as value. Since expressions can be wrapped in parenthesis for readability (or logic grouping), and since whitespace is insignificant to the interpreter, it is possible to do `return(test)`, which really is just `return (test)` and eventually `return test`. I'm obviously biased, but I think the same goes for require_once (and include, require etc.). Right now this is causing quite a few warnings in our php-checkstyle report. I didn't disable that rule because it appears (using our code base as status quo) that we do want this. There's 0 warnings I could find in our code base that violate this, except for when the keyword is include|require(_once)? The check style sniffer does not (and imho should not) have a separate rule per keyword. Either you use constructs like this, or you don't. But let's not have some weird exception just because someone didn't understand it[1] and we all copied it and want to keep it for no rational reason. Because that would mean we have to either hack the sniffer to exclude this somehow, or we need to disable the rule, thus not catching the ones we do use. See pending change in gerrit that does a quick pass of (most of) these in mediawiki/core: https://gerrit.wikimedia.org/r/62753 -- Krinkle [1] Or whatever the reason is the author originally wrote it like this. Perhaps PHP was different back then, or perhaps there was a different coding style. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Coding style: Language construct spacing
But let's not have some weird exception just because someone didn't understand it[1] and we all copied it and want to keep it for no rational reason. I think its probably because Die, List, Array, and Exit are also keywords but require the (). It also makes sense when looking at language constructs like If, ElseIf, While, For, ForEach where although not strictly keywords I view as being the same for the purposes of this argument. ~Matt Walker Wikimedia Foundation Fundraising Technology Team On Wed, May 8, 2013 at 5:26 PM, Krinkle krinklem...@gmail.com wrote: Hi, Since there appears to have been a little bit of trivia around fixing these phpcs warnings, I'll open a thread instead. Both in javascript and PHP there are various keywords that can be used as if they are functions. In my opinion this is a misuse of the language and only causes confusion. I'm referring to code like this (both javascript and php): delete( mw.legacy ); new( mw.Title ); typeof( mw ); echo( $foo . $bar ); print( $foo . $bar ); return( $foo . $bar ); … and, wait for it.. require_once( $foo . $bar ); I think most experienced javascript developers know by now that using delete or new like it is a function is just silly and looks like you don't know what you're doing. To give a bit of background, here's why these work at all (they aren't implemented both keywords and functions, just keywords). Though I'm sure the implementation details differ between PHP and javascript, the end result is the same: Keywords are given expressions which are then evaluated and the result is used as value. Since expressions can be wrapped in parenthesis for readability (or logic grouping), and since whitespace is insignificant to the interpreter, it is possible to do `return(test)`, which really is just `return (test)` and eventually `return test`. I'm obviously biased, but I think the same goes for require_once (and include, require etc.). Right now this is causing quite a few warnings in our php-checkstyle report. I didn't disable that rule because it appears (using our code base as status quo) that we do want this. There's 0 warnings I could find in our code base that violate this, except for when the keyword is include|require(_once)? The check style sniffer does not (and imho should not) have a separate rule per keyword. Either you use constructs like this, or you don't. But let's not have some weird exception just because someone didn't understand it[1] and we all copied it and want to keep it for no rational reason. Because that would mean we have to either hack the sniffer to exclude this somehow, or we need to disable the rule, thus not catching the ones we do use. See pending change in gerrit that does a quick pass of (most of) these in mediawiki/core: https://gerrit.wikimedia.org/r/62753 -- Krinkle [1] Or whatever the reason is the author originally wrote it like this. Perhaps PHP was different back then, or perhaps there was a different coding style. ___ 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] Coding style: Language construct spacing
On 2013-05-08 9:26 PM, Krinkle krinklem...@gmail.com wrote: Hi, Since there appears to have been a little bit of trivia Hi, Since there appears to have been a little bit of trivia around fixing these phpcs warnings, I'll open a thread instead. Both in javascript and PHP there are various keywords that can be used as if they are functions. In my opinion this is a misuse of the language and only causes confusion. I'm referring to code like this (both javascript and php): delete( mw.legacy ); new( mw.Title ); typeof( mw ); echo( $foo . $bar ); print( $foo . $bar ); return( $foo . $bar ); … and, wait for it.. require_once( $foo . $bar ); I think most experienced javascript developers know by now that using delete or new like it is a function is just silly and looks like you don't know what you're doing. To give a bit of background, here's why these work at all (they aren't implemented both keywords and functions, just keywords). Though I'm sure the implementation details differ between PHP and javascript, the end result is the same: Keywords are given expressions which are then evaluated and the result is used as value. Since expressions can be wrapped in parenthesis for readability (or logic grouping), and since whitespace is insignificant to the interpreter, it is possible to do `return(test)`, which really is just `return (test)` and eventually `return test`. I'm obviously biased, but I think the same goes for require_once (and include, require etc.). Right now this is causing quite a few warnings in our php-checkstyle report. I didn't disable that rule because it appears (using our code base as status quo) that we do want this. There's 0 warnings I could find in our code base that violate this, except for when the keyword is include|require(_once)? The check style sniffer does not (and imho should not) have a separate rule per keyword. Either you use constructs like this, or you don't. But let's not have some weird exception just because someone didn't understand it[1] and we all copied it and want to keep it for no rational reason. Because that would mean we have to either hack the sniffer to exclude this somehow, or we need to disable the rule, thus not catching the ones we do use. See pending change in gerrit that does a quick pass of (most of) these in mediawiki/core: https://gerrit.wikimedia.org/r/62753 -- Krinkle [1] Or whatever the reason is the author originally wrote it like this. Perhaps PHP was different back then, or perhaps there was a different coding style. ___ 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] category intersection conversations
Recently a lot of people have been talking about what's possible and what's necessary regarding MediaWiki, CatScan-like tools, and real category intersection; this mail has some pointers. The long-term solution is a sparkly query for, e.g., people with aspects novelist + Singaporean, and it would be great if Wikidata could be the data-source. Generally people don't really want to search using hierarchical categories; they want tags and they want AND. But MediaWiki's current power users do use hierarchical labels, so any change would have to deal with current users' expectations. Also my head hurts just thinking of the but my intuitively obvious ontology is better than yours arguments. Conversations have been a bit scattered: https://meta.wikimedia.org/wiki/Beyond_categories http://lists.wikimedia.org/pipermail/wikidata-l/2013-May/thread.html#2202 (Question about wikipedia categories.) https://en.wikipedia.org/wiki/Wikipedia_talk:Category_intersection#A_working_category_intersection_today CatScan, which can find articles in category intersections: https://en.wikipedia.org/wiki/Wikipedia:CatScan http://lists.wikimedia.org/pipermail/gendergap/2013-April/003552.html https://bugzilla.wikimedia.org/show_bug.cgi?id=5244 Allow searching in intersections, etc. of categories I think the best place to pursue this topic is probably in https://meta.wikimedia.org/wiki/Talk:Beyond_categories . It's unlikely Wikimedia Foundation will be able to make engineers available to work on this anytime soon, but I would not be surprised if the Wikidata developer community or volunteers found this interesting enough to work on. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikidata Features
On 05/03/2013 03:48 PM, Puneet Kaur wrote: Hi all , I know its late but still. I wished to let you all know that I have applied for the Wikidata Features Project Idea in GSOC 2013. I have a bit of experience in website development and designing, but I am not sure whether all of my present knowledge would be sufficient for the project. I shall be exploring my hands on wikidata, the online knowledge base for the rest of days. Do let me know if I am expected of anything else than that mentioned above. Regards, Puneet ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Puneet, thanks for the email, but *linking* to your proposal would have been helpful. https://www.mediawiki.org/wiki/User:Puneet_kaur :-) Have you ever worked in PHP before? Have you worked on MediaWiki before? Have you started the steps in https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker and potentially worked on a small bug suitable for novices? -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] category intersection conversations
On 8 May 2013 18:26, Sumana Harihareswara suma...@wikimedia.org wrote: Recently a lot of people have been talking about what's possible and what's necessary regarding MediaWiki, CatScan-like tools, and real category intersection; this mail has some pointers. The long-term solution is a sparkly query for, e.g., people with aspects novelist + Singaporean, and it would be great if Wikidata could be the data-source. Generally people don't really want to search using hierarchical categories; they want tags and they want AND. But MediaWiki's current power users do use hierarchical labels, so any change would have to deal with current users' expectations. Also my head hurts just thinking of the but my intuitively obvious ontology is better than yours arguments. To put a nice clear stake in the ground, a magic-world-of-loveliness sparkly proposal for 2015* might be: * Categories are implemented in Wikidata * - They're in whatever language the user wants (so fr:Chat and en:Cat and nl:kat and zh-han-t:貓 …) * - They're properly queryable * - They're shared between wikis (pooled expertise) * Pages are implicitly in the parent categories of their explicit categories * - Pages in Politicians from the Netherlands are in People from the Netherlands by profession (its first parent) and People from the Netherlands (its first parent's parent) and Politicians (its second parent) and People (its second parent's parent) and … * - Yes, this poses issues given the sometimes cyclic nature of categories' hierarchies, but this is relatively trivial to code around * Readers can search, querying across categories regardless of whether they're implicit or explicit * - A search for the intersection of People from the Netherlands with Politicians will effectively return results for Politicians from the Netherlands (and the user doesn't need to know or care that this is an extant or non-extant category) * - Searches might be more than just intersections, e.g. Painters from the United Kingdom AND Living people NOT Members of the Royal Academy or whatever. * - Such queries might be cached (and, indeed, the intersections that people search for might be used to suggest new categorisation schemata that wikis had previously not considered - e.g. British politicians People with pet cats People who died in hot-ballooning accidents) * Editors can tag articles with leaf or branch categories, potentially over-lapping and the system will rationalise the categories on save to the minimally-spanning subset (or whatever is most useful for users, the database, and/or both) * - Editors don't need to know the hierarchy of categories *a priori* when adding pages to them (yay, less difficulty) * - Power editors don't need to type in loads of different categories if they have a very specific one in mind (yay, still flexible) * - Categories shown to readers aren't necessarily the categories saved in the database, at editorial judgement (otherwise, would a page not be in just a single category, namely the intersection of all its tagged categories?) Apart from the time and resources needed to make this happen and operational, does this sound like something we'd want to do? It feels like this, or something like it, would serve our editors and readers the best from their perspective, if not our sysadmins. :-) [Snip] I think the best place to pursue this topic is probably in https://meta.wikimedia.org/wiki/Talk:Beyond_categories . It's unlikely Wikimedia Foundation will be able to make engineers available to work on this anytime soon, but I would not be surprised if the Wikidata developer community or volunteers found this interesting enough to work on. I guess I should post this there too, maybe once someone's told me if it's mad-cap. ;-) J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC Proposal - Incremental Data Dumps
On 05/03/2013 10:18 AM, Jeremy Coffman wrote: Hello, My name is Jeremy Coffman. I am a second year student studying Computer Science at Brandeis University, with a possible focus on natural language processing. I have decided to apply to work on the Incremental Data Dumps project. My proposal can be found here: http://www.mediawiki.org/wiki/User:J.a.coffman/GSoc_2013_Proposal I know I'm rather close to the deadline, but I welcome any feedback you may have. Thank you, Jeremy Coffman Thanks for the email, Jeremy, and for your proposal. Since you haven't worked with MediaWiki at all before I have to ask: Have you started the steps in https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker and worked on a small bug suitable for novices? -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Coding style: Language construct spacing
On Wed, May 8, 2013 at 8:26 PM, Krinkle krinklem...@gmail.com wrote: delete( mw.legacy ); new( mw.Title ); typeof( mw ); echo( $foo . $bar ); print( $foo . $bar ); return( $foo . $bar ); … and, wait for it.. require_once( $foo . $bar ); I mostly agree. However, I must admit there are *some* cases where the parentheses are appropriate. However, in those situations, they should not be used as a function call operator. In other words, rather than: return( $foo . $bar ); Sometimes (and only sometimes) it might be appropriate to do return ( $foo . $bar ); In other words, the parentheses are being used to group the expression similar to how it's used in mathematical expressions, but not as a function call operator. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] category intersection conversations
On 2013-05-08 11:48 PM, James Forrester jforres...@wikimedia.org wrote: On 8 May 2013 18:26, Sumana Harihareswara suma...@wikimedia.org wrote: Recently a lot of people have been talking about what's possible and what's necessary regarding MediaWiki, CatScan-like tools, and real category intersection; this mail has some pointers. The long-term solution is a sparkly query for, e.g., people with aspects novelist + Singaporean, and it would be great if Wikidata could be the data-source. Generally people don't really want to search using hierarchical categories; they want tags and they want AND. But MediaWiki's current power users do use hierarchical labels, so any change would have to deal with current users' expectations. Also my head hurts just thinking of the but my intuitively obvious ontology is better than yours arguments. To put a nice clear stake in the ground, a magic-world-of-loveliness sparkly proposal for 2015* might be: Just to clarify, you mean sparkles in the way that a unicorn sparkles as its hopping over a rainbow, not sparkle as in SPARQL (semantic triple store based)? * Categories are implemented in Wikidata * - They're in whatever language the user wants (so fr:Chat and en:Cat and nl:kat and zh-han-t:貓 …) Issue (probably can be dealt with somehow or maybe rare enough not to care): conflicts - what if the name of one cat in french is the same as a different category in spanish. May be non issue if done using wikidata numeric ids * - They're properly queryable Various groups have variois definitions of this * - They're shared between wikis (pooled expertise) Between wikipedias or all wikimedia wikis... category structure has varried meaning between projects. Category:North_America has different types of pages in enwikinews compared to enwikipedia. * Pages are implicitly in the parent categories of their explicit categories * - Pages in Politicians from the Netherlands are in People from the Netherlands by profession (its first parent) and People from the Netherlands (its first parent's parent) and Politicians (its second parent) and People (its second parent's parent) and … * - Yes, this poses issues given the sometimes cyclic nature of categories' hierarchies, but this is relatively trivial to code around In the current structure. It doesnt make sense for Bob to be in list of people by professions. It makes less sense the futher you traverse the cayegory graph. Otoh better querying capabilities may turn the category system into more of a flat namespace making that less of an issue. * Readers can search, querying across categories regardless of whether they're implicit or explicit * - A search for the intersection of People from the Netherlands with Politicians will effectively return results for Politicians from the Netherlands (and the user doesn't need to know or care that this is an extant or non-extant category) We would need some system to turn fake cats into real queries. I suppose users could make redirects. The alternative of magic nlp sounds difficult * - Searches might be more than just intersections, e.g. Painters from the United Kingdom AND Living people NOT Members of the Royal Academy or whatever. * - Such queries might be cached (and, indeed, the intersections that people search for might be used to suggest new categorisation schemata that wikis had previously not considered - e.g. British politicians People with pet cats People who died in hot-ballooning accidents) Dealing with cache invalidation (unless it is quite coarse grained) may be difficult. * Editors can tag articles with leaf or branch categories, potentially over-lapping and the system will rationalise the categories on save to the minimally-spanning subset (or whatever is most useful for users, the database, and/or both) That's quite an interesting idea, and one I haven't heard before from previous times this has been brought up. One concern id have is how to figure out which categories to list at the bottom of the page (all that could fit, or only the base categories, and how to determine what that is) * - Editors don't need to know the hierarchy of categories *a priori* when adding pages to them (yay, less difficulty) * - Power editors don't need to type in loads of different categories if they have a very specific one in mind (yay, still flexible) * - Categories shown to readers aren't necessarily the categories saved in the database, at editorial judgement (otherwise, would a page not be in just a single category, namely the intersection of all its tagged categories?) Apart from the time and resources needed to make this happen and operational, does this sound like something we'd want to do? It feels like this, or something like it, would serve our editors and readers the best from their perspective, if not our sysadmins. :-) [Snip] I think the best place to pursue this topic is probably in
Re: [Wikitech-l] category intersection conversations
On 05/09/2013 12:13 AM, Brian Wolff wrote: Between wikipedias or all wikimedia wikis... category structure has varried meaning between projects. Category:North_America has different types of pages in enwikinews compared to enwikipedia. Right. It would have to be grouped by top-level project (all Wikipedias, all Wikinewses, etc.). But even then you could run into inter-project conflicts. However, I think many of the *intra*-project category disagreements are actually about when intersections are appropriate, so it might not be that bad (since the trend would be towards intersections as just queries). Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Purging parts of varnish cache
Hi, when we edit Zero configuration, it would be very beneficial to flush any cached pages in varnish that are related to the change. For example, if I edit Beeline's banner settings, any objects with the header X-CS=250-99 should be purged, hopefully without any additional manual interaction. Without this purge, the cache will be stale for the next 30 days for the most common articles. Now, according to the http://giantdorks.org/alain/exploring-methods-to-purge-varnish-cache/, varnish has an extensive matching support, and the author provides some PHP-based code to perform the cache flushing. What would we need to implement secure, automated partial varnish flushing in production? Thanks! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
