[Wikitech-l] Timeless grant final report

[Isarra Yos]

Hey all, the Timeless grant has wrapped up and I've submitted the final
report for the project. Please check it out if you're interested:
https://meta.wikimedia.org/wiki/Grants:Project/Timeless/Post-deployment_support/Final

A couple of things to highlight:
* The associated learning pattern is likely going to be relevant to a lot
  of us:
  
https://meta.wikimedia.org/wiki/Learning_patterns/Developing_intercompatible_components_within_a_complex_and_often_inconsistent_system
* Part of the purpose of the grant was to investigate into what we would
  actually need from a new skin on Wikimedia projects, should anyone
  decide to go that route. Here's what we found:


All we really need from a new skin is for everything that went wrong
with Minerva and Timeless, as far as readers and editors are concerned,
to not happen this time:

* We need gadgets to work.
* We need content to display properly, and tools to be available.
* We need to properly reuse core interfaces so things remain consistent.
* We need to not distract users with unnecessary colours and affordances
   that aren't relevant to whatever they're doing, and provide options
   that suit their differing situations and needs.
* We need to not do dumb things, like reinvent random wheels or ignore
   standard hooks and DOM expectations.


I don't know if that's all that likely to help anyone, but... yeah.

Anyway, I'll still be working on maintenance and some feature development
in a volunteer capacity, mind you, so as always if you run into issues or
whatever, please file them on phabricator or come yell at me! I just make
absolutely no promises whatsoever as to when I (or whoever) will actually
deal with it, but it's still really helpful to at least have them tracked.

https://phabricator.wikimedia.org/tag/timeless/
(See, it's even sort of organised! I even renamed the 'Aaa' column!)

-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Help merge patch (Interwiki)

[Isarra Yos]

How do you get patches merged when you don't actually know anyone to 
review it?


Sometimes you just get lucky, but sometimes you add a bunch of people, a 
few others even wander in and +1 it, you ask a few people with core +2 
to take a look, and then you're still waiting on a product owner to 
maybe even comment at all and you can't get anyone to actually merge it 
months later.


The patch I'm referring to right now is this: 
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Interwiki/+/501820


It adds another global inheritance feature, this time for interlanguage 
links, where they can just be set once on a single wiki and other wikis 
in the farm can likewise just use those instead of local ones. Separate 
setting from the global interwikis because ones that would share this 
will be a smaller subset than would share general interwikis.


Normally we'd just merge each other's patches in-team or go get an 
actual product owner to review it, but there are a couple of problems 
with this:


 * The patch was co-authored by Jack Phoenix and me (and I defined the
   design in the first place), so neither of us can meaningfully review
   it any further than we already have. No one else has +2 here.
 * We don't know any product owners (in fact we're not even sure if
   there are any product owners), so we can't get them to review it.
   Given the total lack of comment, normally we might just declare this
   as 'nobody cares' after awhile and charge ahead regardless, but:
 * Nobody else we know with general +2 is willing to merge it without
   weigh-in from the product owners/actually has any time to review it
   in the first place, either.

Basically, uh, can anyone else help us with this? Any of this? Given the 
nature of the patch we really do kind of need it merged so it can get 
translations.


-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 今週あなたを幸せにするものは何ですか？ / What's making you happy this week? (Week of 16 June 2019)

[Isarra Yos]

Mailing lists aren't really a good place to establish consensus, as 
every time someone weighs in, everyone is notified, so 'me too's are 
frowned upon in principle.


Perhaps you might want to create an actual poll about preferred venues 
etc onwiki and then send out a message to wikimedia-l linking to that if 
you want a more meaningful assessment.


-I

On 24/06/2019 01:42, Pine W wrote:

Hi,

Thank you for the positive comments, Stephan and RhinosF1.

I think that there is not a clear public majority opposed or in favor of
continuing to have these threads on Wikitech-l in their current form. The
relatively small number of people who commented suggests to me that most
readers of this list are neutral. I will err on the side of caution and
stop sharing the threads to Wikitech-l. I will continue to post these
threads to Wikimedia-l. Also, I will share modified versions of the content
for these threads in *The Signpost*
, starting with
the next issue of that publication. If someone would like to create a
Wikitech-specific version of these threads, I think that they are welcome
to do that.

Pine
( https://meta.wikimedia.org/wiki/User:Pine )
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Improving the mediawiki.org frontpage: It's available!

[Isarra Yos]

It looks good in Modern.

On 13/04/2019 13:17, Andre Klapper wrote:

Hi everybody,

https://www.mediawiki.org has a new frontpage!

Thank you to everyone who provided great feedback and comments on
https://www.mediawiki.org/wiki/Talk:MediaWiki/Homepage_improvements_2018 and
https://www.mediawiki.org/wiki/Talk:MediaWiki/Homepage_improvements_2018/Proposal
in the last weeks! Several improvements have been implemented before going live.

For a list of potential future work on problems with related pages, see
https://www.mediawiki.org/wiki/MediaWiki/Homepage_improvements_2018#Potential_follow-up_work

Enjoy!
andre

(This email is a follow-up to the previous three announcements:
https://lists.wikimedia.org/pipermail/wikitech-l/2018-September/090886.html
https://lists.wikimedia.org/pipermail/wikitech-l/2018-December/091213.html
https://lists.wikimedia.org/pipermail/wikitech-l/2019-March/091814.html )




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Uploading new versions of other people's patches to gerrit

[Isarra Yos]

On 09/04/2019 19:40, Tyler Cipriani wrote:

Hello,

On 19-04-09 17:50:12, Isarra Yos wrote:
To clarify, I get what you're trying to do, but there has got to be a 
better solution besides denying key features to and thus impairing 
long-term contributors, because disabling this for everyone (but 
apparently WMDE (?!)) does exactly that. On the wikis, for instance, 
we have specific groups for this sort of thing (rollback, file 
moving, bypass captcha, bypass rate limits), to let established users 
do the things they need to do, without it being allowed of absolutely 
everyone from the start, and without requiring them to be admins, 
either, to do it. Perhaps actually using one of our more general 
existing groups for this here would make sense?


Bawolff has suggested Trusted-Contributors as a group that might make 
sense to add. That seems sane to me, so I've added that group in 
addition to the list above. Hopefully that unblocks your work.


I agree: having specific groups that are granted specific permissions 
that allow established users to continue their work unobstructed 
should be achievable in the near-term.



Thank you. And apparently I was only even added to that group just last 
night in the hopes that it would get around this, so... now that it 
does, great! (For anyone else who needs to be added to this for now, who 
should they be reaching out to?)


Sorry about reacting so unkindly - it was just particularly frustrating 
when it seemed like I was being ignored here, but other groups were 
being resolved (though as I understand it now, apparently specific 
members with access simply added that themselves, go figure).


-I


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Uploading new versions of other people's patches to gerrit

[Isarra Yos]

On 09/04/2019 17:53, Greg Grossmeier wrote:

PS: I just saw your follow-up reply. Sadly Gerrit is not mediawiki ;)
so it doesn't have all of the other built in anti-abuse features that
comes with the nice user features.


Most of MediaWiki's anti-abuse features consist of only applying certain 
rights to certain groups. This is, likewise, a certain right. Gerrit, 
likewise, has groups. This right can be attached to groups, as evidenced 
by the fact that it has already been attached to certain groups.


Given that we have no other feasible ways to do the thing the right 
allows, all I am asking is that this right be added to something that 
known volunteers and other trusted contributors can be added to. I 
believe there is even a group called 'trusted-contributors' already.


-I


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Uploading new versions of other people's patches to gerrit

[Isarra Yos]

On 09/04/2019 17:38, Isarra Yos wrote:

On 09/04/2019 16:44, Tyler Cipriani wrote:

On 19-04-09 05:17:17, Isarra Yos wrote:
This seems to be broken, or something. It's causing problems for 
collaboration. Please fix.


This is the addPatchSet permission in Gerrit.

That particular permission was recently abused, and at that time the 
permission was modified. The current status will remain for at least 
the next week or two while we sort out some other Gerrit problems.


The current status is that "Project Owners" can use addPatchSet for 
any projects they own: this does not necessarily map to +2/-2 
permissions for a given project, but should mostly align.


For any projects in the "mediawiki" hierarchy, the "mediawiki" group 
has the ability to addPatchSet.


After our current problems are resolved, I'd like to talk both with 
the folks impacted and with the security team about finding some 
middle ground between the current status and anyone being able to 
modify any patchset at any time.


Hi. I'm trying to think of a way to put this politely, but I can't, 
so: this is insane.


Please reconsider, or I will likely simply need to put off a lot of my 
work entirely until it is resolved, which is particularly problematic 
as this was the week when I was supposed to properly resume my grant 
work in particular. I do not have ownership on many of the 
repositories that I need to work on, despite those also being among 
the ones most likely to require the sort of back and forth amending 
that this blocks, so this is about as bad for me as having gerrit down 
entirely, as that is pretty much where having to fall back to emailing 
patches puts us. (And when that happened I just threw my arms in the 
air and went to the beach.)


To clarify, I get what you're trying to do, but there has got to be a 
better solution besides denying key features to and thus impairing 
long-term contributors, because disabling this for everyone (but 
apparently WMDE (?!)) does exactly that. On the wikis, for instance, we 
have specific groups for this sort of thing (rollback, file moving, 
bypass captcha, bypass rate limits), to let established users do the 
things they need to do, without it being allowed of absolutely everyone 
from the start, and without requiring them to be admins, either, to do 
it. Perhaps actually using one of our more general existing groups for 
this here would make sense?


-I


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Uploading new versions of other people's patches to gerrit

[Isarra Yos]

On 09/04/2019 16:44, Tyler Cipriani wrote:

On 19-04-09 05:17:17, Isarra Yos wrote:
This seems to be broken, or something. It's causing problems for 
collaboration. Please fix.


This is the addPatchSet permission in Gerrit.

That particular permission was recently abused, and at that time the 
permission was modified. The current status will remain for at least 
the next week or two while we sort out some other Gerrit problems.


The current status is that "Project Owners" can use addPatchSet for 
any projects they own: this does not necessarily map to +2/-2 
permissions for a given project, but should mostly align.


For any projects in the "mediawiki" hierarchy, the "mediawiki" group 
has the ability to addPatchSet.


After our current problems are resolved, I'd like to talk both with 
the folks impacted and with the security team about finding some 
middle ground between the current status and anyone being able to 
modify any patchset at any time.


Hi. I'm trying to think of a way to put this politely, but I can't, so: 
this is insane.


Please reconsider, or I will likely simply need to put off a lot of my 
work entirely until it is resolved, which is particularly problematic as 
this was the week when I was supposed to properly resume my grant work 
in particular. I do not have ownership on many of the repositories that 
I need to work on, despite those also being among the ones most likely 
to require the sort of back and forth amending that this blocks, so this 
is about as bad for me as having gerrit down entirely, as that is pretty 
much where having to fall back to emailing patches puts us. (And when 
that happened I just threw my arms in the air and went to the beach.)


-I


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Uploading new versions of other people's patches to gerrit

[Isarra Yos]

On 09/04/2019 09:21, Bartosz Dziewoński wrote:
Hopefully this will not stay disabled forever, for I also miss the 
feature.


In the meantime, you can use the traditional Git way of generating 
patch files and sending them by email (or perhaps, in a modern twist, 
via Phabricator).


To generate a patch file of the most recent commit:

    git format-patch -1

(that's 'dash one', and it's critical, because otherwise Git will 
generate patch files for ALL commits)


Then upload the generated file to Phabricator or something.

To apply such a patch file and turn it into a commit:

    git am foo.patch

There are some other options for dealing with multiple dependent 
commits, if you ever need them.



The problem is I'm going to need to do that for like one in every five 
commits, and often for multiple patches in a set. And... yes, we /do/ 
wind up with multiple dependent commits at times.


To explain why this comes up so much for me: I am a UX designer. I'm not 
much of a dev. Most of what I do is describe generally what I want and 
then throw it at someone else, and they implement the actual logic, but 
then they pass it back to me to fill in the rest of the interaction 
stuff, because not only would it be incredibly tedious for me to try to 
explain every possible combination users might run into, it probably 
wouldn't even work. Without the code in front of me, without testing it 
and playing through each use case to ensure it actually results in the 
expected behaviour, I am going to miss things.


While it does work in some cases to simply have the logic in one patch 
and the interaction in another, much of what we work on is considered 
stable, where we should not be merging half-complete patches unless we 
absolutely must.


(Note too that this is specifically /my/ use case - this isn't even 
getting into issues with minor changes that are easier to apply than to 
explain, especially when helping newcomers through where it'd be 
needlessly frustrating for them to implement a bunch of minor fixes when 
the core of their patch is in fact good; or when just dealing with 
typos; or when restoring someone's five-year-old abandoned patch because 
wait, we actually do need that now; or...)


Should we just, uh, not be using gerrit, or something? Because that's 
just... complicated.


-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Uploading new versions of other people's patches to gerrit

[Isarra Yos]

On 09/04/2019 05:17, Isarra Yos wrote:
This seems to be broken, or something. It's causing problems for 
collaboration. Please fix. 


I now hear that this is intentional for spam/vandalism reasons. This 
seems unwise. Regardless, where is the documentation about this? What is 
the recommended method to now collaborate on specific patches?


Halp.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Uploading new versions of other people's patches to gerrit

[Isarra Yos]

This seems to be broken, or something. It's causing problems for 
collaboration. Please fix.


-I


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New Gerrit privilege policy

[Isarra Yos]

On 16/03/2019 14:35, Bartosz Dziewoński wrote:

On 2019-03-16 14:48, Merlijn van Deen (valhallasw) wrote:
1. According to the policy, self-+2'ing is grounds for revocation of 
Gerrit
privileges. For a Toolforge tool, self +2-ing is common and expected: 
the

repository is hosted on Gerrit to allow for CI and to make contributions
from others easier, not necessarily for the code review features.


The policy calls out this case as acceptable:

"For extensions (and other projects) not deployed to the Wikimedia 
cluster, the code review policy is up to the maintainer or author of 
the extension. Some non-Wikimedia extensions follow Wikimedia's policy 
of prohibiting self-merges, but there is no requirement of that. If 
you are the only person writing the extension and have nobody to 
review your change, or if the extension is abandoned, it is acceptable 
to self-merge your changes."


The problem is now it's a lot more difficult to start scaling beyond 
that. Perhaps we simply need an exception for this, too, in these cases?


-I


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New Gerrit privilege policy

[Isarra Yos]

On 16/03/2019 13:48, Merlijn van Deen (valhallasw) wrote:

On Sat, 16 Mar 2019 at 03:01, Tim Starling  wrote:


No, managing +2 permissions is not up to the maintainer of the tool,
that's the whole point of the change.


I feel that this policy, although well-meaning, and a step forwards for
MediaWiki and other WMF-production software, is unreasonably being applied
as a 'one-size-fits-all' solution to situations where it doesn't make sense.

Two examples where the policy does not fit the Toolforge situation:

1. According to the policy, self-+2'ing is grounds for revocation of Gerrit
privileges. For a Toolforge tool, self +2-ing is common and expected: the
repository is hosted on Gerrit to allow for CI and to make contributions
from others easier, not necessarily for the code review features.

2. Giving someone +2 access to a repository now needs to pass through an
extended process with checks and balances. At the same time, I can *directly
and immediately give someone deployment access to the tool.*

Effectively, this policy forces me to move any tool repositories off Gerrit
and onto GitHub: time and effort better spent otherwise.


Similar issues for smaller skins and extensions. Even in those cases 
where it doesn't merit a move, we'll probably just wind up self-merging 
even more than we already do, and putting even more of the burden of any 
actual review on the folks with +2 higher up, because that's just easier.


-I


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Request for comment: Themes in core

[Isarra Yos]

For those who weren't aware, Jack Phoenix and I have drafted a Request 
for Comment[1] and related initial patch[2] proposing to merge the logic 
from the Theme extension[3] into MediaWiki core.


From the RfC: This will provide built-in functionality that skins can 
implement in a simple and consistent manner, enabling user- or 
site-selection of css variations of a given skin, such as a dark version 
or a layout with more colours.


The RfC itself covers in detail the distinction between skins and themes 
as well as several use cases and issues surrounding the current 
situation, but the key point here is thus: with this functionality, we 
will be able to not just more easily implement night[4], winter, and 
accessibility[5] modes in skins such as Vector and Timeless, but also 
much more consistently, and in a manner that can then be developed to 
better and more consistently use the variables defined by the skins even 
outside of the themes themselves.


Currently, the Theme functionality is limited to the extension itself 
and a few skins that replicate key parts with varying amounts of 
fidelity, which not only results in a bit of a mess in terms of code 
fragmentation, but also limits what we can do with the skins themselves 
due to the added dependency. We would like to fix this, and thus invite 
everyone interested to review our proposal and please, comment if you 
have concerns or see any issues.


-I

See:
[1] https://www.mediawiki.org/wiki/Requests_for_comment/Themes_in_core
[2] https://gerrit.wikimedia.org/r/#/c/465451/
[3] https://www.mediawiki.org/wiki/Extension:Theme
[4] 
https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Reading/Night_mode
[5] 
https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Reading/Accessibility_settings_for_everyone



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] A difficult goodbye

[Isarra Yos]

Sad to see you go - from what I saw as a volunteer, things only improved 
under your leadership here. We were lucky to have you.


All the best.

-I

On 11/01/2019 00:29, Victoria Coleman wrote:

Dear all,

I have some difficult news to share.

A few months ago and completely out of the blue, an opportunity came up for me 
to exercise the full spectrum of my skills as the CEO of an early stage mission 
oriented startup. It has been a mighty struggle between my commitment to my 
team, the Foundation and  the movement and this opportunity to bring all my 
skills to bear and build something from the ground up to do good in the world. 
I will not lie to you - it has not been easy. But ultimately I decided that I 
have to give it a go and I accepted the offer. I plan on starting there on Feb 
4th so my last day at the Foundation will be Feb 1st.

These past two years have been amongst the most enjoyable in my professional 
career. I’ve enjoyed getting to know the movement and what fuels it and I’ve 
been incredibly privileged to work with a Tech team like no other. We have 
together strengthened the technical infrastructure of the movement and while 
much work remains to be done we have a much stronger team in place to take the 
mission to the next level. And I have personally made friendships that will 
last a lifetime.

The organization I will be moving to is Atlas AI, a public benefit corporation 
supported by the Rockefeller Foundation. I will be leading an exceptional team 
of AI and earth system science experts striving for improvements in human well 
being through data driven insights. Our focus areas are drawn from the UN’s 
sustainable development goals of no poverty and zero hunger with emphasis on 
Sub Saharan Africa.

I leave behind a Technology department that I am certain is well on the way to 
achieving our vision to create the infrastructure for the free knowledge 
movement. I am also pleased that during my tenure, we have built leaders who 
are equipped to take on this challenge.

Erika Bjune will be serving as interim CTO. Erika joined us a little over two 
years ago and she has distinguished  herself as one of the finest people 
leaders I have ever worked with. Both she and Katherine will have my ongoing 
support — I will stay on in a consulting role to Erika on organizational 
matters and for the mid term planning work we have ahead of us in the remainder 
of the fiscal year.  I know that I am leaving the Tech team in good hands until 
a permanent CTO is hired.

I want to close this difficult message with my heartfelt thanks to all of you 
for letting me be part of this incredible movement. Being a Wikimedian is a 
great privilege. I wanted you to know that I’m not walking away from something; 
I am walking towards  something that is very  important to me and the world. I 
will miss you all. Deeply. Truly. And a lot!


Victoria

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] My Phabricator account has been disabled

[Isarra Yos]

"We absolutely do not need this all to happen again in another six 
months with yet another incident which cannot be explained."


On 15/08/18 23:08, David Barratt wrote:

  the unclear CoCC action


Why do you feel that you need clarity on the CoCC's actions? or perhaps a
better way to ask would be: What do you gain from getting more clarity?

On Wed, Aug 15, 2018 at 6:58 PM Isarra Yos  wrote:


On 10/08/18 14:31, David Barratt wrote:

yet this is clearly precisely what is needed to avoid incidents like

this

in the future.


Based on what has been provided in this thread, I do *not* see this as an
incident that needs to be avoided in the future.

To clarify, the incident I was referring to was the unclear CoCC action
taken and subsequent confusion and disagreement, including this email
thread.

We absolutely do not need this all to happen again in another six months
with yet another incident which cannot be explained.

-I


On Fri, Aug 10, 2018 at 9:23 AM Isarra Yos  wrote:


It's sounds nice, but no. It is not a feature. One of the arguments I
was given when the CoC was initially pushed through was that of course
it wasn't perfect as was, that it would be amended and fixed based on
the real incidents it came into contact with. I maintain that it is
impossible to do this - to amend, fix, and generally refine a document
based on the real cases - when the details of the real cases and even
the stats about what they are in general remain unavailable, and yet
this is clearly precisely what is needed to avoid incidents like this in
the future.

There has been considerable disagreement as to where we should be
drawing the line between the public cases, the generalised, and the
private, but this too is something we need to figure out out a community
and clearly draw, and the only way to do so is with clear information on
what is possible, common, and feasible.

-I

On 09/08/18 22:39, David Barratt wrote:

I'm not sure I completely understand the problem. What is being called

a

"lack of transparency" is the opposite of "privacy by design." What is
being called a bug, is perhaps a feature. The irony of this, ought not

be

missed.

On Thu, Aug 9, 2018 at 6:33 PM Isarra Yos  wrote:


An interesting comparison, democracy. Community consensus and
transparency were what brought our shared project to the great heights
we now see, and yet the CoC and especially its enforcement are rooted

in

none of this. If this trainwreck that we are currently experiencing on
this list is truly our best shot at an open, welcoming, and supportive
environment when it flies in the face of everything that brought us

here

in the first place, then all of that was a lie.

I'm pretty sure that's just wrong, though. Keeping everything behind
closed doors is the opposite of open. Community members having the CoC
used against them as a club and being afraid of retribution for

seeking

help is the opposite of a welcoming and supportive environment. I

would

put forth that the CoC, or more accurately, this heavy-handed
implementation of it, has been an abject failure that requires us all

to

step back and try to look at all of this more objectively. To move
forward, we must address the issues with the CoC and its enforcement,
but to do so as a community, to come to any meaningful and informed
consensuses as such, will not be possible so long as nobody outside

the

committee has any access to the stats, as no logging of actions taken

is

available publicly, as the cases themselves remain largely invisible
even when they do not pertain to sensitive situations or materials.

Because if we do not base this in open process, consensus, and
transparency, then all platitudes aside, it's just not going to be
very... good. It's not going to address our needs, and we're not going
to be able to refine it as things come up. Not doing this /isn't
working/, and we need it work.

-I

On 09/08/18 20:48, Victoria Coleman wrote:

Hi everyone,

I’ve been following this discussion from afar (literally from a

remote

mountainous part of Greece [1]) so please excuse the reflection. I saw

this

today:

https://www.theatlantic.com/technology/archive/2018/08/jeongpedia/566897/

<

https://www.theatlantic.com/technology/archive/2018/08/jeongpedia/566897/

This is us. This is our shared project. What an incredible privilege

it

is to have the opportunity to be part of something utopian, yet real,

that

is seen by the world as the last bastion of shared reality. This is no
accident, no fluke. It’s because of us. This incredible community of

ours.

We are all different and yet we all, staff and volunteers alike,

