Wikimedia monthly activities meetings/Quarterly reviews/Core features/February 2014

The following are notes from the Quarterly Review meeting with the Wikimedia Foundation's Core features team on February 24, 2014, 2pm-3:45pm.

Present: Benny Situ, Erik Bernhardson, Erik Moeller, Maryana Pinchuk, Brandon Harris (initially), Sue Gardner, May Tee-Galloway, Howie Fung, Dan Garry, Tilman Bayer (taking minutes), S Page

Participating remotely: Nick Wilson, Shahyar Ghobadpour

Please keep in mind that these minutes are mostly a rough transcript of what was said at the meeting, rather than a source of authoritative information. Consider referring to the presentation slides, blog posts, press releases and other official material

Agenda
1. Project overview
2. Product (User Experience and Design)
3. MediaWiki integration
4. Community & deployment
5. Future plans
6. Asks

ErikM: welcome
this is the first quarterly review of Core Features (wasn't included in original lineup)
team is complete now

Maryana: Agenda (team intro, then our 3 main work areas, future plans, asks)

Team currently consists of:

4 FT engineers (2 remote)
2 part-time contractors
S Page as part-time scrummaster
PM (Maryana), designers (May and Kaity), Community Liaison (Nick)

Current focus of the team (formerly known as E2): Flow
page creation and Echo still being maintained, but we do not have a lot of time for that, unfortunately
Why Flow?
discussion is fundamental for WP
Sue: current terms of use amendment discussion is very interesting - lots of new users being brought in, good for diversity, but they mess up the page. This is a big argument for Flow
(Maryana:)
important to give new users a voice, they don't know how to participate in e.g. AfD discussions
system needs to facilitate the right kind of discussion, don't want to become like the YouTube comment section
Timeline:
Project's resourcing was a bit funky initially (Brandon's early designs, only one engineer involved: ErikB)
around Wikimania, ErikB and AndrewG got the first real coding done (without PM, CL, design support)
Now (Q3): released on several pages on mw.org and enwiki
now have an actual frontend developer
If we were a startup, would focus only on building the product (investigate user needs, iterate...)
but we also need to integrate into existing MediaWiki tools and processes
and involve community
unlike VE, Flow can't function on an opt-in basis
Reason why we pushed Flow out early: need to get it tested by real people
had two in-person UX sessions
one in the SF office: ~50 people, many of them not Wikipedians, but still useful feedback
one at UCB with some undergrads
+2 rounds of community feedback
+remote testing (usertesting.com)
altogether, around 100 people have tried Flow
Feedback from new users:
find existing talk pages confusing, overwhelming
collapsed view useful
coded feedback from experienced users (NB: on early version of Flow):
large ratio of negative responses
but it needs to be kept in mind that these are
Sue: whitespace density [highest negative ratio] is about the increased whitespace in the prototype? yes
(Maryana)
existing users have been used for years to the high density of existing pages
First version of Flow (Brandon's proof of concept) - not a lot of UX design, or use of JavaScript
second cut: tightened up whitespace, made it wider
took floating icons and wrapped them into action menu ("...")
ErikM: also, made persistent
(Maryana:)
convey the seriousness and gravitas of contributing to a WP discussion ;)
Focus a bit more on features that power users need (support for processes, workflows - e.g. AfD, unblock request, etc.)
S: also, sorting and filtering
(Maryana:)
Yes
ErikM: prioritizing of tagging, sorting, search features?
(Maryana:)
yes, starting on search now (with search team). tagging - not yet
ErikM: strategic choice of tagging vs. search?
Maryana: team agreed search was more immediately important
ErikM: AfD+ etc?
also, quickpolls (cf. TOU example, where a user added voting structure)
Sue: but, !voting
ErikM: the format people use frequently is quick comment+vote
Asking because this has pretty big impact on UI
(Maryana:)
MediaWiki is a bit like a giant octopus - if you cut off one leg, it grows back ;)
Flow is entangled in many of these legs
e.g. normal pages have history, revdel/suppress ...
Flow is different: it works on the topic level
one topic can appear on several other pages, appear in feeds, be watchlisted individually...
which MW features are necessary, which negotiable?
e.g. spam blacklist, protection - necessary
but e.g. categories, transclusion - negotiable
rubs people the wrong way
ErikM: have people pointed out specific problems?
Maryana: the only specific case: header templates on talk pages
will have to decide how many dev cycles to spend on negotiable stuff
history: provenance is much more visible in Flow than in normal page history (clicking through diffs...)
this is great, but breaks experienced users' expectations on vandalism fighting
next steps: understand users' needs for non-page behavior
define level of mw process support (do we need transclusion?)
in near future, we also need to provide API for user-created tools (vandal fighting bots etc.)
Community:
Sue: color-coded responses in earlier slide were from user of these two WikiProjects?
Maryana: yes
Not all users who contribute heavily to discussions about features actually contribute a lot of content
also, WikiProjects are constantly in need of new users, and are therefore open to features that can bring these in
ErikM: how many users from these two WikiProjects involved?
Maryana: not many, maybe 10-15
build community support in an organic way, show users that their feedback has actual impact on development
Sue: but at what point deployed as default?
(recalling Vector skin, where this was done once a threshold of beta users was met
e.g. 80% of people who tried it out on their user talk page keep it after 1 month, or something like that)
many small sister projects happy to try it out
ErikM, Sue on how much attention should be spent on MW integration vs. Community socializing ...
Maryana: would love to spend more time on Community
Next year: ...
ErikM: user talk page feature around the corner (Q4)?
Maryana: yes, but worried about API support
ErikM: concerned about having inconsistent state for a prolonged period of time
have we thought about ways to address that?
Maryana: ...
Howie: talked about ways to make this suck less, no functional ideas yet
ErikM: feels like we are in the situation of VE ca. March 2013 - some people trying it out, already lots of opinions pro/con, but not getting wide enough usage
could get 1000-2000 users via BetaFeatures
S: actually Brandon has it turned on on his mw.org user talk page right now (but not getting usage)
Sue: roll out to select "invitee" list first?
Maryana: thought about that - and actually that was kind of the approach with the WikiProjects
ErikM: two asks from me:
1. write pro/con list for different rollout scenarios
2. gradual ramp-up, unlike VE
Sue: community acceptance
interesting idea to involve early adopters as advocates, but still have the problem that those who will benefit most might have the quietest voices
need some mechanism where we can quantify and demonstrate appreciation by inexperienced users
and give them a megaphone (again, cf. TOU discussion)
Maryana: (agrees)
ErikM: with UploadWizard, users tests (showing inability of new users to contribute) were a big argument
these might actually work here too
have we user-tested old talk pages?
Maryana: yes, Brandon did
Sue: do we have videos?
Maryana: yes
ErikM: convert 50% of new user talk pages as A/B test? ;)
Maryana: a lot of other projects wanted to test too

