Talk:Wikimedia Engineering/2013-14 Goals

SecurePoll
Please include in the schedule a rewrite and redocumentation of the SecurePoll extension. The extension does not take advantage of many of the improvements in MediaWiki that have occurred over the last several years, and its documentation is incomplete and out of date and does not reflect feature changes that have been incorporated over time. Risker (talk) 22:10, 6 June 2013 (UTC)

"Dozens of Toolserver tools have moved to Labs"
Uh? Tools supposed to be moved are over 540, so "dozens" is a non-goal, unless of course you plan to keep Toolserver alive long after the deadline for this initial testing goal. --Nemo 10:19, 30 June 2013 (UTC)

Gadgets 2.0, Global scripts
Can we have Gadgets 2.0 and/or global scripts among the goals this time? See: Helder 17:19, 9 July 2013 (UTC)
 * Thread:Talk:ResourceLoader/Version 2 Design Specification/Is... this thing still on?
 * [Wikidata-l] Wikimedia-related code & test repository
 * Requests for comment/Global bits and pieces

"Wikimedia depends on a ton of other FLOSS projects…We have no good list of what all those projects are"
Apparently nobody is aware of FLOSS-Exchange, Open Source Toolset, or the tangentially related Best practices in evaluating new software. -MZMcBride, 20:43, 12 July 2013


 * I'm sure Erik is, as he proposed & created the first (IIRC). :) Its purpose is to share best practices though, not to document whatever we use to facilitate wishlists, so I'm not sure it's also a "good" list for that purpose; this aspect is however covered by Bug management/Upstream bugtrackers, a very nice page Andre has been compiling for a while.
 * Adding more pages like these would be harmful and most upstream issues are best filed by the devs encountering them in their work (as they normally do), but when we have useful information to share it's nice to be more proactive upstream about issues which are sadly invalid on our bugzilla. GIMP seems a very bad example though (basically impossible to reach all wikimedians using it and even harder to make sense out of it; negligible userbase compared to GIMP's even all combined). --Nemo 07:30, 13 July 2013 (UTC)

Editor engagement goals
I just now read Wikimedia Engineering/2013-14 Goals and must say it has an ambitious goal. We've had a declining editor base for many long years and it might be unrealistic to turn that around in such a short time. Many things are not under the control of the team such as, the community's general hostility toward newcomers, the number of newcomer edits reverted and articles deleted, etc. These things have a significant impact on retention of new editors and are outside of the team's ability to control. Of course, this is only one person's opinion, but it's enough of a concern that I thought I'd raise the issue. 64.40.54.75 05:14, 2 September 2013 (UTC)
 * 2.4k is just a fraction of our current 75-80k active editors per month. True, WMF engineering usually has a negligible effect on that metric so far, but for comparison Wiki Loves Monuments 2012 increased it by about 7k in September. --Nemo 09:18, 2 September 2013 (UTC)
 * WLM and new features are not really comparable efforts. WLM is a time-limited contest, which produces a very large bump in new Commons contributors for a short period, then they mostly leave (See the data). Features tend to increase new contributors at lower rates, typically 1-10%, but compound over time to produce growth. These small increases are why we run controlled A/B tets with statistical confidence to tell us whether we really made an impact outside seasonal changes or other changes to the editing environment. For instance, the current version of our new onboarding process brings in an additional 2,656 first time English Wikipedia editors in June, and by a month later that cohort collectively made more than 16,000 edits. In July it was up to more than 3,000 additional first time editors, and like usual, ~25% of those editors (about 800) reached 5+ article edits. There's more about stats so far in our Wikimania presentation about this feature set. Our 2,400 target was based on a simple projection of what would happen if we took the conversion rates we see now, and increase them by 5-10%. It's ambitious if we just kept trying to improve the same feature over and over with diminishing returns, but we're working on a set of ideas for the year that will help us reach the target. I'll be posting those on-wiki this week. I should also note that if you do some basic math, you'll see that it will take between one and two thousand additional active editors a month to turn around English Wikipedia, which is another reason we shot for the 2,400 ballpark, even if we aim to release features across wikis. Steven Walling (WMF) &bull; talk   18:06, 3 September 2013 (UTC)
 * Thanks for adding context; I was merely providing order of magnitudes of what's a reasonable number to talk about. Could you explain to us non-English native speakers what "to turn around English Wikipedia" means? --Nemo 18:21, 3 September 2013 (UTC)
 * It's kind of a moot issue, because our team wants to release features across languages, but "turning around English Wikipedia" means moving from the current state of year-over-year decline in enwiki active/new editor metrics to growth. Right now "Total Active Editors" (unique 5+ edits a month users across all projects) is basically flat or stagnant, but this masks the fact that some Wikipedias (like Spanish, Japanese, and others) are growing in terms of active editors. Their growth is offset by small, slow declines in projects like English and German Wikipedias, thus making things look flat overall. Steven Walling (WMF) &bull; talk   23:55, 3 September 2013 (UTC)
 * Thanks for the translation to plain English. I wouldn't call reversing the decline on the English Wikipedia a moot issue. ;) Yes, of course we know from the stats (Wikipedia) that such a decline is rather unique across our projects and that many of have a sustained growth (or even explosive, for ru.wiki; while Japanese is stable or decreasing compared to 2007, with a curious correlation to akamai broadband stats IIRC) as was clearly seen in the plots.
 * I don't know however how that's relevant, unless you wanted to stress 64.40.54.75's point that the main factors for growth are outside our control, or that limn is not yet a really usable tool. --Nemo 04:19, 4 September 2013 (UTC)


 * Thanks for the explanation, Steven. Regarding the editor numbers, are you saying it looks flat or are you saying it is flat from a statistics stand point? I know the Editor Engagement team and others were doing a lot of statistical analysis at one point, but I haven't been following it very well lately. In other words, have we proven statistically that we've finally stopped the loss of editors? Thanks. 64.40.54.22 05:33, 6 September 2013 (UTC)

