Hi,
On Tue, Mar 1, 2016 at 3:36 PM, David Strine <dstrine(a)wikimedia.org> wrote:
> We will be holding this brownbag in 25 minutes. The Bluejeans link has
> changed:
>
> https://bluejeans.com/396234560
I'm not familiar with bluejeans and maybe have missed a transition
because I wasn't paying enough attention. is this some kind of
experiment? have all meetings transitioned to this service?
anyway, my immediate question at the moment is how do you join without
sharing your microphone and camera?
am I correct thinking that this is an entirely proprietary stack
that's neither gratis nor libre and has no on-premise (not cloud)
hosting option? are we paying for this?
-Jeremy
Phabricator users,
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
this.
https://phabricator.wikimedia.org/T238593
--
Daniel Zahn <dzahn(a)wikimedia.org>
Operations Engineer
As of 950cf6016c, the mediawiki/core repo was updated to use DB_REPLICA
instead of DB_SLAVE, with the old constant left as an alias. This is part
of a string of commits that cleaned up the mixed use of "replica" and
"slave" by sticking to the former. Extensions have not been mass
converted. Please use the new constant in any new code.
The word "replica" is a bit more indicative of a broader range of DB
setups*, is used by a range of large companies**, and is more neutral in
connotations.
Drupal and Django made similar updates (even replacing the word "master"):
* https://www.drupal.org/node/2275877
* https://github.com/django/django/pull/2692/files &
https://github.com/django/django/commit/beec05686ccc3bee8461f9a5a02c607a023…
I don't plan on doing anything to DB_MASTER, since it seems fine by itself,
like "master copy", "master tape" or "master key". This is analogous to a
master RDBMs database. Even multi-master RDBMs systems tend to have a
stronger consistency than classic RDBMs slave servers, and present
themselves as one logical "master" or "authoritative" copy. Even in it's
personified form, a "master" database can readily be thought of as
analogous to "controller", "governer", "ruler", lead "officer", or such.**
* clusters using two-phase commit, galera using certification-based
replication, multi-master circular replication, ect...
**
https://en.wikipedia.org/wiki/Master/slave_(technology)#Appropriateness_of_…
***
http://www.merriam-webster.com/dictionary/master?utm_campaign=sd&utm_medium…
--
-Aaron
// sorry for cross-posting
Hello,
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
page [1].
This interface is created as a result of the Technical Wishes survey [2] 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 [3]! -- For the Technical
Wishes Team: Max Klemm
[1]
https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Edit_Conflicts#Edit_c…
[2]
https://de.wikipedia.org/wiki/Wikipedia:Umfragen/Technische_W%C3%BCnsche_20…
[3] https://www.mediawiki.org/wiki/Help_talk:Two_Column_Edit_Conflict_View
--
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
vision!https://spenden.wikimedia.de
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,
Steuernummer 27/029/42207.
Hi all!
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
safely do.
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.
Long version:
TechCom has been working on a Stable Interface Policy for MediaWiki's PHP code
for a while[1]. Previously, the definition of the stable interface that can be
used by extensions was part of the Deprecation Policy[2]. The new policy[3] 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
notice.
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
MediaWikiServices::getMainConfig() instead.
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
overriding.
* 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.
[1] https://phabricator.wikimedia.org/T193613
[2] https://www.mediawiki.org/wiki/Deprecation_policy
[3] https://www.mediawiki.org/wiki/Stable_interface_policy
--
Daniel Kinzler
Principal Software Engineer, Core Platform
Wikimedia Foundation
Introduction
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.
Conclusion
The topics of real-time fact-checking services and AI dialogue systems were broached and some opinions were shared for purposes of discussion.
Best regards,
Adam Sobieski
Hello!
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
* Deployments
* 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
https://foundation.wikimedia.org/wiki/Developer_Satisfaction_Survey_Privacy…
To participate in this survey, please start here:
https://docs.google.com/forms/d/e/1FAIpQLSclq5vtaonRjwQykpfi2lbLIzJl-9wcOzm…
Thank you for your participation,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| Dir. Engineering Productivity A18D 1138 8E47 FAC8 1C7D |
Hi,
could someone review my patches in
https://gerrit.wikimedia.org/r/#/projects/mediawiki/extensions/WikEdDiff,da…
?
With my patches all should be ok, -1's by Jenkins aren't related to my
patches.
Best regards ,
Zoran Dori
volunteer, Wikimedia Serbia
s: zoranzoki21.github.io e: zorandori4444(a)gmail.com
Hi everyone,
The Search Platform Team
<https://www.mediawiki.org/wiki/Wikimedia_Search_Platform> usually holds
office hours the first Wednesday of each month. Come talk to us about
anything related to Wikimedia search!
Feel free to add your items to the Etherpad Agenda for the next meeting.
Details for our next meeting:
Date: Wednesday, March 4th, 2020
Time: 16:00-17:00 GMT / 08:00-09:00 PST / 11:00-12:00 EST / 17:00-18:00 CET
Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours
Google Meet link: https://meet.google.com/vyc-jvgq-dww
Join by phone in the US: +1 786-701-6904 PIN: 262 122 849#
Hope to talk to you in a week!
—Trey
Trey Jones
Sr. Software Engineer, Search Platform
Wikimedia Foundation
UTC-5 / EST
Hi all,
We are a group of undergraduates working on a project using the MediaWiki
API. While working on this project, we ran into a unique issue involving
pageviews. When trying to pull pageview data for a particular page, the
redirects of a page would not be counted along with the original pageviews.
For example, the Hong Kong protests page only has direct views, and not
views from previous titles.
We attempted to use the wmflabs.org tool, but it only shows data from a
certain date. (Example link:
https://tools.wmflabs.org/pageviews/?project=en.wikipedia.org&platform=all-…
<https://tools.wmflabs.org/pageviews/?project=en.wikipedia.org&platform=all-…>
)
Then we attempted to use the redirects of a page and using the old page ids
to grab the pageview data, but there was no data returned. When we
attempted to grab data for a page that we knew would have a long past, but
the parameter of "pvipcontinue" did not appear (
https://www.mediawiki.org/w/api.php?action=help&modules=query%2Bpageviews).
(Example:
https://www.mediawiki.org/wiki/Special:ApiSandbox#action=query&format=json&…
)
In the end, we are trying to get an accurate count of view for a certain
page no matter the source.
Any guidance or assistance is greatly appreciated.
Thanks,
Jackie, James, Junyi, Kirby