Page MenuHomePhabricator

[EPIC] Create proposed technical goals
Closed, ResolvedPublic

Description

Created:

  • T140882 Extracting MobileFormatter to a composer library
  • T138071 Fast isolated unit testing in MobileFrontend
  • T141087 Feature management ("flagging")
  • T141936 Progressively enhanced watchstar
  • T144402 Extract core/foundational UI components from MobileFrontend

Some day

  • MobileView api
    • Split it out to it's own extension
    • Improve test coverage, business use cases
    • Evaluate if refactoring would make sense
  • Extract Special:Nearby into its own extension

Need more thought/discussion before tasking out

  • Improve RL usage in MobileFrontend
    • Either use a linter that matches dependency trees with the actual code
    • Or use an external bundler for the dependency graphs and just include entry points in extension.json

Event Timeline

Hi @phuedx. Please associate at least one project with this task to allow others to find this task when searching in the corresponding project(s).
Also, with the current empty task description it is hard for others to help and contribute, or for a triager/tester to figure out at some point in the future whether this task is still valid. Please consider elaborating. Thanks.

@Aklapper: I'll update the description to note that this, for the moment, is a placeholder task for @Jhernandez and myself.

Proposed: Extracting MobileFormatter to a composer library

Proposed:

  • MobileView api
    • Split it out to it's own extension
    • Improve test coverage, business use cases
    • Evaluate if refactoring would make sense

Proposed:

  • Improve RL usage in MobileFrontend
    • Either use a linter that matches dependency trees with the actual code
    • Or use an external bundler for the dependency graphs and just include entry points in extension.json

This is one goal of mine this quarter

Proposed:

  • Fast isolated unit testing in mobilefrontend

Proposed by @phuedx:

  • Feature flagging modules for php and JS
    • Followup to migrate current features to it
    • Followup to remove access to isBeta in php and JS (to force relying in feature flags)
    • Special page like Special:Versions that shows the flags and which are enabled

Just voicing a +1 on the feature flagging point, specifically I think it'd be useful for local instances and 3rd party users to have a special page like the one mentioned.

  • Extract core/foundational UI components, document the hell out of them, providing examples of how to use them to build new features, and place them way, way, WAY outside of the standard MobileFrontend hierarchy
    • Since Joaquin introduced me to it, I always think of Redux when I think of the outstanding documentation
  • Extract Special:Nearby into its own extension

So... could someone please associate a project to this task so clueless people like me could get a basic idea what this is related to? Web-Team-Backlog ? Thank you...

Jhernandez edited projects, added Web-Team-Backlog; removed MobileFrontend.

@phuedx I've added those to the description.

Are we including documentation-related things in this task? Because I have a slew to mention if we are.

@jhobs: Yes. Mention away!

Bah, I didn't check this on Friday and have since forgotten the specifics of what I was referring to. I'll dive into code again and mention stuff here.

Documentation things:

  • Config variables are poorly documented. It's currently hard to tell exactly what they do and, as we've recently seen with wikidata descriptions, having a vague idea is not good enough. The new feature logging system should help with this, but let's find an easy way to attach config variables to features in documentation.
  • We don't really document our process for making contributions very well. We have sections in README.md that explain tests and commits, but some aren't especially well-written. As an example, I tried following the instructions for running tests and was immediately met with an error and nowhere to go for troubleshooting (if I were a first-time volunteer who didn't know about #wikimedia-mobile on IRC). In order to help onboard new devs and encourage volunteer contributions, I think we should refactor the top of README.md to be a bit more "how-to", or have another document in the repo to describe how to get started. If we decide on a new document I'd recommend CONTRIBUTIONS.md or CONTRIBUTIONS.mediawiki, the latter of which could correspond to a page on mediawiki.org.
  • As a contributor, if I'm not sure of how to properly document a method (syntax, format, etc.), my only real option is to open similar files and hope they have the info I need. For example, I've never known what @ignore does and can only assume it forces the linter to skip the method or something, which is odd as I've seen it on multiple important methods. For me, the answer is as simple as "ask a team member," but volunteers would be much more lost. We should more easily expose documentation -- be it links to official websites or our own documentation -- for libraries, testing frameworks, linters, and any other tools we use. Another example of this is our Selenium tests. We use a custom mediawiki implementation of Selenium, which is already not the most well-known framework. Googling for answers when writing a browser test for our extensions hardly provides useful info and will often just lead people to forego writing tests altogether.
  • There are several undocumented methods, parameters, return values, etc. within our extensions, as well as just poorly documented ones (https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/includes/api/ApiMobileView.php#L45-L243, for example). A clean sweep is probably overdue. This bullet point alone could translate to an epic with subtasks for checking/fixing documentation for every feature.

I'm sure there's more, but this is what I've found for now. In general I just think it's very easy for someone to feel lost within our code rather than knowing exactly where to look to fix Problem X, even if we mark Problem X as an good first task task.

@jhobs: Each of those bullet points can be converted to a subtask of an epic, if you're up for it. As a frinstance, see T141755.

@phuedx Yeah, I went to go do that but I'm a bit unclear on whether I should make one epic for each extension, or an epic that spans all of our extensions, and on top of that, what to call it. I think perhaps a general "Update documentation across all Reading Web extensions" is perhaps a better task to make, but make it as a goal and then create epics from the bullet points above with subtasks for each extension (or further split if necessary). In the case of a new goal, we could attach T141755 to it.

MBinder_WMF renamed this task from Create proposed technical goals to [EPIC] Create proposed technical goals.Aug 11 2016, 8:21 PM
MBinder_WMF added a project: Epic.
Jdlrobson added a subscriber: Jdlrobson.

Now these tasks are created it seems an idea to resolve this and say this is done. Anything in comments should be captured in Phabricator tasks.

Now these tasks are created it seems an idea to resolve this and say this is done. Anything in comments should be captured in Phabricator tasks.

Resolve it once everything's been captured, right? Ping @jhobs.

There are some things that need tasks still, I'll work on creating the ones in the description.

@jhobs Reply when yours are created and I'll close this.

Created T143323 to reflect the documentation tasks.
cc/ @Jhernandez

Jhernandez updated the task description. (Show Details)
Jhernandez updated the task description. (Show Details)

Resolving for now