this is to let you know that the "aphlict" service has been disabled on
Phabricator (for now) because it caused stability issues.
This means you will not get realtime (pop-up) notifications on Phabricator.
(If you had those enabled in the first place).
Regular notifications (that do not pop-up) and emails are not affected by
Daniel Zahn <dzahn(a)wikimedia.org>
// sorry for cross-posting
A lot of heated discussion occur on talk pages – thus, edit conflicts
happen on talk pages a lot. To be able to solve these more effectively, the
Technical Wishes team at Wikimedia Germany is designing an additional user
interface for this situation. This interface is shown to you when you write
on a discussion page and another person writes a discussion post in the
same line and saves it before you do. With this additional editing conflict
interface you can adjust the order of the comments and edit your comment.
If you'd like to know more about this feature, please visit the project
This interface is created as a result of the Technical Wishes survey  in
2015, in which the German Wikipedia community wished for a simpler way to
resolve edit conflicts. For regular edit conflicts on article pages, the two
column conflict user interface was created, which has been available as a
beta feature since November 2018. The plan is to make this additional
interface for talk pages available in a few months.
We are inviting everyone to have a look at the planned feature and let us
know what you think on our central feedback page ! -- For the Technical
Wishes Team: Max Klemm
Working Student Community Communication for Technical Wishes
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30 219 158 26-0https://wikimedia.de
Imagine a world in which every single human being can freely share in
the sum of all knowledge. Help us to achieve our
Wikimedia Deutschland – Gesellschaft zur Förderung Freien Wissens e.
V. Eingetragen im Vereinsregister des Amtsgerichts
Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig
anerkannt durch das Finanzamt für Körperschaften I Berlin,
TL;DR: A new policy defining stable interfaces for use by extensions, and the
deprecation process that must be followed when changing such stable interfaces,
is now in the Last Call period. If no concerns remain unaddressed by March 11,
the new policy will be adopted as official policy. The policy will apply to
MediaWiki 1.35 and later.
The new policy is designed to better protect extensions from breakage when
things change in core, by being more restrictive about what extensions can
Draft document: https://www.mediawiki.org/wiki/Stable_interface_policy
RFC ticket: https://phabricator.wikimedia.org/T193613
Please comment there. Read below for a summary of changes.
TechCom has been working on a Stable Interface Policy for MediaWiki's PHP code
for a while. Previously, the definition of the stable interface that can be
used by extensions was part of the Deprecation Policy. The new policy is
much more detailed and explicit about what extensions can expect to remain
stable and follow the deprecation process, and which things can change without
The introduction of the new policy is driven by problems we found while trying
to refactor core code with the aim to reduce coupling. For instance, when
following the Dependency Injection pattern, the constructor of service classes
is technically public, but is not stable for use outside the module.
The solution is to be more explicit about different kinds of stability (e.g.
whether a method is stable for callers, or can also be safely overwritten).
To allow us more freedom to restructure the source code, the new policy is more
restrictive with respect to what extensions can expect to be able to do safely
(e.g. subclass core classes). This is balanced by improved guarantees in
previously unspecified cases (e.g. stability of protected methods).
The new policy specifies different kinds of stability, establishes defaults for
different parts of the code, and defines new annotations to be used in the
documentation. Once the policy has been adopted, these annotations are soon to
be added to the code.
This will hopefully allow us to more quickly improve the structure and quality
of core code, and reduce the risk of breaking extensions in the future.
Summary of the new policy:
For extension authors:
* It's generally safe to call public methods, and to access public fields in
classes defined by MediaWiki core, unless these methods are documented to be
unsafe (e.g. annotated as @deprecated, @unstable, or @internal).
* It's generally unsafe to extend (subclass) classes or implement interfaces
defined by MediaWiki core, unless that class or interface was marked as @stable
for subclassing or @stable for implementation, respectively. In particular, the
constructor signature may change without notice, and abstract methods may be
added to interfaces.
* It's generally unsafe to directly instantiate (using new) classes defined by
MediaWiki core, unless that class is marked as @newable.
* It's generally unsafe to rely on global variables from MediaWiki core. Use
methods such as MediaWikiServices::getInstance() or
When changing existing code:
* Keep public methods and hook signatures backwards compatible for callers.
Follow the deprecation process when removing them.
* Keep constructor signatures backwards compatible if the constructor was marked
@stable for calling.
* Ensure compatibility of method signatures for code that overrides them if they
are marked @stable for overriding.
* Do not add abstract methods to classes or interfaces marked as @stable for
subclassing or @stable for implementation.
When defining extension points:
* When defining hooks, keep the signature minimal, and expose narrow interfaces,
ideally only pure value objects.
* When defining an interface to be implemented by extensions, provide a base
class, and mark it as @stable for subclassing.
* Discourage extensions from directly implementing interfaces by marking them as
@unstable for implementation. If direct implementation is to be allowed, mark
the interface @stable for implementation.
Notable changes from the 1.34 policy:
* Public methods are per default considered stable only for calling, not for
* Constructors are considered unstable per default.
* Classes and interfaces are considered unstable for subclassing and
implementation, unless documented otherwise.
* Code not used in a public repository that is part of the Wikimedia ecosystem
may be changed or removed without deprecation.
Principal Software Engineer, Core Platform
The topics of real-time fact-checking services and AI dialogue systems are broached and some opinions are shared for purposes of discussion.
Crowdsourced Fact-checking Resources
Are crowdsourced real-time fact-checking services possible? What might the design criteria be for such resources? Can such resources be of use to AI dialogue systems?
Determining the truth value of a given statement – or selecting one statement from a set of mutually exclusive statements – might not always be possible for a crowd at an instant. The instantaneous state of and, in some cases, resolution of, fact-checking processes might be such that multiple mutually-exclusive alternative statements are each supported by evidence and argumentation.
Crowdsourced real-time fact-checking resources should facilitate evidence-based argumentation for elements of sets of mutually exclusive statements as a component of providing groups with processes to determine the factuality of statements. There may be other means of clustering statements beyond mutual exclusivity.
Crowdsourced real-time fact-checking resources should support non-anonymous users as well as verified users, non-anonymous users who, for example, are journalists or fact-checkers.
Crowdsourced real-time fact-checking resources should allow users to opt into receiving notifications whenever a particular statement or statement-cluster is updated and AI dialogue systems should similarly be able to subscribe to such events.
Crowdsourced real-time fact-checking resources should support machine-utilizable output formats, output formats beyond HTML.
Efficiencies and Optimizations Regarding Dialogue Systems and Knowledgebases with Remote Fact-checking Services
At an instant, does a given topic require a dialogue system to poll one or more real-time fact-checking resources? Not every topic that a dialogue system might speak about would seem to require polling the data of one or more fact-checking resources. If dialogue systems could determine which topics were volatile, contentious or dynamic, and if these determinations were cacheable for durations, then dialogue systems could more efficiently provide their services at scale while making use of real-time fact-checking services.
It might be possible to determine the volatility, contentiousness, or dynamicism of a given topic by checking on or receiving notifications with respect to the quantity of recent activity for a topic on one or more fact-checking resources. Dialogue systems could asynchronously seek or receive updates regarding this data to best produce responses for users.
Dialogue System Behaviors
Which behaviors should dialogue systems exhibit if asked about volatile, contentious or dynamic topics? For instance, topics of some unfolding discussion on one or more fact-checking resources?
These scenarios might arise as users ask dialogue systems questions about topics recently discussed or debated, e.g. in the news.
Some options are indicated:
Option 1: I Don’t Know
A dialogue system could indicate that it doesn’t know the answer.
Option 2: I Need More Time to Answer that Question
A dialogue system could indicate that the matter is being reviewed by fact-checkers and somehow provide an estimate of when it should be able to answer the question. A dialogue system could ask a user if they desire a notification, including within specified hours, with respect to updates and could provide notifications to users via one of a number of communication channels.
Option 3: Refer Users to Fact-checking Resources
A dialogue system could refer the user to Web materials, for example to the unfolding discussion on a fact-checking resource. Multimodal dialogue systems could present users with Web content.
Option 4: Explain Alternatives and Possibilities
A dialogue system could, in particular when a fact-checking resolution appears to be disagreement, explain the elements of a set of mutually exclusive alternatives and provide the supporting argumentation for each. “Some are indicating X, while others Y.” Questions include how best to synthesize the output rhetoric in these instances, how best to sort the alternatives and possibilities, how best to specify which parties were supporting which alternatives and possibilities, and so forth.
Option 5: Decide
A dialogue system could review the argumentation and evidence supporting each element of a set of mutually exclusive statements and make a decision.
The topics of real-time fact-checking services and AI dialogue systems were broached and some opinions were shared for purposes of discussion.
The Wikimedia Foundation is soliciting your feedback to measure developer
satisfaction and determine where to invest resources in the future. This is
the second iteration of this survey.
Topics covered include:
* Local Development Environment
* Beta Cluster / Staging Environment
* Testing / CI
* Code Review
* Production Systems
* Development and Productivity Tools
* Developer Documentation
We are soliciting feedback from all Wikimedia developers, including Staff,
3rd party contributors and volunteer developers. *The survey will be open
for a little over 2 weeks, closing on Friday March 6th.*
This survey will be conducted via a third-party service, which may subject
it to additional terms. For more information on privacy and data-handling,
see the survey privacy statement
To participate in this survey, please start here:
Thank you for your participation,
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| Dir. Engineering Productivity A18D 1138 8E47 FAC8 1C7D |