I'm going to be breaking the work boards pretty hardcore this afternoon.
1. I'm going to clean up all the "done" stuff.
2. Everything that isn't done I'm going to add the the sprint boards in the
right columns and then shift to a new "in sprint board" column on the
search team board.
3. Finally I pick some stuff out of the backlog, add it to the backlog in
the sprint boards, and move it to the "in spring board" column.
If that is confusing to you then you aren't alone. I'll reply to myself
when I get a feel for what this ends up looking like.
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.*
As an incremental step, we are going to stop using the main Search
Team workboard to track "current" work, and will shift that into a new
(to be created) "Sprint" workboard. Despite the name "sprint", we
won't be using fixed-length iterations. This new sprint workboard will
last indefinitely, and will work like the team board has been doing.
The columns will track tasks as they flow from a small backlog,
through in progress, needs review, and finally into done. Speaking of
which, we'll document and formalize that at some point.
As soon as the new sprint board has been created and the existing
current work has been moved/copied to it, Nik will let you know, at
which point it should become your day-to-day focus. We'll also clarify
where to look for more tasks if there is nothing in the sprint backlog
that makes sense for you to grab and work on.
We haven't yet worked out the details of how we'll use the team and
freezer workboards. When we do, we'll let you know.
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.
It was brought up briefly in the monday meeting, but wanted to get a full
list somewhere, who all is attending the lyon hackathon? So far i know
moiz, dan and myself are going. Anyone else?
Any suggestions for useful search things to be hacked on?
Hi everyone,
So that we can start thinking about our short and long term futures, I've
had a Search-Department-Freezer
<https://phabricator.wikimedia.org/project/board/1218/> project created to
serve as our longer term backlog.
This backlog will contain any work which is not planned to be done in the
next few weeks, and will have tasks broken down by category. This will help
us figure out what's coming next, and help us start putting tasks in there
for our long term objectives. Mainly, I plan to use it to plan out our
future work, and give the team and stakeholders insight into what's coming
next.
My task today is to create a preliminary structure, and then we can iterate
from there. The structure of the backlog will evolve over time as the team
structure and work changes. The board may even be superseded by another
board. For now, I'll leave the backlog column of the Search-Team-Project
workboard as it is, but I would like to get together with the team leads to
triage that at some point.
The freezer is unsuitable for the storage of frozen goods.
Dan
--
Dan Garry
Product Manager, Search and Discovery
Wikimedia Foundation