This was written with the WMF Engineering staff as the audience in mind,
but it has equally important points for all mediawiki/wikimedia
developers.
----- Forwarded message from Greg Grossmeier <greg(a)wikimedia.org> -----
> Date: Tue, 2 Jun 2015 13:44:54 -0700
> From: Greg Grossmeier <greg(a)wikimedia.org>
> To: Development and Operations engineers <engineering(a)lists.wikimedia.org>
> Subject: What to know before next week's shortening of the deploy cadence
>
> All:
>
> Next week we start the shortened deploy schedule. This means that code
> you write and merge into master will get to all of our users quicker than
> it has before.
>
> There are a few things I need to share with everyone so that we're all
> on the same page about expectations.
>
> 1. The first week or so might be bumpy as we adjust to the new cadence.
> Let's not call it a failure if things go bad next week; I fully expect
> some stabilizing time. I will be assessing things as we go and will not
> be afraid of reverting our process back if things don't go smoothly.
>
> 2. We (Release Engineering, namely Mukunda) will be more diligent and OK
> with reverting/holding the train if things start to look bad. We're
> going to be paying close attention to the fatal monitor in Logstash[0],
> and if there is a spike post-deploy that we can't identify and fix
> immediately, we reserve the right to quickly revert and then assign a
> task to your team to fix.
> <https://logstash.wikimedia.org/#/dashboard/elasticsearch/fatalmonitor>
>
> 2a. This is a great time to clean up your team's/projects log errors:
> <https://phabricator.wikimedia.org/tag/wikimedia-log-errors/>
>
> 3. We will continue to improve our automated and manual testing
> practices. Your help here is appreciated as at the end of the day you're
> the ones who know your code best.
>
> 4. Lastly, I think this exchange between Jon and I really encapsulates
> what we're doing here:
>
> <quote name="Jon Robson" date="2015-06-02" time="10:58:13 -0700">
> > On Mon, Jun 1, 2015 at 10:08 AM, Greg Grossmeier <greg(a)wikimedia.org> wrote:
> > > I hope people take this change
> > > as a vote of confidence that needs to be accepted with continued
> > > maturity of our development and testing practices.
> > >
> > > How is your (everyone's) unit test coverage? Probably not great. Improve
> > > that.
> >
> > Yes!
> > I think this initiative really does make us ask questions about all the
> > code we're supporting. I acknowledge on the short term we are most likely
> > going to see more problems then usual, but from my time working in this
> > community I notice how awesome and effective we are at adapting and
> > responding to big problems.
>
> Here we go :)
>
> Greg
>
> --
> | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
> | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
----- End forwarded message -----
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hello!
MediaWiki-Codesniffer 0.2.0 is now available for use in your MediaWiki
extensions and other projects. Here are the changes since the last
release (0.1.0):
* Fixed sniff that checks globals have a "wg" prefix (Divya)
* New sniff to detect unused global variables (Divya)
* New sniff to detect text before first opening php tag (Sumit Asthana)
* New sniff to detect alternative syntax such as "endif" (Vivek Ghaisas)
* New sniff to detect unprefixed global functions (Vivek Ghaisas)
* New sniff to detect "goto" usage (Harshit Harchani)
* Update ignore with some emacs files. (Mark A. Hershberger)
* Use upstream codesniffer 2.3.0 (Kunal Mehta)
* Make mediawiki/tools/codesniffer pass phpcs (Vivek Ghaisas)
* New sniff to check for spacey use of parentheses (Kunal Mehta)
* Modify generic pass test with a case of not-spacey parentheses (Vivek
Ghaisas)
* Make failing tests fail only for specific respective reasons (Vivek
Ghaisas)
* Change certain errors to warnings (Vivek Ghaisas)
* Update ExtraCharacters Sniff to allow shebang (Harshit Harchani)
To upgrade, just update your composer.json to say 0.2.0 and see if your
code still passes :)
In this release we are now tracking an explicit upstream version
(2.3.0), so you may need to update that dependency as well.
Special thanks to Vivek and James F for helping out with the release today!
If you want to set up PHPCS for your project, see the documentation at
<https://www.mediawiki.org/wiki/Continuous_integration/Entry_points#PHP>
to configure your repository, and file a bug under
#Continuous-Integration-Config to have jenkins configured to run it on
patches.
-- Legoktm
Hi, anybody interested in participating at the
Open Help Conference & Sprints
September 26-30
Cincinnati, Ohio, USA
http://conf.openhelp.cc/
A Wikimedia expedition attended a couple of years ago with a Wikipedia &
user help focus, and they were happy about the event.
http://blog.wikimedia.org/2013/07/03/wikipedians-open-help-conference/
Lately we are focusing on users of our APIs, datasets, tools,
infrastructure... Would it make sense to organize something at that event?
Wikimedia volunteers, remember that we might be able to support your travel
expenses.
https://meta.wikimedia.org/wiki/Grants:TPS
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hi Oliver,
Thanks for sharing your disappointment. I do not think you are alone in
wanting to see wikigrok continue and grow. I would clarify that the
'success rates' you allude to were for reader engagement and accuracy, not
in actually improving our projects by filling in important gaps in
wikidata. A great deal of work would be required to build out in order for
this project to have a scalable impact on wikidata.
I am not saying that casual contributions are going away, simply that we
are going to recognize our resource limitations and evaluate opportunities
for them based on highest return-on-investment. We currently have 5
developers working on readership for the entire web (due to some temporary
leaves) and there might be smaller wins using casual contributions that
work towards our end goal, but don't require the heavy upfront investment.
This doesn't mean we don't take on big thorny problems, just that we take a
step back and see if there are ways to subdivide them into smaller projects
along the way.
Best,
Jon
[1]
https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/WikiGrok
On Mon, Jun 1, 2015 at 12:05 PM, Oliver Keyes <okeyes(a)wikimedia.org> wrote:
> I'm personally incredibly disappointed; this was the most successful
> intervention I'd seen anyone try in a long while, if ever, and the
> results blow me away. My question would be "what interventions with
> similarly high success rates are going to be worked on instead?" - I
> assume that we're not working on them because we can achieve the same
> outcome through easier-to-implement interventions. I would be
> interested to hear what those interventions are.
>
> On 1 June 2015 at 14:57, Jon Katz <jkatz(a)wikimedia.org> wrote:
> > Hi,
> >
> > TLDR: Wikigrok proved that readers are interested in and capable of
> making
> > casual, mobile contributions to Wikipedia. We are putting continued
> > development of the 'Wikigrok' casual contribution feature on hold until
> we
> > have a plan for optimally harnessing this interest/capability.
> >
> > Background
> > Given the growth of mobile traffic on wikipedia and the challenges
> inherent
> > to traditional editing on a mobile device, Wikigrok was proposed as a
> way to
> > test if regular wikipedia readers would be interested in making smaller,
> > more casual contributions to wikimedia projects while reading Wikipedia
> on a
> > mobile device.
> >
> > Results
> > By early 2015, the results were in: readers were relatively interested in
> > engaging with the feature[1]. Some oft-quoted comparisons include:
> >
> > 3x the number of unique responders as mobile editors during test period
> > (4.5K editors, 12.3K WikiGrokkers), even with WG on sample of articles &
> > users
> > 1.5x better clickthrough than 2014 Fundraising full-screen mobile banner
> >
> > (I actually do not have references for these, as they are borrowed
> quotes)
> > Furthermore, we found that the quality of responses was rather high
> [2,3].
> >
> > Future
> > The original thought was to use these responses to fill in gaps in
> Wikidata
> > and our initial test results (2 weeks worth) were successfully ported
> over
> > in late April [4]. However, in order to production-ize the system, we
> would
> > have to:
> >
> > scale and develop queries against the new wikidata query service
> > create an article parser to identify potential multiple choice answers
> for
> > each question
> > create a system for attributing aggregated results to the specific
> > contributors (per Wikidata bot request discussion[5])
> >
> > None of these are unsurpassable, but we have learned a great deal and, at
> > this stage, we believe that further effort should be devoted to
> evaluating
> > areas of need and fit before we commit additional efforts to specifically
> > porting information into Wikidata.
> >
> > Please feel free to reach out if you have any questions or concerns about
> > this decision.
> > Best,
> >
> > Jon
> >
> > [1] https://meta.wikimedia.org/wiki/Research:WikiGrok/Test2
> > [2] Quality of responses, version A:
> >
> https://www.wikidata.org/wiki/File:All_Campagins,_Scatterplot,_version_(a).…
> > [3] Quality of responses, version B:
> >
> https://www.wikidata.org/wiki/File:All_Campaigns,_Scatterplot,_version_(b).…
> > [4]
> https://www.wikidata.org/wiki/Special:Contributions/WikiGrok?limit=500
> > [5]
> >
> https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/WikiGrok
> >
> >
> > _______________________________________________
> > Mobile-l mailing list
> > Mobile-l(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/mobile-l
> >
>
>
>
> --
> Oliver Keyes
> Research Analyst
> Wikimedia Foundation
>
Hi,
*TLDR:* Wikigrok proved that readers are interested in and capable of
making casual, mobile contributions to Wikipedia. We are putting continued
development of the 'Wikigrok' casual contribution feature on hold until we
have a plan for optimally harnessing this interest/capability.
*Background*
Given the growth of mobile traffic on wikipedia and the challenges inherent
to traditional editing on a mobile device, Wikigrok was proposed as a way
to test if regular wikipedia readers would be interested in making smaller,
more casual contributions to wikimedia projects while reading Wikipedia on
a mobile device.
*Results*
By early 2015, the results were in: readers were relatively interested in
engaging with the feature[1]. Some oft-quoted comparisons include:
- 3x the number of unique responders as mobile editors during test
period (4.5K editors, 12.3K WikiGrokkers), even with WG on sample of
articles & users
- 1.5x better clickthrough than 2014 Fundraising full-screen mobile
banner
(I actually do not have references for these, as they are borrowed quotes)
Furthermore, we found that the quality of responses was rather high [2,3].
*Future*
The original thought was to use these responses to fill in gaps in Wikidata
and our initial test results (2 weeks worth) were successfully ported over
in late April [4]. However, in order to production-ize the system, we would
have to:
1. scale and develop queries against the new wikidata query service
2. create an article parser to identify potential multiple choice
answers for each question
3. create a system for attributing aggregated results to the specific
contributors (per Wikidata bot request discussion[5])
None of these are unsurpassable, but we have learned a great deal and, at
this stage, we believe that further effort should be devoted to evaluating
areas of need and fit before we commit additional efforts to specifically
porting information into Wikidata.
Please feel free to reach out if you have any questions or concerns about
this decision.
Best,
Jon
[1] https://meta.wikimedia.org/wiki/Research:WikiGrok/Test2
[2] Quality of responses, version A:
https://www.wikidata.org/wiki/File:All_Campagins,_Scatterplot,_version_(a).…
[3] Quality of responses, version B:
https://www.wikidata.org/wiki/File:All_Campaigns,_Scatterplot,_version_(b).…
[4] *https://www.wikidata.org/wiki/Special:Contributions/WikiGrok?limit=500
<https://www.wikidata.org/wiki/Special:Contributions/WikiGrok?limit=500>*
[5]
https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/WikiGrok
Hi,
I want to build a tool which will generate the statistics for my native
wiki. Before starting to build a tool i was searching for an existing one.
The "Super Counter"[1] has some of the features i want to implement in my
tool.
So is there any way to use the "Super Counter" as an API? if so, can anyone
please show me the path of the documentation?
[1] - https://tools.wmflabs.org/supercount/index.php
--
*Nasir Khan Saikat*
www.nasirkhn.com
Hi Community Metrics team,
this is your automatic monthly Phabricator statistics mail.
Number of accounts created in (2015-05): 248
Number of active users (any activity) in (2015-05): 775
Number of task authors in (2015-05): 474
Number of users who have closed tasks in (2015-05): 238
Number of projects which had at least one task moved from one column
to another on their workboard in (2015-05): 159
Number of tasks created in (2015-05): 3222
Number of tasks closed in (2015-05): 2028
Number of open and stalled tasks in total: 22799
Median age in days of open tasks by priority:
Unbreak now: 13
Needs Triage: 74
High: 137
Normal: 347
Low: 691
Needs Volunteer: 517
(How long tasks have been open, not how long they have had that priority)
TODO: Numbers which refer to closed tasks might not be correct, as described in T1003.
Yours sincerely,
Fab Rick Aytor
(via community_metrics.sh on iridium at Mon Jun 1 00:00:07 UTC 2015)