Page MenuHomePhabricator

Technical Collaboration narratives and budget for strategic work
Closed, ResolvedPublic


WARNING: this is a wild draft; everything may still change.

Strategic goal: Volunteer developer contributions aligned with Wikimedia communities' requests

We will connect our volunteer developers with the needs of the Wikimedia communities expressed through the Community Wishlist survey. This focus will guide our efforts reaching out to new developers, onboarding, and supporting them, and increasing the levels of retention. We will promote the use of our APIs as a way to get started in Wikimedia development without having to go first through the complexities of MediaWiki development and deployment to Wikimedia servers.

Project / Initiative 1: Connect free software developers with the Community Wishlist

Focus our developer outreach activities in the resolution of projects listed in the Community Wishlist maintained by the Community Tech team. This comprises the hackathons we support, outreach programs like Google Summer of Code and Outreachy, and the onboarding support for new contributors, as well as our support to volunteer collaboration in documentation, project management, and code review processes.


Please provide milestones/results/impact and describe how they will impact/contribute to the Wikimedia movement and projects and/or the Wikimedia Foundation.

Project/Initiative 1:

  • Milestone: Triage of the Community Wishlist tasks, selecting those apt for our developer outreach activities based on votes and strategic fit.
  • Milestone: Recruitment of mentors for the top 10 tasks selected.
  • Milestone: Each selected task is promoted to the most suitable outreach activities: hackathons, GSoC, Outreachy, collaboration with universities.
  • Impact: new volunteer developers find useful tasks and mentors easily, increase their chances of deploying useful features.
  • Impact: our hackathons and outreach programs increase their productivity just by channeling their work toward popular community requests.
  • Result: 10 technical community requests with strong demand to be completed by volunteer developers.

Key Performance Indicators (KPIs) or Metrics to measure milestones/success of projects/initiatives

Please ensure that these are both qualitative and quantitative. Some departments may have the same metrics as the following 7 Global Metrics identified for the FDC proposals. Others may need to identify their own KPIs or metrics that are appropriate for their objectives. For example a supporting function such as Office Admin, KPIs or metrics may be in the form of Service Level Agreements.

Project/Initiative 1

Number of volunteer code contributors to Community Wishlist projects
Number of Community Wishlist projects completed
Community health survey for Wikimedia technical spaces

Budget requests

(For now the numbers are provided only in the WMF internal draft)

  • Events (Logistics and volunteer travel sponsorship for Wikimedia Developer Summit and Wikimedia Hackathon)
  • Outreachy internships
  • Merchandising
  • Maintenance of tech community metrics (

Due Date:   Friday, March 4, 2016
Solid draft expected by Feb 26

See also T124041: Technical Collaboration narratives and budget for core work

Related Objects

Event Timeline

Qgil claimed this task.
Qgil raised the priority of this task from to Medium.
Qgil updated the task description. (Show Details)
Qgil added subscribers: Aklapper, Qgil.

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

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.

Quiddity set Security to None.

@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.

@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.


  • 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.

Qgil renamed this task from Community Liaisons and Developer Relations narratives and budget for strategic work to Technical Collaboration narratives and budget for strategic work.Feb 11 2016, 7:35 AM
Qgil raised the priority of this task from Medium to High.Feb 12 2016, 9:07 AM

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?

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.

Qgil lowered the priority of this task from High to Medium.Feb 26 2016, 10:28 AM

Today we are delivering this plan to start the internal review process. We will need to respond to requests, but not push actively as until now. I'm lowering the priority accordingly.

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).

Qgil lowered the priority of this task from Medium to Low.Mar 17 2016, 11:52 AM

I'm lowering the priority of this task only because from now on my role is going to be more reactive than proactive. For more details, see T124019#2129027.

The result of this task can be seen at

The review process has started (and in fact I already replied to one question in the discussion page). The work of responding to feedback during the review process is tracked in the parent task: T124019: Define the Technical Collaboration annual plan FY2016-17.