Page MenuHomePhabricator

Unconf: brainstorm/feedback how should we move from beta to full-rollout
Closed, ResolvedPublic


Facilitator: Jon Katz
How do we get from beta to full-rollout? Particularly with features for readers! I have 5+ features sitting in beta for the web and would like to discuss how we go about shipping! I want to hear from our community members who have something to say about this and ideally community liaisons and other product managers with experience in this area.

Specific topics:

  • 'community buy-in'
  • stats
  • different methods for different features
  • progressive rollouts

Some outcomes/learnings:

  • What principles should we follow?
  • What are common mis-steps?

Event Timeline

JKatzWMF raised the priority of this task from to Needs Triage.
JKatzWMF updated the task description. (Show Details)
JKatzWMF moved this task to Backlog on the Wikimedia-Developer-Summit-2016 board.
JKatzWMF added a subscriber: JKatzWMF.
JKatzWMF set Security to None.
JKatzWMF updated the task description. (Show Details)

I think we will want to focus on features for readers, but obviously learning from previous contributor tools will be crucial.

Updating with Summarized etherpad content from:

Slides for Intro

Existing Beta Features can be seen at:

Beta Feature docs at:

Related docs:

Topics for discussion:

  • Current state of rolling out built features
    • Hovercards, lead images, read more
  • earning 'community buy-in'. what is it?
  • usage stats
  • different methods for different features
  • progressive rollouts

Some outcomes/learnings:

  • Suggestions
    • Start asking community/users about issues earlier in the process. I.e. what problems should we solve for you or 'we are going to make it easier for visual learners, what solutions do you suggest
      • binary yes/no question is a bad idea, "do you want this change or nothing to change at all?" The answer will almost always be keep the status quo. "Our team has to solve this problem, which solution out of X (e.g. 3 possible options) should we do?" We're going to do one of these things, let's figure out the one that has more support. People like choice, discourages just being negative.
    • publicly call out what we are trying, why, and define each stage and how we know to move to the next--make people comfortable with the experimental nature
    • don't just listen to the naysayers--these are the most ambitious, so try to find the constructive people
    • identify the different types of users who this is for and who it will impact and how.
    • need more data about beta feature--we have people turn it on and turn it off, but how many 'use' it and of those who turn it off or turn it back on, can we track the retention or the people whoc hcange their mind and why?
    • Allow wikis to opt-in to be early adopters / opt-out and be late adopters. Not argue with communities not willing a feature today, just push them to a next deployment wave. (It, He, Ca) identified as eager to try new things
  • This works both ways--community trys to push something and it takes forever waiting on wmf
  • Features have different impacts/footprints: Mediaviewer will change your personal experience, VE or ContentTranslation will affect everyone, including people who didn't enable the BF.
  • There is a lot of the same lessons being taught over and over to different people, we should save and share our findings, see task for this: Also see retro from media viewer:
  • We need to remember that we aren't just buidling for our current users, and for our current power users
  • Different communities have different modes of communication
    • wikitech-ambassadors community, useful to engage with them for Wikidata stuff. arabic community uses Facebook(?) going to meetups, talking with people
  • The question of what is the WMF allowed to do should be separated more clearly from the specific feature (superprotect and specific feature decisions should not be lumped together)

Wikimedia Developer Summit 2016 ended two weeks ago. This task is still open. If the session in this task took place, please make sure 1) that the session Etherpad notes are linked from this task, 2) that followup tasks for any actions identified have been created and linked from this task, 3) to change the status of this task to "resolved". If this session did not take place, change the task status to "declined". If this task itself has become a well-defined action which is not finished yet, drag and drop this task into the "Work continues after Summit" column on the project workboard. Thank you for your help!