Page MenuHomePhabricator

Reconsidering of eligibility criteria for technical contributions in elections
Open, Needs TriagePublic

Description

The 2021 Board elections are scheduled to take place in the next few months. I would like to flag the voting eligibility criteria for “Developers” previously and should be reconsidered. In 2017, the criteria were

  • Are Wikimedia server administrators with shell access;
  • Or have commit access and have made at least one merged commits in git to Wikimedia Foundation utilized repos between 1 October 2016 and 1 April 2017.

The wording used is not commonly used in the MediaWiki and Wikitech communities. Issues with the above criteria are:

  • The group of “Wikimedia server administrators with shell access” nearly completely overlaps with Wikimedia staffers.
  • There is no hard-defined category as “Wikimedia Foundation utilized repos” (there is some work in progress: T190891: Develop canonical/single record of origin, machine readable list of all repos deployed to WMF sites. , but nothing concrete as of now)
  • "commit access" has an unclear meaning nowadays. It made sense in SVN days but we use Git and Gerrit nowadays. Now anyone can create a Developer Account and "commit" a change to Gerrit as a proposed code change, but whether the change will also get merged ("+2'ed", means: included and made available by default to everyone pulling that codebase) depends on someone else first reviewing that proposed code change in Gerrit.

A significant number of folks do not necessarily make edits to mediawiki.org but are still developing tools, gadgets etc. A good number of them work on Wikitech and/or Gerrit/Git. That requires using an LDAP account (aka 'Developer account'). An LDAP account is separate from the SUL (Single User Login) account used for mediawiki.org and also used by SecurePoll. There are several people who develop and run bots, user-scripts, building tools for deployment on Toolforge (or anywhere else), but don’t necessarily make edits on mediawiki.org or contribute to MediaWiki core - they are being excluded as well.

It seems like these criteria were developed long ago and have not been updated with the changes in practices of MediaWiki and Wikitech contributors. I don’t have a perfect solution as of now but would like to raise this issue with the Elections Committee. It would be helpful if other developers can share their thoughts and what can be good criteria. This will affect not only the upcoming elections but others such as the Steward elections.

Also posted on the talk page of 2021’s election page on Meta-Wiki: https://meta.wikimedia.org/wiki/Talk:Wikimedia_Foundation_elections/2021#Reconsideration_of_eligibility_criteria_for_technical_contributions_in_election

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

These observations are correct. The criteria were definitely developed a long time ago and don't match the current technical situation anymore.

It isn't just "shell access yes/no" anymore. We have many admin groups with different privileges. We also do have a few volunteers with deployment access but it is true that the vast majority are WMF staff. We also have some former staff who used to work for WMF and then kept their access in a volunteer role.

Back in the days "shell access" meant resolving tickets by doing things directly on servers. That is something we now try to avoid as much as possible by using configuration management / devops.

The thing that most people would associate with that nowadays is deployers, people in the specific admin group needed to deploy MediaWiki (config) changes, or, contributing to the operations/puppet repo when working on Infrastructure or in the future more kubernetes.

Regarding LDAP, yes the Wikitech user is considered the "Developer Account" and it gives then access to code review (Gerrit), Cloud VPS and other things. So having one of those could be a good criterium, it definitely indicates someone is involved in more than just editing projects.

Having it is also a requirement for the things building on that, like shell acces.

brennen moved this task from Backlog to Watching on the User-brennen board.
brennen added a subscriber: brennen.

Thanks for bringing this up Jay. I agree those criteria are not great. A first attempt to improve it would be: users are eligible if they made a contribution to Wikimedia software between 1 October 2016 and 1 April 2017.

  • A contribution could be a merged commit, translation, documentation (although that can be handled by the editcount criteria), design, bug report etc. There could be some quantity limit too (one commit is a pretty low bar compared to the 500 edits in the editor eligibility criteria, although of course there are commits which take a lot of effort).
  • Wikimedia software is anything that's written primarily for the Wikimedia community to use (we don't want to give voting rights to e.g. Apache committers even though Apache is used on the Wikimedia servers, but we also don't want to exclude e.g. the maintainers of Wikiloop, who are technical contributors maintaining a Wikimedia tool, even though neither the tool itself nor its source code or issue tracker is hosted on Wikimedia infrastructure) and does get used to some extent by Wikimedia community members (we don't want to include completely theoretical projects that the movement doesn't actually benefit from).

I think "Wikimedia server administrators with shell access" can be discarded; it's hard to imagine someone in that category not having a single merged commit in a year.

That leaves the issue of MediaWiki technical contributors whose work is not specifically directed towards the Wikimedia movement (e.g. people who authored MediaWiki extensions which aren't used on Wikimedia sites). I'd err on the side of inclusivity here; MediaWiki itself is one of the Wikimedia projects and contributions that make it more versatile for non-Wikimedia use cases still further the mission indirectly.

How does all this get verified (manual verification is presumably not really feasible)?

  • Merged Gerrit commits (to any repo), assuming people will have some way of proving ownership of their LDAP account
  • Merged Github commits to any repo in https://github.com/MWStake/nonwmf-extensions or https://github.com/MWStake/nonwmf-skins (which are not necessarily comprehensive but you have to pull the line somewhere)
  • Translatewiki edits (Translatewiki is an OAuth server so that could be used to verify ownership)
  • Commits to any Wikimedia tool repo, such as e.g. https://bitbucket.org/magnusmanske/magnustools (we'd have to make a list of these)
  • Design, product management etc. contributions cannot be automatically accounted for, but maybe they are rare enough that they can just be managed via some manual verification process.

Originally the "committer" criterion was introduced because it seemed unfair that some formerly active Wikimedia wikis contributors, who had become less active due to spending all their time on the software side of things, would lose voting rights when the activity requirements were raised. It's not meant as a cure-all for the broader issue of "how representative the WMF board is?".

Some of the criteria proposed above may sound sensible but seem unnecessarily complicated to me. I don't know how much bandwidth the election committee has to handle such matters, but historically they barely had the time to get someone to run a script to list the eligible usernames, verify the output made some sense, add it to the election, and later verify that no unseemly voting had happened (like double voting).

Instead of looking for a "perfect" or "complete" set of criteria, I suggest we may want to focus on having a single criterion which is easy to understand, use and verify. For instance, I think it's perfectly fine to just consider actions and/or commits in Gerrit, for accounts linked to some SUL account. Then offer clear instructions for people to make sure their contributions are counted (including moving their extension to Gerrit if they want), and make sure they're emailed to "everyone".

I have asked the Election Committee to compile the response.

If someone still wants to give their valuable feedback. I welcome you. More feedback will eventually help the committee to alter current eligibility criteria.

including moving their extension to Gerrit if they want

I'm not sure how to interpret the lack of technical support to the election committee in previous elections but to restrict the criteria to gerrit seems very exclusionary.

Hi friends, thank you for discussing this. I am one of the Board election facilitators supporting outreach for this Wikimedia Foundation Board election. I see this is still under discussion and I do not see a clear recommendation for the Election Committee. Is there a clear way forward and I perhaps missed something?