- identify the pain points of mobilefrontend in terms of difficulty, efficiency, and ease of building and maintaining features from their perspective
- brainstorm optimal solutions
- provide result to whomever T156259: [Spike 1hr] What technical problems do we need to fix from mobilefrontend - ENG is assigned to
|Resolved||• Jdlrobson||T156257 Strategy Research - Changing mobilefrontend|
|Resolved||None||T156259 [Spike 1hr] What technical problems do we need to fix from mobilefrontend - ENG|
|Resolved||phuedx||T157127 [Spike 1hr] What technical problems do we need to fix from mobilefrontend|
Problem: [Social] No consistent voice/shared definition of high quality, robust software.
Changes to the codebase – new features, tweaks, and refactoring – always require guidance. Until now, that guidance has been given by one or more code reviewers. Depending on the day of the week, you'll get review from different team members (and their
opinions moods will undoubtedly vary between review rounds 😉 ).
- Have a dedicated reviewer per task so that feedback is consistent. The reviewer is also responsible for roping in third-party reviewers when necessary.
- Meet regularly to discuss patterns and practices and how they might be incorporated into our development standards.
- Reading Web Engineering Sync [NO MEETINGS]?
Problem: Tight coupling to MediaWiki.
The problem that doesn't seem like it's a problem...
Mobile Frontend is a (large) collection of hook handlers, which predominantly process data (wikitext or metadata accumulated during the parse) into or enable/disable features, and a mobile-friendly website. The data requirements for Mobile Frontend are mostly scattered throughout the hook handlers, making writing an API (or consuming an existing API) difficult.
On the other hand, Mobile Frontend doesn't share the same constraints as, say, Vector (the "desktop skin"), e.g. Gadgets are disabled, but still shares the same (caching) infrastructure and shared tooling, e.g. the Resource Loader.
- Pursue consuming MediaWiki APIs and RESTBase APIs whenever possible, removing as many hook handlers as we can.
- Integrate a lot of the mobile-specific special casing in the hook handlers into MediaWiki (read: upstreaming!)
Problem: Very little documentation.
This applies equally to all of our projects: there's very little documentation in the codebase about:
- How to install and configure Mobile Frontend.
- How to start hacking on Mobile Frontend.
- How to contribute.
- Guidelines for approaching making a change, e.g. considering caching implications.
- Architectural decisions.
- Ask contributers to document their findings in the codebase or ensure that fellow contributors know where to look, e.g. by providing links to on-wiki documentation pages.
- Ask for documentation during code review.