Asks:

more community liaisons (Nick now full time, but still need more support - unlike VE, Flow can't just be ignored)

ErikM: other languages/projects besides enwiki? not yet
ErikM: got support from others? a bit
Howie (on general community liaison / community advocate setup)
4 is minimum staffing for CL next year
Sue: how difficult to ramp up?
Howie: might not be too difficult to hire, but cold start
new director might help drive this
(Maryana:)

our current engineers are mostly backend experts, kind of imbalanced - need people who are comfortable with JS/CSS

also, need to fix bugs in Echo
hard with 4 FTE
have some part-time help, but very inconsistent
ErikM: full stack hires?
ErikM: who is helping on QA currently?
ErikB: mostly Chris McM
S: I work with them
ErikB: want more automated browser testing
S: right
ErikM: specific human testing can find more stuff (e.g. Rumana...)
Maryana: S does a lot of such work right now
S: e.g. for testing with different user rights, need ask people like Dan and Risker who understand this
ErikM: Surely possible to get person who does both
different teams took different approaches to this, e.g. Mobile write their own browser tests
S: yes... concern: Chris very helpful, but may not always be available, need dedicated capacity
Howie: Flow now looks like a 18-24 month project
talked a lot about features and community aspects - they are more visible - but something like 50% of the work is MediaWiki integration
e.g. RC, watchlist, caching(?)
ErikM: yes, can't expect Flow to be in use on all talk pages on all projects in like June
but: need path, accelerating mechanisms
Sue: agrees, it's a complex project
there's a lot of functionality that people want, built over the years for good reasons
but really need roadmap for minimum viable product, sense what is the necessary level of user acceptance - can't stipulate that it must be 100% airtight before rollout
there will be more complexity at every turn - e.g. there will be lots of non-enwiki problems (RTL)
ErikM: user talk page might be a big booster, but need to be careful when to give such a big boost
S: beta features lottery? ;)
Sue: likes the JSTOR account analogy ;)
Maryana: other WikiProjects lined up, including the big one: military history
ErikM: thank you, this was what we expected from a quarterly review