Hi Everyone --
We wanted to give you an update on where we were with the strategy process
and provide some more avenues for feedback and participation.
When we last spoke, we had presented an initial draft of our strategy along
with some details of the process we are using. This did not get the
feedback that we had hoped for[1]. We considered this feedback and came up
with some conclusions that we've used to move forward:
1. The strategic problem itself was too broad and unclear to be a
suitable foundation for discussion or specifics.
2. The process is difficult to understand if you haven't been immersed
in it.
3. Strategy is hard and collaborative strategy, particularly with a
large group of distributed stakeholders, is harder.
In response to these conclusions, we've done the following:
1. Simplified and pared down our scope and made our strategic problem
more accessible and actionable.
2. Changed our communications plan to focus more on the outcomes of the
strategic process (what we're proposed we do v. how we came to these ideas)
with the belief that this will be easier to discuss.
3. Moved forward with the process to get to more specific plans and most
importantly start the process to reverse engineer them to see if they will
be effective. We also made a video to explain where we are and have started
a process to gather input on design from the community.
We'd like to ask for your help in the following way:
1. Please review this page:
https://www.mediawiki.org/wiki/Reading/Strategy/Strategy_Process/Testing for
details on how you can provide feedback become more involved in the
process. We're also very happy to recieve feedback on the process itself
and on the strategic options we are reverse-engineering.
- The Reading Team
[1] Our favorite was something along the lines of "It sounds like you put
all of the buzzwords into a bag, shook it up, and poured it out on a table"
-- this was good.
I wrote up how we're putting documentation files in git in
Manual:Coding_conventions [1]. It's nothing new, it mentions README.md,
.txt files, etc.
I would prefer extensions on files like COPYING and HISTORY, as it's
friendlier for Windows users and if the file actually uses Markdown or
wikitext markup it lets Diffusion, GitHub, and syntax highlighters do a
better job. I filed T116690 "Give text files in Git correct extensions".
I noticed two conventions for the extension of wikitext files in git:
.mediawiki and .wiki, e.g. tests/browser/README.mediawiki and
extensions/Wikibase/docs/lua.wiki. GitHub will render both kinds as
MediaWiki wikitext (of course it only implements a subset); it seems
Phabricator doesn't recognize either extension. I think we should be
consistent. .mediawiki is more precise (it's not MoinMoin or IkeWiki
markup) while .wiki is shorter. Maybe there are other arguments for one
extension over the other.
Thanks for any thoughts!
[1] https://www.mediawiki.org/wiki/Manual:Coding_conventions#Text_documents
--
=S Page WMF Tech writer
The reading team are keen to have watchstars in more places other than
just at the top right of the page you are viewing.
We already supporting adding things to the watchlist in search,
nearby, watchlist and gather.
We are working on a read more feature which will add a list of pages
with watchstars at the bottom of the page [1]
The code in desktop however is limited in that it is only written to
be usable by the page in question. It does various things such as use
the element id to reflect state (#ca-watch or #ca-unwatch) and runs
once on loading of the script.
We'd like to make this code more reusable so watchstars can be placed
in any interface but this comes with problems.
The model part is not too controversial but when it comes to creating
a reusable UI it becomes a little more complicated.
If we are to turn this into an OOjs UI widget, this would mean that
the OOjs UI library gets pulled in on every single page load. The OOjs
UI library, without styles or icon assets from what I can see is 226.5
kB (without gzip), (for comparisons Backbone is 69kb and React js is
559kb). This is not necessarily an issue, if all our code is built in
OOjs UI but right now we are very very far from that world, so we need
to find a strategy to getting there.
We know this is a problem. When Echo relaunched the new interface
there was a huge spike in first paint [2]. It seems the solution to
this was to render the button on the server side and defer load the
library to avoid this impact on first paint but the underlying problem
still remains - server side rendering is not an option for my team,
so to create a component the standard way we have to load this entire
library.
We have a similar problem with adopting OOJS UI in MobileFrontend. We
want to simply render/style a button on page load via JavaScript and
the library is too heavy weight for this, especially when right now we
don't have use cases for more complicated widgets such as layouts,
popups, windows, toolbars [3]... in fact we already have other
libraries that fulfill these needs that at some point will need to be
converted to oojs ui.
There's been some talk but little movement about cutting up the oojs
ui library into chunks to make it more adoptable by less complex
projects who just need buttons/inputs and other form elements. Is this
still an option? If so, how can we move this along? If not how can we
proceed?
I really think now is the time to talk about this, as adoption outside
the editing team still seems to be limited and from my point of view
this is one of the biggest barriers.
[1] https://www.mediawiki.org/wiki/Reading/Web/Projects/Read_more
[2] https://phabricator.wikimedia.org/T112401
[3] https://www.mediawiki.org/wiki/OOjs_UI
Please join for the following tech talk:
*Tech Talk**:* Nothing Left but Always Right: The Twisted Road to RTL
Support
*Presenter:* Moriel Schottlender
*Date:* November 02, 2015
*Time: *20:00 UTC
<http://www.timeanddate.com/worldclock/fixedtime.html?msg=Tech+Talk%3A+Nothi…>
Link to live YouTube stream <http://www.youtube.com/watch?v=qmLdHuFRGgM>
*IRC channel for questions/discussion:* #wikimedia-office
Google+ page
<https://plus.google.com/u/0/b/103470172168784626509/events/ck5ibgn8l2t056h5…>,
another
place for questions
*Summary: *There are roughly 500 million speakers of Right-to-Left
languages all over the world, and 16 RTL Wikipedias, but support of
right-to-left languages on the Web in general is so abysmal that it is hard
to find a single piece of software that properly supports all the necessary
behaviors. And yet, that's exactly what we're committed on doing for
Wikipedia's right-to-left users.
This talk will demonstrate the challenges that the web poses for Right to
Left languages, some of the solutions that are available, and some of the
work we've been doing to make RTL users' experience better.
In the next RFC meeting, we will discuss the following RFC:
* Streamlining Composer usage
<https://phabricator.wikimedia.org/T105638>
The meeting will be on the IRC channel #wikimedia-office on
chat.freenode.net at the following time:
* UTC: Wednesday 22:00
* US PST: Wednesday 14:00
* Europe CET: Wednesday 23:00
* Australia AEDT: Thursday 09:00
-- Tim Starling
Please join for the following tech talk:
*Tech Talk**:* The making of a MediaWiki skin
*Presenter:* Isarra
*Date:* November 03, 2015
*Time: *18:00 UTC
<http://www.timeanddate.com/worldclock/fixedtime.html?msg=Tech+Talk%3A+The+m…>
Link to live YouTube stream <http://www.youtube.com/watch?v=5b-8-_UpcQc>
*IRC channel for questions/discussion:* #wikimedia-office
Google+ page
<https://plus.google.com/u/0/b/103470172168784626509/events/cn511a81dbs7ijlf…>,
another
place for questions
*Summary: *MediaWiki's skins, or themes, are a lacking area that needs much
love, but much of the problem simply lies with how little it is known. In
this talk I will walk you through the process to create a skin and show you
how powerful MediaWiki's skinning system can be, even as it is now, going
from cloning the Example skin to a deployable implementation of
long-awaited product: Winter.
Hello all,
I am happy to announce that the Software-Development Team at WMDE (TCB)
developed the so called “Deepcat” gadget [1] that is now ready to use not
only in German wikis but also internationally.
The possibility for intersection and subcategory search was one of the
top-wishes from the TOP20 of the Germany Community Technical Wishlist [2].
DeepCat acts as an interface between a graph database and MediaWiki's
search engine. The Wiki's category structure is stored via their page-ids
in the graph database while the Gadget does the translation of the search
string, retrieves the information from the database and sends it to the
search engine. Tool developers interested in exploring possibilities for
using the CatGraph database can find more information on the respective
infopage [3] or can approach us directly.
The Deepcat gadget allows to go deeper in the category search and generates
results not only for a certain category but also for its subcategories.
Furthermore, it supports intersection search (among others: searching for
articles or pictures that are in two different categories e.g. “Art” and
“Technology”). The gadget works on Wikipedia, on Wikimedia Commons, as well
as in many other wikis [4]. For performance and technical reasons there is
a search limitation of 15 categories in depth and 70 categories in total
that the gadget can search through (you will see a hint about that while
using the gadget). The gadget doesn’t load on mobile devices however once
you switch to desktop-view, it should work as usual.
The gadget can be used via typing the keyword “deepcat:” into the regular
search field. An instruction how to install Deepcat and a detailed
description of its functionality can be found on its infopage [5]. Bugs can
be reported on Phabricator [6].
We hope it will serve you well!
Cheers,
Kasia
[1] https://github.com/wmde/DeepCat-Gadget
[2]
https://de.wikipedia.org/wiki/Wikipedia:Umfragen/Technische_W%C3%BCnsche/To…
[3] https://wikitech.wikimedia.org/wiki/Nova_Resource:Catgraph
[4] https://tools.wmflabs.org/cgstat
[5] https://wikitech.wikimedia.org/wiki/Nova_Resource:Catgraph/Deepcat
[6]
https://phabricator.wikimedia.org/maniphest/task/create/?projects=DeepCat-G…
--
Kasia Odrozek
Product Manager
Software Development and Engineering
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. +49 (030) 219 158 260
Mobil: +49 151 46752534
http://wikimedia.de <http://www.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/681/51985.
Hi Subbu,
How hard would it for Parsoid to mark red links in a way that the Mobile
Content Service could detect them (e.g. add class="new")? I've filed
https://phabricator.wikimedia.org/T117519.
Thanks,
Bernd
Hello all,
The deadline for possible candidates to submit their proposal on Outreachy
application system arrives in ~03 days ( Nov 02, 2015 07:00 UTC ).
Potential candidates are urged to submit their application at
https://outreachy.gnome.org well before the same, to avoid any last minute
surprise.
Currently, our Outreachy'11 board at
https://phabricator.wikimedia.org/tag/outreachy-round-11/ have :
1. 9 ideas in featured project with 8/9 projects with at-least 1
proposal submitted by a candidate
2. 11 proposals by 11 candidates submitted, and under review
As usual, the proposal in Phabricator will be evaluated by the mentors, and
candidates are free to polish it, past-deadline. All mentors and
co-mentors, please make sure that you are signing up in the Outreachy'11
portal [2], as a mentor. Community feedbacks are entertained in the
Outreachy projects and proposals so that none of them get stuck in between.
Editing efforts are also welcome at improving
https://www.mediawiki.org/wiki/Outreach_programs/Life_of_a_successful_proje…
which is helping us a lot this term.
[2] https://phabricator.wikimedia.org/T116589
it has been
Thanks,
Tony Thomas <http://blog.tttwrites.in/>
ThinkFOSS <http://www.thinkfoss.com>
*"where there is a wifi, there is a way"*