Reading/Retrospectives/2014-2015q4

From mediawiki.org
Jump to navigation Jump to search

Reading-wide successes[edit]

  • Filling in for PM, team stepped up.
  • Experimentation in 10% time and hackathon successfully contributing to quarters work and Q1 planning
  • Engineers taking up PM work has helped keep things moving

Reading-wide misses[edit]

  • Reorg uncertainty hurt velocity
  • Loss of 2 PMs hurt velocity

Web Successes[edit]

  • Gather
    • Built according to goal (share replaced by public feed)
    • Saw engagement numbers that surpassed our goals:
    • Generic infrastructure around lists re-used in browse prototype, and other types
  • Wikigrok
    • Paused development
    • Identified and pushed 120 claims to Wikidata from WikiGrok using very conservative thresholds.
    • Used Wikigrok to move people to mobile web beta: now we can validate ideas in beta, more quickly and don’t need to move to stable (2k->43k daily adds, trailing back down, but folks don’t opt out)
  • Built the Browse prototype in 2 weeks with a minimal number of bugs.
  • Wikidata descriptors in search results will start rolling out Tuesday, 30th
  • User testing has been very helpful (ad hoc, heuristic + planned live walk-throughs)
  • Anonymous editing went live and seems to be succesful
  • Worked with performance team to identify areas for speed improvement


App Successes[edit]

  • Incorporated Design more fully into the Development Process
    • Begin a more collaborative product/design/engineer design process
    • Successfully prototyped link preview feature with design using new process
    • Formally integrated Design into the feature and bug signoff for users

iOS Successes[edit]

  • Increased Performance of App
    • Improved load time of articles and general speed of navigating articles
    • Increased perceived performance of the app by improving UX
  • Improved delivery process
    • Implemented and documented a comprehensive release process
    • Improved release cadence and tightened feedback loop (5 versions released during the quarter vs 1 release in the previous quarter)
    • Automated distribution of "nightly" builds
    • Increased unit test coverage by 30%
    • Automated running unit tests for builds before automated distribution
    • Shipped crash reporting, and used to fix 12 high volume crashing bugs that may have gone unresolved otherwise
    • Implemented Regression testing for all deployments to the app store
    • Took over ownership of Regression Testing scripts and have added 50 additional test cases (nearly a 100% increase)
    • Engaged customers via social media to identify and fix bugs
  • Contributed to Open Source community
    • Multiple contributions to open source Continuous Integration/Deployment project (Fastlane)
    • Increased experimentation
    • Built 2 prototypes at Hackathon that are being scheduled for development in Q1


Android Successes[edit]

  • Increased unique installs by more than 1.7 million (almost 15% total increase from the end of Q3). Largely due to PR, but owing to new features.
  • Increased Play Store rating (from 4.36 to 4.39, and climbing)
  • Continued to demonstrate ability of mobile apps to quickly prototype and deliver new features. (e.g. link previews)

Web Misses[edit]

  • Did not ship
    • Lead images (beta, but not stable)
    • Browse prototype (not as early as we hoped)
    • Site speed (dashboards)
  • (this impacted Q3 more than Q4) More support for minimizing friction on prototyping--getting extension on gerrit, project on phabricator, required to have documentation
  • Had moderation communication flare ups with community--need to build bridges there.
  • Nobody owns developer happiness--vagrant issues are an example here
  • User feedback loops were slow
  • Uncertainty around re-org and metrics hurt culture and velocity: we paused development on wikigrok and gather
  • Passionate people (even within org) telling you you’re doing a bad job can bum you out
  • Lost engineers to do PM work.

Misses Learning[edit]

  • Lead images: We need to engage with the community (and the engineering community) before we start planning. We're more aware now of the cultural and technical problems around lead images (and the infobox).
  • Browse: Regular review of our beta and stable features is required to stop small projects getting lost in noise, which requires more visibility.

App Misses[edit]

iOS Misses[edit]

  • Failed to catch significant "data migration" bugs prior to release (which caused issues for many users and bad reviews)
  • Failed to deliver link preview feature to end users
  • Failed to ensure tickets are well defined prior to the beginning of sprints
  • Failed to improve overall rating in app store
  • Failed to significantly improve event logging (add search)
  • Failed to increase developer confidence in making changes to the code base