Audio formats
Here are the audio formats I hope you support: Speex, Opus, FLAC, PCM. Please copy this in to the RFC when you open it. 180.158.94.222 15:45, 14 December 2013 (UTC)

Updates needed (January 2014)
I just took a quick look at this. It seems like #Analytics is currently undefined for 2014? Toby or Erik? :-) --MZMcBride (talk) 03:47, 28 January 2014 (UTC)

Spanish Wikipedia perspectives
An excerpt I stumbled upon today, which seems to belong to this page (does it, Sj and Eloquence?): "Finally, even if they had nothing to do with the VisualEditor, several users have meant to note that more economics and human resources should be focuses on fixing existing problems such us the FastButtons —it was disabled weeks ago because a security breach—, the cellular phone and portable devices editing softwares, etc."

- Albertojuanse, 60188

--Nemo 22:05, 10 February 2014 (UTC)
 * I should point out that FastButtons is a user script (similar to Twinkle on enwiki). This, that and the other (talk) 00:02, 11 February 2014 (UTC)
 * We are aware of that, but maybe some sources can be focussed on repair them. I don't know exactly how does it work... but those were a very useful tools. Regards. Albertojuanse (talk) 00:32, 11 February 2014 (UTC)
 * We also have Twinkle enabled on eswiki, but it is deprecated. LlamaAl (talk) 00:51, 11 February 2014 (UTC)
 * Fastbuttons were our only available tool against vandalism since other options like Twinkle or Monobook-suite were retired per totally obsolet (Twinkle it´s only partially operative, and not the best part indeed). And sadly FB should be "disconnected" almost two months ago because a vandalism in a very minor WP not detected on time, that expose vulnerability of the system. At this right point, we've suffiring total lake of support of our antivandalism tools. It there any solution think per es: antivandalism tools? Thanks. --Ganímedes (talk) 02:21, 11 February 2014 (UTC)
 * What is sad is, Tech is so in a war with es: because of we denied VE than not realize if someone could hacked es: from Wikipedia in Hamani, anyone can. Maybe if someone hack en: or de: will be a problem that need your attention... --Ganímedes (talk) 11:02, 11 February 2014 (UTC)


 * I think I need a little bit more context here, unless Nemo is suggesting that solving vandalism issues on es.wp should be a goal for Engineering :) --Elitre (talk) 17:11, 11 February 2014 (UTC)


 * I'm not suggesting anything, only that if people have concerns/ideas on general engineering priorities this is supposed to be the page where to voice them AFAIK. Till few weeks ago this page had an item about gadgets, they're surely not a taboo topic. :) --Nemo 17:16, 11 February 2014 (UTC)


 * What's wrong with the main global anti-vandalism tool, RTRC, that means it isn't suitable for eswiki? Jdforrester (WMF) (talk) 19:40, 11 February 2014 (UTC)
 * I have mentioned the tool to other users on a few occasions; however, it is not used by RC patrollers as of yet and seems to be unknown to the vast majority of them. LlamaAl (talk) 21:43, 11 February 2014 (UTC)
 * Thanks! Given that RTRC, though not officially supported, has a lot of expert developer attention, it seems sensible that people should use it in favour of other, local tools that may break every now and then and not have developers around to fix it. If there are local developers keen to help out, it'd be great to share their ideas and work to make shared tools better for everyone. That said, of course if there are local requirements that one tool doesn't meet, and aren't appropriate for all other wikis' users, it may be necessary to fork the effort – but this should be a last resort, not the default. Jdforrester (WMF) (talk) 00:49, 12 February 2014 (UTC)
 * And if there are issues / unsatified requirements that make it really impossible for you to adopt an existing tool, always write them down (in your language if needed, someone will translate). Otherwise your experience will never get out of your community and nobody will be able to help you. --Nemo 20:44, 14 February 2014 (UTC)