Re: [Wikitech-l] Nobody Wikidata bugs: notify when you start working on a bug
On Thu, 2012-12-06 at 10:07 -0800, Quim Gil wrote: Hi, thanks to the metrics reports now we know that the top bug fixers in November were Nobody (228) and Wikidata bugs (83 Even if the visible problem is a less accurate Bugzilla hall of fame, the actual problem is that a big bunch of developers don't notify when they are taking a bug. This decreases transparency and increases the chances of duplicated work. Setting the assignee field makes sense when working on something for a longer time so you don't duplicate work. I don't see much advantage by setting an assignee for a quick fix (but it's easier now as you only need to click take below the Assigned to field and don't need to enter your email address manually anymore). I consider Gerrit a way better place when it comes to creating statistics about bug *fixes* (RESOLVED FIXED in Bugzilla terms). Obviously I exclude any other Bugzilla resolutions here. :) 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
Re: [Wikitech-l] Nobody Wikidata bugs: notify when you start working on a bug
Hello, On Fri, Dec 7, 2012 at 11:56 AM, Andre Klapper aklap...@wikimedia.org wrote: On Thu, 2012-12-06 at 10:07 -0800, Quim Gil wrote: Hi, thanks to the metrics reports now we know that the top bug fixers in November were Nobody (228) and Wikidata bugs (83 Even if the visible problem is a less accurate Bugzilla hall of fame, the actual problem is that a big bunch of developers don't notify when they are taking a bug. This decreases transparency and increases the chances of duplicated work. Setting the assignee field makes sense when working on something for a longer time so you don't duplicate work. I don't see much advantage by setting an assignee for a quick fix (but it's easier now as you only need to click take below the Assigned to field and don't need to enter your email address manually anymore). I consider Gerrit a way better place when it comes to creating statistics about bug *fixes* (RESOLVED FIXED in Bugzilla terms). Obviously I exclude any other Bugzilla resolutions here. :) I've already been in a situation on Wikimedia where someone fixed a bug in the same time than me. This bug qualified under quick fix. I had set the assignee but were told this assignee field weren't really used. Not to use this field is wrong, even for quick fixes. We never know what is short or not and this it's also more polite to let the bug submitter to know someone is taking care of the bug. I would actively recommend we assign bugs to the code submitter each time we see a nobody bug. -- Best Regards, Sébastien Santoro aka Dereckson http://www.dereckson.be/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] slight change to the review workflow in Gerrit
| I understand the concern, but if we're creating a world | where tests have to wait for developer review, we're doing | CI the wrong way around. The whole point of automated | testing is to minimize the need for human review, so we | should aim to run as many tests as possible as early as | possible. Both test performance and security considerations | are problems to be gradually resolved in aiming for highest | possible test execution for all code that gets submitted, | and minimizing the need for human review on code which is | obviously broken. Why not just add (more) slaves? Computing power is much cheaper than developer time. I absolutely agree. I'm also in agreement on this one. Having tests run after code review negates the point of having tests run in the first place. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The rest of the SMWCon conference is on YouTube
Hi Yury, P.S. dear speakers, if you have time, please add to the template Talk link to your talk on YouTube in a parameter Video. I'm quite slow guy as you can see Done. Did you add http://www.youtube.com/watch?v=plgTaYD37mIfeature=plcp to the SMWCon playlist as well? I couldn't find it there. Cheers, Remco ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla upgrade [was: bugzilla.wikimedia.org downtime: Now.]
On Wed, 2012-12-05 at 00:29 +0100, Andre Klapper wrote: On Tue, 2012-12-04 at 14:53 -0500, Chad wrote: On Tue, Dec 4, 2012 at 2:44 PM, Andre Klapper aklap...@wikimedia.org wrote: The only (potential) regression is that we did not apply previous changes to Bugmail.pm, described as Wikimedia Hack! Pretend global watchers are CCs so we can use their prefs to for instance ignore CC-only mails. Is there a reason for this? We had this hack in place to keep BZ from spamming IRC/wikibugs-l when only the CC list changes... So the aim of the patch was to completely omit bugmail in case of CC list only changes, in order to make IRC + wikibugs-l@ less noisy? 1) I assume this silently broke The CC field changes settings on https://bugzilla.wikimedia.org/userprefs.cgi?tab=email for everybody in the past. Assume because my time machine back to 4.0.9 is broken. 2) wikibugs-l@ is also set as globalwatchers (who should receive a copy of every notification mail Bugzilla sends). After the Bugzilla upgrade wikibugs-l@ *finally* works reliably for me and seems to send ALL bugmail. Before I didn't receive bugmail anymore after wikibugs-l@ got removed as assignee of a report when wikibugs-l@ was not listed either as default CC of the corresponding component (test example: bug 42226). These might be related [or not] to dropping the hack. In any case, I'd like to challenge reapplying this patch, because: 1) Don't set wikibugs-l@ as globalwatchers if you don't want it to receive all bugmail about all changes. 2) If you want a certain account to not receive email in case of changing X in Bugzilla, edit the accounts's when to send mail settings in Bugzilla to not to send bugmail in case of only changing X. Obviously this interferes with 1) currently. 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] xml csv : uploading and handling
hey all, i’m working on an extension that will depend on the upload of xml and csv data files. i need some advice on how to best upload those data file types and then process them. any guidance on how to do this within the mediawiki framework would be greatly appreciated. the end goal is that the extension will run within http://commons.wikimedia.org. here are some initial thoughts/questions : 1. i’ve been looking at how SpecialUpload.php and UploadBase.php work together, but found that i need to override $wgMimieTypeBlacklist’s value of 'text/html' and make sure $wgDisableUploadScriptChecks is set to true in order for UploadBase.php to accept an xml file and i’m still figuring out what needs to be overridden or adjusted in order to accept a csv file. a. is this the recommended path to being able to upload these file types? i. if so, is there a manual that guides one through how to implement this? ii. if not, what is the recommended path? 2. the idea for the form is that after selecting the file, pressing the submit button would asynchronously upload the data file. a. how can this best be accomplished? b. any current documentation on how to do this besides code itself? 3. the files would then be stored and versioned. a. what is the best way to then store those file types for versioning? 4. then a batch process id would be created and have a logging process that would allow the original uploader to view the progress of working on the uploaded data. a. how can this best be accomplished? b. any current documentation on how to do this besides code itself? thanks in advance for your thoughts. with kind regards, dan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] xml csv : uploading and handling
On 07/12/12 16:05, dan wrote: hey all, i’m working on an extension that will depend on the upload of xml and csv data files. i need some advice on how to best upload those data file types and then process them. any guidance on how to do this within the mediawiki framework would be greatly appreciated. the end goal is that the extension will run within http://commons.wikimedia.org. here are some initial thoughts/questions : 1. i’ve been looking at how SpecialUpload.php and UploadBase.php work together, but found that i need to override $wgMimieTypeBlacklist’s value of 'text/html' and make sure $wgDisableUploadScriptChecks is set to true in order for UploadBase.php to accept an xml file and i’m still figuring out what needs to be overridden or adjusted in order to accept a csv file. a. is this the recommended path to being able to upload these file types? i. if so, is there a manual that guides one through how to implement this? ii. if not, what is the recommended path? The problem with overriding the blacklist is that some evil users could upload html, which then runs javascript and hijacks the user accounts. If your xml is different enough than html, it should be possible to detect them with their type, instead of skipping the html blacklist. 2. the idea for the form is that after selecting the file, pressing the submit button would asynchronously upload the data file. a. how can this best be accomplished? b. any current documentation on how to do this besides code itself? Just use the normal upload process, such as the UploadWizard ? 3. the files would then be stored and versioned. a. what is the best way to then store those file types for versioning? The wiki automatically versions the files. 4. then a batch process id would be created and have a logging process that would allow the original uploader to view the progress of working on the uploaded data. a. how can this best be accomplished? b. any current documentation on how to do this besides code itself? Some special page, perhaps. I think there may be something similar with videos, where a job is created to transcode them, but I don't think there's an interface to view the process of working on that. You will have to create your own SpecialPage. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Webinar: Getting the Most Out of Jenkins and, Selenium, with CloudBees and Sauce Labs
On Thu, Dec 6, 2012 at 7:10 PM, Juliusz Gonera jgon...@wikimedia.orgwrote: Reposting to wikitech-l, in case someone is interested: http://www.cloudbees.com/**webinars/getting-most-out-** selenium-and-jenkins-**cloudbees-sauce.cbhttp://www.cloudbees.com/webinars/getting-most-out-selenium-and-jenkins-cloudbees-sauce.cb Thanks for posting this. I have registered for the webinar. We use Coudbees/Jenkins and SauceLabs/Selenium for browser tests: https://github.com/wikimedia/qa-browsertests Željko ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] slight change to the review workflow in Gerrit
Le 06/12/12 19:19, Antoine Musso a écrit : If all works fine tonight, I will configure jenkins-bot so it merges the Change automatically whenever the test are successful. Jenkins now automatically merge changes made to mediawiki/core.git that have received CR+2 and pass all tests. The related Zuul change is: https://gerrit.wikimedia.org/r/#/c/37420/ So we now just have to CR+2 and comment and the rest happens magically. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Nobody Wikidata bugs: notify when you start working on a bug
Good to see that this discussion is not only about quick fixes. This answer goes to wikidata-bugs but it is also applicable to Nobody. On 12/07/2012 03:17 AM, Lydia Pintscher wrote: On Thu, Dec 6, 2012 at 10:17 PM, Quim Gil q...@wikimedia.org wrote: On 12/06/2012 10:56 AM, Lydia Pintscher wrote: For Wikidata at least we do set bugs to ASSIGNED most of the time. But we do leave the assignee set to the mailing list. If there is a strong preference to also change the assignee I can bring it up in the team. Bitte bitte btte! :) Hey Quim, I brought this up today in our daily meeting. It seems people do not think changing this is doable. The way we work in the team is that at the beginning of the sprint we set the tasks we'll be working on to assigned and add them to the task board in the office here. Then people pick things from the board as they go along during the sprint by putting a pin with their face on it on the task. Duplicating this information once again seems like it'll not get done... I think for people outside the team setting the status to assigned is enough. And if they want to know who exactly is working on it they can ask in the bug. I just did: https://bugzilla.wikimedia.org/show_bug.cgi?id=42817 There is more at http://bit.ly/WO5wBk (my new saved search) Let's see what happens. :) Going through a sample of bugs ASSIGNED to Nobody and Wikidata it seems that each developer goes to their newly assigned bug reports and sets them to ASSIGNED (and CCing themselves). Is that the case or is there someone acting as proxy for the developers? If they are the ones doing the work, how hard is to click take? This is now easier than CCing you. If someone is doing the proxy work for the developers (as it happend too frequently when I worked at Nokia, and I have seen other corporations doing the same with public bug trackers) then the main risk is to have a disconnect between the reporter and the bug discussion and the actual work that someone else is doing inside an organization, because that developer is not even getting the feedback that bug might raise. Adding the actual developer to the CC field helps fixing this problem but, once you are there, assigning the bug to the actual developer is just the same amount of work. Conclusion: assigning bugs to the people that got them assigned is quite simple, a good open source software development practice and one factor helping getting more and better contributions. My work consists in helping bringing more and better contributions to Wikimedia software projects, and this is why I care. I understand modifying processes is always an annoyance for busy teams but at least I hope you get what we all get (you included) for the price of a click. Thank you for reading. :) -- Quim Gil Technical Contributor Coordinator Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Wikidata client can't load revision content from wikidata.org
test2.wikimedia.org is now configured to act as a client to wikidata.org. It's supposed to access data items by directly talking to wikidata.org's database. But this fails: Revision::getRevisionText returns false. Any ideas why that would be? I have documented the issue in detail here: https://bugzilla.wikimedia.org/show_bug.cgi?id=42825 Any help would be appreciated. -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Nobody Wikidata bugs: notify when you start working on a bug
On 12/07/2012 02:56 AM, Andre Klapper wrote: On Thu, 2012-12-06 at 10:07 -0800, Quim Gil wrote: Hi, thanks to the metrics reports now we know that the top bug fixers in November were Nobody (228) and Wikidata bugs (83 Even if the visible problem is a less accurate Bugzilla hall of fame, the actual problem is that a big bunch of developers don't notify when they are taking a bug. This decreases transparency and increases the chances of duplicated work. Setting the assignee field makes sense when working on something for a longer time so you don't duplicate work. I don't see much advantage by setting an assignee for a quick fix (but it's easier now as you only need to click take below the Assigned to field and don't need to enter your email address manually anymore). Let's see. No mater how quick you fix is: isn't there a moment when you are sitting in front of the bug report to see what needs to be fixed? Or even if you manage to fix bugs by heart, isn't there a moment when you are in front of the bug report, resolving it as FIXED? Anonymous developer: whenever you are in this situation, please click take. It's extra 5 seconds at most. Thank you. :) I consider Gerrit a way better place when it comes to creating statistics about bug *fixes* (RESOLVED FIXED in Bugzilla terms). Obviously I exclude any other Bugzilla resolutions here. :) Not all bugs are related with Gerrit. But in any case: sure, where is the link to the data? I'll do my best adding that data to the metrics reports. In the meantime, those Bugzilla links are the best data point I could get. -- 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] Nobody Wikidata bugs: notify when you start working on a bug
On Fri, Dec 7, 2012 at 12:54 PM, Quim Gil q...@wikimedia.org wrote: Let's see. No mater how quick you fix is: isn't there a moment when you are sitting in front of the bug report to see what needs to be fixed? Well yes - but just because I know how to fix a bug in theory, doesn't mean I'm actually going to fix the bug :P So hypothetical situation *I'm bored one day and decide to fix a bug. For sake of argument lets say I'm not in an internet zone. *I go somewhere to get wifi. upload my patch to gerrit *I comment on bug that there's a patch in gerrit. I also assign the bug to myself. In this situation I'm really unclear on what the point of taking the bug is. By the time I have the ability to mark the bug assigned, I've already done it. If someone happens to fix the bug in the intermediate time, while that happens sometimes. For a quick fix bug, I'm not going to be upset about it. -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Nobody Wikidata bugs: notify when you start working on a bug
On 12/07/2012 09:01 AM, Lydia Pintscher wrote: No I think we're talking past each other a bit ;-) Assigned means we (the Wikidata dev team) picked up the bug/task for the current sprint. It is not always immediately clear who is going to work on the bug during the sprint. It is just clear that we intend to work on it. This decision is made in a meeting of the whole team. At the end of the meeting someone goes and changes the bug status accordingly for all of them. During the sprint developers pick from that list as they wish/have the skills. Then those ASSIGNED bugs are not really assigned. By setting as ASSIGNED nobody else will attempt to fix them, but then again perhaps nobod is working on them and nobody will actally have the time to work on them on the current sprint, being postponed when perhaps someone else would have taken them. A more accurate approach would be to set those bugs to Highest priority in order to identify them for the current sprint. This is less than Immediate (something requiring immediate action) and more than High (something important, perhaps for the next sprint). -- 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] Nobody Wikidata bugs: notify when you start working on a bug
On Fri, Dec 7, 2012 at 6:08 PM, Quim Gil q...@wikimedia.org wrote: Then those ASSIGNED bugs are not really assigned. By setting as ASSIGNED nobody else will attempt to fix them, but then again perhaps nobod is working on them and nobody will actally have the time to work on them on the current sprint, being postponed when perhaps someone else would have taken them. Yes the whole point of that exercise is among other things to make sure no-one else takes them. There are a lot of bugs that people can work on if they wish. There are even over 50 of them marked as need-volunteer explicitly. A more accurate approach would be to set those bugs to Highest priority in order to identify them for the current sprint. This is less than Immediate (something requiring immediate action) and more than High (something important, perhaps for the next sprint). See above. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Nobody Wikidata bugs: notify when you start working on a bug
Ok, so this discussion can be summarized this way: If assigning a bug to the developer that is working on it takes less than 5 extra seconds, please do it. If it takes more than 5 extra seconds, don't bother. Deal? :) -- 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] Nobody Wikidata bugs: notify when you start working on a bug
On Fri, Dec 7, 2012 at 6:19 PM, Quim Gil q...@wikimedia.org wrote: Ok, so this discussion can be summarized this way: If assigning a bug to the developer that is working on it takes less than 5 extra seconds, please do it. If it takes more than 5 extra seconds, don't bother. Deal? :) Deal ;-) -- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Link how to install media wiki from git on MAC
Can anyone give the link how to install mediawiki from git on MAC OSX ? Thanks in advance Harsh --- Harsh Kothari Research Fellow, Physical Research Laboratory(PRL). Ahmedabad. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] xml csv : uploading and handling
On Dec 7, 2012 7:16 AM, Platonides platoni...@gmail.com wrote: On 07/12/12 16:05, dan wrote: hey all, i’m working on an extension that will depend on the upload of xml and csv data files. i need some advice on how to best upload those data file types and then process them. any guidance on how to do this within the mediawiki framework would be greatly appreciated. the end goal is that the extension will run within http://commons.wikimedia.org. here are some initial thoughts/questions : 1. i’ve been looking at how SpecialUpload.php and UploadBase.php work together, but found that i need to override $wgMimieTypeBlacklist’s value of 'text/html' and make sure $wgDisableUploadScriptChecks is set to true in order for UploadBase.php to accept an xml file and i’m still figuring out what needs to be overridden or adjusted in order to accept a csv file. a. is this the recommended path to being able to upload these file types? i. if so, is there a manual that guides one through how to implement this? ii. if not, what is the recommended path? The problem with overriding the blacklist is that some evil users could upload html, which then runs javascript and hijacks the user accounts. If your xml is different enough than html, it should be possible to detect them with their type, instead of skipping the html blacklist. Uploading arbitrary xml to commons is definitly something that can open up security holes fast. For this extension to run there, you would need pretty extensive whitelisting of the xml. You may have better luck with csv. 2. the idea for the form is that after selecting the file, pressing the submit button would asynchronously upload the data file. a. how can this best be accomplished? b. any current documentation on how to do this besides code itself? Just use the normal upload process, such as the UploadWizard ? 3. the files would then be stored and versioned. a. what is the best way to then store those file types for versioning? The wiki automatically versions the files. 4. then a batch process id would be created and have a logging process that would allow the original uploader to view the progress of working on the uploaded data. a. how can this best be accomplished? b. any current documentation on how to do this besides code itself? Some special page, perhaps. I think there may be something similar with videos, where a job is created to transcode them, but I don't think there's an interface to view the process of working on that. You will have to create your own SpecialPage. ___ 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] Link how to install media wiki from git on MAC
Though I generally do not recommend it, you can find OSX setup instructions here: http://www.mediawiki.org/wiki/Manual:Running_MediaWiki_on_Mac_OS_X Cheers, Rob On Fri, Dec 7, 2012 at 9:24 AM, Harsh Kothari harshkothari...@gmail.comwrote: Can anyone give the link how to install mediawiki from git on MAC OSX ? Thanks in advance Harsh --- Harsh Kothari Research Fellow, Physical Research Laboratory(PRL). Ahmedabad. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Rob Moen Wikimedia Foundation rm...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Link how to install media wiki from git on MAC
Thanks for your reply Rob. But why you do bot recommended? and so Linux is the best way? Thanks Harsh --- Harsh Kothari Research Fellow, Physical Research Laboratory(PRL). Ahmedabad. On 07-Dec-2012, at 11:28 PM, Rob Moen wrote: Though I generally do not recommend it, you can find OSX setup instructions here: http://www.mediawiki.org/wiki/Manual:Running_MediaWiki_on_Mac_OS_X Cheers, Rob On Fri, Dec 7, 2012 at 9:24 AM, Harsh Kothari harshkothari...@gmail.comwrote: Can anyone give the link how to install mediawiki from git on MAC OSX ? Thanks in advance Harsh --- Harsh Kothari Research Fellow, Physical Research Laboratory(PRL). Ahmedabad. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Rob Moen Wikimedia Foundation rm...@wikimedia.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
[Wikitech-l] Unit tests scream for attention
Now that tests need +2 to be run, at least temporarily, I'm going to point out that I've not been able to run tests on my development environment in ages. I mentioned broken unit tests in Oct 4 on this list. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/64390 There are multiple fatal bugs (not to mention the numerous test failures), that halt test runs without any info expect the error. Some bugs I've reported: * https://bugzilla.wikimedia.org/41491 * https://bugzilla.wikimedia.org/42145 (skip the first few comments) Today I tried again and there is new one: Catchable fatal error: Argument 2 passed to OutputPage::addWikiTextTitle() must be an instance of Title, null given, called in /www/dev.translatewiki.net/w/includes/OutputPage.php on line 1426 and defined in /www/dev.translatewiki.net/w/includes/OutputPage.php on line 1472 This might be just a variant of 42145, but I can't tell for sure. I could add exception there, but the other fatal errors make phpunit not to display backtraces. I haven't yet had time to try to find out which test it is. This situation is starting to feel like a bad horror movie, so I ask everyone to give some tender, love and care to our unit tests so that I don't have to come up with even worse analogies. -Niklas -- Niklas Laxström ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Link how to install media wiki from git on MAC
It depends on what you're trying to do with it. If you're looking to create a local test bed to experiment with, there's no reason it has to be particularly complex: just download and run MAMP, create a directory in MAMP's htdocs, then do a normal git clone and follow the usual install instructions (this is assuming you've already installed git). This is also laid out at the bottom of the article Rob linked. If you're looking to create a working site (ie, something you want to share with others and not just experiment with), then yes, it's a bit more complex, but still not too bad, in particular if you have your Mac already set up to act as a server. Don't feel overwhelmed by the link Rob posted -- most of the length and complexity of the article is because it's covering details going back to OS X 10.2. Nabil On Fri, Dec 7, 2012 at 10:02 AM, Harsh Kothari harshkothari...@gmail.comwrote: Thanks for your reply Rob. But why you do bot recommended? and so Linux is the best way? Thanks Harsh --- Harsh Kothari Research Fellow, Physical Research Laboratory(PRL). Ahmedabad. On 07-Dec-2012, at 11:28 PM, Rob Moen wrote: Though I generally do not recommend it, you can find OSX setup instructions here: http://www.mediawiki.org/wiki/Manual:Running_MediaWiki_on_Mac_OS_X Cheers, Rob On Fri, Dec 7, 2012 at 9:24 AM, Harsh Kothari harshkothari...@gmail.com wrote: Can anyone give the link how to install mediawiki from git on MAC OSX ? Thanks in advance Harsh --- Harsh Kothari Research Fellow, Physical Research Laboratory(PRL). Ahmedabad. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Rob Moen Wikimedia Foundation rm...@wikimedia.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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla upgrade [was: bugzilla.wikimedia.org downtime: Now.]
On Sat, Dec 8, 2012 at 12:29 AM, Andre Klapper aklap...@wikimedia.org wrote: So the aim of the patch was to completely omit bugmail in case of CC list only changes, in order to make IRC + wikibugs-l@ less noisy? ... In any case, I'd like to challenge reapplying this patch, because: 1) Don't set wikibugs-l@ as globalwatchers if you don't want it to receive all bugmail about all changes. 2) If you want a certain account to not receive email in case of changing X in Bugzilla, edit the accounts's when to send mail settings in Bugzilla to not to send bugmail in case of only changing X. Obviously this interferes with 1) currently. Wikibugs-l is for technical people that follow it for the bug information, not for Joe Blogs [added/removed] himself from CC and CCing doesn't provide any information that is needed for that list, That is why its hacked out. Wikibugs not receiving it is a bonus since it just reads the wikibugs email list and spits it out. Global watcher is the best option for what we want, Because it always covers the bugs and the only other option really is rely on wikibugs-l being added to the cc list which wasn't a reliable method at all (was used before GW was enabled/present). Can you propose a better option for this than defaulting the cc'er as wikibugs? I doub't there are that that many people that want the wikibugs-l list to receive a copy of every single change (Eg: cc changes) to the bug, But that is probably a discussion for another thread. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Unit tests scream for attention
Le 07/12/12 19:13, Niklas Laxström a écrit : Now that tests need +2 to be run, at least temporarily, I'm going to point out that I've not been able to run tests on my development environment in ages. I mentioned broken unit tests in Oct 4 on this list. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/64390 There are multiple fatal bugs (not to mention the numerous test failures), that halt test runs without any info expect the error. snip Hello Niklas, I will be more than happy to help you track down the root cause of such failures. It seems your setup has lot of extensions loaded in and most probably a non default LocalSettings.php. To track the issue down you could start by disabling all extensions and see how it goes, then enable extension one by one and rerun tests in between. Same goes for settings, try out with a fresh install of just MediaWiki core then add the settings one by one and see what happens. cheers, -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla upgrade [was: bugzilla.wikimedia.org downtime: Now.]
On Fri, Dec 7, 2012 at 9:29 AM, Andre Klapper aklap...@wikimedia.org wrote: On Wed, 2012-12-05 at 00:29 +0100, Andre Klapper wrote: On Tue, 2012-12-04 at 14:53 -0500, Chad wrote: On Tue, Dec 4, 2012 at 2:44 PM, Andre Klapper aklap...@wikimedia.org wrote: The only (potential) regression is that we did not apply previous changes to Bugmail.pm, described as Wikimedia Hack! Pretend global watchers are CCs so we can use their prefs to for instance ignore CC-only mails. Is there a reason for this? We had this hack in place to keep BZ from spamming IRC/wikibugs-l when only the CC list changes... So the aim of the patch was to completely omit bugmail in case of CC list only changes, in order to make IRC + wikibugs-l@ less noisy? 1) I assume this silently broke The CC field changes settings on https://bugzilla.wikimedia.org/userprefs.cgi?tab=email for everybody in the past. Assume because my time machine back to 4.0.9 is broken. 2) wikibugs-l@ is also set as globalwatchers (who should receive a copy of every notification mail Bugzilla sends). After the Bugzilla upgrade wikibugs-l@ *finally* works reliably for me and seems to send ALL bugmail. Before I didn't receive bugmail anymore after wikibugs-l@ got removed as assignee of a report when wikibugs-l@ was not listed either as default CC of the corresponding component (test example: bug 42226). I don't know how your preferences were configured, but our hack has worked as expected for years. The logic only happens to @watchers[0], and all it does is set the default CC param for the global watch user. No actual user preferences should be changed. -Chad [0] https://gerrit.wikimedia.org/r/gitweb?p=wikimedia/bugzilla/modifications.git;a=blob;f=bugzilla-4.0/Bugzilla/BugMail.pm;h=28f378ba80c7bbc91fe29b47e0ae0eb862e900b9;hb=99319f78d16bc15ef5bfa63135a95df5a102739d#l366 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla upgrade [was: bugzilla.wikimedia.org downtime: Now.]
On Fri, Dec 7, 2012 at 2:50 PM, K. Peachey p858sn...@gmail.com wrote: On Sat, Dec 8, 2012 at 12:29 AM, Andre Klapper aklap...@wikimedia.org wrote: So the aim of the patch was to completely omit bugmail in case of CC list only changes, in order to make IRC + wikibugs-l@ less noisy? ... In any case, I'd like to challenge reapplying this patch, because: 1) Don't set wikibugs-l@ as globalwatchers if you don't want it to receive all bugmail about all changes. 2) If you want a certain account to not receive email in case of changing X in Bugzilla, edit the accounts's when to send mail settings in Bugzilla to not to send bugmail in case of only changing X. Obviously this interferes with 1) currently. Wikibugs-l is for technical people that follow it for the bug information, not for Joe Blogs [added/removed] himself from CC and CCing doesn't provide any information that is needed for that list, That is why its hacked out. Wikibugs not receiving it is a bonus since it just reads the wikibugs email list and spits it out. Global watcher is the best option for what we want, Because it always covers the bugs and the only other option really is rely on wikibugs-l being added to the cc list which wasn't a reliable method at all (was used before GW was enabled/present). Can you propose a better option for this than defaulting the cc'er as wikibugs? I doub't there are that that many people that want the wikibugs-l list to receive a copy of every single change (Eg: cc changes) to the bug, But that is probably a discussion for another thread. This. We've had this working for years as-is, and I don't see any consensus to change it (as long as it's continuing to work as expected). -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Unit tests scream for attention
On Fri, Dec 7, 2012 at 1:13 PM, Niklas Laxström niklas.laxst...@gmail.com wrote: There are multiple fatal bugs (not to mention the numerous test failures), that halt test runs without any info expect the error. Some bugs I've reported: * https://bugzilla.wikimedia.org/41491 While that unit test mentioned there does seem screwed up, why is your PHPUnit installation not respecting convertErrorsToExceptions=true and related settings in MediaWiki's provided suite.xml? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Announcement: Matthew Flaschen joins Wikimedia as Features Engineer
Hello everyone, It’s with great pleasure that I’m announcing that Matthew Flaschen has joined the Wikimedia Foundation as a Features Engineer. Before joining us, Matthew was working at Entech Consulting doing a whole bunch of web-projects from electricity utility sites to a cell phone store. He received his B.S. in Computer Science as recently as December 2010 from Georgia Tech. At Georgia Tech, he was the lead developer of the ProveIt[1] Gadget which is live on English Wikipedia which is “probably the most advanced and easy-to-use referencing tool available to editors.” He’s also been a Wikipedia editor ([[User:Superm401]]) since 2004 and administrator since 2006. He hit the ground running with the Experimentation team so fast that he was still being interviewed when one of the team members wrote: “his integration with the team has been so seamless that I’ve to remind myself a few times that he is not yet a bona-fide employee.” His first official day actually was on December 3rd because my team pressured me to start paying him. :-) He is working with the Experimentation team on extensions (such as Onboarding[2]) and core functionality. Beyond that he’s very interested in using tools to improve our development process, so I won’t be surprised if Ori steals him so they can Pinky-and-the-Brain other projects at the WMF. Matt lives in Philadelphia. He will be working remotely, but is working in San Francisco all next week (starting Monday the 10th). Please join me in a belated welcome of Matthew Flaschen to the Wikimedia Foundation. :-) Take care, terry [1]: http://proveit.cc.gatech.edu/ [2]: https://www.mediawiki.org/wiki/Onboarding_new_Wikipedians terry chay 최태리 Director of Features Engineering Wikimedia Foundation “Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment.” p: +1 (415) 839-6885 x6832 m: +1 (408) 480-8902 e: tc...@wikimedia.org i: http://terrychay.com/ w: http://meta.wikimedia.org/wiki/User:Tychay aim: terrychay ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] slight change to the review workflow in Gerrit
Le 07/12/12 04:56, Sébastien Santoro wrote snip This is very disturbing when browsing Gerrit for revisions still to review and doesn't really give any useful information (as the important information here would be the verified -1). Lets open the can of worm here :) Chad came up with another idea that would be to rename Verified to Automatic Tests and extends it to a range of -2 .. +2 where +1 will be lint ok and +2 unit tests ok. Not sure how feasible it is to tweak Gerrit this way though. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Unit tests scream for attention
On 7 December 2012 22:51, Brad Jorsch bjor...@wikimedia.org wrote: While that unit test mentioned there does seem screwed up, why is your PHPUnit installation not respecting convertErrorsToExceptions=true and related settings in MediaWiki's provided suite.xml? I honestly don't know. I barely got working PHPUnit installed in the first place (3.7.8 - see my other previous phpunit thread). I also don't know why it occasionally segfaults. -Niklas -- Niklas Laxström ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] slight change to the review workflow in Gerrit
On Fri, Dec 7, 2012 at 4:19 PM, Antoine Musso hashar+...@free.fr wrote: Le 07/12/12 04:56, Sébastien Santoro wrote snip This is very disturbing when browsing Gerrit for revisions still to review and doesn't really give any useful information (as the important information here would be the verified -1). Lets open the can of worm here :) Chad came up with another idea that would be to rename Verified to Automatic Tests and extends it to a range of -2 .. +2 where +1 will be lint ok and +2 unit tests ok. Not sure how feasible it is to tweak Gerrit this way though. It shouldn't be hard--just two SQL queries to adjust the review labels -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] slight change to the review workflow in Gerrit
On 12/07/2012 04:19 PM, Antoine Musso wrote: Le 07/12/12 04:56, Sébastien Santoro wrote snip This is very disturbing when browsing Gerrit for revisions still to review and doesn't really give any useful information (as the important information here would be the verified -1). Lets open the can of worm here :) Chad came up with another idea that would be to rename Verified to Automatic Tests and extends it to a range of -2 .. +2 where +1 will be lint ok and +2 unit tests ok Should there be a separate label for human testing and verification (as opposed to Code Review, which could just mean after visual review, the code looks right)? Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Announcement: Matthew Flaschen joins Wikimedia as Features Engineer
On 7 December 2012 13:06, Terry Chay tc...@wikimedia.org wrote: Please join me in a belated welcome of Matthew Flaschen to the Wikimedia Foundation. :-) Welcome aboard, Matt! Excited to be working alongside you. 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] Announcement: Matthew Flaschen joins Wikimedia as Features Engineer
Welcome Matt! Philadelphia \o/ On Fri, Dec 7, 2012 at 5:02 PM, James Forrester jforres...@wikimedia.orgwrote: On 7 December 2012 13:06, Terry Chay tc...@wikimedia.org wrote: Please join me in a belated welcome of Matthew Flaschen to the Wikimedia Foundation. :-) Welcome aboard, Matt! Excited to be working alongside you. 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Announcement: Matthew Flaschen joins Wikimedia as Features Engineer
Welcome Matt. Subbu (work remotely from Minneapolis). Welcome Matt! Philadelphia \o/ On Fri, Dec 7, 2012 at 5:02 PM, James Forrester jforres...@wikimedia.orgwrote: On 7 December 2012 13:06, Terry Chay tc...@wikimedia.org wrote: Please join me in a belated welcome of Matthew Flaschen to the Wikimedia Foundation. :-) Welcome aboard, Matt! Excited to be working alongside you. J. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Announcement: Matthew Flaschen joins Wikimedia as Features Engineer
I was really excited when I heard we were interviewing the ProveIt guy, and Matt certainly didn't disappoint :) Welcome aboard, Matt, and looking forward to meeting you IRL next week! On Fri, Dec 7, 2012 at 2:08 PM, Dan Andreescu dandree...@wikimedia.orgwrote: Welcome Matt! Philadelphia \o/ On Fri, Dec 7, 2012 at 5:02 PM, James Forrester jforres...@wikimedia.org wrote: On 7 December 2012 13:06, Terry Chay tc...@wikimedia.org wrote: Please join me in a belated welcome of Matthew Flaschen to the Wikimedia Foundation. :-) Welcome aboard, Matt! Excited to be working alongside you. 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Maryana Pinchuk Associate Product Manager, Wikimedia Foundation wikimediafoundation.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Announcement: Matthew Flaschen joins Wikimedia as Features Engineer
On 12/07/2012 01:06 PM, Terry Chay wrote: Hello everyone, It’s with great pleasure that I’m announcing that Matthew Flaschen has joined the Wikimedia Foundation as a Features Engineer. Before joining us, Matthew was working at Entech Consulting doing a whole bunch of web-projects from electricity utility sites to a cell phone store. He received his B.S. in Computer Science as recently as December 2010 from Georgia Tech. At Georgia Tech, he was the lead developer of the ProveIt[1] Gadget which is live on English Wikipedia which is “probably the most advanced and easy-to-use referencing tool available to editors.” He’s also been a Wikipedia editor ([[User:Superm401]]) since 2004 and administrator since 2006. He hit the ground running with the Experimentation team so fast that he was still being interviewed when one of the team members wrote: “his integration with the team has been so seamless that I’ve to remind myself a few times that he is not yet a bona-fide employee.” His first official day actually was on December 3rd because my team pressured me to start paying him. :-) He is working with the Experimentation team on extensions (such as Onboarding[2]) and core functionality. Beyond that he’s very interested in using tools to improve our development process, so I won’t be surprised if Ori steals him so they can Pinky-and-the-Brain other projects at the WMF. Matt lives in Philadelphia. He will be working remotely, but is working in San Francisco all next week (starting Monday the 10th). Please join me in a belated welcome of Matthew Flaschen to the Wikimedia Foundation. :-) Take care, terry [1]: http://proveit.cc.gatech.edu/ [2]: https://www.mediawiki.org/wiki/Onboarding_new_Wikipedians terry chay 최태리 Wow, we got the lead dev for ProveIt! That's so great! I welcome Matthew to the Wikimedia Foundation. -- 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] Announcement: Matthew Flaschen joins Wikimedia as Features Engineer
On 12/07/2012 05:02 PM, James Forrester wrote: On 7 December 2012 13:06, Terry Chay tc...@wikimedia.org wrote: Please join me in a belated welcome of Matthew Flaschen to the Wikimedia Foundation. :-) Welcome aboard, Matt! Excited to be working alongside you. Thanks! I look forward to meeting you in person sometime. Matt ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Announcement: Matthew Flaschen joins Wikimedia as Features Engineer
On 12/07/2012 05:19 PM, Maryana Pinchuk wrote: I was really excited when I heard we were interviewing the ProveIt guy, and Matt certainly didn't disappoint :) Thanks! I should also give credit to everyone that's worked on ProveIt, though. Besides me: * Kurt Luther * Terris Jordan * Prof. Amy Bruckman * Prof. Andrea Forte * Christopher Jordan http://proveit.cc.gatech.edu/about/team Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Sul on external Scripts
Hi, I know it is technically possible to use the SUL account outside of Wikimedia-Projects. We heard, that it is not very much liked to use this possibility. Maybe somebody of you could tell us if that is so and maybe why? Cheers, Marco ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sul on external Scripts
Are you referring to using Wikimedia CentralAuth accounts to auth against other provider wiki sites? Or using your own CentralAuth setup for your site(s)? On Sat, Dec 8, 2012 at 9:07 AM, Marco Fleckinger marco.fleckin...@wikipedia.at wrote: Hi, I know it is technically possible to use the SUL account outside of Wikimedia-Projects. We heard, that it is not very much liked to use this possibility. Maybe somebody of you could tell us if that is so and maybe why? Cheers, Marco ___ 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] Proposal: MediaWiki Groups
After some valuable feedback from the Affiliations Committee and others, plus a big wave of silent approval... https://www.mediawiki.org/wiki/User:Qgil/MediaWiki_groups Feedback welcome again. As soon as we get consensus here and the green light from the AffCom we will move the page to its official location. Now, essentially: MediaWiki Group = Wikimedia User Group + MediaWiki extension Such extension is just a set of extra rules of coordination within the MediaWiki community: * Defined name schema: MediaWiki _something_ Group. * Defined location of proposals. * Discussion period in main MW mailing list. * Defined location of main pages groups approved. * Recommended: endorsement from MW maintainers or WMF devs. The big change is located in the way a new group is created: https://www.mediawiki.org/w/index.php?title=User%3AQgil%2FMediaWiki_groupsdiff=614316oldid=614298 And we have moved away the idea of MediaWiki reps. We will deal with that separately, with Wikimedia coordination (if there is an ongoing discussion about this topic) or not. How does this look like now? And now the fun part: IF you are reading these lines AND you are interested creating a group just put your betatesting shirt on and head to https://www.mediawiki.org/wiki/Groups/Proposals/(((myGroup))) Without MediaWiki or Group, as in https://www.mediawiki.org/wiki/Groups/Proposals/Lua https://www.mediawiki.org/wiki/Groups/Proposals/Bangalore etc Start editing and reply to this thread in wikitech-l. You will help us fine tuning this process while it's being setup and we will help you becoming one of the first MediaWiki groups ever. Deal? On 11/29/2012 04:50 PM, Quim Gil wrote: Hi, here you have a first draft about MediaWiki Groups, and implicitly MediaWiki reps: http://www.mediawiki.org/wiki/User:Qgil/MediaWiki_groups MediaWiki groups organize open source community activities within the scope of specific topics and geographical areas. They extend the capacity of the Wikimedia Foundation in events, training, promotion and other technical activities benefiting Wikipedia, the Wikimedia movement and the MediaWiki software. Imagine MediaWiki Germany Group, MediaWiki Lua Group... These groups may become a significant source of growth and wider diversity of our community. Please bring your ideas to the discussion page - or here. Thank you! -- 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] Sul on external Scripts
No I'm asking of using Wikimedia's CentralAuth using in our tools. On 08/12/12 00:23, K. Peachey wrote: Are you referring to using Wikimedia CentralAuth accounts to auth against other provider wiki sites? Or using your own CentralAuth setup for your site(s)? On Sat, Dec 8, 2012 at 9:07 AM, Marco Fleckinger marco.fleckin...@wikipedia.at wrote: Hi, I know it is technically possible to use the SUL account outside of Wikimedia-Projects. We heard, that it is not very much liked to use this possibility. Maybe somebody of you could tell us if that is so and maybe why? Cheers, Marco ___ 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] [ee] Announcement: Matthew Flaschen joins Wikimedia as Features Engineer
welcome to the team, you're jumping in at a pretty awesome time. talk soon On Fri, Dec 7, 2012 at 2:30 PM, Dario Taraborelli dtarabore...@wikimedia.org wrote: welcome Matt, I'm excited to have you onboard with E3. I'm a huge fan of ProveIt and have a secret plan to make it totally obsolete ;) Chat next week? Dario On Dec 7, 2012, at 1:06 PM, Terry Chay tc...@wikimedia.org wrote: Hello everyone, It’s with great pleasure that I’m announcing that Matthew Flaschen has joined the Wikimedia Foundation as a Features Engineer. Before joining us, Matthew was working at Entech Consulting doing a whole bunch of web-projects from electricity utility sites to a cell phone store. He received his B.S. in Computer Science as recently as December 2010 from Georgia Tech. At Georgia Tech, he was the lead developer of the ProveIt[1] Gadget which is live on English Wikipedia which is “probably the most advanced and easy-to-use referencing tool available to editors.” He’s also been a Wikipedia editor ([[User:Superm401]]) since 2004 and administrator since 2006. He hit the ground running with the Experimentation team so fast that he was still being interviewed when one of the team members wrote: “his integration with the team has been so seamless that I’ve to remind myself a few times that he is not yet a bona-fide employee.” His first official day actually was on December 3rd because my team pressured me to start paying him. :-) He is working with the Experimentation team on extensions (such as Onboarding[2]) and core functionality. Beyond that he’s very interested in using tools to improve our development process, so I won’t be surprised if Ori steals him so they can Pinky-and-the-Brain other projects at the WMF. Matt lives in Philadelphia. He will be working remotely, but is working in San Francisco all next week (starting Monday the 10th). Please join me in a belated welcome of Matthew Flaschen to the Wikimedia Foundation. :-) Take care, terry [1]: http://proveit.cc.gatech.edu/ [2]: https://www.mediawiki.org/wiki/Onboarding_new_Wikipedians terry chay 최태리 Director of Features Engineering Wikimedia Foundation “Imagine a world in which every single human being can freely share in the sum of all knowledge.* That's our commitment.*” p: +1 (415) 839-6885 x6832 m: +1 (408) 480-8902 e: tc...@wikimedia.org i: http://terrychay.com/ w: http://meta.wikimedia.org/wiki/User:Tychay aim: terrychay ___ ee mailing list e...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee ___ ee mailing list e...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee -- Ryan Faulkner Research Analyst - Editor Engagement Experimentation (e3) Wikimedia Foundation mobile: (415) 793-5086 office: (415) 839-6885 ext 6726 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sul on external Scripts
Yes, we need that. Toys like TUSC should be replaced by scalable and correct stuff at middle term. But this is not currently one of the top priority, so we also need people to implement it, maintain it. This is not only a development issue (I wouldn't be surprise if the current OAuth providers extensions would be virtually mature) but a strong support and integration work afterwards. You need to prepare something like an OAuth2 provider infrastructure to ask the user's Wikimedia home project to do authentication and submit your tool the appropriated result. Please note somewhere your proposal, and if possible, what and who you need to make it real. On Sat, Dec 8, 2012 at 12:33 AM, Marco Fleckinger marco.fleckin...@wikipedia.at wrote: No I'm asking of using Wikimedia's CentralAuth using in our tools. On 08/12/12 00:23, K. Peachey wrote: Are you referring to using Wikimedia CentralAuth accounts to auth against other provider wiki sites? Or using your own CentralAuth setup for your site(s)? On Sat, Dec 8, 2012 at 9:07 AM, Marco Fleckinger marco.fleckin...@wikipedia.at wrote: Hi, I know it is technically possible to use the SUL account outside of Wikimedia-Projects. We heard, that it is not very much liked to use this possibility. Maybe somebody of you could tell us if that is so and maybe why? Cheers, Marco ___ 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 -- Sébastien Santoro aka Dereckson http://www.dereckson.be/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sul on external Scripts
Hi, actually it would be for a WLM-project we want do extend. This is a bit higher priorized, because it will not be such a big deal. In the meantime we could use the old stuff authentication or TUSC in our project. While doing that – why not working on such a proposal. I could do some tests and then develop a concept to decide wheather to implement it or not. @Alex: Sorry somebody forgot to reply to all. On 08/12/12 01:11, Sébastien Santoro wrote: Yes, we need that. Toys like TUSC should be replaced by scalable and correct stuff at middle term. But this is not currently one of the top priority, so we also need people to implement it, maintain it. This is not only a development issue (I wouldn't be surprise if the current OAuth providers extensions would be virtually mature) but a strong support and integration work afterwards. You need to prepare something like an OAuth2 provider infrastructure to ask the user's Wikimedia home project to do authentication and submit your tool the appropriated result. Please note somewhere your proposal, and if possible, what and who you need to make it real. On Sat, Dec 8, 2012 at 12:33 AM, Marco Fleckinger marco.fleckin...@wikipedia.at wrote: No I'm asking of using Wikimedia's CentralAuth using in our tools. On 08/12/12 00:23, K. Peachey wrote: Are you referring to using Wikimedia CentralAuth accounts to auth against other provider wiki sites? Or using your own CentralAuth setup for your site(s)? On Sat, Dec 8, 2012 at 9:07 AM, Marco Fleckinger marco.fleckin...@wikipedia.at wrote: Hi, I know it is technically possible to use the SUL account outside of Wikimedia-Projects. We heard, that it is not very much liked to use this possibility. Maybe somebody of you could tell us if that is so and maybe why? Cheers, Marco ___ 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] Sul on external Scripts
What the WMF is looking at for stuff like that is becoming a OpenID provider so services and tools can act as Consumers, But that is some way away currently. Ryan would be the one to poke about that iirc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Open Tech Talk next Thursday, December 13
Hi everyone, We're planning to have another of our weekly tech talks next Thursday, December 13. Timing and participation details are here: http://www.mediawiki.org/wiki/Meetings/2012-12-13 Our one confirmed topic for next week is an update on browser test automation. Chris McMahon and Željko Filipin will be demonstrating the work that they've been doing, and what you can do to pitch in. Chris will send some more details next week on the topic. If you have other topics that you'd like to lead a discussion and/or prepare a demo for, let me know so I can slot you in. Thanks! Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
