Wikitech-l September 2014

wikitech-l@lists.wikimedia.org

129 participants
127 discussions

Database dumps
by Byrial Jensen 17 Apr '25

17 Apr '25

Until some weeks ago http://dumps.wikimedia.org/backup-index.html used to show 4 dumps in progress at the same time. That meant that new database dumps normally was available within about 3 weeks for all databases except for enwiki and maybe dewiki where the dump process due to size took longer time. However the 4 dumps processes at one time become 3 some weeks ago. And after massive failures at June 4, only one dump has been in progress at the same time. So at the current speed it will take several months to come thru all dumps. Is it possible to speed up the process again using several dump processes at the same time? Thank you, Byrial

3 2

User-Agent:
by Domas Mituzas 17 Apr '25

17 Apr '25

Hi! from now on specific per-bot/per-software/per-client User-Agent header is mandatory for contacting Wikimedia sites. Domas

19 61

EBNF grammar project status?
by Steve Bennett 01 Apr '25

01 Apr '25

What's the status of the project to create a grammar for Wikitext in EBNF? There are two pages: http://meta.wikimedia.org/wiki/Wikitext_Metasyntax http://www.mediawiki.org/wiki/Markup_spec Nothing seems to have happened since January this year. Also the comments on the latter page seem to indicate a lack of clear goal: is this just a fun project, is it to improve the existing parser, or is it to facilititate a new parser? It's obviously a lot of work, so it needs to be of clear benefit. Brion requested the grammar IIRC (and there's a comment to that effect at http://bugzilla.wikimedia.org/show_bug.cgi?id=7 ), so I'm wondering what became of it. Is there still a goal of replacing the parser? Or is there some alternative plan? Steve

26 217

Missing Section Headings
by Marc Riddell 13 Sep '24

13 Sep '24

Hello, I have been a WP editor since 2006. I hope you can help me. For some reason I no longer have Section Heading titles showing in the Articles. This is true of all Headings including the one that carries the Article subject's name. When there is a Table of Contents, it appears fine and, when I click on a particular Section, it goes to that Section, but all that is there is a straight line separating the Sections. There is also no button to edit a Section. If I edit the page and remove the "== ==" markers from the Section Titles, the Title then shows up, but not as a Section Heading. Also, I don't have any Date separators on my Want List. This started 2 days ago. Any thoughts? Thanks, Marc Riddell [[User:Michael David]]

10 11

How to make commits from mirrored Wikimedia repos show up on your GitHub profile
by Bartosz Dziewoński 27 Jun '24

27 Jun '24

I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here. tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.) (Is there a place on mw.org to put this tidbit on?) ------- Forwarded message ------- From: "Brian Levine" <support(a)github.com> (GitHub Staff) To: matma.rex(a)gmail.com Cc: Subject: Re: Commits in mirrored repositories not showing up on my profile Date: Tue, 09 Jul 2013 06:47:19 +0200 Hi Bartosz In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit. The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits. Cheers Brian -- Matma Rex

3 3

New RFC: better JS minification
by Max Semenik 01 Nov '15

01 Nov '15

Hi, I'd like to present a new RFC for your consideration: https://www.mediawiki.org/wiki/Requests_for_comment/Minifier It is about how we can shave 10-15% off the size if JavaScript delivered to users. Your comments are highly welcome!:) -- Best regards, Max Semenik ([[User:MaxSem]])

9 12

Bikeshedding a good name for "the api.php API"
by Brad Jorsch (Anomie) 11 Aug '15

11 Aug '15

When api.php was basically the only API in MediaWiki, calling it "the API" worked well. But now we've got a Parsoid API, Gabriel's work on a REST content API, Gabriel's work on an internal storage API, and more on the way. So just saying "the API" is getting confusing. So let's bikeshed a reasonably short name for it that isn't something awful like "the api.php API". I'm horrible at naming. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation

30 38

Re: [Wikitech-l] Bug in the Wikipedia main web page
by Sukyoung Ryu 24 May '15

24 May '15

