Core Platform Team/Initiatives/Authority
This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. The Core Platform Team and its initiatives do not exist anymore. See MediaWiki Engineering Group instead since 2023. |
Authority
|
Initiative Vision
This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. The Core Platform Team and its initiatives do not exist anymore. See MediaWiki Engineering Group instead since 2023. |
Vision:
|
Theme: Code health (decoupling) | |||
Stakeholdr(s):
|
Problem:
|
Solution:
|
Aligned Goals:
|
Initiative Description
This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. The Core Platform Team and its initiatives do not exist anymore. See MediaWiki Engineering Group instead since 2023. |
- Summary
Explore modelling of Authority for permission checks (phab:T231930)
- Significance and Motivation
High level: Improve readability, testability, and reliability. Concretely: experiment to inform the RFC that defines a new first class entity.
- Outcomes
An experimental definition of the Authority interface along with a first implementation exists. Existing code code has been extended to support the new mechanism, partially by duplicating existing functionality. Other code continues to use the old mechanism. After the experiment has been evaluated, we will schedule time to either undo the changes, or make them stable and permanent.
- Baseline Metrics
None given
- Target Metrics
REST endpoints have been ported to using the new mechanism. At the end of the experiment, we commit to evaluate the new concepts and mechanisms, and then either remove them again, or commit to making them available for use throughout the MediaWiki ecosystem.
- Stakeholders
see vision table
- Known Dependencies/Blockers
some overlap with phab:T208776 (PageIdentity)
Time and Resource Estimates
This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. The Core Platform Team and its initiatives do not exist anymore. See MediaWiki Engineering Group instead since 2023. |
- Estimated Start Date
None given
- Actual Start Date
None given
- Estimated Completion Date
It should be understood that once the spike project is finished, and the experiment evaluated, we need to schedule time to either undo the changes we made, or to follow through with the RFC, and make the changes permanent and stable once it is approved.
- Actual Completion Date
None given
- Resource Estimates
Three engineers for two sprints, doing at least six hours of pair programming per week, in addition to async work.
- Collaborators
None given
Documentation Links
This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. The Core Platform Team and its initiatives do not exist anymore. See MediaWiki Engineering Group instead since 2023. |
- Phabricator
- Plans/RFCs
- Other Documents
None given
Subpages
Poll
Team members are invited to voice support or opposition, and give their reasoning.
- Support Makes sense PPchelko (WMF) (talk) 13:35, 8 September 2020 (UTC)
- Support This work will allow us to not only decouple a key piece of core code but to test our approach to decoupling, measuring the impact of the work as well as unlocking us to approach future changes to our permission model. WDoran (WMF)
- Support Removing another component that relies on global state sounds like a big positive to me NNikkhoui (WMF)
- Neutral Not enough knowledge of the subject area to vote with confidence APaskulin (WMF) (talk)
- Support Improving code health by improving testability sounds good to me. AMooney (WMF)
- Support This will make code more testable CAndrew (WMF) (talk) 20:13, 8 September 2020 (UTC)
- Support This initiative will improve code health and demonstrate management's commitment to addressing this issue.NNzali (WMF)
- Support This would be a very positive change. I note that this initiative is just for exploring the change. If it is successful, we should be prepared for an additional resource commitment to introduce the change and migrate existing code. BPirkle (WMF)
- Support Improves code quality and testability. CCicalese (WMF) (talk) 19:41, 10 September 2020 (UTC)
Please use the polling templates, for example:
* {{support}} I like this example! ~~~~
* {{weak oppose}} This is not a great example example... ~~~~