There is an initiative within the WMF to figure out how much time/effort
teams spend on "new functionality" vs. "maintenance". As a pilot project, I
have been tracking that in our Discovery Cirrus project[1] for a couple
months.
As shown on this graph[2], we have been spending somewhere between 25% and
50% of our time on "maintenance". Note that this should not be considered
at all scientific. For starters, there are several glaring issues with this
graph:
- Because we are not doing point estimation, this graph is based on task
counts, not actual effort.
- Data around Oct 1 is missing/funky due to the offsite.
- The bars are pure percentages, so 50% of 2 tasks completed would look
the same as 50% of 40 tasks completed. That 100% bar, in particular, is
misleading because I believe it is based on a single task being resolved
that week.
- The counts are based on my snap decision for each task, whether to add
the #worktype-new-functionality or the #worktype-maintenance tag.
Still, it's a higher fraction than I would have guessed.
Is it worth my time (or someone else's) to continue to track this data?
[1]
https://phabricator.wikimedia.org/tag/search-and-discovery-cirrus-sprint/
[2] http://phlogiston.wmflabs.org/discir_maint_count_frac.png
Kevin Smith
Agile Coach, Wikimedia Foundation
Hey all,
We're pleased to announce the provisioning and release of a new
dashboard. This one contains something a bit different; it breaks down
our pageviews and shows how external search engines influence the
traffic that hits our wikis. Both a simple count of search-referred
pageviews versus other pageviews, and a breakdown of how much traffic
is coming from what specific search engines, is included.
You can see it at http://discovery.wmflabs.org/external/ - hope it's useful!
--
Oliver Keyes
Count Logula
Wikimedia Foundation
Greetings all,
This weekend I stumbled across this interesting bit of research (done by a
Search Engine Optimization consultant) analyzing the increase in "rich
answers" provided by Google. Rich answers are where Google tries to provide
a full or partial answer to a question without requiring a click to another
website.
The end of the article is concerned with SEO, and the effect different
kinds of rich answers have on website traffic (e.g., partial answers lead
people to your site, full answers don't), but the bulk of the article is a
breakdown of the kinds of rich answers Google provides. The most surprising
to me is that they license song lyrics in order to provide them (without
attribution). Not surprisingly, Wikipedia comes up several times in
screenshots.
Whether you care about SEO or not, it's a nice survey of the kind of rich
answers Google provides:
https://www.stonetemple.com/the-growth-of-rich-answers-in-googles-search-re…
—Trey
Trey Jones
Software Engineer, Discovery
Wikimedia Foundation
The mobile web and mobile app search schemas are currently broken. I'm
contacting the apps and web teams to get this worked out, but I
thought I'd let people know.
--
Oliver Keyes
Count Logula
Wikimedia Foundation
This week, the Discovery Department reconfigured its internal teams, to
better align with our quarterly goals[1]. This new arrangement is
considered experimental and temporary, although we expect it to last
through the end of this quarter.
We believe this change will improve our focus on our goals, reduce
context-switching by individuals, reduce the total amount of time spent in
meetings, and generally improve communication.
The new internal sub-teams are:
"Language Search", focused on our goal of "Improve language support for
search". The people on this team include David, Erik, Stas, and Trey. For
now, this team will continue to track its work on the Cirrus board[2].
"Portal", focused on our goal of "Make www.wikipedia.org a portal for
exploring open content on Wikimedia sites". The people on this team include
Jan, Julien, Max, and Moiz. For now, this team will continue to track its
work on the UX board[3].
"Maps", which will continue to gather user feedback on our newly-deployed
service, as well as doing maintenance and minor enhancements. For now, this
will just be Yuri, who is also splitting his time with supporting Zero and
Graphs. Maps work will continue to be tracked on the Maps board[4].
As a side note, Wikidata Query Service (WDQS) is in a similar position to
maps this quarter, and thus will only receive a fraction of Stas's
attention. Work will continue to be tracked on the WDQS board[5].
Product Manager Dan will work most closely with the Language Search team.
He will help the other teams as needed, but our intent is that they should
largely be self-sufficient from a product standpoint, for this quarter. All
the teams will continue to use a Kanban process with a weekly cadence.
The Analysis folks will continue to support the entire department. To
ensure coordination, an analyst will attend the planning meetings and
standups of each of the two big new sub-teams. Mikhail will work with the
Language Search team, and Oliver will work with the Portal team. All
analysis work will continue to be tracked on the Analysis board[6].
People from external departments (TPG, Ops, Community Liaisons) will
interact with whichever sub-team(s) make sense at the time. And of course
everyone in the department will be available to help out other sub-teams as
needed.
After each departmental retrospective, we will evaluate the new structure,
and will consider changes. Our next retro is 2015-11-02. We expect the
structure to change next quarter, when we have a new set of goals to
support.
Questions and comments are welcome.
[1]
https://www.mediawiki.org/wiki/Wikimedia_Engineering/2015-16_Q2_Goals#Disco…
[2] https://phabricator.wikimedia.org/tag/discovery-cirrus-sprint/
[3] https://phabricator.wikimedia.org/tag/discovery-ux-sprint/
[4] https://phabricator.wikimedia.org/tag/discovery-maps-sprint/
[5]
https://phabricator.wikimedia.org/tag/discovery-wikidata-query-service-spri…
[6] https://phabricator.wikimedia.org/tag/discovery-analysis-sprint/
Kevin Smith
Agile Coach, Wikimedia Foundation
After reviewing a weeks worth of data for the commons terms A/B test we
have decided that we have not collected enough information. The initial
sampling was:
1:1000 users chosen to participate in test
Those users split into 6 buckets, giving each bucket a 1:6000 sampling
This has collected ~100 events per bucket, much less in the "strict" bucket
We are increasing the main sampling by 5x, to 1:200. This will give each
bucket a 1:1200 sampling of users. The reason these collect so little data
is that quite a few queries don't meet the minimum requirements to be
effected by the tests. The "aggressive recall" test requires at least 3
words in the query, and the "strict" test requires at least 6 words in the
query.
Erik B.
Hey all,
Earlier this week at our stand-up I mentioned my concern that although
we were now in the second quarter, our work did not entirely reflect
that; it was hard to point at cards and say "yes, this impacts our
quarterly goals".
At our sprint planning meeting I had the idea of adding a new column
to our sprint board - one for epics. Quarterly goals are epics (or
should be), and so exist in a form that Phabricator can track. By
including them in our sprint board we force ourselves, each planning
meeting or checkin, to pass over those epics and explain whether we've
been working on them or not and why, which results in informed task
prioritisation.
As an example, if we have an epic called "reduce the zero results
rate", and in our sprint planning meeting none of the cards we're
signing off on relate to it, we can prioritise cards that do when
we're pulling stuff out of the backlog.
People seemed to think this was a pretty good idea, but Dan wasn't in
the meeting, so I thought I'd push this to a venue he is in and do so
in a way that is transparent - in case anyone else has suggestions or
concerns or thinks it's something they'd like, too.
Thanks,
--
Oliver Keyes
Count Logula
Wikimedia Foundation
For those who didn't make it to WikiConference USA, you can watch
everything that happened in the biggest auditorium on YouTube. (Don't
forget the settings to play at higher speed—most people don't talk as fast
as you can listen.)
While it isn't focused on Discovery, I found Andrew Lih's talk to be very
interesting:
https://www.youtube.com/watch?v=Gj6U22uJzGM&t=24m30s
Links to the other National Archives recordings are on the schedule:
http://wikiconferenceusa.org/wiki/2015/Schedule
Other talks were also recorded, but not by the National Archives. I'm sure
they'll pop up somewhere online eventually.
Aaron Halfaker gave a very cool talk on AI bots that support Wikipedia, and
discusses a machine learning platform that could support other tasks—and
though he didn't mention it, I thought of detecting languages, detecting
gibberish queries (very similar to what they do to find gibberish edits),
and other things that may be useful to Discovery:
http://wikiconferenceusa.org/wiki/Submissions:2015/Revscoring:_AI_support_f…
See more on machine learning as a service here:
https://meta.wikimedia.org/wiki/Objective_Revision_Evaluation_Service
—Trey
Trey Jones
Software Engineer, Discovery
Wikimedia Foundation
