Wikimedia Apps/Team/Dan's Q4 201415 split proposal
 | This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. |
Statement of the problem
[edit]The Mobile Apps Team has recently grown to six engineers (four iOS engineers, two Android engineers). Our current setup of having a single Apps team for these matters has some drawbacks:
- Increased intra-platform communication overhead on iOS due to having four engineers, decreasing signal-to-noise ratio of such discussions
- Increased strain on product and design to develop a deep backlog for the user group the team serves (readers)
- A single team can only maintain focus on serving a single user group, but total engineering velocity is large enough to support two user groups
This has also brought a single, crucial improvement for our users:
- Increased velocity on iOS, allowing the team to catch up with their reader feature backlog
There have been other negatives introduced due to team size and current meeting structure that has all members of the team in meetings concerning both platforms. Such concerns are valid and will be addressed, but are addressed by altering meeting structure rather than splitting the team, so are outside the scope of this document.
Proposal for Q4 2014/15
[edit]With the aim of leveraging the work done towards the readership experience so far, the Mobile Apps Team will refocus its efforts towards contributors for Q4 2014/15 (April to June 2015). That team will be comprised of two iOS and two Android engineers for Q4. The meeting structure of the team will be also be enhanced and pruned to reduce the meeting overhead of the engineering team, but the details of this are outside the scope of this proposal.
Meanwhile, recognising the serious performance regressions that have occurred on the iOS Platform, a spin-off team of two engineers will be formed for this quarter. That team will focus on delivering user value by fixing crucial user-perceived performance regressions that have occurred, and instrumenting the platform so that such regressions are caught earlier in the development process in the future.
Team goals
[edit]This section contains a straw man proposal for each team's goals for Q4 2014/15.
Contributions Team
[edit]- Allow users to edit the focal point of lead images
- Allow users to select an article's lead image from the set of images currently in that article
- Give users the ability to edit Wikidata descriptions
- Design and iterate on UX that explains to users the fundamentals of writing Wikidata descriptions in a mobile-appropriate way (think: one sentence or less)
Stretch goals:
- Build a new backend for read more using RESTBase so that it's not dependent on the full-text search API and can be easily leveraged in other areas
- Extend the read more service to allow user submission of alternative read more results
- Design and iterate on UX that allows users to submit alternatives to read more pages themselves
iOS Performance Team
[edit]- Decrease average user-perceived article load time (post-networking) by 50%
- Add instrumentation to monitor article load time across all devices in running Wikipedia Beta app so performance issues can be caught earlier
- Create a performance dashboard which displays user-perceived article load time over time so regressions can be caught
Stretch goals:
- Created automated alpha build server that allows user to download a version of the app cut from master branch
- Emit warnings via email and/or on IRC if the performance dashboard has a sudden change for the worse
- Make pressing "back" load the previous article almost instantaneously
- Create automated tests which assess each patch's impact on article load time, post-networking
- Make Jenkins run these automated tests, so that Jenkins can mark any patch that causes unacceptable performance regressions as Verified -1, preventing merge until the problem is addressed