strive

to

bring the best of ourselves to this monumental project of ours.

Sometimes

we get it wrong. We get emotional, we say the wrong thing, we get
frustrated with each other.  But we are all in this together. And we

hold

ourselves to a higher standard. I hope we can also forgive each other

when

we fall down

Re: [Wikitech-l] My Phabricator account has been disabled

[Isarra Yos]

On 10/08/18 14:31, David Barratt wrote:

yet this is clearly precisely what is needed to avoid incidents like this
in the future.


Based on what has been provided in this thread, I do *not* see this as an
incident that needs to be avoided in the future.


To clarify, the incident I was referring to was the unclear CoCC action 
taken and subsequent confusion and disagreement, including this email 
thread.


We absolutely do not need this all to happen again in another six months 
with yet another incident which cannot be explained.


-I


On Fri, Aug 10, 2018 at 9:23 AM Isarra Yos  wrote:


It's sounds nice, but no. It is not a feature. One of the arguments I
was given when the CoC was initially pushed through was that of course
it wasn't perfect as was, that it would be amended and fixed based on
the real incidents it came into contact with. I maintain that it is
impossible to do this - to amend, fix, and generally refine a document
based on the real cases - when the details of the real cases and even
the stats about what they are in general remain unavailable, and yet
this is clearly precisely what is needed to avoid incidents like this in
the future.

There has been considerable disagreement as to where we should be
drawing the line between the public cases, the generalised, and the
private, but this too is something we need to figure out out a community
and clearly draw, and the only way to do so is with clear information on
what is possible, common, and feasible.

-I

On 09/08/18 22:39, David Barratt wrote:

I'm not sure I completely understand the problem. What is being called a
"lack of transparency" is the opposite of "privacy by design." What is
being called a bug, is perhaps a feature. The irony of this, ought not be
missed.

On Thu, Aug 9, 2018 at 6:33 PM Isarra Yos  wrote:


An interesting comparison, democracy. Community consensus and
transparency were what brought our shared project to the great heights
we now see, and yet the CoC and especially its enforcement are rooted in
none of this. If this trainwreck that we are currently experiencing on
this list is truly our best shot at an open, welcoming, and supportive
environment when it flies in the face of everything that brought us here
in the first place, then all of that was a lie.

I'm pretty sure that's just wrong, though. Keeping everything behind
closed doors is the opposite of open. Community members having the CoC
used against them as a club and being afraid of retribution for seeking
help is the opposite of a welcoming and supportive environment. I would
put forth that the CoC, or more accurately, this heavy-handed
implementation of it, has been an abject failure that requires us all to
step back and try to look at all of this more objectively. To move
forward, we must address the issues with the CoC and its enforcement,
but to do so as a community, to come to any meaningful and informed
consensuses as such, will not be possible so long as nobody outside the
committee has any access to the stats, as no logging of actions taken is
available publicly, as the cases themselves remain largely invisible
even when they do not pertain to sensitive situations or materials.

Because if we do not base this in open process, consensus, and
transparency, then all platitudes aside, it's just not going to be
very... good. It's not going to address our needs, and we're not going
to be able to refine it as things come up. Not doing this /isn't
working/, and we need it work.

-I

On 09/08/18 20:48, Victoria Coleman wrote:

Hi everyone,

I’ve been following this discussion from afar (literally from a remote

mountainous part of Greece [1]) so please excuse the reflection. I saw

this

today:

https://www.theatlantic.com/technology/archive/2018/08/jeongpedia/566897/

<

https://www.theatlantic.com/technology/archive/2018/08/jeongpedia/566897/

This is us. This is our shared project. What an incredible privilege it

is to have the opportunity to be part of something utopian, yet real,

that

is seen by the world as the last bastion of shared reality. This is no
accident, no fluke. It’s because of us. This incredible community of

ours.

We are all different and yet we all, staff and volunteers alike, strive

to

bring the best of ourselves to this monumental project of ours.

Sometimes

we get it wrong. We get emotional, we say the wrong thing, we get
frustrated with each other.  But we are all in this together. And we

hold

ourselves to a higher standard. I hope we can also forgive each other

when

we fall down and offer a helping hand instead of a harsh, hurtful word.

The

CoC , like democracy, is not perfect but it’s our best shot at an open,
welcoming and supportive environment in our technical spaces. Let’s
continue refining it and let’s get back to work.

Warmly,

Victoria


[1] https://en.wikipedia.org/wiki/Pelion <

https://en.wikipedia.org/wiki/Pelion>



On Aug 9, 2018, at 7:24 PM, Stas Malyshev 

wrote:

Hi!

Re: [Wikitech-l] My Phabricator account has been disabled

[Isarra Yos]

On 15/08/18 22:40, David Barratt wrote:

In this particular case, it was based on a comment that was deleted.


https://web.archive.org/web/20180803232905/https://phabricator.wikimedia.org/T200742#4475216


And no, my intention was not to imply "if you did nothing wrong, you have
nothing to hide", it was only that, our public actions ought to speak for
themselves.


A nice sentiment, but unrealistic. We come from too many backgrounds, 
too many cultures, make too many typos, and are sufficiently bad at 
communicating overall as a movement that there will be many things that 
require clarification. We should always be open to making these 
clarifications - this is the key to better communication, and thus 
better understanding. Only from understanding can we improve things, not 
just ourselves, but our processes, our work, and our movement.


-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] My Phabricator account has been disabled

[Isarra Yos]

On 15/08/18 22:08, David Barratt wrote:

This isn't a he said, she said
 type of issue, it's
based on evidence that is public and difficult (if not impossible) to
delete.
If you feel that you would have to defend your behavior, perhaps the
behavior ought to be self-examined.


One of the complaints here has consistently been that the accusations, 
evidence, and deliberations are all not made public, so this statement 
doesn't make a whole lot of sense.


Even then, we shouldn't assume every accusation is made in good faith, 
nor that every accusation is based on correct interpretations of events. 
Misunderstandings happen, and sometimes the entire problem is lack of 
clarity, or context. Given the lack of any public access, this becomes 
particularly difficult to remedy, or even identify, in any instances 
where it does come up.


-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] My Phabricator account has been disabled

[Isarra Yos]

On 15/08/18 20:50, Nuria Ruiz wrote:

Given that
here is a narrative going around that the CoC is unfairly biased in favour
of staff, would you mind sharing what deliberations took place that
resulted in sactions against only one of the participants in a dispute

The deliberations as well as the reporter are confidential and they will
continue to be so everyone feels safe to report and be part of the
committee.
(note that you are assuming the reporter is just one person that works for
WMF).


This makes me feel the opposite of safe, and is why I will never report 
anything to the committee as things stand.


If someone accuses me, I have no way to defend myself. If I seek help or 
accuse another, I have no way to be sure my words won't be used against 
me, or against said other to far greater harm than I ever expected or 
intended.


-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] My Phabricator account has been disabled

[Isarra Yos]

But this wasn't an unconstructive comment. And as a designer, angry 
comments are particularly useful, to a point, as they help give us 
insight into our users and thus better prioritise problems that require 
immediate address. You cite my later response as an example of better 
communication, and yet without comments such as MZMcBride's to highlight 
the nature of the situation, I would never have thought there any NEED 
to leave such a comment.


Now I actually sort of wonder if, had I been less busy at the time being 
sick and backlogged (still backlogged, but wow did things get out of 
hand) and just replied then when he originally brought the situation to 
my attention, all of this might have been avoided?


-I

On 14/08/18 20:02, Amir Ladsgroup wrote:

That's very valid but you don't see the CoCC bans anyone who makes an
unconstructive or angry comment. The problem here happens when it happens
too often from one person. When a pattern emerges. Do you agree that when
it's a norm for one person and warnings are not working out, the option is
to ban to show this sort of behavior is not tolerated?

One hard part of these cases is that people see tip of an iceberg, they
don't see number of reports, pervious reports and number of people who the
user made uncomfortable so much that they bothered to write a report about
the user for different comments and actions. That's one thing that shows
the committee that it's a pattern and not a one-time thing.

Best



On Tue, Aug 14, 2018, 21:49 Isarra Yos  wrote:


Expecting every single comment to specifically move things forward
seems... a bit excessive, frankly. Not everyone is going to have the
vocabulary to properly express themselves, let alone the skill to fully
explain exactly what the issues are, why they are, how to move forward,
or whatever. And even then, I would argue that having input that isn't
directly doing any of this can still be useful to indicating to others
that can that such might indeed be in order, that there is indeed
sufficient interest to merit the effort, or sufficient confusion that
there might be more issue than immediately met the eye.

A wtf from one person can help to get others involved to actually
clarify, or ask followup questions, or what have you. It's not off topic.

-I

On 14/08/18 19:41, Amir Ladsgroup wrote:

Hey Petr,
We have discussed this before in the thread and I and several other

people

said it's a straw man.

The problem is not the WTF or "What the fuck" and as I said before the

mere

use of profanity is not forbidden by the CoC. What's forbidden is

"Harming

the discussion or community with methods such as sustained disruption,
interruption, or blocking of community collaboration (i.e. trolling).".
[1]  When someone does something in phabricator and you *just* comment
"WTF", you're not moving the discussion forward, you're not adding any
value, you're not saying what exactly is wrong or try to reach a

consensus.

Compare this with later comments made, for example:
https://phabricator.wikimedia.org/T200742#4502463

I hope all of this helps for understanding what's wrong here.

[1]: https://www.mediawiki.org/wiki/Code_of_Conduct
Best

On Tue, Aug 14, 2018 at 9:29 PM Petr Bena  wrote:


I am OK if people who are attacking others are somehow informed that
this is not acceptable and taught how to properly behave, and if they
continue that, maybe some "preventive" actions could be taken, but is
that what really happened?

The comment by MZMcBride was censored, so almost nobody can really see
what it was and from almost all mails mentioning the content here it
appears he said "what the fuck" or WTF. I can't really think of any
language construct where this is so offensive it merits instant ban +
removal of content.

I don't think we need /any/ language policy in a bug tracker. If
someone says "this bug sucks old donkey's " it may sounds a bit
silly, but there isn't really any harm done. If you say "Jimbo, you
are a f retard, and all your code stinks" then that's a problem,
but I have serious doubts that's what happened. And the problem is not
a language, but personal attack itself.

If someone is causing problems LET THEM KNOW and talk to them. Banning
someone instantly is worst possible thing you can do. You may think
our community is large enough already so that we can set up this kind
of strict and annoying policies and rules, but I guarantee you, it's
not. We have so many open bugs in phabricator that every user could
take hundreds of them... We don't need to drive active developers away
by giving them bans that are hardly justified.

P.S. if someone saying "WTF" is really giving you creeps, I seriously
recommend you to try to develop a bit thicker skin, even if we build
an "Utopia" as someone mentioned here, it's gonna be practical for
interactions in real world, which is not always friendly and nice. And
randoml

Re: [Wikitech-l] My Phabricator account has been disabled

[Isarra Yos]

Expecting every single comment to specifically move things forward 
seems... a bit excessive, frankly. Not everyone is going to have the 
vocabulary to properly express themselves, let alone the skill to fully 
explain exactly what the issues are, why they are, how to move forward, 
or whatever. And even then, I would argue that having input that isn't 
directly doing any of this can still be useful to indicating to others 
that can that such might indeed be in order, that there is indeed 
sufficient interest to merit the effort, or sufficient confusion that 
there might be more issue than immediately met the eye.


A wtf from one person can help to get others involved to actually 
clarify, or ask followup questions, or what have you. It's not off topic.


-I

On 14/08/18 19:41, Amir Ladsgroup wrote:

Hey Petr,
We have discussed this before in the thread and I and several other people
said it's a straw man.

The problem is not the WTF or "What the fuck" and as I said before the mere
use of profanity is not forbidden by the CoC. What's forbidden is "Harming
the discussion or community with methods such as sustained disruption,
interruption, or blocking of community collaboration (i.e. trolling).".
[1]  When someone does something in phabricator and you *just* comment
"WTF", you're not moving the discussion forward, you're not adding any
value, you're not saying what exactly is wrong or try to reach a consensus.
Compare this with later comments made, for example:
https://phabricator.wikimedia.org/T200742#4502463

I hope all of this helps for understanding what's wrong here.

[1]: https://www.mediawiki.org/wiki/Code_of_Conduct
Best

On Tue, Aug 14, 2018 at 9:29 PM Petr Bena  wrote:


I am OK if people who are attacking others are somehow informed that
this is not acceptable and taught how to properly behave, and if they
continue that, maybe some "preventive" actions could be taken, but is
that what really happened?

The comment by MZMcBride was censored, so almost nobody can really see
what it was and from almost all mails mentioning the content here it
appears he said "what the fuck" or WTF. I can't really think of any
language construct where this is so offensive it merits instant ban +
removal of content.

I don't think we need /any/ language policy in a bug tracker. If
someone says "this bug sucks old donkey's " it may sounds a bit
silly, but there isn't really any harm done. If you say "Jimbo, you
are a f retard, and all your code stinks" then that's a problem,
but I have serious doubts that's what happened. And the problem is not
a language, but personal attack itself.

If someone is causing problems LET THEM KNOW and talk to them. Banning
someone instantly is worst possible thing you can do. You may think
our community is large enough already so that we can set up this kind
of strict and annoying policies and rules, but I guarantee you, it's
not. We have so many open bugs in phabricator that every user could
take hundreds of them... We don't need to drive active developers away
by giving them bans that are hardly justified.

P.S. if someone saying "WTF" is really giving you creeps, I seriously
recommend you to try to develop a bit thicker skin, even if we build
an "Utopia" as someone mentioned here, it's gonna be practical for
interactions in real world, which is not always friendly and nice. And
randomly banning people just for saying WTF, with some cryptic
explanation, seems more 1984 style Dystopia to me...

On Tue, Aug 14, 2018 at 4:08 PM, David Barratt 
wrote:

Again, this isn't enwiki, but there would be a large mob gathering at

the

administrators' doorstep on enwiki for a block without that context and
backstory.


That seems like really toxic behavior.

On Tue, Aug 14, 2018 at 6:27 AM George Herbert 
I keep seeing "abusers" and I still haven't seen the evidence of the
alleged long term abuse pattern.

Again, this isn't enwiki, but there would be a large mob gathering at

the

administrators' doorstep on enwiki for a block without that context and
backstory.  That's not exactly the standard here, but ... would someone
just answer the question?  What happened leading up to this to justify

the

block?  If it's that well known, you can document it.

On Tue, Aug 14, 2018 at 12:18 AM, Adam Wight 

wrote:

Hi Petr,

Nobody is language policing, this is about preventing abusive behavior

and

creating an inviting environment where volunteers and staff don't

have to

waste time with emotional processing of traumatic interactions.

I think we're after the same thing, that we want to keep our community
friendly and productive, so it's just a matter of agreeing on the

means

to

accomplish this.  I see the Code of Conduct Committee standing up to

the

nonsense and you see them as being hostile, so our perspectives

diverge

at

that point.  I also see lots of people on this list standing up for

what

they think is right, and I'd love if that energy could be organized

better

so that we're 

Re: [Wikitech-l] [Wikimedia-l] C-team Statement on the Code of Conduct

[Isarra Yos]

Sorry, I apparently replied to the wrong mailing list.

On 14/08/18 18:19, Isarra Yos wrote:
As a total random, I'd also like to second this - as much as I think 
the CoC and the committee in particular have room to improve in how 
things are handled, this will never happen without proper support for 
the work they're doing in the first place.


While some of us have been somewhat flabbergasted by specific events, 
these are after all the people we need to be working with to actually 
resolve the issues at hand, and indeed the events (and handling 
thereof) themselves have also highlighted the need for more clearer 
standards moving forward. I'm glad to see some steps have already been 
taken. Let's continue in this vein.


Thank you!

-I

On 14/08/18 18:08, Amir Ladsgroup wrote:

Hey,
As a member of Code of conduct committee I just wanted to express how 
much

I appreciate your statement. The work we are doing is not fun, we are
dealing with frustrations, harassments, trolling, and all sorts of 
the dark

side of the Wikimedia movement but I genuinely believe that this type of
work is vital to keep the movement moving forward, to make us more
welcoming and foster a diverse environment.

All of the support I've received, private and public, online and 
offline is

overwhelming. Thank you, Thank you, Thank you.

Best
On Tue, Aug 14, 2018 at 7:46 PM Victoria Coleman 


wrote:


Hello everyone,

The executive leadership team, on behalf of the Foundation, would 
like to
issue a statement of unequivocal support for the Code of Conduct[1] 
and the
community-led Code of Conduct Committee. We believe that the 
development

and implementation of the Code are vital in ensuring the healthy
functioning of our technical communities and spaces. The Code of 
Conduct
was created to address obstacles and occasionally very problematic 
personal
communications that limit participation and cause real harm to 
community
members and staff. In engaging in this work we are setting the tone 
for the
ways we collaborate in tech. We are saying that treating others 
badly is
not welcome in our communities. And we are joining an important 
movement in

the tech industry to address these problems in a way that supports
self-governance consistent with our values.

This initiative is critical in continuing the amazing work of our 
projects
and ensuring that they continue to flourish in delivering on the 
critical

vision of being the essential infrastructure of free knowledge now and
forever.

Toby, Maggie, Eileen, Heather, Lisa, Katherine, Jaime, Joady, and 
Victoria



https://www.mediawiki.org/wiki/Code_of_Conduct <
https://www.mediawiki.org/wiki/Code_of_Conduct>




___
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: wikimedi...@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l

New messages to: wikimedi...@lists.wikimedia.org
Unsubscribe: 
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>






___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] My Phabricator account has been disabled

[Isarra Yos]

It's sounds nice, but no. It is not a feature. One of the arguments I 
was given when the CoC was initially pushed through was that of course 
it wasn't perfect as was, that it would be amended and fixed based on 
the real incidents it came into contact with. I maintain that it is 
impossible to do this - to amend, fix, and generally refine a document 
based on the real cases - when the details of the real cases and even 
the stats about what they are in general remain unavailable, and yet 
this is clearly precisely what is needed to avoid incidents like this in 
the future.


There has been considerable disagreement as to where we should be 
drawing the line between the public cases, the generalised, and the 
private, but this too is something we need to figure out out a community 
and clearly draw, and the only way to do so is with clear information on 
what is possible, common, and feasible.


-I

On 09/08/18 22:39, David Barratt wrote:

I'm not sure I completely understand the problem. What is being called a
"lack of transparency" is the opposite of "privacy by design." What is
being called a bug, is perhaps a feature. The irony of this, ought not be
missed.

On Thu, Aug 9, 2018 at 6:33 PM Isarra Yos  wrote:


An interesting comparison, democracy. Community consensus and
transparency were what brought our shared project to the great heights
we now see, and yet the CoC and especially its enforcement are rooted in
none of this. If this trainwreck that we are currently experiencing on
this list is truly our best shot at an open, welcoming, and supportive
environment when it flies in the face of everything that brought us here
in the first place, then all of that was a lie.

I'm pretty sure that's just wrong, though. Keeping everything behind
closed doors is the opposite of open. Community members having the CoC
used against them as a club and being afraid of retribution for seeking
help is the opposite of a welcoming and supportive environment. I would
put forth that the CoC, or more accurately, this heavy-handed
implementation of it, has been an abject failure that requires us all to
step back and try to look at all of this more objectively. To move
forward, we must address the issues with the CoC and its enforcement,
but to do so as a community, to come to any meaningful and informed
consensuses as such, will not be possible so long as nobody outside the
committee has any access to the stats, as no logging of actions taken is
available publicly, as the cases themselves remain largely invisible
even when they do not pertain to sensitive situations or materials.

Because if we do not base this in open process, consensus, and
transparency, then all platitudes aside, it's just not going to be
very... good. It's not going to address our needs, and we're not going
to be able to refine it as things come up. Not doing this /isn't
working/, and we need it work.

-I

On 09/08/18 20:48, Victoria Coleman wrote:

Hi everyone,

I’ve been following this discussion from afar (literally from a remote

mountainous part of Greece [1]) so please excuse the reflection. I saw this
today:



https://www.theatlantic.com/technology/archive/2018/08/jeongpedia/566897/
<https://www.theatlantic.com/technology/archive/2018/08/jeongpedia/566897/


This is us. This is our shared project. What an incredible privilege it

is to have the opportunity to be part of something utopian, yet real, that
is seen by the world as the last bastion of shared reality. This is no
accident, no fluke. It’s because of us. This incredible community of ours.
We are all different and yet we all, staff and volunteers alike, strive to
bring the best of ourselves to this monumental project of ours. Sometimes
we get it wrong. We get emotional, we say the wrong thing, we get
frustrated with each other.  But we are all in this together. And we hold
ourselves to a higher standard. I hope we can also forgive each other when
we fall down and offer a helping hand instead of a harsh, hurtful word. The
CoC , like democracy, is not perfect but it’s our best shot at an open,
welcoming and supportive environment in our technical spaces. Let’s
continue refining it and let’s get back to work.

Warmly,

Victoria


[1] https://en.wikipedia.org/wiki/Pelion <

https://en.wikipedia.org/wiki/Pelion>




On Aug 9, 2018, at 7:24 PM, Stas Malyshev 

wrote:

Hi!


to me that this could easily be used as a shaming and blaming list. If

the

block is over and the person wants to change their behavior, it might

be

hard for them to start with a clean sheet if we keep a backlog public

of

everyone. I'd see it not only as a privacy issue for the people

reporting,

but also the reported.

You have a good point here. Maybe it should not be permanent, but should
expire after the ban is lifted. I can see how that could be better
(though nothing that was ever public is completely forgotten, but still
not carrying it around in our spaces might be good). S

Re: [Wikitech-l] My Phabricator account has been disabled

[Isarra Yos]

An interesting comparison, democracy. Community consensus and 
transparency were what brought our shared project to the great heights 
we now see, and yet the CoC and especially its enforcement are rooted in 
none of this. If this trainwreck that we are currently experiencing on 
this list is truly our best shot at an open, welcoming, and supportive 
environment when it flies in the face of everything that brought us here 
in the first place, then all of that was a lie.


I'm pretty sure that's just wrong, though. Keeping everything behind 
closed doors is the opposite of open. Community members having the CoC 
used against them as a club and being afraid of retribution for seeking 
help is the opposite of a welcoming and supportive environment. I would 
put forth that the CoC, or more accurately, this heavy-handed 
implementation of it, has been an abject failure that requires us all to 
step back and try to look at all of this more objectively. To move 
forward, we must address the issues with the CoC and its enforcement, 
but to do so as a community, to come to any meaningful and informed 
consensuses as such, will not be possible so long as nobody outside the 
committee has any access to the stats, as no logging of actions taken is 
available publicly, as the cases themselves remain largely invisible 
even when they do not pertain to sensitive situations or materials.


Because if we do not base this in open process, consensus, and 
transparency, then all platitudes aside, it's just not going to be 
very... good. It's not going to address our needs, and we're not going 
to be able to refine it as things come up. Not doing this /isn't 
working/, and we need it work.


-I

On 09/08/18 20:48, Victoria Coleman wrote:

Hi everyone,

I’ve been following this discussion from afar (literally from a remote 
mountainous part of Greece [1]) so please excuse the reflection. I saw this 
today:

https://www.theatlantic.com/technology/archive/2018/08/jeongpedia/566897/ 


