Wikitech-l September 2014

129 participants
127 discussions

People with knowledge of English swear words needed :o
by Petr Bena 20 Nov '14

20 Nov '14

Are you good in swearing? WE NEED YOU Huggle 3 comes with vandalism-prediction as it is precaching the diffs even before they are enqueued including their contents. Each edit has so called "score" which is a numerical value that if higher, the edit is more likely a vandalism. If you want to help us improve this feature, it is necessary to define a "score words" list for every wiki where huggle is about to be used, for example on English wiki. Each list has following syntax: (see https://en.wikipedia.org/w/index.php?title=Wikipedia:Huggle/Config&diff=573…) score-words(score): list of words separated by comma, can contain newlines but comma must be present example score-words(200): these, are, some, words, which, presence, of, increases, the, score, each, word, by, 200, So, if you know english better than me, which you likely do, go ahead and improve the configuration file there, no worries, huggle's config parser is very syntax-error proof. If you have any other suggestion how to improve huggle's prediction, go ahead and tell us!

8 8

third-party icon sets
by Ricordisamoa 26 Oct '14

26 Oct '14

Are there policies/guidelines regarding the use of third-party icons in software maintained on WMF's Gerrit instance (e.g. MediaWiki extensions)? For example, the Chameleon <https://www.mediawiki.org/wiki/Skin:Chameleon> skin appears to use Glyphicons <http://glyphicons.com>, whose license <http://glyphicons.com/license/> is not very clear. Even if it uses them as part of the Twitter Bootstrap, is it legal/fair to embed a piece of software (Glyphicons) that cannot be used freely without another piece (Bootstrap)? Even git.wikimedia.org <https://git.wikimedia.org> uses Glyphicons (the free PNG version) without complying with the CC-BY 3.0 license. Wouldn't it be better to use a really /free/ icon set (such as Font-Awesome <https://fortawesome.github.io/Font-Awesome/> or Elusive Icons <http://shoestrap.org/downloads/elusive-icons-webfont/>) instead?

5 6

Meet-up at WMF: Exploratory Testing for Complex Software, Oct 22 2014
by Arthur Richards 22 Oct '14

22 Oct '14

On Wednesday, October 22, 2014 the Quality Assurance Group and Team Practices Group hope you will join us for a meet-up at the WMF entitled 'Exploratory Testing for Complex Software; Lessons from Cloud Foundry' with special guest speaker Elisabeth Hendrickson [1]. We will be discussing testing in agile iterative software development, and in particular exploratory testing <https://en.wikipedia.org/wiki/Exploratory_testing> [0]. This will be a lively and enlightening conversation, aimed at everyone concerned about the overall quality of software - even those who do not necessarily contribute code. *When*: Wednesday, October 22, 2014, 6:00pm - 8:30pm (for WMF folks there is a calendar event on the Engineering calendar) *Where*: Wikimedia Foundation 6th Floor, collab space 149 New Montgomery St. San Francisco, CA (Accessible for remote participation via Hangouts on Air; link TBA) *From the meet-up invite <http://www.meetup.com/wikimedia-tech/events/207856222/>*[2]: In modern software development organizations, the days are gone when separate, independent Quality Assurance departments test software only after it is finished. Iterative development and agile methods mean that software is constantly being created, tested, released, marketed, and used in short, tight cycles. An important testing approach in such an environment is called Exploratory Testing, and the Wikimedia Foundation has made significant investments to support Exploratory Testing for its software development projects. Elisabeth Hendrickson is "test obsessed". She was an early adopter and vocal proponent of all aspects of agile software testing. She has been particularly instrumental in encouraging and defining the practice of Exploratory Testing. Elisabeth's 2013 book "Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing" is the standard reference on the subject. Join us in the Wikimedia Foundation collaboration space to hear Elisabeth discuss her experience doing software testing for complex projects, with particular examples of Exploratory Testing from her current work as Director of Quality Engineering for Cloud Foundry. This talk is for everyone involved in the overall quality of software, and it will be of particular interest to Project Managers, Product Managers, and those working with software development projects who do not necessarily contribute code directly to the projects. [0] https://en.wikipedia.org/wiki/Exploratory_testing [1] Elisabeth Hendrickson is a tester, developer, and Agile enabler. She wrote her first line of code in 1980, and almost immediately found her first bug. In 2010 she won the prestigious Gordon Pask Award from the Agile Alliance. She is best known for her Google Tech Talk on Agile Testing as well as her wildly popular Test Heuristics Cheatsheet. In 2003, she learned how to do Agile for real from Pivotal Labs while working as a tester on one of their projects. In 2012 she decided it was time to take up permanent residence in the Pivotal offices, where she is the Director of Quality Engineering for Cloud Foundry, Pivotal's Open Source Platform as a Service (PaaS). [2] http://www.meetup.com/wikimedia-tech/events/207856222/ -- Arthur Richards Team Practices Manager [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687

4 6

Tor and Anonymous Users (I know, we've had this discussion a million times)
by Derric Atzrott 13 Oct '14

13 Oct '14

Hello everyone, I've been a Tor user for many years and I frequently make use of anonymising proxies services. Recently (yesterday), I set up my first Tor relay.[1] This has once again gotten the use of Tor and other anonymising services with Wikipedia on my mind again. In a recent article on the Tor blog,[2] Wikipedia is actually called out a number of times for being unfriendly to Tor, and I think they make a good point. "[H]ow can we quantify the loss to Wikipedia, and to society at large, from turning away anonymous contributors? Wikipedians say 'we have to blacklist all these IP addresses because of trolls' and 'Wikipedia is rotting because nobody wants to edit it anymore' in the same breath, and we believe these points are related." There must be a way that we can allow users to work from Tor. My understanding of why we block Tor categorically is that it is very hard to block individual Tor users. Perhaps we could allow Tor users to only edit pages if they make an account? That would allow us to at least block those accounts, which increases the cost of being problematic on Wikipedia a bit. Or to take from the blog post, perhaps Tor users could be issued a certificate that they could use to prove their identity from one session to another. New Tor users would need to prove they are the same person as someone we already trust or their edits would be put in some sort of review queue. Or combine the two and new accounts made from Tor connections would need to have their edits reviewed, or perhaps just wouldn't get autopatrolled status as quickly (if ever). There has got to be a better solution to the problem than just blocking all Tor users completely. Thank you, Derric Atzrott [1]: https://atlas.torproject.org/#details/6413D947D15B81B423D65D76DA3F2BFEF76BE… [2]: https://blog.torproject.org/blog/call-arms-helping-internet-services-accept… ymous-users

21 64

Registration Open: MediaWiki Developer Summit 2015
by Rachel Farrand 12 Oct '14

12 Oct '14

Hello! We are happy to announce the MediaWiki Developer Summit 2015, which will be taking place on January 26th and January 27th in San Francisco, California, USA. Registration is now open. Details about the MediaWiki Developer Summit 2015 and a link to the registration form can be found here: https://www.mediawiki.org/wiki/MediaWiki_Developer_Summit_2015 Hope to see you in San Francisco! Rachel

4 6

Wrapping signatures with a <span> for discoverability
by Erik Bernhardson 03 Oct '14

03 Oct '14

There is currently a patch in gerrit, https://gerrit.wikimedia.org/r/#/c/130094/ , that has been hanging around for a few months. To me it seems like an easy patch with some obvious benefits. JackMcbarn suggested this might need wider discussion/notice so putting it up here to get a little more visibility. Erik B.

12 15

State of the DumpHTML extension
by Daniel Friesen 02 Oct '14

02 Oct '14

The DumpHTML extension looks like it's in a pretty bad state, it doesn't work at all in the current version of MediaWiki. This seems to be an unfortunate symptom of how it's used and how it's treated by core developers. DumpHTML is most useful when someone is shutting down and archiving their wiki, so it doesn't get tested regularly. The act of creating a version of wiki pages suitable for offline use from static files is something which inherently requires different behaviour from things deep within core. Because DumpHTML has been segregated into an extension and core doesn't support an offline/dump mode internally DumpHTML has to use a bunch of hacks to make core behave properly during the dump. Then, because they are completely unaware of DumpHTML's needs, core developers make improvements to core that then break DumpHTML without providing it an alternative interface to get what it needs out of core. For one DumpHTML needs to proxy and mess with file repo behaviours. To do that it messed with properties like thumbScriptUrl, but then those properties were protected leaving DumpHTML unsupported. This was reported as a bug a month ago, which has gone relatively unnoticed: https://bugzilla.wikimedia.org/show_bug.cgi?id=69824 It also subclassed RepoGroup and since it proxied existing repo instances instead of working with repo info it had to bypass the __constructor. But then a $repoGroup->cache was added to the __constructor in core, breaking DumpHTML in another way. There are probably more issues that I haven't found yet while trying to workaround the other issues. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

5 4

Farewell
by Sumana Harihareswara 30 Sep '14

30 Sep '14

This is my last email to wikitech-l as a Wikimedia Foundation staffer; at some point in the future, after a long break, I may re-join as a volunteer. Thanks for the kind goodbyes you've sent me, publicly and privately, over the past few weeks. And thanks for the work you've done and continue to do, to help enable every human being to freely share in the sum of all human knowledge. I'll leave you with one of my favorite songs, "Somebody Will." http://www.sassafrassmusic.com/songs/sci-fi-fantasy-fandom/somebody-will/ Sumana Harihareswara Senior Technical Writer Wikimedia Foundation On Fri, Sep 12, 2014 at 12:09 PM, Sumana Harihareswara < sumanah(a)wikimedia.org> wrote: > I write this email with regret to let you know that I've decided to leave > the Wikimedia Foundation after nearly four years working here, and that my > last day will be 30 September. > > I go into my reasoning and plans in this personal blog post: > http://www.harihareswara.net/sumana/2014/09/12/0 > > I'm grateful for what I've learned here and will take these lessons > wherever I go. And I've made many friends here; thank you. I'll remain > [[User:Sumanah]] in any volunteer work I do onwiki. Quim Gil will be the > person to contact for any loose threads I leave behind; still, if you have > questions for me, the next two weeks would be a good time to ask them. > > best, > Sumana Harihareswara > was Volunteer Development Coordinator, then Engineering Community > Manager, now Senior Technical Writer > Wikimedia Foundation >

1 0

suggestions to reduce code review backlog
by Sumana Harihareswara 30 Sep '14

30 Sep '14

TL;DR: ask specific newish people to review specific changesets; pair program; nominate maintainers. I did a little poking-around in http://korma.wmflabs.org/ , especially http://korma.wmflabs.org/browser/gerrit_review_queue.html , and on Gerrit to check out our code review situation, although of course more people's spot analysis or systematic assessments would be welcome. It seems we have somewhat more committers and commits than a year ago (yay!) but not more than, say, 10% more. Some hypotheses that I was unable to prove or disprove: * that there's been a freak spike in backlogged work * that HHVM or some other project is soaking up the review times of people who used to do a lot of general MediaWiki code review But I will note that the group of people with +2 access in MediaWiki core https://gerrit.wikimedia.org/r/#/admin/groups/11,members has fewer people outside WMF/WMDE than it used to. (I remember when there were ~13 and now there are ~8.) And, although we have many praiseworthy exceptions, there's a tendency for WMF staff and contractors to -- legitimately -- concentrate on writing and reviewing the code they're paid to work on (I presume it's the same for WMDE), and thus to make less time for reviewing code outside of those projects. On the interiority of becoming a reviewer: Here is a bit of a digression on capacity-building. Back when I was volunteer development coordinator, I thought my two biggest jobs were: 1) creating processes that scale, and 2) inculcating empathy in others. Both of these come into play in increasing code review capacity. An open process like https://www.mediawiki.org/wiki/Gerrit/Project_ownership scales better than a cliquey "oh hey maybe you should have merge rights" does. But we also have to grow new contributors into habitual reviewers, which means we have to get inside the heads of developers who currently aren't in the habit of offering reviews. One useful approach is the pathway to inclusion http://infotrope.net/2014/08/12/the-pathway-to-inclusion/ : 1) Awareness: “I’ve heard of this thing.” 2) Understanding: "I understand what this is about." 3) Identification: “I can see myself doing this.” 4) Access: "I can physically, logistically, and financially do this." 5) Belonging: "I feel like I fit in here." 6) Ownership: "I care enough to take responsibility for this." During my time at WMF I saw that many people needed help with all six of those steps in order to start reviewing code, to broaden the scope of what they reviewed, and to ask for maintainership rights. Informative email blasts and wiki pages could only do so much; to cross some chasms, people need personal invitation, one-on-one reassurance and encouragement, and private misconception-clearing. Recommendations: * If you review code, you can help by poking through Gerrit with imaginative searches https://gerrit.wikimedia.org/r/Documentation/user-search.html and adding reviewers to changesets, focusing on people who don't review as much as they write. And follow up with email to them pointing them to https://www.mediawiki.org/wiki/Gerrit/Code_review and reminding them that all reviews help, that this is totally something they could do. * Pair programming, pairing a newer developer with a reviewer, will also help with the backlog (the person you pair with can review you pretty fast!), and with awareness, understanding, and identification. For more see my 15 September email https://lists.wikimedia.org/pipermail/wikitech-l/2014-September/078627.html . * Nominate people to maintain repositories. Including yourself. https://www.mediawiki.org/wiki/Gerrit/Project_ownership Hope this helps. Sumana Harihareswara Senior Technical Writer Wikimedia Foundation

1 0

Removal of Scribunto's "Allow saving code with errors" option
by Jackmcbarn 30 Sep '14

30 Sep '14

Scribunto has an option to allow code to be saved even if it contains syntax errors that prevent it from ever working. The original reason for this feature was to make it more convenient to save incomplete code. However, in practice, this has never been used for its intended purpose, and users who don't know any Lua are breaking otherwise-functional modules with it. Because of this, and because it's easy enough to save incomplete code by simply wrapping it all in a multiline comment, I plan to remove the option unless objections are raised. Jackmcbarn

5 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l September 2014