Yesterday I opened Gerrit change 112699 [0] with a proof of concept
implementation for the Structured logging RFC [1] that leverages PSR-3
and Monolog. I'm sure it's not ready to merge yet but hopefully it
will get some attention from interested parties to move this
discussion forward.
>From the commit message:
> This proof of concept implementation of the structured logging RFC
> introduces a PSR-3 based logging class. The MWLogger class is actually
> a thin wrapper around any PSR-3 LoggerInterface implementation. Named
> MWLogger instances can be obtained from the MWLogger::getInstance()
> static method. MWLogger expects a class implementing the MWLoggerSpi
> interface to act as a factory for new MWLogger instances. A concrete
> MWLoggerSpi implementation using the Monolog library is also provided.
There are a couple things in this change that I expect deserve
discussion. The biggest is the way that I am proposing to use Composer
to manage importing Monolog and the Psr\Log libraries into
mediawiki-core. This crosses into the territory of the Third-party
components RFC [2]. This topic has come up on gerrit already. I gave
this response there:
> Jeroen wrote:
>> Not really nice to just copy the monolog sources into MW...
>
> I would agree that it's not the cleanest or prettiest way to get significant
> third-party code incorporated into MediaWiki, but this is part of the
> conversation that I was hoping this patch could move forward.
>
> Do you have a suggestion for a better way to incorporate external packages
> that will allow deployment to WMF cluster and easy packaging for the tarball
> releases? I'm using a Composer file to manage the lib directory so that we
> can upgrade to newer versions with a minimum amount of fuss. The full
> "vendor" structure from the Composer is maintained so that license files, etc
> are preserved. I see this method as being similar to the way that we include
> jQuery and other javascript libraries.
[0]: https://gerrit.wikimedia.org/r/#/c/112699/
[1]: https://www.mediawiki.org/wiki/Requests_for_comment/Structured_logging
[2]: https://www.mediawiki.org/wiki/Requests_for_comment/Third-party_components
--
Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
[[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA
irc: bd808 v:415.839.6885 x6855
Hi, the registration to the Zürich Hackathon will open very soon.
https://www.mediawiki.org/wiki/Zurich_Hackathon_2014
Wikimedia CH is doing a great work putting in place the foundations of
the event. There are two areas where they need help from the tech community:
* defining the schedule
* processing travel sponsorship requests
We should have 3-5 experienced contributors in each of these areas,
overlaps allowed. In the first case they would drive the definition of
the schedule, with whatever community process they want to put in place.
In the second place they would need to go case by case and decide
privately as a team whether candidate X gets sponsorship or not.
Who wants to get involved in the program?
I'm happy to help with the sponsorship requests.
Please document in the wiki page. I will be on offline holidays on Feb
8-17, but you can ask any questions about the event to Manuel, CCed.
Thank you!
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hi,
I'm curious how people would go about hiding text from the internal
MediaWiki
search engine (not external robots). Right now I'm thinking of doing a
rather
naïve .nosearch class that would be stripped before indexing. I can see
potentials
for abuse though.
Does anyone have any bright ideas?
-Chad
On Wed, Feb 19, 2014 at 1:26 AM, MZMcBride <z(a)mzmcbride.com> wrote:
> There are likely others. What can be done to address this issue?
Only way I can think of is to improve the Lua <-> PHP API so that users can
make the queries directly.
*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
On Sun, Feb 16, 2014 at 10:04 AM, Jon Robson <jdlrobson(a)gmail.com> wrote:
> Brad since you work for the for the foundation and seem to have a lot of
> expertise in this area and seem to have been one of the more vocal
> supporters of free fonts have you reached out to your work colleagues over
> video conferencing or similar to understand the problems being hit and
> helped them work through them? Email doesn't seem to have been an effective
> method of communication in this situation as you have pointed out. Maybe
> you can help with documenting these issues and helping people like yourself
> understand the problems and why this change was reverted?
>
As Brad's manager, I think it's fine to invite Brad to a meeting if you
believe that the mailing list won't work for the conversation you'd like to
have. However, I object to putting the responsibility for initiating a
video conversation on him. As Brian Wolff mentioned earlier in the font
thread, a public mailing list is a perfectly fine place to bring this sort
of thing up, since sooner or later, this issue would have found its way to
this mailing list anyway.
For what it's worth, I think I can represent Brad's viewpoint pretty well,
so if anyone wants to discuss this with me in the office, I'm happy to
oblige.
Rob
Hoy all,
I've been meaning to start a thread about this for a while, but just hadn't
gotten around to it. Things have been rather heated the past few days, so I
figured now would be as good a time as any to go about starting this thread.
Have any of you ever heard of Non-Violent Communication (NVC). It's a method of
communicating, well really more a method of thinking, that aims to reduce and
resolve conflicts between people. NVC has sometimes also been called Empathetic
Communication or Needs Based Communication. The idea of NVC is to frame the
discussion in terms of needs and feelings, followed up by requests. "Nonviolent
Communication holds that most conflicts between individuals or groups arise from
miscommunication about their human needs, due to coercive or manipulative
language that aims to induce fear, guilt, shame, etc. These 'violent' modes of
communication, when used during a conflict, divert the attention of the
participants away from clarifying their needs, their feelings, their
perceptions, and their requests, thus perpetuating the conflict." [0]
The core of NVC is an NVC expression, which is made up of four components:
Observations ("When I see/hear/notice..."), Feelings ("...I feel..."), Needs
("...because I need/value..."), and Requests ("Would you be willing to...?").
Observations are the facts themselves, and are not broad generalizations.
Feelings are emotions, they are distinct from stories, thoughts, and
evaluations. Feelings are also self-owned and not attributed to others (so one
doesn't feel attacked, one feels angry, likewise one doesn't feel betrayed, one
feels hurt or stunned, or perhaps even outraged). Finally requests are simply
that requests, but they are not demands. You have to be willing to hear the
other person say no.
To take a recent example from the mailing list:
"Cool, I'll just pop in. Oh, wait." (David, I want you to know I am not picking
a quote from you specifically for any reason, it was just one that stood out to
me as something that could have been much better expressed within the NVC
framework)
This could have been expressed as:
When people talk about things off-list, I feel resentful and frustrated because
my needs for community, consideration, and to be heard are not being met. Would
you be willing to keep the discussion on-list so that I can participate?
NVC values honestly expressing your own needs and feeling and empathetically
listening to those of others. Two things that really harm this connection are
blaming others and blaming ourselves.
I really encourage everyone on this list to do a little bit of reading into NVC.
I've linked to the Wikipedia article at the bottom of this email along with the
website for the Center for Non-Violent Communication. The NVC way of thinking
has really made a huge difference in how I understand and express myself to
people. I'm by no means perfect at it myself, but even with the practice that I
have I've already seen a huge improvement in how I relate to others. I really
think that it could do a lot of good here.
Thank you,
Derric Atzrott
Computer Specialist
Alizee Pathology
[0] https://en.wikipedia.org/wiki/Nonviolent_Communication NVC on Wikipedia
[1] http://www.cnvc.org/ Center for Non-Violent Communication
[2] https://www.cnvc.org/Training/feelings-inventory Feelings Inventory (really
useful for those of us who aren't in touch with our feelings, like myself)
[3] http://www.cnvc.org/Training/needs-inventory Needs Inventory (also very
useful for those of us who aren't in touch with our needs, again, like myself)
On Sat, Feb 15, 2014 at 11:52 PM, Denis Jacquerye <moyogo(a)gmail.com> wrote:
> Maybe I haven't looked in the right place, but why aren’t webfonts being
> considered?
>
> Webfonts would mean the same fonts can be delivered everywhere, relying on
> installed font only as a last resort.
> There are more options than just the 4 fonts mentioned (DejaVu Serif,
> Nimbus Roman No9 L, Linux Libertine, Liberation Sans): PT Sans/PT Serif,
> Droid Sans/Droid Serif and likes (Open Sans, Noto), the other Liberation
> fonts and likes (Arimo, Tinos), Source Sans, Roboto, Ubuntu, Clear Sans, if
> you just want hinted fonts and household names.
>
> I’ll also point out that Georgia is a great font originally designed for
> small size, and Helvetica Neue/Helvetica/Arial was originally designed for
> display. When it comes to language coverage both are lacking but that
> cannot be fixed easily.
>
To add on to what Jared said...
On webfonts: it's not just that it would take "more research". We have
already tried webfonts and failed miserably so far.
UniversalLanguageSelector is an example of how even the most
well-intentioned efforts in this area can face serious setbacks. Keep in
mind also that this typography work is largely being done with volunteer or
side project time from myself, the developers, and most of the designers.
We are simply not prepared to implement and test a webfonts system to work
at Wikipedia scale.
There are many gorgeous, well-localized free fonts out there... but few
that meet our design goals are delivered universally in popular mobile and
desktop operating systems. We can't get a consistent and more readable
experience without delivering those as webfonts, and webfonts are not
practically an option open to us right now. Maybe in the future we will get
(as Jared says) a foundry to donate a custom free font for us, or maybe
we'll just use a gorgeous free font out there now, like Open Baskerville or
Open Sans.
For now, however, we get the following result from the Typography Refresh
beta feature:
1. the vast majority of our 500 billion or more users get a more
readable experience
2. we unify the typography across mobile and desktop devices, which is a
good thing for both Wikimedia and third party users of Vector/MobileFrontEnd
3. individual users and individual wikis can still change their CSS as
needed and desired
4. we don't jeopardize Vector and MediaWiki's status as FOSS, by not
distributing nor creating a dependency on any proprietary software
*whatsoever*. Thank you, CSS font-family property and fallbacks.
That all sounds like a pretty good way to maintain freedom while improving
readability and consistency to me.
--
Steven Walling,
Product Manager
https://wikimediafoundation.org/