We'd like to solve the following perceived problems:
- It is difficult for contributors and project maintainers to find policies that are relevant and must be followed.
For project maintainers, I believe we currently only expect https://www.mediawiki.org/wiki/Gerrit/%2B2 to be understood and followed. Contributors likely won't read this, instead relying on reviewers to correct them as needed.
Our other policies (deprecation, security, ..) tend to be referenced in code-review by maintainers as-needed, but not otherwise discoverable by contributors, and even maintainers themselves might not be aware of them.
It is also somewhat unclear which policies apply to all Wikimedia sofware, MediaWiki core + WMF extensions, and only MediaWiki core.
- It is difficult to distinguish between a documented practice and an officially adopted development policy.
An official policy may set hard requirements that are socially unacceptable to not follow, of which violations are generally expected to be reverted without prior discussion, and may eventually result in revocation. An official policy can also be expected to be up-to-date (Yeah...., more about that later!).
On the other hand, a documented best-practice might only partially represent status quo, or only apply to a narrow subset of code areas (e.g. areas maintained by the authors of the document). Such best-practices may also be amended organically by peers based on goodwill and perceived consensus. Typically, these documents are changed at will, and only reverted/discussed when someone is uncertain or disagrees; these changes usually don't require TechCom involvement.
- It is easy to discover all our official development policies (for new contributors, and for projects maintainers).
- Contributors are able to easily recognise a policy as one.
- Contributors can know, as part of their discovery path, which policies are applicable to them.
- Explicitly code into the policy that changes to the policy follow the RFC process.
Change https://www.mediawiki.org/wiki/Development_policy to be a good entry point for our development policies. Basically, reduce it to just the following two normative statement:
- Changes to MediaWiki core that deprecate or remove aspects of the PHP API, must follow the Deprecation policy.
- Those with merge rights to MediaWiki core or a Wikimedia-deployed extensions/skin for MediaWiki, must follow the +2 policy for all changes they merge.
In addition to changing the "Development policy" page, I would also propose that we move "Deprecation policy" to "Development policy/Deprecation" to clearly mark in URL and first heading that it is part of this hierarchy .
If this RFC establishes the development policy as our entry point, I would recommend that afterward, we revisit some of our other documents. Then, for those we wish to keep in some form, start an RFC with the objective to revise the page in question (if needed) and incorporate it with a sentence in the development policy.
Some of the other documents that come to mind:
- Category:MediaWiki development policies
- Development policy (Status: "Official". Last major revision before 2012)
- Deprecation policy (Status: RFC-Approved. Last revised in 2017)
- Security policy (Status: "Official". Last major revision in 2012)
- Architecture guidelines (Status: Draft. Last major revision in 2014)
- Gerrit/+2 (Status: "Official". Last major change in 2013)
- Misc bits:
- Database optimization (Linked from "Development policy" and "Gerrit/+2")
- Database transactions
- "RFC: Deprecate use of serialize()" – T161647
- TechCom's Platform Architecture Principles