Some related links to add to the RFC:

2015

• Related RFCs
  • T89889: RFC: Service split along presentation vs data manipulation line
  • T88301: RFC: Clean frontend - backend separation; make all frontends API consumers
• WikiDev Summit 2016: Next Generation Content Loading and Routing
  • Content analysis - Live version
  • Backend rest service prototype
  • Frontend Server & PWA prototype

2016

• PWA mobile web prototype: Weekipedia - Live version
• New readers research
  • meta.wiki: Research info & findings
  • PWA prototype used - Live version

2017

• Project information
  • Technical overview
• ArchCom 2017/03/15 notes on "High level mobile frontend requirements & plans"
• Related discussions and socialization:
  • T157014: CONSULTATION/PLAN: Managing Complex State and GUI on MediaWiki (e.g. for Wikidata/Wikibase UI)

Another related RFC: https://www.mediawiki.org/wiki/Requests_for_comment/Services_and_narrow_interfaces. I imagine that the issues identified in that RFC will be brought up again in this RFC, so it's something that we should address as part of the initial submission.

I'm not sure if it's clear from the RFC process wiki pages, but a recommended practice is to run the RFC earlier rather than later.

Before writing an RFC, it makes sense to research, analyze, and experiment enough to be able to include specifics in the RFC itself. But ideally the RFC would be circulated before a large investment has been made in a specific technological solution. So to throw out some arbitrary numbers, I would favor spending a day or perhaps up to a couple weeks of effort before writing an RFC. I would definitely want to solicit input via the RFC process prior to spending a month or more developing something. Different people would have a different threshold, but probably they would fall within an order of magnitude of that.

It hasn't been clear to folks in TechCom whether this project is still in the exploratory stages, or if it has shifted to implementation. That uncertainty has led to concerns that the project might be at risk of advancing too far before getting broad input. (The main consequences of that would be the risk of wasted technical effort and/or the need for rework.)

Anyway, thanks for putting the RFC front and center as a necessary part of the project.

+ @dr0ptp4kt +@JMinor

Quoted Text It hasn't been clear to folks in TechCom whether this project is still in the exploratory stages, or if it has shifted to implementation. That uncertainty has led to concerns that the project might be at risk of advancing too far before getting broad input. (The main consequences of that would be the risk of wasted technical effort and/or the need for rework.)

Thanks @ksmith - you know how I feel about waste ;)

@phuedx @ovasileva
Can we clarify the stage of project to @ksmith ? Would a synchronous conversation help clear up issues faster? Thanks!

Thanks for the insights @ksmith

In T177464#3661680, @ksmith wrote:

I'm not sure if it's clear from the RFC process wiki pages, but a recommended practice is to run the RFC earlier rather than later.

Right, we actually met with ArchCom in March and presented product notes and technical architecture overview for comment (not an official RFC but more a consultation on the approach to get early feedback).

Some of the final comments were about it being to early and not having a working POC to evaluate. Some members and other people encouraged us to come back with more concrete proposals that could be discussed, so we've been working to clarify things until we came back.

Before writing an RFC, it makes sense to research, analyze, and experiment enough to be able to include specifics in the RFC itself. But ideally the RFC would be circulated before a large investment has been made in a specific technological solution. So to throw out some arbitrary numbers, I would favor spending a day or perhaps up to a couple weeks of effort before writing an RFC. I would definitely want to solicit input via the RFC process prior to spending a month or more developing something. Different people would have a different threshold, but probably they would fall within an order of magnitude of that.

Cool, makes sense. We have been doing different types of work for years as you can see in T177464#3660011 so with those and what we have now we have a good backlog of information to write an initial plan down.

It hasn't been clear to folks in TechCom whether this project is still in the exploratory stages, or if it has shifted to implementation. That uncertainty has led to concerns that the project might be at risk of advancing too far before getting broad input. (The main consequences of that would be the risk of wasted technical effort and/or the need for rework.)

That makes sense. We prefer to think in more agile terms. We hope to achieve the best result by iterating, and so does product, which has requested we do more exploration in front of real users instead of a waterfall process of development to ensure a higher chance of success with end users on the end product.

Thus, we as engineers have created a task (parent) to figure out how to take this early version of the project in front of real users in 6-8 months which means deploying to production. We didn't think that sending real users traffic to a staging deployment in wmflabs was a very good idea.

Precisely the intention to deploy early to get early user feedback is to avoid the long term risk of wasting effort on something users don't like.

Anyway, thanks for putting the RFC front and center as a necessary part of the project.

Of course, there is extremely valuable experience and comments that the RFC provides. Hopefully we can also figure out a way to actually deliver an early product to (some) production users as well!

Thank you for your feedback, it is very much appreciated.

In T177464#3661861, @Jhernandez wrote:

That makes sense. We prefer to think in more agile terms. We hope to achieve the best result by iterating, and so does product, which has requested we do more exploration in front of real users instead of a waterfall process of development to ensure a higher chance of success with end users on the end product.

Thus, we as engineers have created a task (parent) to figure out how to take this early version of the project in front of real users in 6-8 months which means deploying to production. We didn't think that sending real users traffic to a staging deployment in wmflabs was a very good idea.

Precisely the intention to deploy early to get early user feedback is to avoid the long term risk of wasting effort on something users don't like.

I find it helpful to distinguish between deep architecture/technology decisions which are hard to reverse, and feature/product/UI decisions that are relatively easy.

I'm completely on board with agile for the latter, and would love if you were able to find a way to start getting real user feedback even faster than 6-8 months from now. But at least some technology decisions must be made at the start of the project, and are very difficult to change later. It's those decisions that benefit most from the RFC process.

The RFC process covers strategic/cross-cutting/hard-to-undo technology decisions. I hope it is (and remains) compatible with agile feature development. And that we as an organization more fully embrace agile user feedback loops.

I agree with you that sending real user traffic from labs is not a good idea.

In T177464#3662059, @ksmith wrote:

I find it helpful to distinguish between deep architecture/technology decisions which are hard to reverse, and feature/product/UI decisions that are relatively easy.

I agree 👍, which is why we presented the architecture to ArchCom in March. No strong opposition or blockers were raised.

I'm completely on board with agile for the latter, and would love if you were able to find a way to start getting real user feedback even faster than 6-8 months from now.

Definitely, we are planning on doing controlled user tests in the staging environment until we are ready with some production infrastructure to where we could send a tiny portion of users (always only if they opt-in).

But at least some technology decisions must be made at the start of the project, and are very difficult to change later. It's those decisions that benefit most from the RFC process.

Of course. We will present it again 🙂

The RFC process covers strategic/cross-cutting/hard-to-undo technology decisions. I hope it is (and remains) compatible with agile feature development. And that we as an organization more fully embrace agile user feedback loops.

I'm fully with you. We will present again making a proper RFC phab task following the process.

@Jhernandez : All sounds great. Thanks.

Also, I apologize for not being aware/remembering about the presentation to TechCom back in March. It's great that happened, and that more interaction is planned.

For anyone curious, the closest document to an actual "RFC" appears to be https://www.mediawiki.org/wiki/Reading/Web/Projects/NewMobileWebsite.

It remains unclear why anyone thinks that a product should be both developed and deployed to production before being planned or discussed.

It also remains unclear how this new Marvin project is different from the very problematic MobileFrontend and Wikipedia Zero projects (or the problematic Ruby-based mobile interface that preceded MobileFrontend), all of which had dozens, if not hundreds, of lessons of what not to do that should be incorporated into any future related proposals.