Hi,
As your inbox might have noticed, I spent some time triaging the Echo
board <https://phabricator.wikimedia.org/tag/echo/>. I didn't really
change priorities, mainly focused on the columns.
The board now has 5 columns:
* Backlog - default, untriaged. Should be empty most of the time, it
isn't right now because I didn't finish.
* Needs plan - still under discussion, doesn't have a clear direction or
obvious reproduction steps.
* Needs code - Ready for someone to pick up and write code! May not
always be code related though (ex: "some images need to be reversed for
RTL languages").
* In progress - in progress, should always have an assignee.
* External - Things related to Echo we should be aware of, but not
necessarily something we need to work on.
This is based off of the board we've been using for the MediaWiki-API[1]
project, which I've found generally works well. If I mis-triaged stuff,
please re-triage as necessary :)
[1] https://phabricator.wikimedia.org/tag/mediawiki-api/
-- Kunal
Today's RFC meeting was regarding general priorities for the coming
months (https://www.mediawiki.org/wiki/Architecture_focus_2015).
One of the key issues discussed was the idea of widgets, which is a new
approach to representing and editing bundles of content (such as an
infobox or a graph).
We also talked about canonical formats, and whether content should be
stored in wikitext and extracted out (like a more sophisticated version
of https://www.mediawiki.org/wiki/Extension:TextExtracts), or stored
elsewhere (e.g. Wikidata) and assembled. Gabriel Wicke noted the
importance of minimizing disruption for existing editors and tools, and
Bryan Davis suggested this could limit the flexibility editors now have.
This led us to discuss further what areas likely made sense to be
generated. I.E. graphs and data tables, probably not prose (but Daniel
Kinzler suggested possibly auto-generating prose if there was no
human-written prose).
We talked about some approaches to backend storage. Timo Tijhof
suggested allowing a page to be built from multiple blobs that reference
each other.
We talked about some approaches to widgets like infoboxes and inline
editing of templates more generally.
We also talked about testing coverage and code architecture guidelines.
Daniel Kinzler plans to update the document in response to feedback.
Matt Flaschen
---
Minutes at
https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.20…
Log at
https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.20…
Hi all,
I created this ticket to track the work on improving the notification system
<https://phabricator.wikimedia.org/T100528>. The goal is to better support
users going through the notifications without missing relevant items and
keep the volume of notifications aligned with their interest on topics.
This is a very early exploration. At this point we are interested on (a)
data points/examples to better understand the issues and relevant usecases
not yet considered, (b) feedback on existing ideas and (c) new ideas to
solve the issues. More specific tasks for different activities (user
research, discuss the development of a specific aspect, etc.) will be added
as sub-tasks to this ticket.
Feel free to provide any feedback.
Thanks.
--
Pau Giner
Senior User Experience Designer
Wikimedia Foundation
Hi all,
I have been iterating through the details of the designs for finding topics
on Flow (search, browse the ToC, and filtering). I updated this phabricator
ticket <https://phabricator.wikimedia.org/T76823> to provide an overview of
the related hi-level areas and link to the specific cards.
As tickets are considered for development, more details will be added and
cards will be split into smaller pieces, but for now I think the current
status provide a good overview of the main parts.
Please, feel free to provide feedback on the different cards (or correct
any Phabricator metadata I forgot to add).
Thanks
--
Pau Giner
Senior User Experience Designer
Wikimedia Foundation
Forwarding an interesting blog post in which the author shares thoughts
about the Wikimedia communities, including the editor engagement roles and
attributes of offline meetups for Wikimedians. Some of this blog post might
also be relevant for those who are involved in thinking about creating a
project-wide "friendly space" policy.
Pine
---------- Forwarded message ----------
From: Andrew Sherman <asherman(a)wikimedia.org>
Date: Tue, May 12, 2015 at 11:18 PM
Subject: [Social-media] Wikimania and the differences between online and
offline cultures
To: lionel(a)scheepmans.be, Social media discussion list for Wikimedia
projects <social-media(a)lists.wikimedia.org>
Hello Everyone,
We just published "Wikimania and the differences between online and offline
cultures" to the blog. URL:
https://blog.wikimedia.org/2015/05/12/wikimania-online-and-offline/
Thanks to Lionel for writing and helping us edit this post.
Below are some proposed social media messages. Tweak as needed.
*Twitter (@wikimedia/@wikipedia):*
• .@Wikimania, @Wikipedia and the differences between online and offline
culture (link)
• A French anthropologist observes the differences between online and
offline participation at @Wikimania (link)
*Facebook/Google+*
• A French anthropologist observes the differences between online and
offline participation in the Wikimedia movement, based on a visit to the
Wikimania 2014 conference in London. (link)
Thanks,
--
Andrew Sherman
Digital Communications | Wikimedia Foundation
*E:* asherman(a)wikimedia.org
*WMF:* ASherman (WMF) <https://meta.wikimedia.org/wiki/User:ASherman_(WMF)>
_______________________________________________
Social-media mailing list
Social-media(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/social-media
On 05/13/2015 02:48 AM, Tim Starling wrote:
> In the next RFC meeting, we will discuss the following RFC:
>
> * Improving extension management
> <https://www.mediawiki.org/wiki/Requests_for_comment/Improving_extension_man…>
The focus of the meeting was two aspects:
1. A way for the extension to specify which version(s) of MediaWiki core
it worked with.
This was the focus of the majority of meeting. Basically, this would
let an extension specify that a given commit (and thus, a given branch)
worked with particular versions of core, using syntax like:
"supports": ">1.23<1.26"
Any syntax that Composer supports will work on the right.
There was a lot of support with this, with some desire for better
communication, socialization, and documentation, and some debate over
the key name. However, this was not unanimous. Outcome of this was
"just submit a patch for it and we can continue the discussion in gerrit".
2. Tardist. Details at
https://www.mediawiki.org/wiki/Extension:ExtensionDistributor/tardist .
There wasn't much discussion of this, but some support based on having
read it.
There was also some big-picture debate on whether we should be
implementing a packaging/dependency system and various concerns:
1. Can we use Composer unmodified, whereas the current proposal/already
implemented decisions is to use Composer for libraries, and build our
extension system on top of it?
General reason we haven't done this is that extensions are not
libraries, and have MediaWiki-specific concerns (e.g update.php).
However, there was some push-back in today's meeting about whether this
distinction is valid.
2. Should we instead use (or auto-generate) something like Debian
packages, even if we don't actually try to get it into Debian proper.
This means having our own Debian repo. People pointed out that to even
start getting serious about this we have to at least package latest
MediaWiki and provide it in a public repo. We haven't done this so far,
and the latest MW in even Debian unstable is 1.19.20+dfsg-2.3 (latest
release is 1.24, 1.25 coming out Real Soon Now).
Also, if Debian packages are our solution for manging extensions and
core, what about people on Red Hat, Windows, BSD, etc.?
3. In general, has enough research been done on the existing packaging
and dependency ecosystem to see if we can leverage an existing system?
Matt Flaschen
Sounds good. Perhaps Kourosh Karimkhany could help with a conversation with
Facebook.
Pine
On May 11, 2015 7:47 AM, "Dan Andreescu" <dandreescu(a)wikimedia.org> wrote:
On Fri, May 8, 2015 at 10:00 PM, Jeremy Baron <jeremy(a)tuxmachine.com> wrote:
> On Sat, May 9, 2015 at 1:58 AM, Oliver Keyes <okeyes(a)wikimedia.org> wrote:
> > Facebook sanitises their users' referers. There's no research and
> > engagement work to perform there.
>
> well facebook surely has this data. (both views of Wikipedia content
> and probably also clicks of edit buttons) we could ask them about
> sharing it.
>
We could even create a prominent "who brought editors to Wikipedia"
dashboard. And if Facebook shares with us verifiable data, we can use it
as an incentive for google to add an Edit button in their Knowledge graph
(because then they'd get a spot on our spiffy dashboard). Of course, we'd
put a bit "this is all self reported data", etc. as a disclaimer at the
bottom.
_______________________________________________
Analytics mailing list
Analytics(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics
Hi EE and and analytics,
I searched for Seattle on Facebook and am surprised to see that Facebook
says below the page lede, "From Wikipedia, the free enclopedia. Edit on
Wikipedia". I don't recall seeing an edit link there before. Does Analytics
have a way of tracking Wikipedia content views on FB and edits that were
from FB viewers? Are there any plans for FB readership, text editing or
image upload editor engagement work?
Thanks,
Pine