A lot of my "management" time during this quarter has gone into annual plan, end of fiscal year, and hiring a developer advocate. Our next quarterly review in a couple of weeks will follow the same structure as the previous one. I'm pushing this task to the next quarter.

Note by @Elitre: if someone had participated to a conference and given a session, in which workflow should that be mentioned?

(I don't know where it would belong yet, but it sounds like an interesting metric for the entire dept/org?)

"Number of participation to community events" would be a good KPI, but is attending to such events in our scope? (To me it is a yes.)

Mere participation maybe not so much- although it may be yet another thing to track somewhere.

I had this fantasy about storing tabular data in Commons and then present it with graphs, on our wiki pages. Technically doable. A bit of work the first time, but then adding data once per quarter should be quite trivial.

Thanks to @Elitre, I am learning how the Team-Practices group uses light engagement surveys with the Foundation teams they work with.

This task is progressing indirectly thanks to the initial discussions about the Wikimedia Foundation Annual Plan program that will organize the support of Community Liaisons to Product. We will share this proposal publicly as part of the WMF process to share the annual plan.

We *might* discuss and decide on these KPIs etc before. We'll see.

I have captured in the description measurements that are being discussed as part of our annual plan drafts.

I believe we have enough ingredients in the Community Liaisons side.

@Aklapper @srishakatux @Rfarrand, we need to define the exact metrics that we are going to use to measure our efforts onboarding new developers.

Code review is a must (and Andre should propose what exactly are we measuring there) but it cannot be the only magnitude. We have other entry points that don't go through code review: Labs, Bots, Gadgets, Lua Modules, whatever happens in GitHub...

The good news is that the scope to measure are the recommended projects first. From the description:

Number of software projects recommended for new developers, based on their ability to provide mentors, good entry-level documentation, first tasks, and a roadmap.

If we nail down the metrics within this very controlled scope then we will have a very good starting point.

Quim, have the KPIs for CLs changed? I see a long list of things to consider, but no comments that look like a final decision.

I think those are the ones suggested for our future annual program, they're not "frozen", but they make sense with the kind of work we said we'd do.

Yes, the batch I added comes from our annual plan proposal, where targets and milestones are required. As Erica says, those are currently proposed and open to discussion.

Something I like about this situation is that these KPIs will become official on July 1 (together with the rest of the WMF Annual Plan) unless someone challenges them before. :)

In T132499#3079825, @Qgil wrote:

Code review is a must (and Andre should propose what exactly are we measuring there)

I've created T160430 for that (which is a stub)...

If we nail down the metrics within this very controlled scope then we will have a very good starting point.

Generally speaking, https://wikimedia.biterg.io allows applying a filtered view of activity in certain code repositories (and sharing a static URL for that view).

[slightly offtopic]

In T132499#3079825, @Qgil wrote:

We have other entry points that don't go through code review: Labs, Bots, Gadgets, Lua Modules, whatever happens in GitHub...

Regarding Lua modules, I asked anomie in 11/2016 "if you know of any way to get a list of the most active Lua template editors across WMF sites?"
His answer was "Not really. The best you might do would be to look at the top editors in the Module namespace on different wikis, although that might as well catch people who make lots of edits to some test module [...] or (on smaller wikis) people who copied/pasted modules from other wikis."

The discussion specific to Developer Relations is happening at T160430: Have statistics which allow measuring success of a potential "Onboarding new developers" program.

I have started to put all this together at https://meta.wikimedia.org/wiki/Technical_Collaboration/Metrics