This is us. This is our shared project. What an incredible privilege it is to 
have the opportunity to be part of something utopian, yet real, that is seen by 
the world as the last bastion of shared reality. This is no accident, no fluke. 
It’s because of us. This incredible community of ours. We are all different and 
yet we all, staff and volunteers alike, strive to bring the best of ourselves 
to this monumental project of ours. Sometimes we get it wrong. We get 
emotional, we say the wrong thing, we get frustrated with each other.  But we 
are all in this together. And we hold ourselves to a higher standard. I hope we 
can also forgive each other when we fall down and offer a helping hand instead 
of a harsh, hurtful word. The CoC , like democracy, is not perfect but it’s our 
best shot at an open, welcoming and supportive environment in our technical 
spaces. Let’s continue refining it and let’s get back to work.

Warmly,

Victoria


[1] https://en.wikipedia.org/wiki/Pelion 




On Aug 9, 2018, at 7:24 PM, Stas Malyshev  wrote:

Hi!


to me that this could easily be used as a shaming and blaming list. If the
block is over and the person wants to change their behavior, it might be
hard for them to start with a clean sheet if we keep a backlog public of
everyone. I'd see it not only as a privacy issue for the people reporting,
but also the reported.

You have a good point here. Maybe it should not be permanent, but should
expire after the ban is lifted. I can see how that could be better
(though nothing that was ever public is completely forgotten, but still
not carrying it around in our spaces might be good). So I'd say public
record while the ban is active is a must, but after that expunging the
record is fine.

--
Stas Malyshev
smalys...@wikimedia.org

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] My Phabricator account has been disabled

[Isarra Yos]

On 09/08/18 07:40, Amir E. Aharoni wrote:

No, it was not thoughtful. What actually happened is that the other users
are now submerged with dozens of emails analyzing that interjection. Sure,
it's pretty easy to ignore this thread or even mute it in one's email
reader, but one could just as well ignore that bug report. So no, it's not
thoughtful. It's provocative, unnecessary, and nonconstructive.

Using the f-word shouldn't be fully banned, but it should be obvious that
it is not always OK. Every case of using such language is supposed to
trigger a consideration: "Is it OK to use it now?". This should be common
sense, but apparently it isn't, so it's good to have a CoC to encourage
people to be considerate. And it's good to enforce the CoC when necessary.


I don't really see how it's fair to hold someone responsible for the 
complete and utter overreaction of others as a result of a single, 
fairly ordinary statement on their part. No, MZMcBride's wtf wasn't 
exactly ideal, but by itself should have at worst been an easily ignored 
irritation. Only because of the compounding reactions to it does it 
appear to hold any weight at all; no other 'wtf's, 'fuck php's, 'oh fuck 
shit shit fucking fuck fuck did this do's, or even the sometimes cited 
James Wales statement that I would argue truly was completely 
inappropriate, have had any such impact, simply because everyone else 
refrained from losing their heads over it.


Perhaps we should all step back a bit and realise that /we're/ the ones 
making this a major issue - that the problem is not the statement that 
was made on phabricator, but everything that has occurred after.


What was it that really caused all this?

-I


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] My Phabricator account has been disabled

[Isarra Yos]

Er, apologies for my previous email, I may have gone a bit overboard 
with it. Is it generally improper to blame the cold medicine, in such 
cases, bow out, and generally just go straight to bed? Because I blame 
the cold medicine.


Again, sorry about that.

-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] My Phabricator account has been disabled

[Isarra Yos]

Having personally been subject of a case of sexual harassment at an 
unrelated event a few years back where I was supposedly the victim, I 
have to wonder even about those. Seriously, what the hell /is/ sexual 
harassment? Because in my case, apparently me butting into a 
conversation just to be an arse constituted me being sexually harassed, 
which... just... what? (I only found out about this at all because it 
was in the godsdamn news.)


Meanwhile we probably actually have real cases of folks being harassed 
or even assaulted and they don't even realise that's what's going on 
either because everything's all hushy hush and they've no sensible 
examples of what's worth going to help for themselves, or anything to 
show what is or isn't apt to just blow up in their face in practice so 
they actually feel /safe/ doing so. Seriously, if we don't talk about 
this stuff, how is anyone supposed to learn from it? How the hell is the 
current code of conduct supposed to be refined? How are we as a 
community supposed to address any existing issues?


Obviously we need something to protect the folks involved, but this is 
just a mess as is. I haven't even felt at all safe going to the CoC 
folks about other things that have happened in venues subject to the 
CoC, for much the same reason, and while that was just incidents of 
frayed nerves overflowing and someone yelling at me for what turned out 
to be a total miscommunication anyway, I wound up having to remove 
myself from a D game I was a part of as a result because I just 
couldn't focus properly on anything for awhile afterwards AND YOU KNOW 
IT WOULD SURE HELP IF WE HAD REASONABLE PEOPLE TO GO TO TO JUST... HELP 
SMOOTH THINGS OVER AND TELL US IT'S OKAY OR STUFF. WITHOUT HAVING TO 
WORRY ABOUT ANYTHING BEING MADE WORSE FOR ANYONE INVOLVED OR GETTING 
BANNED OURSELVES OR CRAP.


Feckin'...

-I

On 08/08/18 20:29, Amir Ladsgroup wrote:

Taking my coc hat off, I'm not representing the committee at all.
Several things have been misunderstood imo. I want to address them.
1) The use of profanity is not prohibited by the COC, using them against
others or for unconstructive reasons is. If you see the whole discussion,
you could clearly see the comment is not made to move discussion forward.
These are clear case of disruptive actions.
1.1) the response to these violations depends on the user, very similar to
what Wikipedia does. If it was the first case reported about Mz, they
wouldn't get this ban.
2) the duration of block which is for one week was determined and
communicated in the email. You can check the email as it's public now.
3) not being able to discuss cases clearly also bothers me too as I can't
clarify points. But these secrecy is there for a reason. We have cases of
sexual harassment in Wikimedia events, do you want us to communicate those
too? And if not, where and who supposed to draw the line between public and
non-public cases? I'm very much for more transparency but if we don't iron
things out before implementing them, it will end up as a disaster.

Sent on my phone, on a vacation.
Best
On Wed, Aug 8, 2018, 21:49 Chad  wrote:


On Wed, Aug 8, 2018 at 11:48 AM bawolff  wrote:


So MZMcBride is temporarily banned for an unspecified amount of time.
I have some concerns:
a) The fact all these are secret is a recipe for FUD and
misunderstandings. From accusations of partiality of the committee to
people being unblocked because people think its an accident, are all
natural consequences of things being secret. I think this is bound to
create a negative environment in the long term.


This.



b) What is the point of blocking him temporarily and not telling him
how long he's banned for. That's just silly.


I'm going to quote someone out of context here, but I think it establishes
the point I'd like to make:

"temporary solutions have a terrible habit of becoming permanent, around
here"

-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] My Phabricator account has been disabled

[Isarra Yos]

Okay, in all seriousness, ArbCom does work. It does a good /enough/ job, 
when you weigh it against the alternatives. I'm not really sure how, at 
the sorts of scales we're looking at, anything would do much better.


While our technical communities operate on a much smaller scale, this 
still shows us a model we can learn from. Because while ArbCom isn't 
great - most users would not say they actually trust it and a lot of 
arbs probably would in particular say how bad it is - the thing is, it 
does do quite a bit right. In light of the incidents we've had thus far 
in technical spaces, we should really be learning from that.


-I

On 08/08/18 20:15, Isarra Yos wrote:

Nope! But this just seems /worse/ in practice.

-I

On 08/08/18 20:12, Ryan Kaldari wrote:

Are you suggesting that ArbCom does a good job of maintaining a collegial, 
harassment-free environment on English Wikipedia? Just wanted to double-check ;)


On Aug 8, 2018, at 1:02 PM, Isarra Yos  wrote:

On other projects, we have community-elected groups among whom we see oversight 
in the form of new members upon subsequent elections who can audit the 
backlogs, and who conduct their primary functions in the open and issue clear 
statements when a matter does indeed merit not discussing openly, using their 
discretion as to when to apply privacy and similar concerns specifically. 
Generally speaking, most users actually trust their discretion in those matters.

Nothing about /this/ particular issue appears to merit any such concern, and 
because none of the above holds here, either, I can't say I necessarily trust 
this committee to make that call to begin with.

-I


On 08/08/18 19:35, Ryan Kaldari wrote:
With all the clamoring for transparency, has anyone considered the privacy
implications for publicly documenting every complaint against a Phabricator
user? That seems like it could have just as much of a chilling effect on
participation, if not more, than the idea that you can be blocked for being
rude.



On Wed, Aug 8, 2018 at 12:05 PM Yair Rand  wrote:

I very much agree that profanity should not be used around Wikimedia, but
there's a large gap between "things we ideally wouldn't have", "things an
employee of a Wikimedia institution should be fired for", and "things a
volunteer contributor should be blocked for" (in that order). (The acronym
"wtf" has been used 532 times on Phabricator according to search results
(including some by the relevant CoCC members), and 10 times fully spelled
out.)

Just to remind everyone of some background, the CoC came into existence
after having a policy tag edit-warred onto it after a non-consensus-backed
discussion regarding a particular section was self-closed as consensus
reached for the entire document, attempting to establish an unaccountable
and secretive Committee that may ban users for any of a number of extremely
vaguely worded violations including "attempting to circumvent a decision of
the Committee", appoints its own members (none of which were
community-selected), can veto any changes to the CoC, and recently claimed
absolute authority over all development-oriented spaces on all Wikimedia
projects (including VPT, gadget/script/module talk pages) on a "consensus"
of a single user. It's quite clearly a completely illegitimate institution.

But leaving all that aside, this was a terrible decision. I recommend an
immediate unblock.

-- Yair Rand



2018-08-08 13:02 GMT-04:00 David Cuenca Tudela:


In general I would prefer to keep vulgar language out of the projects, as
it doesn't bring anything positive.
Research shows that swearing causes stress [1], and there are many ways

of

showing dissatisfaction without using coarse language.

For instance, I would appreciate if there would be more interest in using
Nonviolent Communication, as it is more effective in getting the message
across than with negativity.
Introduction:https://www.youtube.com/watch?v=M-129JLTjkQ

Regards,
Micru


[1]http://journals.plos.org/plosone/article?id=10.1371/
journal.pone.0022341


On Wed, Aug 8, 2018 at 5:53 PM Bináris  wrote:

That's what I called a very first world problem.
This happens when American culture and behavioral standard is extended

to

an international community.
It is not rally polite to write that F-thing (how many times has it

been

written directly or abbreviated or indirectly in this very

discussion?).

But to ban a member of the technical community from the working

environment

is really harmful.
Although we do block people from editing Wikipedia, too, but we do it
publicly, clearly, comparably, and by the rules of the local community,

not

by hidden rules of admin board. And not for one ugly word.
This secret banning undermines the community, and therefore it is
destructive.

Additionally, as code of conduxt itself was discussed here, the coc

file

case was discussed here a few weeks ago, and this is the place where

most

Pha

Re: [Wikitech-l] My Phabricator account has been disabled

[Isarra Yos]

Nope! But this just seems /worse/ in practice.

-I

On 08/08/18 20:12, Ryan Kaldari wrote:

Are you suggesting that ArbCom does a good job of maintaining a collegial, 
harassment-free environment on English Wikipedia? Just wanted to double-check ;)


On Aug 8, 2018, at 1:02 PM, Isarra Yos  wrote:

On other projects, we have community-elected groups among whom we see oversight 
in the form of new members upon subsequent elections who can audit the 
backlogs, and who conduct their primary functions in the open and issue clear 
statements when a matter does indeed merit not discussing openly, using their 
discretion as to when to apply privacy and similar concerns specifically. 
Generally speaking, most users actually trust their discretion in those matters.

Nothing about /this/ particular issue appears to merit any such concern, and 
because none of the above holds here, either, I can't say I necessarily trust 
this committee to make that call to begin with.

-I


On 08/08/18 19:35, Ryan Kaldari wrote:
With all the clamoring for transparency, has anyone considered the privacy
implications for publicly documenting every complaint against a Phabricator
user? That seems like it could have just as much of a chilling effect on
participation, if not more, than the idea that you can be blocked for being
rude.



On Wed, Aug 8, 2018 at 12:05 PM Yair Rand  wrote:

I very much agree that profanity should not be used around Wikimedia, but
there's a large gap between "things we ideally wouldn't have", "things an
employee of a Wikimedia institution should be fired for", and "things a
volunteer contributor should be blocked for" (in that order). (The acronym
"wtf" has been used 532 times on Phabricator according to search results
(including some by the relevant CoCC members), and 10 times fully spelled
out.)

Just to remind everyone of some background, the CoC came into existence
after having a policy tag edit-warred onto it after a non-consensus-backed
discussion regarding a particular section was self-closed as consensus
reached for the entire document, attempting to establish an unaccountable
and secretive Committee that may ban users for any of a number of extremely
vaguely worded violations including "attempting to circumvent a decision of
the Committee", appoints its own members (none of which were
community-selected), can veto any changes to the CoC, and recently claimed
absolute authority over all development-oriented spaces on all Wikimedia
projects (including VPT, gadget/script/module talk pages) on a "consensus"
of a single user. It's quite clearly a completely illegitimate institution.

But leaving all that aside, this was a terrible decision. I recommend an
immediate unblock.

-- Yair Rand



2018-08-08 13:02 GMT-04:00 David Cuenca Tudela :


In general I would prefer to keep vulgar language out of the projects, as
it doesn't bring anything positive.
Research shows that swearing causes stress [1], and there are many ways

of

showing dissatisfaction without using coarse language.

For instance, I would appreciate if there would be more interest in using
Nonviolent Communication, as it is more effective in getting the message
across than with negativity.
Introduction: https://www.youtube.com/watch?v=M-129JLTjkQ

Regards,
Micru


[1] http://journals.plos.org/plosone/article?id=10.1371/
journal.pone.0022341


On Wed, Aug 8, 2018 at 5:53 PM Bináris  wrote:

That's what I called a very first world problem.
This happens when American culture and behavioral standard is extended

to

an international community.
It is not rally polite to write that F-thing (how many times has it

been

written directly or abbreviated or indirectly in this very

discussion?).

But to ban a member of the technical community from the working

environment

is really harmful.
Although we do block people from editing Wikipedia, too, but we do it
publicly, clearly, comparably, and by the rules of the local community,

not

by hidden rules of admin board. And not for one ugly word.
This secret banning undermines the community, and therefore it is
destructive.

Additionally, as code of conduxt itself was discussed here, the coc

file

case was discussed here a few weeks ago, and this is the place where

most

Phabricatos users communicate,  this is a good place to discuss this

case,

too. Publicity is good.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


--
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing lis

Re: [Wikitech-l] My Phabricator account has been disabled

[Isarra Yos]

On other projects, we have community-elected groups among whom we see 
oversight in the form of new members upon subsequent elections who can 
audit the backlogs, and who conduct their primary functions in the open 
and issue clear statements when a matter does indeed merit not 
discussing openly, using their discretion as to when to apply privacy 
and similar concerns specifically. Generally speaking, most users 
actually trust their discretion in those matters.


Nothing about /this/ particular issue appears to merit any such concern, 
and because none of the above holds here, either, I can't say I 
necessarily trust this committee to make that call to begin with.


-I

On 08/08/18 19:35, Ryan Kaldari wrote:

With all the clamoring for transparency, has anyone considered the privacy
implications for publicly documenting every complaint against a Phabricator
user? That seems like it could have just as much of a chilling effect on
participation, if not more, than the idea that you can be blocked for being
rude.


On Wed, Aug 8, 2018 at 12:05 PM Yair Rand  wrote:


I very much agree that profanity should not be used around Wikimedia, but
there's a large gap between "things we ideally wouldn't have", "things an
employee of a Wikimedia institution should be fired for", and "things a
volunteer contributor should be blocked for" (in that order). (The acronym
"wtf" has been used 532 times on Phabricator according to search results
(including some by the relevant CoCC members), and 10 times fully spelled
out.)

Just to remind everyone of some background, the CoC came into existence
after having a policy tag edit-warred onto it after a non-consensus-backed
discussion regarding a particular section was self-closed as consensus
reached for the entire document, attempting to establish an unaccountable
and secretive Committee that may ban users for any of a number of extremely
vaguely worded violations including "attempting to circumvent a decision of
the Committee", appoints its own members (none of which were
community-selected), can veto any changes to the CoC, and recently claimed
absolute authority over all development-oriented spaces on all Wikimedia
projects (including VPT, gadget/script/module talk pages) on a "consensus"
of a single user. It's quite clearly a completely illegitimate institution.

But leaving all that aside, this was a terrible decision. I recommend an
immediate unblock.

-- Yair Rand



2018-08-08 13:02 GMT-04:00 David Cuenca Tudela :


In general I would prefer to keep vulgar language out of the projects, as
it doesn't bring anything positive.
Research shows that swearing causes stress [1], and there are many ways

of

showing dissatisfaction without using coarse language.

For instance, I would appreciate if there would be more interest in using
Nonviolent Communication, as it is more effective in getting the message
across than with negativity.
Introduction: https://www.youtube.com/watch?v=M-129JLTjkQ

Regards,
Micru


[1] http://journals.plos.org/plosone/article?id=10.1371/
journal.pone.0022341

On Wed, Aug 8, 2018 at 5:53 PM Bináris  wrote:


That's what I called a very first world problem.
This happens when American culture and behavioral standard is extended

to

an international community.
It is not rally polite to write that F-thing (how many times has it

been

written directly or abbreviated or indirectly in this very

discussion?).

But to ban a member of the technical community from the working

environment

is really harmful.
Although we do block people from editing Wikipedia, too, but we do it
publicly, clearly, comparably, and by the rules of the local community,

not

by hidden rules of admin board. And not for one ugly word.
This secret banning undermines the community, and therefore it is
destructive.

Additionally, as code of conduxt itself was discussed here, the coc

file

case was discussed here a few weeks ago, and this is the place where

most

Phabricatos users communicate,  this is a good place to discuss this

case,

too. Publicity is good.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
Etiamsi omnes, ego non
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] coc ban

[Isarra Yos]

Yeah, even if it seems like volunteers are treated as second class 
citizens, advocating mistreatment of staff too isn't going to resolve 
anything. We should all just try to do our best, and all realise that 
these are /peolpe/ we're dealing with. It's not always going to be 
perfect, it's not always going to be professional... and this goes both 
ways. We shouldn't expect needlessly high standards of behaviour or 
putting up with things from anyone, on any side.


-I

On 08/08/18 17:54, Brion Vibber wrote:

Oleg -- I interpret that suggestion as "employees of WMF and WMDE have to
accept all ongoing abuse they are given without complaint"; that may not be
what you intended but that's how I read it, and I'd like to unequivocally
*reject that notion*.

WMF and WMDE employees are people performing a job, and deserve a safe work
environment. When it's suggested that long-term abusive behavior against
employees be tolerated because it's not a big deal or it's just volunteers
letting off steam, I have to counter that it *is* a big deal. It promotes
burn-out and harms people both personally and professionally.

Please don't be part of that cycle of abuse and burn-out, all. It's not
cool, it's not productive, it's not funny, and it doesn't help you get what
you wanted done.

-- brion

On Wed, Aug 8, 2018 at 10:43 AM Saint Johann  wrote:


Sure.

Wikimedia Foundation employees inherently have more privilege and weight
in MediaWiki developer community than the volunteers do, especially less
participating ones. Power dynamics of the discussion between a volunteer
and an employee (and, sometimes even more generally on Phabricator) are
structured in a way in that more than frequently an end decision will be
taken not by volunteers or all Wikimedia community, but by employees or
people that are more well-versed in MediaWiki development spaces (who
also can happen to be employees).

Code of conduct is important to be enforced, but, in my opinion, there
should be a difference in how it’s enforced. To volunteers that help the
movement, there should be no unacceptable language, as it is a way (and
a purpose of something like code of conduct) to make MediaWiki
development spaces more welcoming to future volunteers.

However, employees, while in their capacity, should be (in reasonable
amounts) less guarded against non-constructive criticism, because at
many times all you can provide to someone’s work decisions could only be
non-constructive because you know that no minds and hearts will be
changed by any amount of constructive criticism. I am, of course, not
talking about any kinds of serious stuff (Jimmy Wales language), but
more about ‘WTF language’.

Oleg

On 08/08/2018 19:20, Arlo Breault wrote:

On Aug 8, 2018, at 9:42 AM, Saint Johann  wrote:

especially when said to Wikimedia employees as opposed to volunteers.)

Can you elaborate on that?



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] My Phabricator account has been disabled

[Isarra Yos]

This is actually a rather good point, and one I would argue also shows 
why we need more transparency from the CoC committee in the first place 
- lacking that, all the community at large can really go on is what the 
accused provides, which does no favours toward the effectiveness of any 
actions taken, especially if said actions really were justified.


-I

On 08/08/18 15:26, Lucas Werkmeister wrote:

Can we please avoid jumping to conclusions like “Ladsgroup [was] enforcing
the CoC out of their personal feelings” or that this was an “immediate
escalation”, when the only information we have in this thread is a quoted
email that the author probably never intended to be a comprehensive summary
of the situation in the first place, and which was only relayed to this
list through a non-neutral party?

Cheers,
Lucas

Am Mi., 8. Aug. 2018 um 16:45 Uhr schrieb Dan Garry :


On 8 August 2018 at 14:29, Alex Monk  wrote:


Are you trying to ban people discussing CoC committee decisions publicly?
Not that it even looks like he wrote grievances.


Hardly. I have absolutely nothing to do with the administration of this
list, nor the authority to set what is discussed on this list, nor any
involvement in the Code of Conduct, all of which you are well aware.

Dan

--
Dan Garry
Lead Product Manager, Editing
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l






___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] My Phabricator account has been disabled

[Isarra Yos]

I see two issues here:

1. Lack of logging of autodisabled accounts means that confusions such 
as this may arise, but more especially, we appear to lack any way to 
track for false positives of accounts from new users who do mean well, 
who instead of going to someone to bring up the issue, simply give up at 
that point - this is a major issue. It sounds like this feature will be 
going out soon, though, so that's good.


2. What the fuck is going on with the Code of Conduct (committee)?

