Re: [Wikitech-l] Plan for a Developer Relations team

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