Wikimedia Release Engineering Team/Project/Self-serve CI

Goal
Provide a simplier job definition system so repo owners can create and modify their own CI jobs without having to understand and wait on merges to a central repo of JJB configuration.

What

 * Maintain two long-lived production branches, wmf/next and wmf/prod
 * Periodically merge from master into wmf/next. As part of this process, all merged commits should be briefly reviewed for production readiness
 * Communicate with the author of questionable or not-well-understoon commits. Release engineering should be confident that a change is reasonable before merging to wmf/prod. Otherwise the commit will be reverted on the branch.

Dependencies

 * Possible tech ops dependencies and/or expertise - RELATED TO WHAT?

Milestones

 * 1) Migration of all jobs/projects to isolated CI instances and further isolated CI processes
 * 2) Central service and/or toolchain library for provisioning/tearing down dependent resources in the CI cluster such as MW installs, Elasticsearch, etc.
 * 3) Ability of teams to define/edit their own CI jobs without idiosyncratic knowledge of Jenkins Job Builder

Movement

 * Less friction for staff and volunteer developers in automated testing/linting/packaging and, as a result, more reliable MediaWiki software overall

Foundation

 * More shared understanding of CI jobs and less toolset fragmentation (teams moving to Travis, etc. for lack of understanding of a complex in-house CI system)

KPI

 * ratio of changes in per-repository CI definitions to changes in central RelEng maintained CI configuration