* How are variants of 'wtf' inherently problematic? They convey a 
generally very relevant meaning ('I don't get this', 'this makes no 
sense', 'this is just strange', etc), which, while it could be used as 
part of a larger attack on a contributor, by itself is something we 
/need/ to be able to say.


* Did anyone actually reach out to MZMcBride before blocking him with an 
explanation as to why the 'wtf' was a problem, or ask him to otherwise 
fix it or amend his behaviour? Immediate escalation to banning, unless 
to prevent actively ongoing disruption, is nothing but disruptive. Users 
need to be told why what they're doing is a problem and given a chance 
to fix it on their own - only if they refuse or persist doing that same 
thing after can that possibly become an instance actively ongoing 
disruption and merit a ban, which given that this appears to have come 
out of the blue only several days after the comment was made does not 
even remotely seem to be the case here.


* Transparency and actionability of CoCC actions/warnings in general 
seems to be very lacking. This doesn't just mean that it's an issue that 
the information as to why action has been taken isn't available to 
everyone for scrutiny (though it is - barring extremes, this is not just 
the wikimedia way, but also basically the only way to ensure a body 
doesn't wind up with effectively absolute power to do whatever with no 
accountability whatsoever), but that said information often isn't even 
available to the one being taken action against is downright 
counterproductive, as they thus have nothing to go on. The warnings 
become meaningless and unactionable (as was the case with the prior 
warnings MZMcBride has received for unrelated... things), the blocks 
just confusing (as this one is).


Ironically this also actually sort of comes back to the main issue with 
the lack of logging - an established user like MZMcBride has recourse to 
actually call out this and complain, thus bringing the issue to 
attention. Any newcomer who gets bitten by this, however, is almost 
certainly not going to... and the rest of us will never have any idea 
anything even happened. So this needs to be addressed, not just for his 
sake, but for everyone else we DON'T know about.


-I

On 08/08/18 13:01, Alex Monk wrote:

So are we supposed to be careful about using 'wtf' now?

On Wed, 8 Aug 2018, 13:53 MZMcBride,  wrote:


Amir Ladsgroup wrote:

I disabled the account and now I disabled it again. It's part of a CoC
ban. We sent the user an email using the "Email to user" functionality

>from mediawiki.org the moment I enforced the ban.

We rather not to discuss details of cases publicly but I feel this
clarification is very much needed.

Ah, I found the e-mail:


Subject: Temporarily ban from phabricator

Hello,

We received reports about your comments in phabricator. While we
encourage criticism and productive comments to improve the software,
comments like "What the fuck" do not contribute to the discussion and
turns the discussion from respectful criticism to folks swearing at other
folks.


We asked you to stop making such comments that do not contribute to the
discussion. We have no choice to issue a temporarily ban from
phabricator. We hope you notice this type of behaviour is not welcome in
our technical spaces.

Please read Code of conduct in depth:
https://www.mediawiki.org/wiki/Code_of_Conduct

Best

This email was sent by TechConductCommittee to MZMcBride by the "Email
this user" function at MediaWiki. If you reply to this email, your email
will be sent directly to the original sender, revealing your email
address to them.

This is re: .

Greg Varnum created a mess, inappropriately closed a valid bug, and
removed its parent task because he didn't want to even acknowledge the
bug. I expressed exasperation with his actions, particularly gaslighting
volunteers (cf.
. Amazing.

MZMcBride



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l 

[Wikitech-l] Timeless Newsletter

[Isarra Yos]

Hey all,

For anyone not familiar, the Timeless skin has been available as an 
option on Wikimedia wikis since november or so, and development of the 
skin is now being funded by a Project Grant. If you're interested in 
receiving updates about this, I've created a newsletter which should be 
going out monthly.


You can sign up for the newsletter here: 
https://meta.wikimedia.org/wiki/Timeless/Newsletter
Or read the first issue: 
https://meta.wikimedia.org/wiki/Timeless/Newsletter/1


Timeless: https://www.mediawiki.org/wiki/Skin:Timeless?useskin=timeless
The grant now funding this: 
https://meta.wikimedia.org/wiki/Grants:Project/Isarra/Timeless:_Post-deployment_support


Thank you to everyone for your interest and support thus far, and making 
all of this possible!


-Isarra

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit as a shared community space

[Isarra Yos]

On 09/06/18 17:30, Brion Vibber wrote:

On Sat, Jun 9, 2018 at 10:21 AM Alex Monk  wrote:


  For example where you said "IMHO specifically because some people are
trying to avoid being bound by it or protesting its existence by looking
for loopholes to avoid it", which is not at all what that thread is about
as has been made very clear in that thread.


I disagree that it has been made clear. I found the opposite to be true in
my experience of reading that thread -- for instance the ability to exclude
the code of conduct from some interactions between developers and users was
cited as a desired feature, and thus a reason to want to avoid advertising
the code of conduct in the repo.

Perhaps I'm reading too much into the idea of wanting to avoid the code of
conduct as a proxy for not liking it?


I am genuinely at a loss how this could possibly be made any clearer. 
People are already explicitly stating this. Yaron in particular stated 
this from the start.




...
This is a bad analogy. Repository owners *are* essentially the admins, and
in this case get content control. The people involving themselves are more
akin to global users like stewards trying to override local admin actions,
and in this case they're not really supposed to have such control of
content. Like with on-wiki stuff, it's not really so bad when a global user
comes and does uncontroversial cleanup, but global permissions are not for
the purpose of involving oneself in local controversy.


I'll let that one stand. Sounds like a good analogy except that this is
exactly the sort of thing a steward might have to intervene for.


That is not what stewards do. They are not superadmins, but backups. 
Support. As people with more general +2 normally do in specific 
repositories.



Not just outsiders generally, but outsiders who have not had a fair shake
in the past because the place has been unwelcoming or full of toxic
interactions.

Reducing toxic interactions is an important part of that, and sometimes
that means telling people who cause toxic interactions that they are not
welcome because we would rather have other people who are less toxic and
can bring different perspectives and representation.

-- brion


Perhaps I was too subtle the last time I hinted at this: this is toxic. 
What you and others are doing misrepresenting what others are saying, 
the general heavy-handedness, the implications that anyone against a 
specific aspect of implementation is against the very concept of good 
conduct...


Please stop.

-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Can/should my extensions be deleted from the Wikimedia Git repository?

[Isarra Yos]

On 08/06/18 09:29, Gergo Tisza wrote:

... I'm sure you
wouldn't act (inside or outside Wikimedia technical spaces) in ways
inconsistent with the spirit of the code of conduct anyway, but this was a
silly fight to pick and I hope you'll reconsider (or if you have pragmatic
reasons for not wanting the file, you'll explain those).


The CoC does not apply to contributors outside of Wikimedia itself. A 
repository that happens to be hosted by Wikimedia is not exclusive to 
Wikimedia, and a file like this can cause confusion among 
contributors/users elsewhere. This is a pragmatic reason for not having 
it, especially when these repositories are primarily created for these 
external contributors/users.


But this is backwards - the default state was not having it in the 
repositories. Changing that (across the board) was what should have 
required justification, not going back. And given that it doesn't even 
affect whether or not the CoC applies if the file is there or not, what 
even is the point of all this?


Frankly the harsh response from proponents and handling here, to the 
point of bypassing normal processes and misusing rights to enforce 
something that was never even decided as a community, seems completely 
at odds with the spirit and intent of the CoC in the first place. If 
we're trying to make contributors feel welcome, this is if anything 
doing the exact opposite.


-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Can/should my extensions be deleted from the Wikimedia Git repository?

[Isarra Yos]

This. The links should be in the interfaces in which we actually 
interact with each other, not the repositories themselves. A repository 
isn't even inherently a wikimedia technical space because it can be 
cloned anywhere, as Yaron rightfully points out; using 
gerrit/phab/things wikimedia manages to interact with it, however, is. 
Yes, people could potentially use those without going through the 
frontend UI, but it'd still hold. For them, if anything, it'd be even 
more important not to clutter up the repositories with redundant files, 
as they're working with more limited tools to begin with.


Given that these files don't contain anything meaningful (just a link, 
thus requiring an extra step regardless to find the content); that 
developers won't have any particular reason to open these files from the 
repository while interacting with others, as the interaction that the 
CoC covers happens via tools such as gerrit/phab/etc; and that these 
files won't even be visible when people are using said tools as said 
tools normally show only what's currently being modified, I highly 
recommend losing the COC.md files entirely. It's clutter, to no 
particular gain. Generic advertising, at best, in an often irrelevant place.


-I

On 08/06/18 06:50, Nischay Nahata wrote:

The right place for COC related stuff is probably on the Gerrit user
interface.

On Fri, Jun 8, 2018, 11:48 AM Daniel Zahn  wrote:


On Thu, Jun 7, 2018 at 11:40 PM, Max Semenik 
wrote:


My personal opinion is twofold:


I agree with Max here. The CoC applies anyways whether the file is in the
repo or not
because Wikimedia infrastructure is being used.

But we should not make it mandatory to keep a copy of this file in each and
every repo.

I don't see how "not having the file
is against the CoC itself" because it certainly doesn't say anything about
that, in that regard Yaron
is correct.

--
Daniel Zahn 
Operations Engineer
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] "PHP test coverage decreased" - really?

[Isarra Yos]

On 26/04/18 19:02, Daniel Kinzler wrote:

Also, am I correct in thinking that I could introduce a completely new 1000 line
class with no tests, and that would *not* be detected as decreasing coverage,
since the new class didn't have any coverage before?


Given that I've done similar (not a new class, but a bunch of functions 
to an existing test-free class) and had it not complain, quite possibly! 
Is weird, but given that the class in question is terrifying soup, I'm 
glad it didn't complain there because I wouldn't even know where to 
begin adding coverage.


-I


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Mobile MonoBook

[Isarra Yos]

On 03/04/18 22:52, Strainu wrote:

Well, it looks a bit dated, but in cute and geekish way. I love the
way you took the menu out of the way without hiding it under a
hamburger button,


Well, admittedly, that approach was largely just so it would work at all 
without js. I was kind of planning on also having a more traditional 
popout thing for when js is enabled, but I haven't implemented that yet.



but what I would particularly like to see is how it
handles navboxes. Traditionally, they have been hidden on the
Wikipedia mobile site, prompting people to do all kinds of sick
workarounds that kind of work, but not really. If anyone can come up
with a decent solution to that it's probably you :)


As others rightly point out, the problem with navboxes is as much an 
onwiki/content problem as a skinning one - many of these did not need to 
be tables to begin with, but there was no reason not to, but there also 
wasn't really any better alternative. Now that we have things like 
templatestyles, options exist to convert them, but that's going to take 
considerable time and effort as well from actual content editors - but 
there are also a lot of tables in the wiki content that actually do need 
to be tables, too. This sort of data is hard to present and... well, 
frankly resolving that for tables in general should at least begin to 
approach navboxes as they are currently, as well?


So I see a few approaches here, beyond just convert the navboxes 
content-side, since, again, that doesn't solve all of it anyway (though 
we still should do that too):


* Hide such tables entirely (what MF apparently does?). They display 
poorly, and provide relatively little value as a result. I... don't like 
this logic, because if they weren't worth having they wouldn't be on the 
page in the first place, generally. This is the sort of call the editors 
should be making.
* Collapse tables into a modal, as DJ says - have some sort of thumbnail 
and the like to indicate what it is in general, and then open it up into 
a full-screen viewer. Unfortunately requires js. (So fine for modern 
skins, but this is monobook!)
* Just kind of... separate them from the rest of the content with 
contained scrolling (overflow: auto, I think?). Has potential to be very 
annoying, but at least it doesn't require js!


Given that that's all I've got, I'll just come out and say that a canned 
version of the second one in core would be incredibly useful across all 
skins, and... we can probably just manually add in the third as a nojs 
fallback? Except why not include that fallback regardless? Hmm.


Are there any other options here?

-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Mobile MonoBook

[Isarra Yos]

I have made a patch for a responsive version of MonoBook with mobile 
support. See: https://gerrit.wikimedia.org/r/c/421199/ or if you just 
want a live demo, 
https://wiki.zaori.org/wiki/Page_title?useskin=monobook - load it on a 
phone or make your browser window narrow or something and you can see 
what it looks like. This is a prototype nojs version; I intend to make 
an even sillier js layout with popovers and stuff as a followup patch.


A potential issue has already been raised with the icons: I don't really 
know how to make text strings actually, well, reliably fit on mobile 
devices, but a lack of support for no-image usage could also be a real 
problem in MonoBook. Feedback on that or whatever, as well as other 
testing and reviews, would be greatly appreciated.


There is also a rather more immediate problem at present. As you can see 
on the patch, jenkins has -1ed it for style problems. Unfortunately I 
have no idea what the style problems are because the output of that test 
is totally useless (https://phabricator.wikimedia.org/T190072) - can 
anyone tell me what the problem(s) are so I can fix them? And/or just 
resolve T190072? Please? It's starting to get a bit annoying, frankly, 
as it's been coming up across several of these patches.


-I


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Refactoring MonoBook

[Isarra Yos]

Yeah, that is basically what we decided to do.

And hey, it's bitrotting in production, at least!

-I

On 20/03/18 10:51, Derk-Jan Hartman wrote:

So.. what if you shove the old monobooktemplate into the Modern skin,
rename it and let it use that. Then it becomes self contained, you
don't have your problem anymore, and Modern can slowly further bitrot
;)

Its not ideal, but I would consider it acceptable.

DJ

On Sun, Mar 18, 2018 at 2:03 AM, Isarra Yos <zhoris...@gmail.com> wrote:

I have just been informed that Modern works by extending MonoBookTemplate.
This is a problem.

-I


On 18/03/18 00:56, Isarra Yos wrote:

I'm refactoring MonoBook, starting with MonoBookTemplate. The current
change gets rid of the entire immediate print/html soup approach and instead
assembles a giant string and prints that in one statement at the end. See:
https://gerrit.wikimedia.org/r/#/c/420154/ and
https://gerrit.wikimedia.org/r/#/c/420161/

Pending reviews and assurances that I have indeed not totally broken
everything, we'll probably be merging this in the next week or so. If anyone
would like to point out particular reasons why this is a terrible idea,
please do so now.

Future plans include putting that ridiculous getPortlet into core
BaseTemplate, making a less dumb BaseTemplate::getFooter without breaking
anything already using it so MonoBook can lose its silly replication
thereof, organising all the files in MonoBook better (putting them in
resources, includes, etc according to standard skin practices), and making
MonoBook responsive.

There are also some problems that need addressing down the road: that I'm
not sure how safe it is for caching and the like to just go moving
images/css files around willy-nilly, that there are no 'standard' skin
practices as far as anyone can tell, and that some people seem to think
MonoBook is bad and not worth this. But MonoBook is not bad. It is a
delightful skin. We should preserve it, and not just in formaldehyde.

-I




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Refactoring MonoBook

[Isarra Yos]

On 18/03/18 03:09, K. Peachey wrote:

Just make it MonoBookV5? *runs*, or more realistically V2 then
progressively get rid of the orginal MonoBook?


The problem with splitting things up like that is then you need to deal 
with transitions from a v1 to a v2, which make everyone's lives more 
difficult, and especially create more work for and confuse reusers. As 
long as we can maintain a relatively smooth transition within the 
original, sticking to that is much more ideal - which is why, while I've 
gone and totally refactored MonoBookTemplate, I've also endeavoured to 
ensure the output remains functionally the same, and that all hooks and 
whatnot also continue to be supported, as dumb as several of them are. 
(Right now we're still trying to verify it really IS the same, though, 
so more eyes on that would be appreciated.)


The only other blocker I know of at this point is the other skins that 
straight-up extend MonoBookTemplate, a practice that made rather more 
sense back when this was all part of core, but as there only appear to 
be two of them, it should be pretty straight forward to simply change 
that behaviour now. (Which I've already gone ahead and done for Modern; 
Cavendish has apparently also had a task for doing the same for some 
time, and so shouldn't be far behind.)


-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Refactoring MonoBook

[Isarra Yos]

I have just been informed that Modern works by extending 
MonoBookTemplate. This is a problem.


-I

On 18/03/18 00:56, Isarra Yos wrote:
I'm refactoring MonoBook, starting with MonoBookTemplate. The current 
change gets rid of the entire immediate print/html soup approach and 
instead assembles a giant string and prints that in one statement at 
the end. See: https://gerrit.wikimedia.org/r/#/c/420154/ and 
https://gerrit.wikimedia.org/r/#/c/420161/


Pending reviews and assurances that I have indeed not totally broken 
everything, we'll probably be merging this in the next week or so. If 
anyone would like to point out particular reasons why this is a 
terrible idea, please do so now.


Future plans include putting that ridiculous getPortlet into core 
BaseTemplate, making a less dumb BaseTemplate::getFooter without 
breaking anything already using it so MonoBook can lose its silly 
replication thereof, organising all the files in MonoBook better 
(putting them in resources, includes, etc according to standard skin 
practices), and making MonoBook responsive.


There are also some problems that need addressing down the road: that 
I'm not sure how safe it is for caching and the like to just go moving 
images/css files around willy-nilly, that there are no 'standard' skin 
practices as far as anyone can tell, and that some people seem to 
think MonoBook is bad and not worth this. But MonoBook is not bad. It 
is a delightful skin. We should preserve it, and not just in 
formaldehyde.


-I




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Refactoring MonoBook

[Isarra Yos]

I'm refactoring MonoBook, starting with MonoBookTemplate. The current 
change gets rid of the entire immediate print/html soup approach and 
instead assembles a giant string and prints that in one statement at the 
end. See: https://gerrit.wikimedia.org/r/#/c/420154/ and 
https://gerrit.wikimedia.org/r/#/c/420161/


Pending reviews and assurances that I have indeed not totally broken 
everything, we'll probably be merging this in the next week or so. If 
anyone would like to point out particular reasons why this is a terrible 
idea, please do so now.


Future plans include putting that ridiculous getPortlet into core 
BaseTemplate, making a less dumb BaseTemplate::getFooter without 
breaking anything already using it so MonoBook can lose its silly 
replication thereof, organising all the files in MonoBook better 
(putting them in resources, includes, etc according to standard skin 
practices), and making MonoBook responsive.


There are also some problems that need addressing down the road: that 
I'm not sure how safe it is for caching and the like to just go moving 
images/css files around willy-nilly, that there are no 'standard' skin 
practices as far as anyone can tell, and that some people seem to think 
MonoBook is bad and not worth this. But MonoBook is not bad. It is a 
delightful skin. We should preserve it, and not just in formaldehyde.


-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] WikiProject X followup grant to fund finalising CollaborationKit

[Isarra Yos]

Hey all,

I'm pleased to announce a proposed followup for WikiProject X, a project 
previously funded by an Individual Engagement Grant. I have now 
submitted a Project Grant, according to the new system, with which I 
intend to complete and fully assess the development of CollaborationKit, 
the extension James Hare, Brian Wolff, and I created in 2016 in the 
renewal round of the original grant to facilitate the creation, 
management, and usage of WikiProjects on the English Wikipedia.


While the CollaborationKit extension is largely complete as a 
functioning prototype, it has yet to be deployed to the target wiki, the 
English Wikipedia (while technically in production, at present it's only 
enabled on testwiki). Subsequent to that deployment, actual testing can 
begin, and only then will it be possible to iterate on the extension's 
layout and functionality to effectively address the needs and pitfalls 
that come up in practice. Only then, too, will we be able to effectively 
assess the overall project: how successful has WikiProject X, as both 
IEG and Project Grant, been at meeting the outcomes originally 
described? How effective is this kind of design and software project as 
a whole? What can we learn, and how can others learn from this approach?


I would like to invite anyone interested in the project to check out the 
new proposal, and to comment or ask any questions you might have: 
https://meta.wikimedia.org/wiki/Grants:Project/Isarra/WikiProject_X


For more information on the original grant: 
https://meta.wikimedia.org/wiki/Grants:IEG/WikiProject_X
WikiProject X on the English Wikipedia: 
https://en.wikipedia.org/wiki/Wikipedia:WikiProject_X

CollaborationKit: https://www.mediawiki.org/wiki/Extension:CollaborationKit

Thanks!

Isarra

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Timeless grant resubmission

[Isarra Yos]

Hey all,

As many of you know, the Timeless skin was deployed for testing across 
all Wikimedia projects in late November last year. I submitted a Project 
Grant proposal at the time seeking funding to more actively support for 
this deployment as well as enable further development based on user 
feedback and the bugs that have been coming up in practice, but the 
proposal was ultimately vetoed in the late stages due to objections from 
WMF staff.


It is my understanding that these objections have since been withdrawn, 
and based on what happened, I have been recommended by relevant WMF 
staff to resubmit the proposal in the subsequent, now current, round of 
Project Grants. I have done this, and would like to invite anyone 
interested in this project to comment (again, even) on the current 
proposal, or ask any questions you might have on the talkpage. The 
current proposal can be found here: 
https://meta.wikimedia.org/wiki/Grants:Project/Isarra/Timeless:_Post-deployment_support


As for some general background:

If you don't know me, I'm Isarra, a volunteer MediaWiki developer and 
designer, and a previous WMF grantee on another project, WikiProject X. 
I originally created the Timeless skin itself as a volunteer project for 
a Wikimedia Tech Talk in 2015; after that the skin just sort of sat 
there being ignored for the better part of 2016, and then Paladox found 
it, filed a bug saying it should be deployed to Wikimedia, and it turned 
out a lot of people agreed with him and we spent most of 2017 pushing it 
through various processes, reviews, and fixes to be deployed 
(https://phabricator.wikimedia.org/T154371).


If you haven't and would like to try out Timeless, you can enable it in 
your preferences under Appearance > Skin, or just add ?useskin=timeless 
to the end of most page URLs to see what that page looks like in Timeless.


Thanks,

Isarra

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Thank you 2017 code reviewers

[Isarra Yos]

Do the extensions numbers also include skins?

That's an excellent goal, and I hope others will indeed do the same!

Also I really like how Krinkle beat the translatewiki bot in core.

-I

On 08/01/18 06:56, Kunal Mehta wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Nemo generated a list of the top +2'ers for MediaWiki core and
MediaWiki extensions in 2017:


Thank you very much for all of the code review that you do :-) Special
shout out to Timo with 365 +2's in MediaWiki core - one for every day
of the year!

- 

Inspired by that, for 2018, my goal will be to review one MediaWiki
patch by a volunteer for each day I'm working. And if I can't find a
patch to review, I'll find an abandoned looking patch by a volunteer,
and fix it up to a merge-able state. I encourage others to take on
this pledge too!

- -- Legoktm
-BEGIN PGP SIGNATURE-

iQJLBAEBCgA1FiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAlpTFhsXHGxlZ29rdG1A
bWVtYmVyLmZzZi5vcmcACgkQUvyOe+23/KLLQg//TRCgSwkRlrGprcYcYJnDlAU3
FfEzgH6j0CEKKSzNnMmkoi75B8QMyCh2UH9VSbjPHCU7AY6ElO1NhGZ/r7fhZLbb
otDYCi7b684K/nGFzw2MlBd4IhERJ6K69jGnzbPOrxeDGnsN8lggsRW/dSM8YYtq
zNCzqQ5ZSHPomCNW9oKiA8xXTS+wddD+++HOLdlTlqiyiyJIhvFuAvtrdXlatLWb
o758HtCaRhI6cegqO7UIhcvtB0rN8AtIqOD/3qoNZKQkcIhCUxQrtKvwCJpyoCTG
p3J/I5aDt6LPVwpRyXLqVYy7h+d+MCiC/pfDdPVJ6D5XT9CiagVnqMSsc/Q5BoF5
VElh47NPAydRRGgprSI6+MpnitSEebUR3kLPWTUlKEp9iLKgGvPWgK64GGgYH1ww
8I4KCWC/HxNPV2ZUCTOFcIhG5bEO0fYSgpydfUJRLjJM/ZO+27bHl6bcBUBrimaG
z7iMVOCziA0nJYdvbdyHWm/xB/wA6IW4LFkqRz+OnP9f4Ntsi3ikdNof6BELROBk
efshfqyZ/N3CWtD2+rQaO6BzdCOIKea1xGG9XbYCaVTCmPDJEe7yq0+yVnDPq+Dh
7WRWrVqdJS5BqJ0MD16u6Q94OVNn+IoEBmP9tnHmZA2PW4KyPjlQWOFU7WpGtkJE
7oRLuvF9iOxA+ThHsE4=
=A7ZA
-END PGP SIGNATURE-

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Post-deployment support for Timeless

