Topic on Talk:Wikimedia Engineering/2016-17 Goals/New MediaWiki-focused team/Platform proposal

Gergo, I want to thank you for leading the writeup of this. Having struggled with the scope boundaries for years, I know it's difficult work.

I'd like us to discuss an important scope boundary that this document doesn't cover: what is the proposed scope boundary between this team at the Wikimedia Services team? It would seem that "loosely coupled, well-documented components with clean interfaces and easy-to understand interactions" is exactly what @GWicke has proposed for years, but this document acknowledge potentially competing visions for describing how developers should interact with Wikimedia sites.

One thing that I was hoping would emerge from WikiDev16 is a working framework to address these issues collaboratively. Quoting WikiDev16, we had "Content access and APIs (T119029) - this is about getting our data in-and-out of the system (e.g. rest.wikimedia.org). The central problem in this area: 'how do we make accessing and distributing our data easier and more useful?'". Per T124504, I was hoping a working group would form in this area, but that doesn't seem to be happening.

My thinking behind the Availability proposal is to make the mandate a little clearer for a MediaWiki-focused team. That said, Ori has suggested combining Performance and Availability, which makes sense to me. A team focused on the stability and performance of MediaWiki would be a good counterbalance to desires for aggressive creation of loosely coupled microservices; there is only so aggressive one can get and still have an efficient, easy-to-understand system with respectable uptime.

Thoughts?

Let me try to rephrase what you are saying to see if I understood it correctly.

1. Given that Services and this proposed team both focus on "loosely coupled, well-documented components with clean interfaces and easy-to understand interactions", there is an overlap or conflict of scope.
2. Decoupling into microservices has a cost in availability and easy of use, which needs to be balanced but currently is not. The Platform team would make it harder to form a team (Availability) that would do the balancing.
3. Gabriel's vision and this proposal "acknowledge potentially competing visions for describing how developers should interact with Wikimedia sites".

I'm not sure what you mean by the last one. On the general issue of whether MediaWiki is something developers need to interact with (and thus need to have a good experience interacting with) in the future, the proposal contains my thoughts already. The Services team's charter seems to be in line with that. Did you have something more specific in mind?

About #1, (part of) the scope of the Platform team would be to decouple functionality into independent PHP components. The scope of the Services team includes extracting functionality from MediaWiki into external microservices. The first is a clear prerequisite to the second, and the Services team is clearly not doing that (the team has, combined, three MediaWiki core commits in the last 12 months). So it seems to me there is no overlap and the scopes of the two teams could complement each other nicely.

About #2, I don't see the difficulty. There does not seem to be that much of an overlap between the people interested in the two prospective teams, and in any case, the number of people who have expressed interest would be more than enough for two separate teams.