Wikifunctions:Status
This page aims to give a reasonably current view on the current status of Wikifunctions. If something does not work, this page is a good first stop to check if that is a known issue.
This page is not the complete source of details. A more immediate view is the "Abstract Wikipedia" Phabricator board. This page just aims to provide a good and more easily understandable overview of major known issues and problems.
See Wikifunctions:Report a technical problem for details on how to report a bug or make a feature request.
Summary: This page is not complete. We don't plan to list every single user facing issue, but merely the main ones.
Prioritisation framework
This is the framework the development team use to make sure we're working on the important things for you.
| Level | Meaning | Timeliness | Areas of concern | Example |
|---|---|---|---|---|
| P0 | A critical concern in production that must be fixed immediately | Fix immediately. Drop everything. |
|
|
| P1 | The service is significantly limited, for a large number of users | Fix within a week. |
|
|
| P2 | The service is limited, for a smaller number of users | Fix within a month. |
|
|
| P3 | The service is imperfect, or could do better (including new feature requests) | Triage and set expectations. |
|
|
Is anything currently very broken?
- No current known P0 or P1 issues!
What are we working on this Quarter? (October–December 2024)
Each Quarter, we set out in a Weekly Update our plans, and then report on how we're doing.
The current work plan, for October–December 2024, was published in 2024-09-26:
- (T376521) Enable one Wikifunctions use case in one language Wikipedia: Just two weeks ago, we announced that we aim to have our first integration with Wikipedia on the Dagbani Wikipedia. We aim to develop everything needed for that integration this quarter, and to likely deploy it very early next year (i.e., January 2025).
- (T376078) Wikipedia integration usability improvements: We will continue our research, design and user test usability enhancements to make the integration of Wikifunctions into Wikipedia easier. The implementation of these design improvements will happen afterwards.
- (T376662) Iterate the Wikidata integration, and plan its and the Type system's evolution: We are very close towards the first integration of Wikidata into Wikifunctions. The next quarter will see us extend that integration to cover more parts of the Wikidata data model, and to evolve the Wikifunctions type system to work with that.
- (T376664) Wikifunctions services alert monitoring: We want to be automatically notified when the Wikifunctions services are having issues.
- (T376668) Service platform improvements: Our services are built on top of an outdated "template" of how to write a back-end service, originally created a decade ago before many changes in how Wikimedia manages them. We want to modernise our services, replacing the base platform with a simpler, faster framework. We also will explore rewriting the evaluator in a different language better suited to process management.
- (T376671) On-wiki tooling to improve content and help editors onboard: We plan to create a set of related special pages to support the Wikifunctions community with maintenance, like finding proposed Implementations that need to be connected, or Functions that don't have any labels in a given language like French or Igbo.
- (T368002) Testing Wikifunctions Services with Catalyst: Catalyst is the Wikimedia Foundation’s platform to support development through Continuous Integration and testing. We want to integrate the Wikifunctions backend services.
- (T375065) Improve performance of the PHP layer: We want to give the MediaWiki layer a proper audit. For example, we know that we are validating objects more often than needed. The goal is to cut unnecessary work and improve performance.
- (T376663) Make Phabricator more useful for the team: Phabricator is our main task and bug management system, but it needs some work to get a better handling of the many tasks on our board so that we are focussed on working on the right things at the right time.
- (No Phab task) Establish team chores practice: As a team, we want to adopt practices to help us improve reliability of the site and our responsiveness to issues and questioned that you raise on the site.
You can see our team's Phabricator board for the current Quarter for more detailed tracking of how things are going.
Longer-term plans
- These are issues that we hope to work on in the future, as part of the bigger plans for Wikifunctions and Abstract Wikipedia. We will prioritise between them based on your feedback and ideas.
Type creation is locked-down to staff
For now, we only support a limited number and nature of types, and creation is limited to only staff. There are a number of built-in functions, e.g. first element of a list, typed list, and many others, which are currently not well-supported for custom types, which we are looking at addressing. Generic types and generic functions require a bit of development and bug-fixing, and are not ready yet.
You cannot embed Wikifunctions calls in Wikipedia articles, Wiktionary entries, etc.
This is a vital part of helping communities get the benefit of Wikifunctions, as well as building towards the Abstract Wikipedia goal. We're currently working on this
Function pages don't show you where or how much they're used
This would be an important way for the Wikifunctions community to decide how to focus effort and warn users of changes, like how the GlobalUsage tool guides the Commons community.
Diffs are ugly, so it's hard to do vandalism patrolling or community moderation
For now, diffs "work" but shows ugly blobs of JSON rather than a nice, understandable, formatted result. We want an experience like Wikidata's or better.
Search is ugly, so it's a problem to find things
For now, the search "works" but shows ugly blobs of JSON rather than a nice, understandable, formatted result, and you can't filter by type of object (e.g. "show me only Implementations that match my search").
Note: You can include the required type’s reference (e.g. "Z14") prefixed by the literal "Z1K1:" (case insensitive) in your search. For example, "suffix z1k1:Z14" will tend to find Implementations containing the string "suffix" (because Functions and Test cases are unlikely to contain a string that is equivalent to "z1k1:Z14, whereas all Implementations contain "Z1K1": "Z14" in their JSON representations and this is equivalent to "z1k1:Z14").