[Isarra Yos]

As you may be aware, the Timeless skin has been undergoing deployment to 
various Wikimedia projects over the past couple of months, thus far 
deployed to five french projects, with a pending deployment for five 
more hebrew, german, and english projects in the works.


As the primary developer and designer on Timeless, it falls to me to 
address most of the issues as they come up, but to be quite blunt, I no 
longer have the financial stability to actually do this effectively, so 
I have submitted a grant proposal asking for funding for post-deployment 
support for Timeless. While the deadline for the community comments 
period is technically today, I have unfortunately been ill and unable to 
finish the proposal or get word out until now, and so would ask that 
anyone with comments, concerns, or other feedback (including and 
especially 'the proposal is completely incoherent'), please comment 
anyway within the next week (by the 24th) as this way it may be possible 
to incorporate and address them such that the grants Committee members 
will still be able to review them within the period. Even if not, 
comments and such may still prove useful for other purposes - task 
prioritisation, demonstration of support if needing to seek funding 
elsewhere, etc.


Timeless skin documentation: https://www.mediawiki.org/wiki/Skin:Timeless
Deployment task: https://phabricator.wikimedia.org/T154371
Grant proposal: 
https://meta.wikimedia.org/wiki/Grants:Project/Isarra/Post-deployment_support


Thanks!

-Isarra


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Update to web print styles

[Isarra Yos]

On 30/08/17 17:41, Jon Robson wrote:

On Wed, Aug 30, 2017, 10:16 AM Bartosz Dziewoński <matma@gmail.com>
wrote:


On Mon, Aug 28, 2017 at 10:18 PM, Isarra Yos <zhoris...@gmail.com> wrote:


Are these changes in core, or in the skins themselves (Vector and
Minerva)? In other words, will printing from other deployed skins such as
MonoBook also see improvement, or is it up to the maintainers of each

other

skin to independently apply similar changes?


As far as I know, the big features are only in Vector, but core styles have
also received a few tweaks.


Yep that's right. They are also feature flagged. There are also some in
MediaWiki:Print.css

Most of the styles in Vector could be applied to all skins if that's useful
provided they can be overridden  (via getDefaultModules ) but that's not a
priority right now whole we get these tested  and easily done later on.

Minerva doesn't need these styles for instance.


An optional core module might be good here - like the external links 
one, the ones with all the content object styles, etc.





https://gerrit.wikimedia.org/r/#/q/message:print+(project:mediawiki/core+OR+project:mediawiki/skins/Vector)+is:merged


--
Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Update to web print styles

[Isarra Yos]

Are these changes in core, or in the skins themselves (Vector and 
Minerva)? In other words, will printing from other deployed skins such 
as MonoBook also see improvement, or is it up to the maintainers of each 
other skin to independently apply similar changes?


Thanks.

-I

On 03/08/17 20:42, Chris Koerner wrote:

Wiki articles can be printed by most modern web browsers.The design and
layout of printed articles by the web browser is controlled via a special
print style sheet. This is similar to, but not the same as, the "Download
as PDF" feature, which recently saw a similar update.

Our current print styles have issues printing tables that are common on
many articles. They also do not contain any reference to the Wikipedia
brand. The Readers team at the Wikimedia Foundation plans to update these
print styles with some improvements.

* Book-like styling similar to our current book (PDF) rendering option
* New layout of article content to reduce paper usage. This can potentially
reduce the number of pages printed by 20 to 25%.
* Clear printing of tables and infoboxes
* Better headings
* Project-specific branding

We are planning on deploying these styles in August 2017. For a comparison
of the old print styles and the new, please visit the project page on
MediaWiki.org. Comments and feedback can be left on the talk page there.

https://www.mediawiki.org/wiki/Reading/Web/Projects/Print_Styles#Desktop_Printing

Yours,
Chris Koerner
Community Liaison
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Timeless skin now available on mw.org

[Isarra Yos]

I'm going with both.

(Width cuttoffs are a bit unnecessarily narrow in Timeless, but we need 
content stuff to scale down better as well, as there are also a lot of 
devices that are just plain narrower, and such, too.)


On 12/08/17 20:42, Jan Dittrich wrote:

This means on the Wikibase UI you will not
see the sitelinks on the right side anymore :(.

I wonder if  that a problem of the new skin or of the way we created the
Wikidata UI?

Jan

2017-08-12 22:31 GMT+02:00 Jonas Kress :


Thanks, I really like it!
I already installed it on my local wiki.

One thing I noticed is that the content width is smaller than with vector.
This means on the Wikibase UI you will not see the sitelinks on the right
side anymore :(.

Cheers,
Jonas

2017-08-12 16:19 GMT-04:00 Bartosz Dziewoński :


W dniu sobota, 12 sierpnia 2017 Amir Ladsgroup 
napisał(a):


It's fantastic, it will be my default skin when it gets deployed in
Wikipedia.

One thing: OOjs UI has a different theme for monobook (apex theme) and

for

vector the theme is "mediawiki", Are you planning to design another

OOjs

UI

theme for this skin?



Timeless has some styles for MediaWiki UI buttons and forms, extending

that

to other things included in OOjs UI is probably possible.

The main obstacle right now would be that skins have no way to define

their

own custom OOjs UI theme - I have change
https://gerrit.wikimedia.org/r/#/c/343239/ pending review which would
allow
that.


--
Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l




--
Jonas Kress
Software Developer

Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30 219 158 26-0
http://wikimedia.de

Imagine a world, in which every single human being can freely share in the
sum of all knowledge. That‘s our commitment.

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.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l







___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Timeless skin now available on mw.org

[Isarra Yos]

Yes, the plan is to make an actual oojs ui theme, but I haven't gotten 
around to it because doing this stuff is complicated. If anyone wants to 
start one for me, that would be really helpful.


> Compliance with the WMF colour palette

This was the plan, but it kept changing. And apparently we still don't 
have a good way to just inherit it from a central source in extensions? 
I'll look into this later.


-I

On 12/08/17 20:06, Amir Ladsgroup wrote:

It's fantastic, it will be my default skin when it gets deployed in
Wikipedia.

One thing: OOjs UI has a different theme for monobook (apex theme) and for
vector the theme is "mediawiki", Are you planning to design another OOjs UI
theme for this skin?

Also it would be great to have it comply with WikimediaUI color palette (or
make it so only in WMF wikis), just thinking out loud.

Best
On Sat, Aug 12, 2017 at 11:53 PM bawolff <bawolff...@gmail.com> wrote:


This is kind of odd, but probably not an issue with the skin.

I suspect you have some of the MediaWiki pages cached in browser cache
from before you used the skin, and as a result are using them via a
304 response. But the user_touched timestamp should prevent that.
Maybe central auth doesn't update the local one or something. need to
look into that further.

Maybe you got logged out  and then central auth globally logged back in.

I don't know, kind of grasping here, but definitely is a MW issue not
a Timeless issue.

--
bawolff

On Sat, Aug 12, 2017 at 7:38 PM, יגאל חיטרון <khit...@gmail.com> wrote:

Hi. I did not expected to much, because I did not like any non vector
skins, but this is awesome! Thank you very much. One little bug - when
working in mediawiki and navigating to another page, sometimes it opens
again in vector and you should reopt it in in preferences.
Igal (User:IKhitron)

On Aug 12, 2017 17:51, "Alangi Derick" <alangider...@gmail.com> wrote:


Wow, this is wonderful.

I like this skin and I already switched to it. A lot of stylish minded
developers (like me) will start moving to the Timeless skin soon. Good

work

Team

Nevertheless, will file in any bugs found :)

*Kind regards*
*Alangi Derick N*

*[image: https://twitter.com/AlangiDerick]
<https://twitter.com/AlangiDerick>
<https://www.facebook.com/derick.alangi>  *

On Sat, Aug 12, 2017 at 3:46 PM, Daniel Kinzler <
daniel.kinz...@wikimedia.de

wrote:
Wow, this looks great!

Am 11.08.2017 um 18:26 schrieb Isarra Yos:

The Timeless skin has been deployed to test, test2, and mw.org.

Anyone

interested, please go ahead an enable it and find everything wrong

and

swear at

me about it.

Note that the current design is not the final design and I haven't

quite

worked

out what the final design should be, either, so feel free to swear

at

me

about

that, too, if you have any ideas/whatever.

* Bad documentation: https://www.mediawiki.org/wiki/Skin:Timeless
* Bugs: https://phabricator.wikimedia.org/tag/timeless/
* To enable it:
https://www.mediawiki.org/wiki/Special:Preferences#mw-

prefsection-rendering

If all goes well, we will move on to deploy it to the pilot wikis,

as

listed on

the deployment task, sometime next week:

https://phabricator.wikimedia

.

org/T154371

A huge thank you to all the insane people who have worked to get us

to

this

point, when the entire notion of a new skin seemed something of an

impossibility

most of the way through.

-I


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


--
Daniel Kinzler
Principal Platform Engineer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Timeless skin now available on mw.org

[Isarra Yos]

The Timeless skin has been deployed to test, test2, and mw.org. Anyone 
interested, please go ahead an enable it and find everything wrong and 
swear at me about it.


Note that the current design is not the final design and I haven't quite 
worked out what the final design should be, either, so feel free to 
swear at me about that, too, if you have any ideas/whatever.


* Bad documentation: https://www.mediawiki.org/wiki/Skin:Timeless
* Bugs: https://phabricator.wikimedia.org/tag/timeless/
* To enable it: 
https://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-rendering


If all goes well, we will move on to deploy it to the pilot wikis, as 
listed on the deployment task, sometime next week: 
https://phabricator.wikimedia.org/T154371


A huge thank you to all the insane people who have worked to get us to 
this point, when the entire notion of a new skin seemed something of an 
impossibility most of the way through.


-I


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Improvements to developer events in the WMF Annual Plan draft

[Isarra Yos]

First off, thank you for your excellent response.

On 05/05/17 12:58, Quim Gil wrote:

Sorry for being so late replying. Isarra asks a good question and I have
been thinking of a good answer.

On Thu, Apr 27, 2017 at 8:35 PM, Isarra Yos <zhoris...@gmail.com> wrote:


Different events serve very different purposes, though - hackathons, for
instance, seem to be largely useful for onboarding newcomers and giving
staff and other occupational contributors an opportunity to work on
projects separate from their usual work, basically whatever they feel like
doing, as opposed to what they have to. But these often don't do much for
established volunteers, as a result, who generally just work on whatever
they feel like all the time already. Have you looked into how the roles of
these different events fit together across all the different groups, and
how scopes affect them (regional, topical, etc)? This would also be useful
for chapters/groups planning their own events.


Yes, we have started to think seriously how the different developer events
fit together, how can they support better each other, and how can chapters
and other affiliates get better involved organizing local / regional events
or adding a tech component to the events they are already organizing.

Until recently our approach has been quite fragmented, organizing
technically successful events disconnected from each other. We started a
new trend last Summer, at the Wikimania Hackathon in Esino Lario,
discussing with Wikimedia Austria how could we improve the Wikimedia
Hackathon 2017 (in Vienna, in two weeks) after the high bar set by
Wikimedia Israel in Jerusalem. We had this idea of supporting the
organization of smaller hackathons and sponsoring the best participants to
travel to Vienna. The idea is working so far.

Growth paths for volunteers is another idea that has become very important
in our strategy and plans. While we seem to be quite good at organizing
developer events, developer outreach programs, developer community
support... the fact is that we are not doing good at retaining new
volunteer developers. Many come, but most leave. And there are many reasons
for this, but we think that an important one is that we are not offering
clear growth paths that make people stick around. Some volunteers find
these growth paths themselves, and we have many examples in this list, but
many simply don't see them and leave.

Developer events play an important role in these growth paths. Imagine that
a chapter or even a small affiliate organizes a simple local workshop
somewhere. One of the best participants, a total newcomer to Wikimedia
although a fluent JavaScript developer, is invited to travel to the next
hackathon in the nearest regional event (WikiArabia, WikiIndaba, the CEE
conference...) There, the best developers are invited to one of our global
hackathons (invited to South Africa in 2018, how cool is that!?!?).

Actually, the growth paths through events can be connected with related
online activities (self-paced, scheduled), which allows us to work with
more people beyond travel budget and people's possibilities with travel and
calendars. We can also connect them with developer outreach programs (GSoC,
Outreachy...). Who was a newcomer becomes more experienced, maybe a speaker
or a trainer invited to online / offline events, maybe a maintainer, maybe
a mentor, maybe grantee, a professional developer at Wikimedia...

OK, all these are ideas in progress that we are starting to put together at
https://meta.wikimedia.org/wiki/Technical_Collaboration/Onboarding_New_Developers

Now, back to the Summit. The Wikimedia Developer Summit never was an event
crucial for onboarding new developers, and in fact it was not an event easy
to involve volunteers, because of its location (expensive San Francisco, in
a region where there are not many volunteer developers) and also because
the topics were quite focused on what is work mostly for professional
developers (see our cyclic discussions about how to integrate volunteer
developers and the topics crucial for them).

We have tried in several editions, and it has been very difficult to obtain
a mild success. Instead, now we are trying to bring some of the "Summit
topics" to those hackathons based on who is attending anyway (or vice
versa) and then we can focus the Summit around a specific topic and the
people specializing on it, in the terms explained by Victoria. What topics
will be discussed where will be decided by a program committee that will be
active through the year, helping to provide this connection across events
(see https://phabricator.wikimedia.org/T160996 )

Sorry for the long response. It is the first time I write down all these
ideas in a single place. Feedback is very welcome.


A... suggestion, I suppose, though it comes with a caveat: if you 
haven't, I would highly recommend documenting what you've found/wound up 
with as learning patterns on meta, or similar, as well. This is

Re: [Wikitech-l] Improvements to developer events in the WMF Annual Plan draft

[Isarra Yos]

That would be great.

Interesting, thanks.

-I

On 28/04/17 20:57, Victoria Coleman wrote:

Hi there,

Quim and his team have indeed thought through the totality of tech community 
events and I am sure he can respond here with his thoughts. Regarding the 
MediaWiki roadmap, the thinking is that by publishing it we a/make planning for 
3rd party users much more feasible, b/inform the community about what the 
Foundation will be doing so that we can avoid overlap,  and c/hopefully 
incentivize broader participation by the community in the formulation and 
delivery of the roadmap.

I hope this makes sense.

Victoria


On Apr 27, 2017, at 11:35 AM, Isarra Yos <zhoris...@gmail.com> wrote:

Thanks.

Different events serve very different purposes, though - hackathons, for 
instance, seem to be largely useful for onboarding newcomers and giving staff 
and other occupational contributors an opportunity to work on projects separate 
from their usual work, basically whatever they feel like doing, as opposed to 
what they have to. But these often don't do much for established volunteers, as 
a result, who generally just work on whatever they feel like all the time 
already. Have you looked into how the roles of these different events fit 
together across all the different groups, and how scopes affect them (regional, 
topical, etc)? This would also be useful for chapters/groups planning their own 
events.

How exactly is publishing a roadmap going to help facilitate community 
contributions?

-I

On 27/04/17 03:11, Victoria Coleman wrote:

Hi Isarra,

thank you for the question. We want to support our diverse technical 
communities in a variety of ways. One of our key tools are the hackathons, 
where we hope to welcome both seasoned and new volunteer developers. We want to 
support them not just by providing a series of events but also with tools and 
WMF staff time. These are the key goals of our new Wikimedia Cloud Services 
team. They build and make labs and tools available and participate in the 
hackathons to onboard newcomers and in general assist volunteers. Another key 
change we are making this year is creating the MediaWiki Platform team who as 
well as  doing much needed work on the codebase will also facilitate 
contributions and planning with the volunteer community by publishing a 
roadmap. And as Quim notes below we are changing the nature of the Dev Summit 
to have it focus on the strategic technology issues and decisions the Movement 
is faced with. As such it is an event that might appeal more to the seasoned 
members of our community. Attendance for the summit will be decided on the 
basis of position papers for WMF staff and volunteers alike. I am personally 
excited about the lineup of events this coming year. But as always we learn and 
adapt. If we collectively decide to try for a different configuration the 
following year, we can totally do that. Please keep the feedback coming!

Best regards,

Victoria



On Apr 26, 2017, at 12:23 PM, Isarra Yos <zhoris...@gmail.com> wrote:

Regarding the Developers Summit in particular, how do you plan to reconcile 
making the event smaller with your goal of better retention of newcomers and 
volunteers in general when that's often the only venue they have at which to 
discuss the high-level technical issues with other stakeholders? Volunteer and 
third-party developers are not privy to most of the usual venues afforded to 
WMF staff such as inter-team meetings and events, and yet they make up an 
important part of the overall stakeholder community that these issues impact. 
They - we - need to be able to participate in these discussions, and the 
Developers Summit is one of very few opportunities even open to us where we can 
make our voices heard.

-I

On 20/04/17 07:28, Quim Gil wrote:

On Sun, Apr 9, 2017 at 1:14 AM, Quim Gil<q...@wikimedia.org>  wrote:


Hi, the Wikimedia Foundation has published a draft of its Annual Plan
FY2017-18
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2017-2018/Draft>
and it welcomes your review.

I want to highlight here the improvements that we are proposing to the
developer events (co)organized by the WMF. From local to global:

The Technical Collaboration team proposes to combine multiple activities
(often disconnected) in a single program focusing on onboarding new
developers
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2017-2018/Draft/Programs/Community_Engagement#Program_12:_Onboarding_new_developers>.
 We
want to work with the Wikimedia technical community to bring a new wave of
developers to our projects, and events play an important role.

Local developer events
We want to support developers and organizations willing to reach out to
specific groups and geographies. We are hoping to see many local developer
meetups and small hackathons or workshops around the World, starting small
and simple. We should be able to offer introductory mate

Re: [Wikitech-l] Improvements to developer events in the WMF Annual Plan draft

[Isarra Yos]

Thanks.

Different events serve very different purposes, though - hackathons, for 
instance, seem to be largely useful for onboarding newcomers and giving 
staff and other occupational contributors an opportunity to work on 
projects separate from their usual work, basically whatever they feel 
like doing, as opposed to what they have to. But these often don't do 
much for established volunteers, as a result, who generally just work on 
whatever they feel like all the time already. Have you looked into how 
the roles of these different events fit together across all the 
different groups, and how scopes affect them (regional, topical, etc)? 
This would also be useful for chapters/groups planning their own events.


How exactly is publishing a roadmap going to help facilitate community 
contributions?


-I

On 27/04/17 03:11, Victoria Coleman wrote:

Hi Isarra,

thank you for the question. We want to support our diverse technical 
communities in a variety of ways. One of our key tools are the hackathons, 
where we hope to welcome both seasoned and new volunteer developers. We want to 
support them not just by providing a series of events but also with tools and 
WMF staff time. These are the key goals of our new Wikimedia Cloud Services 
team. They build and make labs and tools available and participate in the 
hackathons to onboard newcomers and in general assist volunteers. Another key 
change we are making this year is creating the MediaWiki Platform team who as 
well as  doing much needed work on the codebase will also facilitate 
contributions and planning with the volunteer community by publishing a 
roadmap. And as Quim notes below we are changing the nature of the Dev Summit 
to have it focus on the strategic technology issues and decisions the Movement 
is faced with. As such it is an event that might appeal more to the seasoned 
members of our community. Attendance for the summit will be decided on the 
basis of position papers for WMF staff and volunteers alike. I am personally 
excited about the lineup of events this coming year. But as always we learn and 
adapt. If we collectively decide to try for a different configuration the 
following year, we can totally do that. Please keep the feedback coming!

Best regards,

Victoria



On Apr 26, 2017, at 12:23 PM, Isarra Yos <zhoris...@gmail.com> wrote:

Regarding the Developers Summit in particular, how do you plan to reconcile 
making the event smaller with your goal of better retention of newcomers and 
volunteers in general when that's often the only venue they have at which to 
discuss the high-level technical issues with other stakeholders? Volunteer and 
third-party developers are not privy to most of the usual venues afforded to 
WMF staff such as inter-team meetings and events, and yet they make up an 
important part of the overall stakeholder community that these issues impact. 
They - we - need to be able to participate in these discussions, and the 
Developers Summit is one of very few opportunities even open to us where we can 
make our voices heard.

-I

On 20/04/17 07:28, Quim Gil wrote:

On Sun, Apr 9, 2017 at 1:14 AM, Quim Gil<q...@wikimedia.org>  wrote:


Hi, the Wikimedia Foundation has published a draft of its Annual Plan
FY2017-18
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2017-2018/Draft>
and it welcomes your review.

I want to highlight here the improvements that we are proposing to the
developer events (co)organized by the WMF. From local to global:

The Technical Collaboration team proposes to combine multiple activities
(often disconnected) in a single program focusing on onboarding new
developers
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2017-2018/Draft/Programs/Community_Engagement#Program_12:_Onboarding_new_developers>.
 We
want to work with the Wikimedia technical community to bring a new wave of
developers to our projects, and events play an important role.

Local developer events
We want to support developers and organizations willing to reach out to
specific groups and geographies. We are hoping to see many local developer
meetups and small hackathons or workshops around the World, starting small
and simple. We should be able to offer introductory materials, contacts
with Wikimedia developers in the region, maybe travel budget to send
experienced volunteers to help mentoring the in the bigger events, maybe
travel budget to invite the best newcomers to our regional and global
events.

Adding tech to regional Wikimedia events
Last year we experimented organizing technical workshops in WikiArabia,
and others have done similar efforts in other regional events (for
instance, a small hackathon next to WikiConference India). We want to work
with the organizers of these regional events in order to attract
experienced Wikimedia developers and newcomers, organize developer
activities, and also improve the collaboration between the technical and
no

Re: [Wikitech-l] Improvements to developer events in the WMF Annual Plan draft

[Isarra Yos]

Regarding the Developers Summit in particular, how do you plan to 
reconcile making the event smaller with your goal of better retention of 
newcomers and volunteers in general when that's often the only venue 
they have at which to discuss the high-level technical issues with other 
stakeholders? Volunteer and third-party developers are not privy to most 
of the usual venues afforded to WMF staff such as inter-team meetings 
and events, and yet they make up an important part of the overall 
stakeholder community that these issues impact. They - we - need to be 
able to participate in these discussions, and the Developers Summit is 
one of very few opportunities even open to us where we can make our 
voices heard.


-I

On 20/04/17 07:28, Quim Gil wrote:

On Sun, Apr 9, 2017 at 1:14 AM, Quim Gil  wrote:


Hi, the Wikimedia Foundation has published a draft of its Annual Plan
FY2017-18

and it welcomes your review.

I want to highlight here the improvements that we are proposing to the
developer events (co)organized by the WMF. From local to global:

The Technical Collaboration team proposes to combine multiple activities
(often disconnected) in a single program focusing on onboarding new
developers
.
 We
want to work with the Wikimedia technical community to bring a new wave of
developers to our projects, and events play an important role.

Local developer events
We want to support developers and organizations willing to reach out to
specific groups and geographies. We are hoping to see many local developer
meetups and small hackathons or workshops around the World, starting small
and simple. We should be able to offer introductory materials, contacts
with Wikimedia developers in the region, maybe travel budget to send
experienced volunteers to help mentoring the in the bigger events, maybe
travel budget to invite the best newcomers to our regional and global
events.

Adding tech to regional Wikimedia events
Last year we experimented organizing technical workshops in WikiArabia,
and others have done similar efforts in other regional events (for
instance, a small hackathon next to WikiConference India). We want to work
with the organizers of these regional events in order to attract
experienced Wikimedia developers and newcomers, organize developer
activities, and also improve the collaboration between the technical and
non-technical contributors in these regions.

Better retention of newcomers at the Wikimedia and Wikimania hackathons
Although we don't expect major changes in the organization of the
Wikimedia Hackathon and the hackathon at Wikimania, we want to focus better
on new developers onboarding and retention. In every Hackathon we meet many
new developers, but the retention rates are very low. We want to review
what we can do before, during, and after these apparently successful events
in order to retain newcomers better. One hypothesis is that we should focus
call for participation, scholarships, and Wikimedia Foundation
participation in providing a great experience to new volunteers who have
gone through local and regional events, and also "junior" developers coming
from wiki projects through the development of bots, gadgets, tools,
templates.

A smaller and more focused Wikimedia Developer Summit
After some discussions between Community Engagement, Technology, and
Product, we have decided to propose a different approach for the Wikimedia
Developer Summit. Organized by the Technology department as part of their 
technical
community building

efforts, we want the Summit to finally become the venue where the toughest
technical problems are discussed between the stakeholders directly related.
We want to reduce the size/budget of the event, separate it from the WMF
AllHands,


Due to travel budget considerations, the Summit still might be connected to
the WMF AllHands.



and define its main themes well in advance.

A Program Committee  would
decide these main themes to be discussed at the Summit. We also want to
explore the possibility of tackling some of these themes at the Wikimedia
Hackathon and Wikimania, where we could get most stakeholders involved with
just a little extra effort (since many of them would be attending anyway).

We believe that this approach will serve better the Wikimedia technical
community that we have, and also the the community that we want to have,
with a new wave of developers joining our various projects.

--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil

Re: [Wikitech-l] Editing JSON in MediaWiki

[Isarra Yos]

Sounds like what they want is what collaborationlistcontent/handler 
does, specifically, at least for now.


On 09/04/17 06:30, James Hare wrote:

Why, exactly, do you want a wikitext intermediary between your JSON and
your HTML? The value of wikitext is that it’s a syntax that is easier to
edit than HTML. But if it’s not the native format of your data, nor can
browsers render it directly, what’s the point of having it?

The CollaborationKit extension [0] has two content models,
CollaborationHubContent and CollaborationListContent, and they have two
different strategies for parsing. CollaborationHubContent takes validated
JSON and puts out raw HTML; this is the most straightforward to work with.
CollaborationListContent instead puts out wikitext that is fed into the
parser, since it is expected that lists can be transcluded onto other
pages, and this means using wikitext (as transcluded HTML is not an
option). However, this creates a lot of limitations, including parser
restrictions that make sense in the context of arbitrary wikitext parsing
but not when the markup is provided directly by an extension. The long term
plan is for CollaborationListContent to put out HTML, since it’s more
straightforward than using a wikitext intermediary that the user does not
see anyway.

[0] https://www.mediawiki.org/wiki/Extension:CollaborationKit

On April 8, 2017 at 11:23:38 PM, Denny Vrandečić (vrande...@gmail.com)
wrote:

Here's my requirement:
- a wiki page is one JSON document
- when editing, the user edits the JSON directly
- when viewing, I have a viewer that turns the JSON into wikitext, and that
wikitext gets rendered as wikitext and turned into HTML by MediaWiki

I have several options, including:

1) hook for a tag like , and write an extension that parses the
content between the tags and turns it into wikitext (not ideal, as I don't
use any of the existing support for JSON stuff, and also I could have
several such tags per page, which does not fit with my requirements)

2) I found the JsonConfig extension by yurik. This allows me to do almost
all of the things above - but it returns HTML directly, not wikitext. It
doesn't seem trivial to be able to return wikitext instead of HTML, but
hopefully I am wrong? Also, this ties in nicely with the Code Editor.