Thank you for the quick fix! Best, -- Sukyoung On Jan 29, 2014, at 9:55 AM, Nathan wrote: > FYI in case you aren't subscribed to the list. > > ---------- Forwarded message ---------- > From: Yair Rand <yyairrand(a)gmail.com> > Date: Tue, Jan 28, 2014 at 7:25 PM > Subject: Re: [Wikitech-l] Bug in the Wikipedia main web page > To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > > > Thank you for pointing out this bug. Your suggested change to > MediaWiki:Gadget-wm-portal.js has been implemented by Meta-Wiki > administrator User:PiRSquared17. > > > On Tue, Jan 28, 2014 at 6:50 PM, Sukyoung Ryu <sukyoung.ryu(a)gmail.com>wrote: > > > Dear all, > > > > We are researchers at KAIST in Korea working on finding JavaScript bugs in > > web pages. While analyzing top websites from Alexa.com, we found an issue, > > which seems to be a bug, on the Wikipedia main web page (wikipedia.org). > > We would be grateful if you can either confirm that it is a bug and even > > better fix it or let us know what we're missing. > > > > Here's the issue. When a user selects a language in which search results > > are displayed via the language selection button from the Wikipedia main web > > page, the following JavaScript function is executed: > > > > 1 function setLang(lang) { > > 2 var uiLang = navigator.language || navigator.userLanguage, date > > = new Date(); > > 3 > > 4 if (uiLang.match(/^\w+/) === lang) { > > 5 date.setTime(date.getTime() - 1); > > 6 } else { > > 7 date.setFullYear(date.getFullYear() + 1); > > 8 } > > 9 > > 10 document.cookie = "searchLang=" + lang + ";expires=" + > > date.toUTCString() + ";domain=" + location.host + ";"; > > 11 } > > > > Depending on the evaluation result of the conditional expression on line > > 4, "uiLang.match(/^\w+/) === lang", the function leaves or dose not leave > > the selected language information on the user's computer through a cookie. > > But we found that the expression, "uiLang.match(/^\w+/) === lang", always > > evaluates to false, which results in that the function always leaves > > cookies on users' computers. We think that changing the contidional > > expression, "uiLang.match(/^\w+/) === lang", to the expression, > > "uiLang.match(/^\w+/) == lang", will solve the problem. > > > > This problem may occur in the main web pages of all the Wikimedia sites. > > Could you kindly let us know what you think? Thank you in advance. > > > > Best, > > Changhee Park and Sukyoung Ryu > > > > > > _______________________________________________ > > Wikitech-l mailing list > > Wikitech-l(a)lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >

3 3

Upcoming jQuery upgrade (breaking change)
by Krinkle 01 Dec '14

01 Dec '14

