If we are moving forward with this proposal, we need to be in sync with Community-Tech and Cloud-Services. CCing some people that might be interested.

Initiative 1 needs resourcing in the form of product management and code/security review. The code/security review part can sort of be sidestepped by looking for solutions that run outside of the Wikimedia production cluster but that becomes dangerous if the solutions are meant to be general purpose and widely used. Labs and Tool Labs are an awesome resource for our community but we can't start treating them as the place to put mission critical software just because it is easier to deploy things there.

Initiative 2 has been an on going process since I was hired if not before. I'm all for it to continue and expand as long as things don't get hung up on goofy issues like tying the documentation clean up to deploying new skins on various wikis. It also needs resourcing in the form of product ownership, technical writers and outreach to attract volunteer technical writers. Our documentation is never going to compete with the documentation of even a small commercial company as long as we continue to hope that software engineers will suddenly become accomplished writers and editors of technical documentation.

@bd808, yes, I fully agree. Let's see what this means in practice:

Connect free software developers with the Community Wishlist

• T113707: Decision on Wikimedia Foundation service-level agreement on code review times or at least clear progress in T78768: Agree on and implement actions to prioritize code review of patches submitted by volunteers is needed. These continue to team quarterly goals owned by @Aklapper, so at least the current planning and work is consistent.
• @csteipp, see above. Our (tentative) annual plan for strategic work might have a hard dependency in the annual plan for core work of the Security team. Does this make sense to you? Please take this into consideration when organizing security review work.

Promote the Wikimedia APIs

• OK to avoid being hung up on details. Lesson learned in 2015. We have control over this.
• Resourcing and prioritization, in my view it is essential to watch and analyze the feedback and discussions around the WMF Strategy 2016, where topics related with the Wikimedia APIs and technical documentation are on the table. If our APIs are found to be strategically important, then we need to resource this accordingly. And if not, fine, let's just set expectations accordingly and move on.
• Even if the WMF Strategy decides that promoting Wikimedia APIs is important, we cannot expect to get resources for a whole new division. ;) But let's see.
  • The WMF has one role of Tech Writer and also some budget allocated for technical documentation. The problem is that these resources were spread and, now, infra-utilized, partly due to the lack of a clear strategy. Agreeing that these same resources should be lined up towards this goal would be progress already.
  • Outreach, agreed. We must be the only top Internet site with an API and the only company with an API and more the 20 employees in the SF Bay Area without someone appointed as developer advocate. An engineer who happens to be socially skilled and versed in community management, who enjoys going out to places and talk about our APIs, enjoys writing blog posts and improving our documentation with interesting code examples that then demos in screencasts, etc. I think this would be a very good addition to our team.
  • Product management, agreed, although I would expect getting approval for such new role only if the 2016 Strategy marks this as a top priority. Let's wait to see the trends.

In any case, I'm all for pushing this goal in these terms. Looks doable and the right thing to do.

@csteipp, see above. Our (tentative) annual plan for strategic work might have a hard dependency in the annual plan for core work of the Security team. Does this make sense to you? Please take this into consideration when organizing security review work.

@Qgil, can you describe what the most likely plan your considering will be? For my annual plan asks, I'm proposing to cover current levels of code reviews, security reviews, and bug/maintenance. If you're planning something that will need more, then let me know what the size of that is, and either you can make the ask as part of your funding (I'll support your team hiring a Security Engineer just to handle community stuff), or I'll build something into my budget that's tied to your ask.

@csteipp, we are not going to get a Security Engineer in our team, that is for sure. We'll have to look deeper into the Community Wishlist and the expectations to resolve tasks in order to make an estimation of how many new features per year this work could bring.

In T124420#1989766, @Qgil wrote:

@csteipp, we are not going to get a Security Engineer in our team, that is for sure. We'll have to look deeper into the Community Wishlist and the expectations to resolve tasks in order to make an estimation of how many new features per year this work could bring.

@Qgil, cool, can you get me a rough estimate today (even rough order of magnitude)? Otherwise I can add it when we finalize the strategic portion of the budget.

Sorry, I saw this just now. Raw math:

Extra 15 projects going through code review during the next FY.

Reasoning

• While Community-Tech focuses on the top 10 Community Wishlist projects, we aim to help others completing the next 10 tasks (11-20, approx).
• Let's say that 5 more tasks of the list would be completed as well.
• Some of these solutions might be tools or other projects not going through Wikimedia deployment and code review, but let's just ignore this because this is raw math.
• Also, while the CW refers to natural years, our annual plans refer to fiscal years. This could bring some distortion to the flush of finished projects, but that is very difficult to predict, and we are doing raw math.

Thanks @Quim. If our core request gets funded, this shouldn't be a problem to absorb. If that doesn't get funded, then we'll have to prioritize those with the other requests from WMF teams, and decide which are the most important.

Alright, here goes a more solid draft of the narratives. I welcome feedback especially in the KPIs. Are they appropriate? Do we have the means to calculate them?

In T124420#2055005, @Qgil wrote:

Alright, here goes a more solid draft of the narratives. I welcome feedback especially in the KPIs. Are they appropriate?

These four metric seem to be of dubious value to me:

• Number of active projects using our APIs (Wikimedia Labs / External)
• Number of new projects using our APIs (Wikimedia Labs / External)
• Number of non-reverted contributions to Wikimedia projects made via Wikimedia Labs / External API requests
• Number of Wikimedia read queries made via Wikimedia labs / External requests

These are all highly gameable numbers. I'm not seeing the direct correlation between quantity and quality here. Even non-reverted contributions is something that just requires pumping changes into wikis where the level of tolerance for reverting is higher.

Do we have the means to calculate them?

Not yet honestly. T108618: Publish detailed Action API request information to Hadoop is still a work in progress and even when it it done all we will have is a better data set for an analyst to work from.

The idea is how to measure the success of the Technical Writer, the Developer Advocate, and the rest of people contributing to promote the Wikimedia APIs. Counting articles and presentations is something, but... is it enough? The point of promoting our APIs is to increase adoption and to increase their use spreading and improving Wikimedia content.

I wonder if there is any measurement that is conceptually sensible and technically feasible.

Then again, it is pointless to commit to KPIs that we are not able to measure, so I will remove these now. Thank you for the reality check, @bd808 !

I'll save the world from my rants about abusing quantitative metrics to measure qualitative changes.

Perhaps you could craft some periodic surveys to actual gather data on qualitative improvements? It's not entirely clear which audiences you would be interested in most, but I know that Partnerships has tried to run some API consumer surveys in the last 6 months.

I have added details to Milestones/Results/Impact, which was pending. I have tried to collate data from several plans, intentions, and conversations in the past.

Probably the most controversial suggestion is to include T115650: Create an authoritative and well promoted catalog of Wikimedia tools to the plan.

Project / initiative 2: Promote the Wikimedia APIs didn't resist the first rounds of WMF internal negotiation. Therefore we are not asking for a Technical Writer and a Developer Advocate in the annual plan.

From a Developer-Advocacy point of view, this means that our annual plan focuses on recruiting developers for the Community Wishlist and also assure that the Product Development Process makes the most from volunteer developer contributions (in relation to T124041).