3) there is actually a JsonContentHandler in core. But looking through it
it seems that this suffers from the same limitations - I can return HTML,
but not wikitext.

3 seems to have the advantage to be more actively worked on that 2 (which
is not based on 3, probably because it is older than 3). So future goodies
like a Json Schema validator will probably go to 3, but not to 2, so I
should probably go to 3.

Writing this down, one solution could be to create the wikitext, and then
call the wikitext parser manually and have it create HTML?

I have already developed the extension in 1, and then fully rewritten it in
2. Before I go and rewrite it again in 3, I wanted to ask whether I am
doing it right, or if should do it completely differently, and also if
there are examples of stuff developed in 3, i.e. of extensions or features
using the JsonContent class.

Example:
I have a JSON document
{ "username": "Denny" }
which gets turned into wikitext
''Hello, [[User:Denny|Denny]]!''
which then gets turned into the right HTML and displayed to the user, e.g.
Hello, Denny!

Cheers,
Denny
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Timeless skin on Wikimedia projects - current status, grant proposal

[Isarra Yos]

Hi,

Timeless is a new responsive skin based on the Vector layout, 
incorporating in design principles from Winter and other modern sites, 
which I originally started in 2015 as an example for a tech talk. I kind 
of forgot about it for awhile since, but then we (essentially a bunch of 
random people on phabricator), based on Paladox' recommendation, started 
working on getting it ready for deployment to Wikimedia projects.


Links:
* Labs wiki specifically for timeless: 
https://timeless-skin.wmflabs.org/wiki/Main_Page
* A copy of the Simple English Wikipedia on the Beta Cluster, where 
Timeless has already been deployed and you can see what it might look 
like in production: 
https://simple.wikipedia.beta.wmflabs.org/wiki/Main_Page - you can 
create an account, set your skin to timeless, and go through some of the 
things you might do here, and maybe get a feel for the skin

* Skin ocumentation: https://www.mediawiki.org/wiki/Skin:Timeless
* Phabricator workboard: 
https://phabricator.wikimedia.org/project/board/1912/ (there are bugs - 
please file more)


As you can probably tell, it needs a lot of work.

Current status: Timeless is deployed to the Beta Cluster; consensus is 
being established on various projects as to whether or not they would 
want to test it out specifically. See: 
https://phabricator.wikimedia.org/T154371
If anyone else would like to ask projects they're particularly active on 
or that they think would be useful, that would also be great.


Because the problem is, while things are moving forward and development 
is sort of happening, I can't do all of this alone (which, fortunately, 
I'm not), and I certainly can't devote the time and effort this project 
deserves as a volunteer (which, unfortunately, I am). To address this, 
I've put in a proposal for a grant that would allow me to work full-time 
on this project, working on developing Timeless into a product truly 
worth deploying, and also doing much needed research on and outreach to 
the projects in order to determine and properly document how they use 
their skins, what they expect out of skins, and what problems and needs 
need to be addressed with the general MediaWiki frontend.


Grant proposal: https://meta.wikimedia.org/wiki/Grants:IdeaLab/Timeless

As MediaWiki developers and whatnot yourselves, I expect many of you 
have worked on similar projects, would be affected by this down the 
road, and/or may have thoughts, concerns, or advice on this matter, so 
please, I would very much appreciate any feedback you can give, either 
here, on the grant page, or on the Phabricator project.


Thanks!

-Isarra


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Extension compatibility styles and responsive skins

[Isarra Yos]

If I don't get a satisfactory reply I'll just decide something 
arbitrarily and then declare that standard practice moving forward, and 
look down on anyone doing anything different disappointedly.


Well, not really, since if anyone's doing anything related at all, that 
would actually be quite interesting. But you know.


-I

On 27/03/17 01:54, Pine W wrote:

Hi Isarra,

You might try the design@ email list if you don't get a satisfactory reply
here within a day or two. Also pinging Quiddity in case he has ideas.

HTH,

Pine


On Sat, Mar 25, 2017 at 11:40 AM, Isarra Yos <zhoris...@gmail.com> wrote:


Basically: skins style the interface, extensions add new interface.
Compatibility then needs to be added to the skins for the extensions, so
they can style the new interface too, but we don't want to load the
extension-specific styles unless the extensions is actually used. Thus we
use $wgResourceModuleSkinStyles to add the skin styles to the extension
modules.

Simple, right?

The problem arises when you're making a fully-responsive skin with
multiple stylesheets for different view modes (say, a common stylesheet for
desktop and mobile, a mobile stylesheet, a desktop stylesheet with
specifics for smaller screens, and a desktop stylesheet for gigantic
monitors). Each of these is a separate file, with its target screen sizes
specified in the module definition in skin.json. For many extensions,
proper compatibility will also require specific styles for several of these.

Unfortunately $wgResourceModuleSkinStyles cannot be defined the usual way
in skin.json, and lacks support for @media queries, so the only way to even
do this is to set the @media sizes inside the files themselves.

What I'm wondering:

1. Is there any good way to parametrise the @media sizes so we only have
to define them once, and then just have the main skin styles, and all the
extension ones, inherit those values? Or is setting a series of less
variables and then keeping those up-to-date with the values in skin.json
probably the best approach?
2. What are best practices for organising this when you have many sizes
and many extensions? Should each extension have one file? Even if the
@media sizes are all in-line in the same file, that is still a separate
file for each extension. Where should these files be kept?
3. Who would be the folks to go to about making this less bad?

-I


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Extension compatibility styles and responsive skins

[Isarra Yos]

Basically: skins style the interface, extensions add new interface. 
Compatibility then needs to be added to the skins for the extensions, so 
they can style the new interface too, but we don't want to load the 
extension-specific styles unless the extensions is actually used. Thus 
we use $wgResourceModuleSkinStyles to add the skin styles to the 
extension modules.


Simple, right?

The problem arises when you're making a fully-responsive skin with 
multiple stylesheets for different view modes (say, a common stylesheet 
for desktop and mobile, a mobile stylesheet, a desktop stylesheet with 
specifics for smaller screens, and a desktop stylesheet for gigantic 
monitors). Each of these is a separate file, with its target screen 
sizes specified in the module definition in skin.json. For many 
extensions, proper compatibility will also require specific styles for 
several of these.


Unfortunately $wgResourceModuleSkinStyles cannot be defined the usual 
way in skin.json, and lacks support for @media queries, so the only way 
to even do this is to set the @media sizes inside the files themselves.


What I'm wondering:

1. Is there any good way to parametrise the @media sizes so we only have 
to define them once, and then just have the main skin styles, and all 
the extension ones, inherit those values? Or is setting a series of less 
variables and then keeping those up-to-date with the values in skin.json 
probably the best approach?
2. What are best practices for organising this when you have many sizes 
and many extensions? Should each extension have one file? Even if the 
@media sizes are all in-line in the same file, that is still a separate 
file for each extension. Where should these files be kept?

3. Who would be the folks to go to about making this less bad?

-I


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MVVM/Single-State solution for our UIs?

[Isarra Yos]

Er, what does this mean? What is MVVM?

On 30/01/17 13:57, Jan Dittrich wrote:

Hello Wikitext-l,

---
TL;DR: The Wikidata team is considering to use a MVVM/Single-State solution
for Wikidata’s UI. What are requirements and concerns would be important to
consider?
---

Wikidata’s current UI is built on jQuery UI. Since jQueryUI shall be faded
out, we are looking at possible future frameworks or paradigms to build our
UI on. Our needs are:

- Having a sustainable foundation
- Being able to handle complex state dependencies (simplest are like: "if
element x is in edit mode, set element y to saving mode")
- A solution that is easy to learn for beginners and easy to read and
reason about for our engineers.


State management and data/event propagation goes beyond of what OOUI can
provide, as far as I (Jan) know. So an obvious candidate was looking into
MVVM solutions of which the most well known is the React library.

We had a deeper look at Vue.js which is known for having a large community,
too, but being easier to understand and not using an additional patent
clause in its licensing.


We see the following possible advantages:

- Better modularization
- understandability of our code, in particular reasoning about event- and
data-flow
- better separation of concerns and testability for:
-- HTML templates
-- Component interactivity
-- Data manipulation
-- connection to backend-API


- If we use a well documented framework, learning to contribute is much
easier compared to software for which there is only auto-generated
code-level-docs


Here are some answers to obvious questions:

1) Does using a MVVM mean we need to write mixed JS/CSS/HTML in a new
syntax? (aka JSX)? -> No, it is possible, but for most frameworks (Vue,
too) normal HTML templates are used

2) Does that mean that people coming from Object oriented languages will
need to learn a whole new paradigm – reactive, pure-functional programming?
-> While there are some elements of functional programming used in
react-like-frameworks, I would (subjectively) say that few additional,
totally new knowledge is needed and most can be covered by "take
parameters, work with them, return values; don't manipulate non-local
values"

3) How does DOM access work? Does this mean no jQuery?


-> DOM can be still be directly accessed. Libraries like jQuery can still
be reused (even if they might not be necessary in many points any more).
However, to change data or dom persistently, you need to tell the library
(which is not unusual, afaic)


There are also some other concerns:

- Should we introduce a new dependency like a framework as Vue?
- What would be the process of introducing such a dependency (if we agree
on one)?
- Can we agree on this (or another?) paradigm for managing complex UIs, so
that it is not a Wikidata-only solution, but could be used by other
Wikimedia projects in the future, too?
- How will this work with OOUIjs? OOUI seems to be mainly responsible for
creating DOM elements and this actions are usually owned by the MVVM
framework. One can use hooks to use libraries like OOUI and such, but it
feels like having the same functionality twice. A possible solution would
be using OOUI styles and markup but leaving DOM creation to the framework.


Do you think using Vue (or a similar framework) is an option for us? What
are requirements and concerns which would be important?


Kind Regards,
  Jan




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit 2.12.2 test instance - PLEASE TEST

[Isarra Yos]

On 13/07/16 06:50, Niklas Laxström wrote:

Many good and bad changes I can live with. One thing I will miss:
* Columns setting no longer wraps the diff lines. Horizontal scroll is
now unavoidable and cumbersome due to having to use either the mouse
or the arrow keys to move the cursor on the line.


Yeah, if it's possible to make these wrap instead of horizontal 
scrolling, that would be great. There is way too much scrolling 
everywhere, even on large displays.


Here's a bunch of other design things I'm hoping we can fix, since 
they're all a bit glaring:


 * Diffs - using icons for back to change, previous file, next file is
   very unclear and hard to find; new users will not see them and have
   any idea what to do with them. The current textual 'up to change',
   previous/next file is immediately clear and would be great to
   maintain. (The side-by-side and unified diff icons are also very
   strange, like fuzzy rgb blobs, but at least they're a bit clearer.
   Sort of.)
 * Commit message - limiting the height doesn't really help anything
   since if there's a long commit message, presumably it's long for a
   reason and we still want to see it. And it really makes it worse on
   small screens where we need to scroll through everything anyway, so
   the fewer separate things we need to scroll through, the better.
 * Diff preferences - white text on black background is very bad,
   especially when it suddenly appears on top of an interface that uses
   black text on white.

 * Padding - please more. Things should not be shoved up against other
   things. It makes them hard to pick out and read things at a glance,
   and the entire thing looks a lot messier and overly busy than it
   actually is; there should be padding around each bit of content (esp
   the commit message stuff), and at the end of blocks in order to
   distinguish them from the blocks that come after.
 * The very narrow scrollbars are weird and unnecessary, and hard to
   use. Considering most people are probably either on a system that
   already has similar by default (and hides them when not in use), or
   have large system scrollbars for a reason (hi), would it be possible
   to just remove that?

 * hrs probably need styles
 * Solid black lines are generally bad

 * Is there any way we can put the different file opening options back
   on the main change page? The view side-by-side diff, view unified
   diff, and now the edit file option too, instead of only having the
   filename as a link? It opening up to whatever mode was last open is
   really weird behaviour, especially with edit, since closing the edit
   mode always dumps the user back onto the main change page instead of
   going back to viewing the diff, and then when they click on the file
   again it takes them back into edit mode, which they don't want, and
   the obvious path at that point is 'close', even though the only way
   back to the diffs for anything at that point is the rather ambiguous
   icons in the corner of the edit thing.


Assuming it's at least pretty trivial to append css, here's a quick fix 
for the commit message box:


.com-google-gerrit-client-change-CommitBox_BinderImpl_GenCss_style-collapsed 
.com-google-gerrit-client-change-CommitBox_BinderImpl_GenCss_style-scroll {

padding: 1em;
height: auto;
}
.com-google-gerrit-client-change-CommitBox_BinderImpl_GenCss_style-header {
padding: 1em;
}

Quick fix for the diff preferences:

.com-google-gerrit-client-diff-PreferencesBox_BinderImpl_GenCss_style-dialog 
{

background: rgba( 240, 240, 240, .9 );
color: #000;
border: solid 1px #ccc;
text-shadow: none;
}
.com-google-gerrit-client-diff-PreferencesBox_BinderImpl_GenCss_style-table 
td,
.com-google-gerrit-client-diff-PreferencesBox_BinderImpl_GenCss_style-table 
th {

color: #000;
}

Maybe?

hr {
border: solid 1px #ccc;
}

Note that all colours are made up on the spot, I don't know anything 
about how gerrit actually comes up with these crazy class names, so 
nothing is really guaranteed with these snippets, etc etc. But please, 
if we can make this better, that would be great. Some of the new 
features are already great. Also the other things.


-I
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Diff algorithms: the shootout

[Isarra Yos]

Cool!

It's entirely possible that the shortcuts it takes correspond to what 
makes a more cohesive thing to present to the user - the same shortcuts 
in the diff implementation are what we want in the front-end when 
looking for meaningful changes anyway.


I mean, this is just random speculation, but it would be interesting if 
this is indeed the case.


On 21/04/16 20:53, Max Semenik wrote:

All right, votes indicate that wikidiff3 is even better in quality, so here
we go:
https://gerrit.wikimedia.org/r/#/c/284003/ removes DairikiDiff. After it's
merged, I plan to refactor this area further and work on improving diff
quality now that we'll have 2 places to make changes instead of 3.

On Mon, Apr 18, 2016 at 1:56 PM, Antoine Musso  wrote:


Le 16/04/2016 04:00, MZMcBride a écrit :

Is there a related Phabricator Maniphest task about this? I'm not sure I
understand the motivation for making a switch. I would think that heavy
diffs are a very small portion of traffic.

An intensive would be for MediaWiki core to only have a single diff
system instead of two.

For the historic part, wikidiff3 got introduced in August 2008:

  https://www.mediawiki.org/wiki/Special:Code/MediaWiki/38653
  commit e45cf2b8


--
Antoine "hashar" Musso


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l







___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] tags are a usability nightmare for editing on mediawiki.org

[Isarra Yos]

Is there any way to just flag pages to not get translated? These tags 
are basically the main reason I've given up on documenting any of my 
extensions/skins.


On 01/04/16 16:31, Brion Vibber wrote:

Lots of pages on mediawiki.org are pretty much uneditable because they're
strewn with  spanning multiple paragraphs that make VisualEditor
completely unusable and the source editor very difficult to use.

I'm trying to update documentation, and I'm seriously thinking of regexing
out all the  stuff so I can actually edit the wiki pages.

This is probably not a good thing.


https://phabricator.wikimedia.org/T131516

-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Hackathon buddy familiar with page content type stuff needed

[Isarra Yos]

I'm sort of familiar with content handling in general, since I've been 
working on an extension using this stuff as well, so I might be able to 
help. I've found it difficult to get help in this area as well just 
because so few folks have had the opportunity to properly figure it out, 
and there isn't really any meaningful documentation about what we should 
actually be doing since it doesn't seem like anyone who has figured it 
has really had any time to spare toward making any, either (or would 
necessarily know where to even begin).


It might be worth also getting more of a list of folks who do know stuff 
together and documenting it and such at the hackathon. It's a valuable 
stuff that a lot of folks don't even realise they could be using.


On 20/03/16 15:57, Danny B. wrote:

Hello,

we're looking for a buddy to help / guidance with page-content-type handling
extension at Jerusalem Hackathon.

If you are familiar with it, but not coming to the hackathon, please let me
know as well.

Feel free to reply to me directly to not pollute the list.

Thanks for help.


Kind regards


Danny B.
[[meta:User:Danny B.]]
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RfC: Notifications in core

[Isarra Yos]

Ye.

On 01/03/16 21:41, Legoktm wrote:

Hi,

I've written an RfC about moving most of the Echo extension code into
MediaWiki core:
.

RobLa has written a summary of it on the Phab task:
.

Feedback is appreciated. :)

-- Legoktm

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Appreciation thread, 2015

[Isarra Yos]

Perhaps a thanks to the people we don't think about, who we often never 
even work with. Volunteers and third-party developers who contribute to 
and maintain repositories not part of the big tickets. People who take 
the time to file bugs, and triage them, and sort things out. The ops who 
keep things running, even when on a plane. Those who comment on 
proposals, finding problems, expressing support. Liaisons, developers, 
designers who take the time to reach out and talk to the people affected 
by what they do, and take the time to listen.


And also a thanks to everyone on this list for keeping things fairly 
sensible and productive and not turning it into a massive drama fest 
every tuesday.


On 05/12/15 08:25, Legoktm wrote:

Hi,

It's been a while since we had one of these, and 2015 has been a very
busy year! :-)

I'll quote Sumana from last time:


How about a little email thread for us to say nice things about each
other?  Rules: be kind, thank someone, and say why you're thanking
them.
[If you don't get thanked and you feel mopey, email me and I'll
comfort you. :-)]


I'll start off with thank yous to:
* Addshore, for his awesome work on CatWatch and help with recent
ExtensionDistributor improvements
* YuviPanda, for coming up with unique and useful tools for Wikimedians,
and then following through and building them
* S Page, for consistently nagging me and other developers to improve
documentation

-- Legoktm

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

[Isarra Yos]

Your email client seems to have mangled the indenting for some reason, 
so I tried to repair it. Apologies if I've messed anything up in the 
process.


On 15/11/15 09:47, Jon Robson wrote:

On 15 Nov 2015 2:31 p.m., "Isarra Yos" <zhoris...@gmail.com> wrote:

I agree that it's important to move away from desktop-first, but switching to 
mobile-first isn't the answer either.


Why not? Whats wrong with a fixed width centered site? Old phones do not
have media query support nor do they have ability to support conditional
statements.