Hey all, TL;DR: jQuery will soon be upgraded from v1.8.3 to v1.11.x (the latest). This major release removes deprecated functionality. Please migrate away from this deprecated functionality as soon as possible. It's been a long time coming but we're now finally upgrading the jQuery package that ships with MediaWiki. We used to regularly upgrade jQuery in the past, but got stuck at v1.8 a couple of years ago due to lack of time and concern about disruption. Because of this, many developers have needed to work around bugs that were already fixed in later versions of jQuery. Thankfully, jQuery v1.9 (and its v2 counterpart) has been the first release in jQuery history that needed an upgrade guide[1][2]. It's a major release that cleans up deprecated and dubious functionality. Migration of existing code in extensions, gadgets, and user & site scripts should be trivial (swapping one method for another, maybe with a slight change to the parameters passed). This is all documented in the upgrade guide[1][2]. The upgrade guide may look scary (as it lists many of your favourite methods), but they are mostly just addressing edge cases. == Call to action == This is a call for you, to: 1) Get familiar with http://jquery.com/upgrade-guide/1.9/. 2) Start migrating your code. jQuery v1.9 is about removing deprecated functionality. The new functionality is already present in jQuery 1.8 or, in some cases, earlier. 3) Look out for deprecation warnings. Once instrumentation has begun, using "?debug=true" will log jQuery deprecation warnings to the console. Look for ones marked "JQMIGRATE" [7]. You might also find deprecation notices from mediawiki.js, for more about those see the mail from last October [8]. == Plan == 1) Instrumentation and logging The first phase is to instrument jQuery to work out all the areas which will need work. I have started work on loading jQuery Migrate alongside the current version of jQuery. I expect that to land in master this week [6], and roll out on Wikimedia wikis the week after. This will enable you to detect usage of most deprecated functionality through your browser console. Don't forget the upgrade guide[1], as Migrate cannot detect everything. 2) Upgrade and Migrate After this, the actual upgrade will take place, whilst Migrate stays. This should not break anything since Migrate covers almost all functionality that will be removed. The instrumentation and logging will remain during this phase; the only effective change at this point is whatever jQuery didn't think was worth covering in Migrate or were just one of many bug fixes. 3) Finalise upgrade Finally, we will remove the migration plugin (both the Migrate compatibility layer and its instrumentation). This will bring us to a clean version of latest jQuery v1.x without compatibility hacks. A rough timeline: * 12 May 2014 (1.24wmf4 [9]): Phase 1 – Instrumentation and logging starts. This will run for 4 weeks (until June 9). * 19 May 2014 (1.24wmf5): Phase 2 – "Upgrade and Migrate". This will run for 3 weeks (upto June 9). The instrumentation continues during this period. * 1 June 2014 (1.24wmf7) Finalise upgrade. == FAQ == Q: The upgrade guide is for jQuery v1.9, what about jQuery v1.10 and v1.11? A: Those are regular updates that only fix bugs and/or introduce non-breaking enhancements. Like jQuery v1.7 and v1.8, we can upgrade to those without any hassle. We'll be fast-forwarding straight from v1.8 to v1.11. Q: What about the jQuery Migrate plugin? A: jQuery developed a plugin that adds back some of the removed features (not all, consult the upgrade guide[2] for details). It also logs usage of these to the console. Q: When will the upgrade happen? A: In the next few weeks, once we are happy that the impact is reasonably low. An update will be sent to wikitech-l just before this is done as a final reminder. This will be well before the MediaWiki 1.24 branch point for extension authors looking to maintain compatibility. Q: When are we moving to jQuery v2.x? A: We are not currently planing to do this. Despite the name, jQuery v2.x doesn't contain any new features compared to jQuery v1 [3]. The main difference is in the reduced support for different browsers and environments; most noticeably, jQuery 2.x drops support for Internet Explorer 8 and below, which MediaWiki is still supporting for now, and is outside the scope of this work. Both v1 and v2 continue to enjoy simultaneous releases for bug fixes and new features. For example, jQuery released v1.11 and v2.1 together[4][5]. -- Krinkle [1] http://blog.jquery.com/2013/01/15/jquery-1-9-final-jquery-2-0-beta-migrate- final-released/ [2] http://jquery.com/upgrade-guide/1.9/ [3] http://blog.jquery.com/2013/04/18/jquery-2-0-released/ [4] http://blog.jquery.com/2014/01/24/jquery-1-11-and-2-1-released/ [5] http://blog.jquery.com/2013/05/24/jquery-1-10-0-and-2-0-1-released/ [6] https://gerrit.wikimedia.org/r/131494 [7] https://github.com/jquery/jquery-migrate/blob/master/warnings.md [8] http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg72198.html [9] https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap

6 14

Feature request.
by Nkansah Rexford 30 Nov '14

30 Nov '14

Hi all, I'm Rexford, and just posting here for the first time. Please inform if this place isn't the right area to suggest features. I was encouraged to request features here. Please correct me if I'm wrong. Its about edit conflict on Wikipedia and other projects. It happens when I get into an article to edit, but before I could save, someone else goes into the article, edits and save. It happens to myself and many out there. Sometimes many minutes work of changes can be lost. The feature request is this: When a person starts editing an article, and another person tries to edit that same article, he or she gets a message on screen that the article is already engaged. This suggestion is similar to how WordPress informs the second person who tries to edit a page whiles someone else is already editing. Its likely one wouldn't like to edit a page when he or she knows someone is in it editing. I think its much better that way than allowing multiple edits on the page but allowing one persons edit to go in per save. Thanks. rexford | google.com/+Nkansahrexford | sent from smartphone

20 53

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

FOSS OPW open to submissions + Ascend Project
by Quim Gil 30 Sep '14

30 Sep '14

