Thanks for the bugs, Nemo!
(search team: should we take those over?)
On 7 May 2015 at 03:08, Federico Leva (Nemo) <nemowiki(a)gmail.com> wrote:
> Thanks for looking into www.wikipedia.org traffic from India; I've been
> "complaining" about it for a while. :) See also:
> * https://phabricator.wikimedia.org/T26767
> * https://phabricator.wikimedia.org/T5665
>
> Mark J. Nelson, 07/05/2015 04:24:
>>
>> But for the average Copenhagener, the following order is far more
>> likely:
>>
>> * Danish, English, Norwegian Bokmål, ...
>
>
> This is something you can help fix. Please do!
> https://www.mediawiki.org/wiki/ULS/FAQ#language-territory
>
> Nemo
>
>
> _______________________________________________
> Wiki-research-l mailing list
> Wiki-research-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
--
Oliver Keyes
Research Analyst
Wikimedia Foundation
Hey all,
(Throwing this to the public list, because transparency is Good)
I recently did a presentation on a traffic analysis to the Wikipedia
"home page" - www.wikipedia.org.[1]
One of the biggest visualisations, in impact terms, showed that a lot
of portal traffic - far more, proportionately, than traffic to
Wikipedia overall - is coming from India and Brazil.[2] One of the
hypotheses was that this could be Zero traffic.
I've done a basic analysis of the traffic, looking specifically at the
zero headers,[3] and this hypothesis turns out to be incorrect -
almost no zero traffic is hitting the portal. The traffic we're seeing
from Brazil and India is not zero-based.
This makes a lot of sense (the reason mobile traffic redirects to the
enwiki home page from the portal is the Zero extension, so presumably
this happens specifically to Zero traffic) but it does mean that our
null hypothesis - that this traffic is down to ISP-level or
device-level design choices and links - is more likely to be correct.
[1] http://ironholds.org/misc/homepage_presentation.html
[2] http://ironholds.org/misc/homepage_presentation.html#/11
[3] https://phabricator.wikimedia.org/T98076
--
Oliver Keyes
Research Analyst
Wikimedia Foundation
This week, we are shifting how the Search and Discovery team(s) track the
work we are doing. The existing Search-Team phab project will become our
"Product Backlog". That's the collection of all the ideas, features, bug
reports, and other possible tasks that we might eventually take on. As the
Product Owner, Dan will pretty much live in that board, figuring out the
relative priorities of all the possible tasks.
We will be creating a "sprint workboard" for each sub-team. Despite using
the word "sprint", we are not switching to time-boxed iterations (e.g.
2-week sprints). But the boards serve the same purpose: Each sprint
workboard will track current work, plus work scheduled for the next week or
two. Anything outside that scope will stay in the product backlog. They
will have some variation of TODO, In Progress, and Done columns. As you
work on, and then complete tasks, you will move those tasks across the
board. I think most if not all of you are already familiar with that style
of task tracking.
We are creating a sprint workboard for each of the "subteams": Cirrus,
Wikidata Query Service, OpenStreetMap, UX, and Research-and-Data.
A side effect of using the sprint extension of phab is that tasks will now
have a "Story Points" field. That field is intended to hold an estimate,
but you can just ignore it for now. Perhaps at some point we'll have
discussions about whether to start doing estimates, but not yet.
Why are we doing this?
As a developer, this will allow you to focus your attention on just one
workboard, that is specific to your area of work. (Unless you happen to do
work in two different sub-teams, in which case you'll have to bounce
between two small workboards).
As a product owner, Dan will be able to see each subteam's status at a
glance. Later, when we have more product managers, they will probably focus
on one or two subteams each, and they will be able to focus their attention
on just the relevant board(s).
Nik will let developers know when he has moved their current and
near-future work into the sprint workboards, along with the exact name of
the workboard(s) you'll be working in.
We still have an open TODO item of dealing with all the existing
search-related phab projects. Many of them will probably be archived, after
merging their contents into the new structure, but that hasn't been fully
worked out yet.
Feel free to ask me any questions about this, either on the list or off.
Kevin Smith
Agile Coach
Wikimedia Foundation
*Imagine a world in which every single human being can freely share in the
sum of all knowledge. That's our commitment. Help us make it a reality.*