Hi Quim, A scope expansion for your team makes sense to me. I have two questions. 1. Does your team currently have the capacity for this scope expansion, with only existing staff, while continuing to support the existing Community Engineering mission? 2. Will the team continue to have goals related to code review? Pine On Jun 29, 2015 2:01 PM, "Quim Gil" <qgil(a)wikimedia.org> wrote:

On Jun 29, 2015 3:01 PM, "Quim Gil" <qgil(a)wikimedia.org> wrote: https://www.mediawiki.org/wiki/Engineering_Community_Team/Developer_Relatio… https://www.mediawiki.org/wiki/Engineering_Community_Team/Developer_Relatio… Interesting. I like a lot of this. I think perhaps you should define your target groups more clearly. You are using the phrase "developer" and "third party developer" to refer to different groups of people than I usually refer to with those words. Which is fine, i understood what you meant, but if there is the potential for different people to interpret those words differently, perhaps they should have stated definitions to avoid confusion. The types of developers section kind of confuses me. Is it saying that the wmf focus of mw api users has been labs users only? Because i think wmf has focused on a much broader section of api users than that. I think it might be a useful idea to expand this section into an enumeration of all the different type of tech people into broad classes, and document the sorts of things they work on, so we know who the target audiance of this project is. If there are tech people who are explicitly out of scope, i think it should be explicitly documented who is definitely not a target or who is tangently a target as time permits but id largely out of scope. success. Therefore, if we want to be successful at partnerships, distribution and user acquisition, we too must have multiple APIs that are modern and well-documented." I disagree with this statement. The key to success is apis that provide the required information in as easy to access way as possible. Modern is mostly in the eye of the beholder, and chasing after whatever is the most recent fad is not always best for our users (but sure, we dont want to be using some forgotten design paradigm from the 90s either). The number of apis is also fairly irrelevent, all that matters is if they fulfil the need properly. Simple to use is great, but depending on what the api is trying to achieve, sometimes flexibility and power is more important. We should be considering our apis like any other piece of software: who are the stakeholders, and what are they trying to achieve. From there all other considerations should flow. -- Bawolff

Quim Gil wrote: Hi. In the "Developer offering" section, I see "APIs to extract, publish, edit, and monitor Wikimedia content from external apps and services." Does this mean that your team will be developing new APIs? For example, to add or remove a category from a page. Or to extract information out of Wiktionary and Wikisource. "Developer Relations" makes me think this is closer to public relations, or marketing and branding for Wikimedia's APIs. I'm not sure that's a good use of resources. Event coordination seems like a much better fit. I see mentions of "Wikimedia Developer Summit 2016" and "Wikimedia Hackathon 2016" on the page. Has the MediaWiki Developer Summit been renamed? And is the Wikimedia Hackathon the one that takes place at Wikimania or a different one? Can someone please remind me why dev.wikimedia.org is needed? We have <https://www.mediawiki.org/wiki/How_to_contribute> linked from the footer of every Wikimedia wiki as a "Developers" link. If you want a shorter, more memorable URL, can't we just make dev.wikimedia.org a redirect to the "How to contribute" page and be done with it? Any additional documentation and showcasing can be done on mediawiki.org wiki pages. Why all the fuss? MZMcBride