Hi, all FOSS Outreach Program for Women participants need to sign in as candidates or mentors at https://opw.gnome.org/ Mentors can find specific documentation at https://wiki.gnome.org/OutreachProgramForWomen/Admin/System The deadline for submissions is Oct 22 2014, 07:00 pm UTC Selection decisions will be posted on Nov 12 2014, 07:00 pm UTC As a novelty in Round 9, all Ascend Project participants, regardless of gender, are welcome to apply. Ascent is a mentorship and barrier-removing accelerator program designed to explicitly invite, include, and support adult learners in making a first technical contribution to Open Source software. http://ascendproject.org/participants/portland/index.html After some discussions, this is a first step expanding this outreach program to other groups under-represented in the free software community. I'm personally very happy to see actual progress! Kudos to the GNOME Foundation and the FOSS OPW supporters. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

OPW: Wikipedia article translation metrics (was Re: Outreach Program for Women/Round 9)
by Quim Gil 30 Sep '14

30 Sep '14

Hi Roxana, On Mon, Sep 29, 2014 at 11:39 PM, Roxana Necula <necula.roxana91(a)gmail.com> wrote: > But before diving into the code and do the suggested micro-task, I first > wanted to fix some annoying little bugs, starting with bug #25163 > <https://bugzilla.wikimedia.org/show_bug.cgi?id=25163>. Feel free to comment on this bug report that you are working on it. The reporter and at least six users CCed will be happy seeing some movement there. > So far everything > is working fine in my local development environment, but I am still trying > to familiarize myself with the code review / patching part. > Just in case: https://www.mediawiki.org/wiki/Gerrit/Tutorial So, to wrap things up, my question is if I am heading towards the right > direction, and if not, what advice do you have. > I agree with Brian, you seem to be heading to the right direction, and the fact that you are communicating your intentions in wikitech-l is also a good symptom. I just took the liberty of editing the subject of the thread to make it more clear. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

FOSDEM deadlines
by Quim Gil 30 Sep '14

30 Sep '14

Hi, about FOSDEM -- Europe's biggest free software conference: 31 January & 1 February 2015 in Brussels https://fosdem.org/2015/ The first deadline actually passed: devrooms. Last year we had a Wikis devroom organized together with XWiki and TikiWiki. It was not bad at all but I'm not sure whether we should put our effort there. Rather, we could try to get more Wikimedia / MediaWiki sessions in the main track and other devrooms, where we have more chances to interact with other communities we rely on. The deadline to present main track proposals is October 1. If you have a topic wide interest, don't miss this one. https://fosdem.org/2015/news/2014-07-01-call-for-participation/ The deadline for lightning talks and stands is November 20. You can work on your lightning talk proposals, I will try to help Wikimedia Belgium and the Wikimedia Shop in a joint venture that should bring a great Wikimedia stand to an event with thousands of free culture & free software merchandise lovers. https://fosdem.org/2015/news/2014-09-19-call-for-participation-part-two/ Who is planning to attend? Anybody willing to create the wiki page? -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

2 3

Re: [Wikitech-l] Removal of Scribunto's "Allow saving code with errors" option
by MZMcBride 29 Sep '14

29 Sep '14

Jackmcbarn wrote: >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. As long as false positives are low, this is probably fine. It'd be nice to get rid of the checkbox as it's user interface clutter. That said, a hard block is still pretty potent... I wonder whether simply warning the user and auto-categorizing the pages as likely broken on page save would be adequate. MZMcBride

2 2

Outreach Program for Women/Round 9
by Roxana Necula 29 Sep '14

29 Sep '14

Hello, My name is Roxana and I am an engineering student at the Polytechnic University of Bucharest, Romania. I would like to be part of MediaWiki open-source community and participate in the Outreach Program for Women round 9. The project that interests me is Wikipedia article translation metrics <https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_9#Wiki…> But before diving into the code and do the suggested micro-task, I first wanted to fix some annoying little bugs, starting with bug #25163 <https://bugzilla.wikimedia.org/show_bug.cgi?id=25163>. So far everything is working fine in my local development environment, but I am still trying to familiarize myself with the code review / patching part. So, to wrap things up, my question is if I am heading towards the right direction, and if not, what advice do you have. Thank you, Roxana. <https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_9#Wiki…>

3 2

2026

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