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 😉 ).

Possible solutions:

• 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.

Possible solutions:

• 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.

Possible solutions:

• 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.

I'm leaving this assigned to me so that folk can tell that my part of this work is done… mostly.