It doesn't work for MediaWiki. As a product, it is too complicated, has 
too many modes and tools, to effectively communicate to the user what 
they can and cannot do using only simple styles. (I assume you mean 
max-width, since just fixed width doesn't work on mobile anyway.)


When you have more space, you can tell them more. When you have less 
space, you need to use other affordances to tell them things, and hide 
links and tools behind menus, but this adds to the steps required for 
both discovery and use, and should only be done when you have no other 
options. For desktop users who actually do have the space to lay the 
important things out, having everything hidden behind buttons and menus 
is simply not fair - or useful.



For complex products (discussion boards, skins, anything that could benefit
from a lot of space), there are going mobile-specific styles same as any
other resolution - do ANY as the 'main', and you're having to undo and
override those styles on every other one, which results in unnecessarily
complicated and large code, which just makes it all that much harder to
maintain and work with.

As an example, this is an important part of why it's been so hard to make
Vector properly responsive - so many of the desktop styles needed to be
overridden in order for any mobile design
to be applied. (This would have applied in either direction because its
desktop and mobile layouts are so completely different.) But suppose that
same step had been replaced with instead separating out the desktop styles
into a separate stylesheet for a similar amount of effort, and with each as
separate, independent stylesheets - code for both desktop and mobile would
be made cleaner, and far easier to iterate upon.

This will never happen. True mobile development is a lot more than moving
around styles.


True mobile development is nothing more than developing for mobile. You 
lay things out and use the tools mobile affords - same as any other 
platform. You just need to actually do this for ALL your platforms. 
Including mobile. Including desktop. Including screen readers.



For example the current responsive vector skin that exists
in an experimental state sits at the bottom of the page which is a dead
zone. I'm yet to see any good examples of this done well.


What exactly do you mean? Is this a bug in the implementation in which 
the entire skin shows up off the page on mobile or something?


Or are you referring to the navigation? Because yes, that definitely 
needs work. I was under the impression nobody had actually gotten to 
that part yet; my point was more that the skin now renders on mobile in 
a legible fashion at all, which was previously not the case with the 
sidebars and tabs and whatnot.



You want a responsive skin though. What you are describing is not one. A
responsive site uses the same stylesheet for both desktop and mobile.


'Responsive', in reference to websites, means that the site layout 
responds to and renders well regardless of the size of or device type on 
which it is displayed.


A single set of styles for everything can be made to work (or even no 
styles, technically speaking - just look at motherfuckingwebsite.com), 
but also introduces serious limitations in terms of what can be done for 
each, which in particular poses problems for MediaWiki for the reasons I 
explained above (yes, you can still do it; it's just not exactly 
optimal). But the fact of the matter is that the entire reason @media 
size queries were introduced in the first place was mitigate this sort 
of thing by allowing for more specific styles to be employed, optimised 
for the different displays and taking full advantage of their different 
features. This is exactly what it is for, and we should be using it for 
this.



(People wanted me to iterate on what's there now and I couldn't even figure
out where to begin. Not that I'm that good at CSS in the first place, but
that code is scary.)

What we need to do is get better at distinguishing and leveraging the
common styles, and using common variables and mixins, because this is how
you make consistent overall styles and also simplify the overall thing.
Then build these into something that works for each platform.

And if we're going to support stupid broken things, we need to explicitly
support them with some sort of fallback that doesn't require a lot of
manual rejigging. I'm not sure IE8, as an ancient

Re: [Wikitech-l] [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

[Isarra Yos]

Is there any way to use addModuleStyles() so that it outputs 
browser-conditional stylesheets? Such that such a one could apply only to IE8-? 
That's really what I need here.

On 15/11/15 00:17, Krinkle wrote:

Just wanna make a small correction here to avoid confusion.

The top and bottom queue are both JavaScript-enabled, using 'position' =>
'top' only controls where the load() command is placed (at the top or
bottom, naturally). Neither of these will run in IE 8 after January.

What Florian is referring to does exist. That is the "styles-only" queue It
is triggered by using addModuleStyles(). This method will ensure the module
is included in a regular  stylesheet. These modules don't have a
position, as stylesheets are always in the top.

One could consider these stylesheets as part of the top queue (based on
where they are in the HTML), but we don't do that in our documentation to
avoid confusion as instructions you may find about using the "top queue"
will refer to the 'position' attribute as used by addModules() – which is
not what you want in this case.

These styles-only modules are still processed by ResourceLoader (e.g. LESS
can be used, minified, and cached as usual). We've always used this skin
styling and other styles associated with server-side generated page output
(e.g. thumbnail styles, table of contents, skins etc.).

Primarily because it performs better (browsers discover these urls and
start fetching when statically looking ahead in the html parse stream). And
because it's a more stable and a semantically correct way to associate
styles. For instance, JavaScript runtime could intermittently fail for any
number of reasons even in modern browsers, as well as on mobile browsers.
In such scenarios the stylesheet  more important, and users effectively get
the fallback experience (as opposed to a page with no styling, which would
happen if we don't do that).

-- Krinkle


On Fri, Nov 13, 2015 at 10:02 AM, Florian Schmidt <
florian.schmidt.wel...@t-online.de> wrote:


I'm not totally sure, but if you put your styles into a top queue module,
the module would be delivered through RL (with all it's features, including
LESS compilation) and the browser requests it without JavaScript (it should
be added into one of the RL link tags in head). The change to disable JS on
IE8 should affect bottom queued modules, only (the requests for these
modules are initialized by JS).


-Original-Nachricht-
Von: "Isarra Yos" <zhoris...@gmail.com <lt%3bzhoris...@gmail.com>>

Using js got around this whole problem as with that you can simply check
the browser there and then conditionally mw.loader.load a size-free
module for IE8.

Is there any other way around this?



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

[Isarra Yos]

I agree that it's important to move away from desktop-first, but 
switching to mobile-first isn't the answer either. For complex products 
(discussion boards, skins, anything that could benefit from a lot of 
space), there are going mobile-specific styles same as any other 
resolution - do ANY as the 'main', and you're having to undo and 
override those styles on every other one, which results in unnecessarily 
complicated and large code, which just makes it all that much harder to 
maintain and work with.


As an example, this is an important part of why it's been so hard to 
make Vector properly responsive - so many of the desktop styles needed 
to be overridden in order for any mobile design to be applied. (This 
would have applied in either direction because its desktop and mobile 
layouts are so completely different.) But suppose that same step had 
been replaced with instead separating out the desktop styles into a 
separate stylesheet for a similar amount of effort, and with each as 
separate, independent stylesheets - code for both desktop and mobile 
would be made cleaner, and far easier to iterate upon. (People wanted me 
to iterate on what's there now and I couldn't even figure out where to 
begin. Not that I'm that good at CSS in the first place, but that code 
is scary.)


What we need to do is get better at distinguishing and leveraging the 
common styles, and using common variables and mixins, because this is 
how you make consistent overall styles and also simplify the overall 
thing. Then build these into something that works for each platform.


And if we're going to support stupid broken things, we need to 
explicitly support them with some sort of fallback that doesn't require 
a lot of manual rejigging. I'm not sure IE8, as an ancient desktop 
browser, getting mobile styles is really any better than an ancient 
mobile browser getting desktop styles.


On 14/11/15 22:39, Jon Robson wrote:

The solution to this is to do true mobile first development e.g. wrap your
desktop and tablet styles in media queries. Rendering a mobile site in IE8
is an acceptable trade off and ensures the content remains readable which
is the most important thing here.

We (Wikimedia devs) still build desktop first in all our major projects and
we really need to shift away from this. We can't simply build for desktop
and then adapt it to work on mobile which seems to be a common
misconception by anyone who hasn't built things for mobile. This approach
is costly as we end up rebuilding things we've already built to make them
work on mobile. We used to have a mobile department that pretty much did
this as a full time job but now that has gone we really need to adopt this
tried and tested approach.
On 13 Nov 2015 2:20 a.m., "Isarra Yos" <zhoris...@gmail.com> wrote:


Perhaps I should clarify why this is a problem. In fully responsive skins,
you generally have separate stylesheets for desktop, mobile, really big
desktop, whatever in order to keep the CSS rules simple and not redundant
(to avoid having mobile overriding desktop rules or visa versa, you just
only send the mobile styles to mobile, the desktop to desktop). You do this
by setting maximum and minimum screen sizes in the @media queries, but the
problem is, IE8 does not support this, and will not load a stylesheet at
all if these sizes are set. So you need to give it the desktop styles some
other way, without the @media size rules present.

While it is possible to simply add CSS to the page header using
outputPage, probably bypassing RL and all that entirely, this only works
with CSS, not LESS, because all the LESS magic is happening within RL. So
without RL, that means you need to render your desktop stylesheet into CSS
for this, which means you now need to maintain it in two different places
even though it's the same rules in both.

Using js got around this whole problem as with that you can simply check
the browser there and then conditionally mw.loader.load a size-free module
for IE8.

Is there any other way around this?

On 12/11/15 02:56, Isarra Yos wrote:


Is there a way to conditionally load RL modules for folks using IE8?
Because I couldn't figure out any proper way to do that in my skins and
I've just been using js to do it instead as a result.

But that's not going to work anymore. But it's also stupid regardless.

On 12/11/15 02:11, Krinkle wrote:


Hey all,

Starting in January 2016, MediaWiki will end JavaScript support for
Microsoft Internet Explorer 8. This raises the cut-off up from MSIE 7.
Users with this browser will still be able to browse, edit, and otherwise
contribute to the site. However, some features will not be available to
them. For example, the enhanced edit toolbar will not appear, and the
notification buttons will take you to a page rather than a pop-out.

This change will affect roughly 0.89% of all traffic to Wikimedia wikis
(as
of October 2015). For comparison, 0.33% of traffic comes from Internet
Expl

Re: [Wikitech-l] [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

[Isarra Yos]

I don't really understand how this solves anything, though - the 
stylesheets need to be conditional because IE8 needs a different value 
for the @media than everything else (and thus can't use the same 
module). Other than that, it's still the same stylesheet as is being 
served to everything else.


But the conditional stylesheet method employed by vector  won't work if 
it's LESS because this method is not for RL modules, and yet it is 
looking like this will be our only option now? If we're using LESS on a 
responsive skin, we simply have to maintain two (probably pretty 
identical) desktop stylesheets if we want to support IE8 at all?


On 13/11/15 10:02, Florian Schmidt wrote:

I'm not totally sure, but if you put your styles into a top queue module, the 
module would be delivered through RL (with all it's features, including LESS 
compilation) and the browser requests it without JavaScript (it should be added 
into one of the RL link tags in head). The change to disable JS on IE8 should 
affect bottom queued modules, only (the requests for these modules are 
initialized by JS).

Another solution could (probably) be conditional style sheets, like Vector uses 
for IE7:
https://github.com/wikimedia/mediawiki-skins-Vector/blob/3f1515a7b223793818c6ac82805ee3b6c462fe50/SkinVector.php#L58-L62

Best,
Florian

-Original-Nachricht-
Betreff: Re: [Wikitech-l] [BREAKING CHANGE] IE 8 will go JavaScript-less 
starting January 2016
Datum: 2015-11-12T18:20:39+0100
Von: "Isarra Yos" zhoris...@gmail.com
An: "Wikimedia developers" wikitech-l@lists.wikimedia.org

Perhaps I should clarify why this is a problem. In fully responsive
skins, you generally have separate stylesheets for desktop, mobile,
really big desktop, whatever in order to keep the CSS rules simple and
not redundant (to avoid having mobile overriding desktop rules or visa
versa, you just only send the mobile styles to mobile, the desktop to
desktop). You do this by setting maximum and minimum screen sizes in the
@media queries, but the problem is, IE8 does not support this, and will
not load a stylesheet at all if these sizes are set. So you need to give
it the desktop styles some other way, without the @media size rules present.

While it is possible to simply add CSS to the page header using
outputPage, probably bypassing RL and all that entirely, this only works
with CSS, not LESS, because all the LESS magic is happening within RL.
So without RL, that means you need to render your desktop stylesheet
into CSS for this, which means you now need to maintain it in two
different places even though it's the same rules in both.

Using js got around this whole problem as with that you can simply check
the browser there and then conditionally mw.loader.load a size-free
module for IE8.

Is there any other way around this?

On 12/11/15 02:56, Isarra Yos wrote:> Is there a way to conditionally load RL modules for folks using IE8?> Because I couldn't figure out any proper way to do that in my skins> and I've just been using js to do it instead as a result.>> But that's not going to work anymore. But it's also stupid regardless.>> On 12/11/15 02:11, Krinkle 
wrote:>> Hey all,>>>> Starting in January 2016, MediaWiki will end JavaScript support for>> Microsoft Internet Explorer 8. This raises the cut-off up from MSIE 7.>> Users with this browser will still be able to browse, edit, and>> otherwise>> contribute to the site. However, some features will not be available 
to>> them. For example, the enhanced edit toolbar will not appear, and the>> notification buttons will take you to a page rather than a pop-out.>>>> This change will affect roughly 0.89% of all traffic to Wikimedia>> wikis (as>> of October 2015). For comparison, 0.33% of traffic comes from Internet>> Explorer 6, and 
1.46% from Internet Explorer 7. Support for these was>> dropped in August and September 2014 respectively.>>>> Providing JavaScript for IE 8 adds a significant maintenance burden. It>> also bloats the software we ship to all users, without proportionate>> benefit. This enables us to simplify and streamline the JavaScript>> 
codebase>> for all other users. Users unable to upgrade from Internet Explorer 8>> will>> have a faster experience going forward, based on well-tested and more>> stable code.>>>> This change will land in the development branch in January, and so>> will be>> part of MediaWiki 1.27 (to be released around May 
2016).>>>> Tech News will announce this change as well, but please help carry this>> message into your communities. In January, we will send a reminder>> before>> the change happens.>>>> Yours,>> -- Krinkle>>>> For details about the JavaScript-less experience, see>> 
https://www.mediawiki.

Re: [Wikitech-l] [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

[Isarra Yos]

Perhaps I should clarify why this is a problem. In fully responsive 
skins, you generally have separate stylesheets for desktop, mobile, 
really big desktop, whatever in order to keep the CSS rules simple and 
not redundant (to avoid having mobile overriding desktop rules or visa 
versa, you just only send the mobile styles to mobile, the desktop to 
desktop). You do this by setting maximum and minimum screen sizes in the 
@media queries, but the problem is, IE8 does not support this, and will 
not load a stylesheet at all if these sizes are set. So you need to give 
it the desktop styles some other way, without the @media size rules present.


While it is possible to simply add CSS to the page header using 
outputPage, probably bypassing RL and all that entirely, this only works 
with CSS, not LESS, because all the LESS magic is happening within RL. 
So without RL, that means you need to render your desktop stylesheet 
into CSS for this, which means you now need to maintain it in two 
different places even though it's the same rules in both.


Using js got around this whole problem as with that you can simply check 
the browser there and then conditionally mw.loader.load a size-free 
module for IE8.


Is there any other way around this?

On 12/11/15 02:56, Isarra Yos wrote:
Is there a way to conditionally load RL modules for folks using IE8? 
Because I couldn't figure out any proper way to do that in my skins 
and I've just been using js to do it instead as a result.


But that's not going to work anymore. But it's also stupid regardless.

On 12/11/15 02:11, Krinkle wrote:

Hey all,

Starting in January 2016, MediaWiki will end JavaScript support for
Microsoft Internet Explorer 8. This raises the cut-off up from MSIE 7.
Users with this browser will still be able to browse, edit, and 
otherwise

contribute to the site. However, some features will not be available to
them. For example, the enhanced edit toolbar will not appear, and the
notification buttons will take you to a page rather than a pop-out.

This change will affect roughly 0.89% of all traffic to Wikimedia 
wikis (as

of October 2015). For comparison, 0.33% of traffic comes from Internet
Explorer 6, and 1.46% from Internet Explorer 7. Support for these was
dropped in August and September 2014 respectively.

Providing JavaScript for IE 8 adds a significant maintenance burden. It
also bloats the software we ship to all users, without proportionate
benefit. This enables us to simplify and streamline the JavaScript 
codebase
for all other users. Users unable to upgrade from Internet Explorer 8 
will

have a faster experience going forward, based on well-tested and more
stable code.

This change will land in the development branch in January, and so 
will be

part of MediaWiki 1.27 (to be released around May 2016).

Tech News will announce this change as well, but please help carry this
message into your communities. In January, we will send a reminder 
before

the change happens.

Yours,
-- Krinkle

For details about the JavaScript-less experience, see
https://www.mediawiki.org/wiki/Compatibility
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l





___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Skinning tutorial

[Isarra Yos]

On 12/11/15 03:39, S Page wrote:

On Tue, Nov 10, 2015 at 6:31 PM, Isarra Yos <zhoris...@gmail.com> wrote:


On 11/11/15 02:06, S Page wrote:


I meant the on-wiki three-part skinning thing that's been
around for a while and introduces in a nutshell as "This page is part 1 of
a three-part tutorial".


Oh, I want to murder that. Have I mentioned that? I think I have, but if I
haven't, I'D LIKE TO MURDER THAT. It doesn't even say how to do the
important bits, while focussing on bits nobody in their right mind will
ever even touch, with no real structure or sensible organisation. It's
ludicrous.


I spent two hours adding a screenshot for the elements mentioned in
Skinning Part 1 [1]. Given that part 1 spends so much time describing
elements of a page, a picture seemed worth 1000 words. Is your thesis that
anyone who starts from the Example skin already has these elements and any
skin designer knows the ins and outs of wiki pages, so they don't need to
be mentioned? (
https://www.mediawiki.org/wiki/User:Isarra/How_to_make_a_motherfucking_skin
doesn't mention actions, personal tools, the page subheader, etc.) I'm
dubious.  Even if one had a set of test pages that exercise all these
elements, saying what they are seems useful.

[1] https://www.mediawiki.org/wiki/Manual:Skinning_Part_1


Yeah, sorry. What I mean to say in particular is the layout as is needs 
to go - what I'm thinking at this point is ideally we'd have a barebones 
just-some-steps thing on top, with subpages of specific details and 
stuff clearly linked from there. A major problem I see with 
Manual:Skinning right now is it is incredibly overwhelming, with no 
indication which parts are actually important (in part because which 
parts are actually important has also changed so much recently). Someone 
thinking to make a skin can easily look at it and just balk right there, 
when really the steps they need to follow are much more straight 
forward, and they only need to worry about some of this anyway.


https://www.mediawiki.org/wiki/User:Isarra/How_to_make_a_skin is based 
much more on a visual approach, where ideally folks will be looking at 
the page and then just styling whatever they see - including all these 
things, which appear there on the page. Why list all the things when 
they're right there on the page (though some is probably a good idea 
just as an example, with the link to the full list), when a lot of them 
don't even need any styling, when they're all actually built-in now? 
Because yes, people should definitely be starting from the example skin. 
That's what it's for. Ideally with the whole autogenerated alreadynamed 
skin downloads.


But of course just looking at the actual tutorial, people can't actually 
see the skin, so it really would also need illustrations to really pull 
that off anyway.


Eh.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

[Isarra Yos]

Is there a way to conditionally load RL modules for folks using IE8? 
Because I couldn't figure out any proper way to do that in my skins and 
I've just been using js to do it instead as a result.


But that's not going to work anymore. But it's also stupid regardless.

On 12/11/15 02:11, Krinkle wrote:

Hey all,

Starting in January 2016, MediaWiki will end JavaScript support for
Microsoft Internet Explorer 8. This raises the cut-off up from MSIE 7.
Users with this browser will still be able to browse, edit, and otherwise
contribute to the site. However, some features will not be available to
them. For example, the enhanced edit toolbar will not appear, and the
notification buttons will take you to a page rather than a pop-out.

This change will affect roughly 0.89% of all traffic to Wikimedia wikis (as
of October 2015). For comparison, 0.33% of traffic comes from Internet
Explorer 6, and 1.46% from Internet Explorer 7. Support for these was
dropped in August and September 2014 respectively.

Providing JavaScript for IE 8 adds a significant maintenance burden. It
also bloats the software we ship to all users, without proportionate
benefit. This enables us to simplify and streamline the JavaScript codebase
for all other users. Users unable to upgrade from Internet Explorer 8 will
have a faster experience going forward, based on well-tested and more
stable code.

This change will land in the development branch in January, and so will be
part of MediaWiki 1.27 (to be released around May 2016).

Tech News will announce this change as well, but please help carry this
message into your communities. In January, we will send a reminder before
the change happens.

Yours,
-- Krinkle

For details about the JavaScript-less experience, see
https://www.mediawiki.org/wiki/Compatibility
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Skinning tutorial

[Isarra Yos]

As a bit of a follow up to the talk I did last week, I wrote up a 
tutorial on-wiki how to make a skin: 
https://www.mediawiki.org/wiki/User:Isarra/How_to_make_a_motherfucking_skin
The plan is to eventually replace Manual:Skinning with that and some 
subpages with specific info, but if anyone wants to run through now, see 
if it's useful, try it out, see if anything is missing or wrong, I'd 
appreciate the help making it better.


-I

ps - Yes, I may have read motherfuckingwebsite.com a few too many times 
before writing that up. I, uh, sort of apologise.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Skinning tutorial

[Isarra Yos]

On 10/11/15 21:59, S Page wrote:

The tutorial is pretty good IMO, the problem is it forced repetition. part
1 "Here are some page elements you need to worry about"; part 2 "Let's
output some of those page elements"; part 3 "How to test these page
elements". But maybe that's OK.


This may just be because I did it at three in the morning; it probably 
doesn't need that much. I'll see if I can clean that up a bit. >.>


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Skinning tutorial

[Isarra Yos]

On 11/11/15 02:06, S Page wrote:

On Tue, Nov 10, 2015 at 2:39 PM, Isarra Yos <zhoris...@gmail.com> replied:


On 10/11/15 21:59, S Page wrote:


The tutorial is pretty good IMO, the problem is it forced repetition


This may just be because I did it at three in the morning; it probably
doesn't need that much. I'll see if I can clean that up a bit. >.>


D'oh, I'm sorry, I meant the on-wiki three-part skinning thing that's been
around for a while and introduces in a nutshell as "This page is part 1 of
a three-part tutorial".


Oh, I want to murder that. Have I mentioned that? I think I have, but if 
I haven't, I'D LIKE TO MURDER THAT. It doesn't even say how to do the 
important bits, while focussing on bits nobody in their right mind will 
ever even touch, with no real structure or sensible organisation. It's 
ludicrous.



Re:
https://www.mediawiki.org/wiki/User:Isarra/How_to_make_a_motherfucking_skin

I have a dream where both extensions/BoilerPlate and skins/Example are a
script that prompts for your extension or skin name, clones it into
YourProject, sets up the example as a non-master remote (so you can track
updates to the skeleton), and does the mindless file renames and search and
replace to YourProjectName. [1]


Or not even having the remote necessarily (letting people just download 
it so they can mess around without necessarily leaving any sign around 
they did), but yes, that sounds very useful.



Also you can probably delete any random things that say 'composer' or

'grunt' or whatever in the filenames. Not really sure why those are in the
example skin. That's a bit confusing.

Nope, they're gold. It means you can run npm test and composer test and
automatically have a growing set of basic tests and coding checkers run for
you.  See BoilerPlate's README.md [1] , maybe the same instructions should
be copied to skins/Example.


Isn't that all broken by default because it's still using the example 
config?



The good advice in your Step 4 and Testing could fit well into Skinning
Part 3.


Frankly the fact that there are three parts means most users are never 
going to make it to part three. Which is also something to... not do?



[1] Legoktm built such a thing for Wikimedia libraries,
https://github.com/wikimedia/generator-wikimedia-php-library#readme
[2] https://github.com/wikimedia/mediawiki-extensions-BoilerPlate#readme




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Summit proposal: Turning the Table of Contents into a discrete object

[Isarra Yos]

Hi! I would like to turn the mw ToC into a discrete object within the 
codebase. Write a ToC class and pull all the random building parts out 
of the parser and five levels of pageoutput, and make it stop messing up 
the page caching and stuff. Make this class a thing, separate from the 
content itself, that can appear on the page or be toggled or messed with 
or added to or moved or whatever by extensions.


I have a proposal about this for the developers summit which is about as 
specific: https://phabricator.wikimedia.org/T114057


Please come discuss. Would this affect what you're doing in a good or 
bad way? What do we know of that this should support at present? What 
would we, as developers or whatever the buckets, want out of it?


Also is this the sort of thing you normally use an RfC for? I'm a 
designer so I'm just asking questions and soliciting stories and all 
that before I go trying to do designy stuff on the mw backend, but maybe 
that's not really the way to do this here.


-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Forking, branching, merging, and drafts on Wikipedia

[Isarra Yos]

On 07/11/15 00:32, David Gerard wrote:

On 7 November 2015 at 00:29, Brian Wolff  wrote:


I feel like different people want different things, and what is really
needed is a user-centric discussion of use-cases to drive a feature
wishlist, not any sort of discussion about implementation.

Yes. I see the rationaie in that Phabricator ticket, but it reads like
personal ideology without reference to the Wikimedia projects. What is
the use case?


Yeah, we need to figure out who all these different groups are, too. Who 
are doing similar things currently, and who would have use? Who already 
knows they want to do these things, and what can we ask them?


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fwd: [MediaWiki-l] An "advanced search" page for CirrusSearch?

[Isarra Yos]

On 06/10/15 17:12, Daniel Barrett wrote:

MZMcBride writes:

It also seems worthwhile to note that "Special:Search" already has an
advanced profile/tab where users can select arbitrary namespaces to search.

Technically that is true, but I suspect that 95% of the time, 95% of users care 
only about the main namespace. Filter by category, wildcard searches, title 
searches, fuzzy searches, etc., are eminently more usable.  I'll probably build 
an advanced search plugin myself if nobody else has done it yet.

DanB


This is an important point. Namespace searching by itself really feels 
like a much more ham-fisted approach to a lot of this, for when lacking 
anything more elegant to narrow things down (not that it's not useful 
too). But we do have elegant now, and yet nobody sees it.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Fwd: [MediaWiki-l] An "advanced search" page for CirrusSearch?

[Isarra Yos]

This strikes me as a rather good idea, but I don't really know that much 
about cirrussearch in the first place. Anyone know, or have any thoughts 
on this?



 Forwarded Message 
Subject:[MediaWiki-l] An "advanced search" page for CirrusSearch?
Date:   Mon, 5 Oct 2015 14:12:18 +
From:   Daniel Barrett 
Reply-To: 	MediaWiki announcements and site admin list 

To: 	MediaWiki announcements and site admin list 





CirrusSearch has so many wonderful keywords for advanced searching: 
https://www.mediawiki.org/wiki/Help:CirrusSearch.

Has anybody created an "advanced" search form (a special page) that uses these 
wonderful options under the hood, to help less sophisticated users?  That would make a 
great addition to MediaWiki.  For example:

Enter your search terms:
Limit to category:
Limit to namespace:  (dropdown)
Search page titles only (yes/no):
Approximate matching (on/off):
Search within wikitext source (on/off):
etc...

I looked on mediawiki.org but didn't see anything.

Thanks,
DanB

___
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Would anyone be interested in a tech talk about how to make a mw skin?

[Isarra Yos]

How would a hack day/afternoon work? Is that an office thing? If so, 
would that be something you could run based off... uh, more information?


On 28/09/15 22:15, Jon Robson wrote:

I'd be interested in the process people go through purely from a how can I
make this simpler perspective. Alternatively you might want to consider
doing a skin hack day/afternoon where people build skins and learn for
themselves the horror of that process :)



On Mon, Sep 28, 2015 at 3:08 PM, Bryan Davis <bd...@wikimedia.org> wrote:


On Mon, Sep 28, 2015 at 3:00 PM, Isarra Yos <zhoris...@gmail.com> wrote:

Jack Phoenix and I were considering doing a tech talk about how to make a
MediaWiki skin. Would there be any interest in this? What would you folks
want to see from such a talk?

I'd love to get an overview on creating a new skin. I would be
especially interested in the "tales from the real world" aspects of
working with RL, what is and isn't possible without implementing
hooks, and lessons learned from past skins the two of you have worked
on.

Bryan
--
Bryan Davis  Wikimedia Foundation<bd...@wikimedia.org>
[[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
irc: bd808v:415.839.6885 x6855

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l







___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Would anyone be interested in a tech talk about how to make a mw skin?

[Isarra Yos]

Oh, aye. Might also make sense to have this after the talk, which 
discusses theory, so then the hack whatever can be where the theory all 
falls apart.


Wait...

On 30/09/15 19:55, Jon Robson wrote:

It could be a 4 hour afternoon session around the dev summit for instance
and could be advertised so anyone can join. Essentially it would be a
hackathon focused on skins. If you were really ambitious you'd add prizes
for best judged skin etc :)
On 30 Sep 2015 12:49 pm, "Isarra Yos" <zhoris...@gmail.com> wrote:


How would a hack day/afternoon work? Is that an office thing? If so, would
that be something you could run based off... uh, more information?

On 28/09/15 22:15, Jon Robson wrote:


I'd be interested in the process people go through purely from a how can I
make this simpler perspective. Alternatively you might want to consider
doing a skin hack day/afternoon where people build skins and learn for
themselves the horror of that process :)



On Mon, Sep 28, 2015 at 3:08 PM, Bryan Davis <bd...@wikimedia.org> wrote:

On Mon, Sep 28, 2015 at 3:00 PM, Isarra Yos <zhoris...@gmail.com> wrote:

Jack Phoenix and I were considering doing a tech talk about how to make
a
MediaWiki skin. Would there be any interest in this? What would you
folks
want to see from such a talk?


I'd love to get an overview on creating a new skin. I would be
especially interested in the "tales from the real world" aspects of
working with RL, what is and isn't possible without implementing
hooks, and lessons learned from past skins the two of you have worked
on.

Bryan
--
Bryan Davis  Wikimedia Foundation<bd...@wikimedia.org>
[[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
irc: bd808v:415.839.6885 x6855

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l





___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Skins in tarball releases

[Isarra Yos]

I would like to get a skin added as an option to the tarball releases. 
What all do they generally need to have done before that's possible?


For reference, this is the skin: 
https://www.mediawiki.org/wiki/Skin:GreyStuff


Any feedback about the skin in general would also be appreciated.

-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The "other" developers at the Wikimedia Developer Summit

[Isarra Yos]

On 28/09/15 16:16, Quim Gil wrote:

On Mon, Sep 28, 2015 at 6:07 PM, Isarra Yos <zhoris...@gmail.com> wrote:


In the example of template editors, gadget and tool developers, etc used
earlier in this thread, how would that apply? Folks just do enough
templates etc elsewhere and poke a related proposal saying 'yup relevant'
so interest is known on that end, and then just list their involvements on
the application?


It would apply exactly in the same way than to the rest of developers.
Getting travel sponsorship to the Summit is not based on "what you do" but
on "what is your participation in the Summit". Someone requesting travel
sponsorship for the Summit must be able to explain their participation in
the discussions leading to the Summit.


So why are they explicitly included for the call for participation? 
Either they are already involved in the core discussions and would see 
the call for participation regardless, or... they won't be? Am I missing 
something, here?


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The "other" developers at the Wikimedia Developer Summit

[Isarra Yos]

On 28/09/15 11:05, Quim Gil wrote:

On Sun, Sep 27, 2015 at 12:48 AM, Isarra Yos <zhoris...@gmail.com> wrote:


Here's a question. For volunteers or third-party folks less close to core
- suppose we do want to come talk about whatever pertains to us. How do we
bring these things up? How do we propose discussions when they're not our
projects (upstream) and we don't even necessarily know whose projects they
are (I've certainly lost complete track of what WMF teams are which, and
whoever is actually doing/maintaining the stuff can still apparently be
other folks entirely)? Do we just put up a proposal 'talk about blah' and
hope someone who actually knows about blah shows up? If I want to discuss
the future of MF, do I just put up a thing 'the future of MF' and hope it
attracts the relevant attention needed to actually go somewhere?


In the context of the Summit, "talk about blah" becomes a useful session
proposal when the problem of blah is defined, the goals of the session are
defined, and the people and projects related with blah are invited to
participate.

If you want to discuss the future of MobileFrontend, it is useful to define
what problems MobileFrontend has today, and what do you expect to solve
between now and the day of this session at the Summit. #MobileFrontend has
a project in Phabricator, and depending on the problems you might want to
add more projects/tags. If that is not enough to raise attention (it
should), then you have this list and/or mobile-l.


Okay, thanks. That does help clarify things a bit.


See
https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016#Call_for_participation
for the fields we expect in all Summit proposals.


Also, something I find particularly confusing is that we need to be heavily

involved in the proposals in order to even be considered for sponsorship
when in a lot of cases volunteers/third party folks may not even in much
position to bring them up in the first place even when we're definitely
impacted. And yet we're also the ones who are most likely to need
sponsorship, being less likely to be already working out of the bay area,
and much less likely to be involved in the general team discussions that
happen throughout the year.


https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016#Travel_sponsorship
says "Candidates for travel sponsorship must be active contributors in
ongoing Summit proposals". If a candidate is not active right now in the
specific task, but they can proof their involvement in that topic in other
ways, that is fine as well. We just want to see a clear connection between
the people we sponsor and the activities being planned. It is a sensible
requirement.


In the example of template editors, gadget and tool developers, etc used 
earlier in this thread, how would that apply? Folks just do enough 
templates etc elsewhere and poke a related proposal saying 'yup 
relevant' so interest is known on that end, and then just list their 
involvements on the application?



(And seriously, what's with the timing? So close after new year's, people
are going to be on holiday and plane prices are horrible; for me it'd bring
the price down by over half if it were even just a week later, and others
may be more extreme.)


These dates were not our first option, but the availability of venues in
San Francisco for the Summit and WMF AllHands during those weeks didn't
gave us many alternatives. Also, the Wikimedia Hackathon is very close next
year (end of March). On the other hand, the proximity / overlap with
holidays might make it easier for some (i.e. students) to travel?


Students probably aren't the best example, as it starts the same time as 
classes some places, which means they don't even have the option. (Later 
in the term would allow them to find folks to cover for them, talk to 
professors ahead of time, etc, but missing the beginning, especially if 
they have TA meetings, is a very bad idea for most.)




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Would anyone be interested in a tech talk about how to make a mw skin?

[Isarra Yos]

Jack Phoenix and I were considering doing a tech talk about how to make 
a MediaWiki skin. Would there be any interest in this? What would you 
folks want to see from such a talk?


-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The "other" developers at the Wikimedia Developer Summit

[Isarra Yos]

On 16/09/15 06:11, Quim Gil wrote:

The content of the Summit is derived from the proposals submitted discussed
well before the Summit. If a developer had topics to discuss before the
Summit, they will have topics to discuss during the Summit. However, if a
developer didn't have any topic to discuss before the Summit then indeed,
there is a likely chance that such developer will have an unclear role
during the event.

At least when it comes to the developers requesting travel sponsorship
(most volunteers not based in the San Francisco Bay Area), we are requiring
them to point out to proposals they are submitting or where they are
heavily involved. So you see, I think we have a system that works, open to
anyone but in practice unlikely to propitiate i.e. template editors lost at
the Summit.


Here's a question. For volunteers or third-party folks less close to 
core - suppose we do want to come talk about whatever pertains to us. 
How do we bring these things up? How do we propose discussions when 
they're not our projects (upstream) and we don't even necessarily know 
whose projects they are (I've certainly lost complete track of what WMF 
teams are which, and whoever is actually doing/maintaining the stuff can 
still apparently be other folks entirely)? Do we just put up a proposal 
'talk about blah' and hope someone who actually knows about blah shows 
up? If I want to discuss the future of MF, do I just put up a thing 'the 
future of MF' and hope it attracts the relevant attention needed to 
actually go somewhere?


Also, something I find particularly confusing is that we need to be 
heavily involved in the proposals in order to even be considered for 
sponsorship when in a lot of cases volunteers/third party folks may not 
even in much position to bring them up in the first place even when 
we're definitely impacted. And yet we're also the ones who are most 
likely to need sponsorship, being less likely to be already working out 
of the bay area, and much less likely to be involved in the general team 
discussions that happen throughout the year. (And seriously, what's with 
the timing? So close after new year's, people are going to be on holiday 
and plane prices are horrible; for me it'd bring the price down by over 
half if it were even just a week later, and others may be more extreme.)


-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Do you run mediawiki on shared hosting? Tell us about it

[Isarra Yos]

On 24/09/15 17:46, Daniel Barrett wrote:

Brian Wolff writes:

I feel like the types of people who use shared hosting are very unlikely to be 
following this list.

I am one of those people. I happily use shared hosting for MediaWiki because 
(1) it is very cheap and (2) I don't have to maintain the OS.

DanB


I used shared hosting initially. Another thing it was very good for was 
processing power - it could actually handle intensive tasks like 
instantcommons or semantic queries fairly well. When I switched to 
dedicated initially (this was a very crappy one a few years back) I 
couldn't use instantcommons at all because it just didn't have the 
needed power.


-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Code of conduct committee

[Isarra Yos]

On 21/08/15 14:39, Oliver Keyes wrote:

On 21 August 2015 at 06:43, Quim Gil q...@wikimedia.org wrote:

Hi,

On Fri, Aug 21, 2015 at 11:49 AM, Steinsplitter Wiki 
steinsplitter-w...@live.com wrote:


* I see a lot (maybe 70%) staffer edits there.

I also would like to see more edits from volunteers and other affiliations.
Please jump in! Most WMF employees drafting and discussing there are doing
so out of their personal interest, with no WMF directive and most likely on
their own time. I'm basically the only exception.

Speaking as a WMF employee who is involved in the discussion, this is
my personal opinion - hence my choice of accounts to comment with. I
suspect that WMF employees probably make up a big proportion of the
technical community itself (something this proposal will hopefully
help change!) and so large amounts of WMF participation is not
surprising.


If nothing else, WMF employees are likely the bulk of technical 
contributors with the spare time to actually talk meta about this stuff, 
since they're already spending their paid time making things. Imagine if 
you were doing all of this in your spare time, would you rather be using 
your limited time making things, or talking about some ephemeral 
proposed thing that may not ever even affect you even if it does become 
real? Having to make that choice could impact matters too.


-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Code of conduct

[Isarra Yos]

I'm curious who all 'we' is as well.

On 07/08/15 17:29, Steven Walling wrote:

On Fri, Aug 7, 2015 at 7:32 AM MZMcBride z...@mzmcbride.com wrote:


Matthew Flaschen wrote:

We're in the process of developing a code of conduct for technical
spaces.  This will be binding, and apply to all Wikimedia-related
technical spaces (including but not limited to MediaWiki.org,
Phabricator, Gerrit, technical IRC channels, and Etherpad).

Who's we? This seems to be a pet issue of yours. I'm curious who else is
supportive of this initiative to enact a binding policy.

MZMcBride


What kind of standards for behavior we want and think are acceptable is a
core concern of everyone in the Wikimedia and MediaWiki technical
communities.

This kind of personally-directed and demeaning feedback (This seems to be
a pet issue of yours) is, perhaps ironically, precisely an example of why
it would improve interaction in technical spaces to have some clearer
ground rules.




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Data and Developer Hub protoype

[Isarra Yos]

On 07/07/15 08:07, Quim Gil wrote:

Sorry for my misunderstanding. Then we agree.

Right now the proposal is to improve the API: namespace in mediawiki.org,
instead of creating a new Dev: namespace in mediawiki.org. See and join
https://www.mediawiki.org/wiki/Project:Current_issues#Adding_a_dev_namespace_for_.22Data_and_developer_hub.22_articles_58129

The very initial plan was to have a new site indeed, but that was a long
ago, and I pushed (hard) to go for a solution integrated with mediawiki.org.


Ah, cool. I missed that.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Data and Developer Hub protoype

[Isarra Yos]

On 06/07/15 16:41, Quim Gil wrote:
The problem I have with this reasoning is that we are not proposing a 
different skin for Wikipedia.


This has nothing to do with skins. This is making another new site when 
we already have sites that could serve this purpose, that are already 
/supposed/ to serve this purpose. We have portals on mw.org, on meta, on 
wikitech, and places where the documentation should be... but instead of 
cleaning that up, making the mainpages more informative and useful and 
directing the different types of users to the correct places, filling in 
the information itself, we need another site? Why?

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Data and Developer Hub protoype

[Isarra Yos]

On 26/06/15 21:21, Quim Gil wrote:

Note that probably the complementary side of your frustration is the
frustration of designers and others trying to improve Wikimedia and its
projects, only to find a strong resistance to change almost every time that
fresh ideas are proposed. In our case here, currently we are not very
successful at attracting third party developers to use our APIs, definitely
not at the scale that one would expect considering Wikipedia's relevance.
We welcome ideas and help from people willing to solve this problem. We are
happy to take risks trying solutions, even if that means that we will make
some mistakes along the way.


It should perhaps be noted that this seems a continuation on a general 
trend to avoid learning how to work with the communities and existing 
designs. It may be faster and less frustrating to simply sod off and do 
something new somewhere else, but this does not solve the existing 
problems - all it does is introduce more inconsistencies and more things 
that need to be consolidated later, if they survive at all. Except they 
usually don't, because ignoring what people do and use and expect does 
not lead to practical designs, it leads to things people don't use, 
maintain, or contribute to, which brings us back in part to the 
technical debt associated with having so many different wikis.


But when it comes to working with what already exists, I know from 
experience that this is far from easy, and in fact often incredibly 
frustrating in practice. Thing is, though, we have to - the existing 
products need to be worked with in order to move forward. That's just 
how it is.


As we tend to say about the unsolicited redesigns of (en) wikipedia, 
it's always a lot easier when you don't have to design with reality as a 
constraint. There's a reason we never use any of them.


-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

[Isarra Yos]

On 19/03/15 07:00, Daniel Friesen wrote:

On 2015-03-18 11:31 PM, Isarra Yos wrote:

On 19/03/15 01:42, Danny Horn wrote:

Brad: unfortunately, it's really hard to tell very much from a
conversation
with messages like 3: Post C: reply to Post A. You could do that
with the
old model, the new model or the perfect magic Nobel-Prize-winning
discussion threading still to be discovered, and it would probably look
like nonsense in all three.

We've tried in our testing to pretend that we're having real
conversations,
so we could see whether there's any logical way to get to eight
levels of
nested threading. It's not easy to organize make-believe
conversations, but
if you want to start a thread, I'd be happy to fire up a few sockpuppets
and pretend to talk about something with you.

I'm a little confused. Didn't LQT already solve this problem? Why not
just nest/thread things the same way it does, or how well-formatted
wikitext conversations in general do? That seemed to work fine; the
issues with LQT lay elsewhere, and the issue with wikitext really just
seems to be it all needs to be done manually and users often don't get
it right as a result, hence a good chunk of why we're trying to
replace it in the first place.

-I

Yes, Wikitext conversations did have a threading pattern.

 From what I can see looking at a long discussion on a random FA talkpage
archive it goes like this:
Users indent after each message.
Then when it gets too deep someone starts their message with 0 indentation.
Conversations with larger messages end up reset quicker.

Unfortunately this model cannot be applied to LQT or Flow.



Um... LQT has exactly that model. Yes, you can keep going, but you can 
keep going in wikitext, too, even off the side of the page (which is 
exactly what uncyclopedians do sometimes precisely because they want to 
go off the side of the page because they think it's funny, because let's 
face it, it is funny), but normally you just start a new 
conversation/thread/topic/whatever you want to call it if it goes too far.


There's no way to solve the threading problem for long complex 
conversations directly because while you need that threading in order to 
discern who is responding to whom, or even what is going on in general, 
there is always only so much space on the screen. We accept this, we 
outdent, or we refocus with a new section after it gets too long/we feel 
like putting our usernames in the ToC, or we even wind up just having 
everyone involved creating their own thread from the start (because 
really, we all want our usernames in the ToC), but the problem of how to 
handle it has been solved in practice.


-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

[Isarra Yos]

On 19/03/15 01:42, Danny Horn wrote:

Brad: unfortunately, it's really hard to tell very much from a conversation
with messages like 3: Post C: reply to Post A. You could do that with the
old model, the new model or the perfect magic Nobel-Prize-winning
discussion threading still to be discovered, and it would probably look
like nonsense in all three.

We've tried in our testing to pretend that we're having real conversations,
so we could see whether there's any logical way to get to eight levels of
nested threading. It's not easy to organize make-believe conversations, but
if you want to start a thread, I'd be happy to fire up a few sockpuppets
and pretend to talk about something with you.


I'm a little confused. Didn't LQT already solve this problem? Why not 
just nest/thread things the same way it does, or how well-formatted 
wikitext conversations in general do? That seemed to work fine; the 
issues with LQT lay elsewhere, and the issue with wikitext really just 
seems to be it all needs to be done manually and users often don't get 
it right as a result, hence a good chunk of why we're trying to replace 
it in the first place.


-I

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Starting conversion of LiquidThreads to Flow at mediawiki.org

[Isarra Yos]

On 17/03/15 15:32, Brad Jorsch (Anomie) wrote:

On Tue, Mar 17, 2015 at 11:17 AM, Marc A. Pelletier m...@uberbox.org
wrote:


Indentation is a crappy workaround for when your communication system
does not support a sane threading model - it isn't a threading model or
a substitute for one.


Err, what's the threading model in Flow's UI? Or Facebook, phpbb, and so
on, or whatever other site you were referring to that knitting grandmothers
use? Can you really call not having any (user-visible) threading model a
threading model?

 From what I've seen of those types of discussions, people have to either
explicitly refer back to whatever they're replying to (e.g. Twitter tries
to, and doesn't very well from what I've seen), quote whatever they're
replying to (e.g. phpbb, email (especially how Gmail renders it)), and/or
just deal with having to dig through an undifferentiated pile of replies to
find the ones that might be replying to the post they're interested in
(phpbb, Facebook).


On a lot of sites they can also get away with a lack of threading 
because the discussions themselves are relatively inactive, where you 
don't have multiple people jumping in and replying to different points. 
Such inactivity isn't the case on many wikis, where discussion is more 
key to their functionality, and certainly shouldn't be an assumption here.


- I


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor proxy with blinded tokens

[Isarra Yos]

On 10/03/15 16:00, Chris Steipp wrote:

On Tue, Mar 10, 2015 at 7:45 AM, Kevin Wayne Williams 
kwwilli...@kwwilliams.com wrote:


Chris Steipp schreef op 2015/03/10 om 7:23:


Jacob Applebaum made another remark about editing Wikipedia via tor this
morning. Since it's been a couple months since the last tor bashing
thread,
I wanted to throw out a slightly more modest proposal to see what people
think.


The easiest way to prevent a series of Tor bashing threads is to not make
Tor promoting threads. At least for English Wikipedia, there is no reason
now or in the conceivable future to permit, much less endorse or formalise,
editing via Tor.



I believe there is a strong reason for it.

Even if you use https for every connection to Wikipedia, traffic analysis
currently makes finding out what you're reading fairly easy. From a risk
perspective, if a user wants to edit Wikipedia on a subject and from a
location that could endanger themselves, I would much prefer they edit via
tor than rely on the WMF to protect their identity. We spend a lot of
effort protecting the privacy of our users, but all it would take is
compromising the right server in our cluster, and correlating which IP is
editing as which user becomes very easy. Promoting the user of Tor lets us
push some of the risk onto the Tor team, who are both experts in this and
have a strong motivation to make it work correctly.

So I think there is both a responsibility and a benefit (to the WMF) in
allowing editing via Tor.


Aye, even if people don't like something, that doesn't mean it should be 
avoided. For whatever it's worth, personally I think this sounds pretty 
awesome, and even if it doesn't work, it would be worth the risk to try 
it, because if it does the benefit could be enormous.


-I


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l