Mailing List Archive

1 2 3 4 5 6  View All
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
You can start by asking around in your own circle of aquaintance, and I'll
bet that such research will make you quickly realize that hard stats will
be very hard to discover, since in my circle, most of the women I know are
married and though their household contains a desktop, the desktop is owned
and operated by their husband, not them. In any official questionaire
served to them however, they are probably asked whether their household has
one, not whether they themselves are the primary user of one.


On Thu, Aug 28, 2014 at 8:29 AM, Fæ <faewik@gmail.com> wrote:

> On 28 August 2014 12:56, Jane Darnell <jane023@gmail.com> wrote:
> > I agree with Gerard, and would add that a good portion of the new
> readers and "missing female editors" do not own or operate a desktop and
> are only available on mobile and tablet, so this is not only where the new
> readers are, but also where the "first edit" experience is for most women
> (and sadly, a corollary to that is that they don't try again after their
> first edit failure).
> mechanics of how this would work. We could do it, but reforming WMF is
>
> Every year we see many expensive surveys and funded research on women
> and Wikipedia, so presumably there are some verifiable statistics to
> support Jane's assertion that a significant difference between readers
> of Wikipedia is that men are significantly more likely to own or have
> access to a desktop compared to women that they might edit from.
>
> Can someone provide a link to the research that demonstrates this is
> more than apocryphal?
>
> Thanks,
> Fae
> --
> faewik@gmail.com https://commons.wikimedia.org/wiki/User:Fae
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
Hi g,
Thanks for calling me an old power editor. I suggest you try to make an
edit to a WIkimedia project of choice (e.g. add a photo to an existing
article) on a desktop, then do the same on a mobile smartphone, and then
report back here.
Jane


On Thu, Aug 28, 2014 at 8:50 AM, ; ) <box@gmx.at> wrote:

> Hey Jane,
>
> as the desktop is sometimes characterised only as a legacy input
> device for old power editors, while the reading is done from mobile
> devices, often in the form of mash-ups and geo-apps, why is a
> compromise so hard to achieve?
>
> One solution that pops up would be to cache the content (as most
> useful wikipedia apps do anyway) in a light mobile version, while
> allowing an existing group of useful contributors their little island.
> This feeling of belonging makes those editors do all the dirty jobs
> noone wants to do on a regular basis - most of it fact and copyright
> checks that make the content so good it is useful to readers and keeps
> them coming back.
>
> You could create a newbie-friendly version with rich text editing
> optimised for different devices, more customisation in an easy way...
> if we are realistic that would be the way to go anyway, as you can
> start out much easier and with less baggage - and would be able to
> target groups on an individual basis in the process, too. When they
> evolve in the ("bitter-vet") power users and editors, they can switch
> to the still more useful but less pretty interfaces for large data
> manipulation, that the desktop offers.
>
> Shouldn't the focus be on the readers that read the content AND
> the editors that produce interesting content to make readers come
> back? Gerard in this regard seems to have a somehow bi-polar view of
> this process with his us - them characterisation ("the
> community that remains with the WMF will lose all of the
> separatists"). They will just no longer do the hard stuff, if they
> feel that they are not welcome - and finding such people is hard,
> really hard (speaking as a long-term gutenberg proof-reader).
>
> cheers,
>
> g
>
>
>
>
>
> Thursday, August 28, 2014, 1:56:38 PM, you wrote:
>
> > I agree with Gerard, and would add that a good portion of the new
> > readers and "missing female editors" do not own or operate a desktop
> > and are only available on mobile and tablet, so this is not only
> > where the new readers are, but also where the "first edit"
> > experience is for most women (and sadly, a corollary to that is that
> > they don't try again after their first edit failure).
>
> > Sent from my iPad
>
> > On Aug 28, 2014, at 4:30 AM, Gerard Meijssen
> > <gerard.meijssen@gmail.com> wrote:
>
> >> Hoi,
> >> Such separate hostings and ownership would not be that much of a risk to
> >> the WMF. The challenges will be first and foremost with the separatists;
> >> then again it is firmly their choice. There will be benefits on both
> sides
> >> as well. The community that remains with the WMF will lose all of the
> >> separatists and they will sadly see some of them go. It will allow for
> the
> >> influx of new people and new ideas. The people that go will get a
> reality
> >> check; they will find out to what extend the things they fought battles
> >> over are actually worth it. I am sure that both communities will
> benefit.
> >>
> >> When the people who talk about going their own way rethink their stance
> and
> >> start considering the other side of the coin it may lead to an
> equilibrium.
> >> However, the Visual Editor is not the only thing that will change the
> look
> >> and feel there is so much more happening and at that, a single community
> >> only considering its own is in effect a cul de sac.
> >>
> >> When numbers of readers are to be our main worry, it should be obvious
> by
> >> now that both for editing and reading they are happening on the mobile,
> the
> >> tablet. This is were our new readers are happening. Maybe not
> necessarily
> >> in Europe but certainly in the global south. They have by definition a
> >> different mode of operandi and consequently much of our current
> bickering
> >> is only distracting from putting our efforts in welcoming our newbies
> and
> >> building a full fledged environment for them.
> >> Thanks,
> >> GerardM
>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
On Thu, Aug 28, 2014 at 6:55 AM, Jane Darnell <jane023@gmail.com> wrote:

> You can start by asking around in your own circle of aquaintance, and I'll
> bet that such research will make you quickly realize that hard stats will
> be very hard to discover, since in my circle, most of the women I know are
> married and though their household contains a desktop, the desktop is owned
> and operated by their husband, not them.


I use (primarily) my carbon-fiber beast of a desktop, with my wife using
primarily a laptop. The use of "desktop" to (presumably) refer to laptops
is very confusing here, and would make accurate data gathering more
difficult, not less.

We both use a tablet and/or phone, but only when away from the real
machines or for very quick stuff. Doing real work on a tablet/phone is a
pain in the ass, not just on Wikipedia but for anything. If I have a decent
amount of text to type, I'll take a real keyboard and two monitors, not one
"keyboard" taking up half of a 4" screen, thanks very much. I can't even
imagine trying to make a significant edit to an article on a phone, no
matter how good we make the interface. Even in a visual editor, articles
require the entry of a lot of text, not the Facebook-style "I'm here,
having a great time!"

That's a usage pattern that's very common with couples in my experience.
It's apparently not in yours. That's why the plural of anecdote is not
evidence.



> In any official questionaire
> served to them however, they are probably asked whether their household has
> one, not whether they themselves are the primary user of one.
>

Why would they be? If we're trying to determine use patterns, it's silly to
ask about the simple presence of something, but that's easy to fix.

"What device do you primarily use when accessing the Internet?"
(Alternatively, or as a followup, "What type of device do you routinely use
to access the Internet? Check all that apply.")

[ ] A desktop computer
[ ] A laptop or notebook computer
[ ] A tablet or smartphone

Not that hard to design a question that addresses the user directly, by not
just access to a given device but actual use of it. If we need that data,
we ought to actually gather it.


>
>
> On Thu, Aug 28, 2014 at 8:29 AM, Fæ <faewik@gmail.com> wrote:
>
> > On 28 August 2014 12:56, Jane Darnell <jane023@gmail.com> wrote:
> > > I agree with Gerard, and would add that a good portion of the new
> > readers and "missing female editors" do not own or operate a desktop and
> > are only available on mobile and tablet, so this is not only where the
> new
> > readers are, but also where the "first edit" experience is for most women
> > (and sadly, a corollary to that is that they don't try again after their
> > first edit failure).
> > mechanics of how this would work. We could do it, but reforming WMF is
> >
> > Every year we see many expensive surveys and funded research on women
> > and Wikipedia, so presumably there are some verifiable statistics to
> > support Jane's assertion that a significant difference between readers
> > of Wikipedia is that men are significantly more likely to own or have
> > access to a desktop compared to women that they might edit from.
> >
> > Can someone provide a link to the research that demonstrates this is
> > more than apocryphal?
> >
> > Thanks,
> > Fae
> > --
> > faewik@gmail.com https://commons.wikimedia.org/wiki/User:Fae
> >
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> >
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
I should explain that I am a resident of the Netherlands, where we have a
central statistics bureau which includes census statistics that you can
query for free and download your own datasets in xls format. As a data
analyst I have spent lots of time gathering such data and reporting on it
in Microsoft Excel, which is still my tool of choice. I frequently read
news stories about published reports that misinterpret data and I sometimes
will check the cited data against published open data sources. I base my
conclusions on that experience as well as my personal experience. It may
also be helpful to explain that many of my friends are or were stay-at-home
moms. I agree that most of the questions served in public surveys do not
seem to be formulated by data analysts.

I am proud to say that after a rocky start I can finally edit Wikipedia and
Wikimedia Commons on my iPad, but I couldn't tell you what I did to set it
up. I have successfully uploaded several photos with my android app to Wiki
Loves Monuments. I do know that I tried to make an edit on someone else's
iPhone this week and was stopped short by the mobile interface.


On Thu, Aug 28, 2014 at 9:35 AM, Todd Allen <toddmallen@gmail.com> wrote:

> On Thu, Aug 28, 2014 at 6:55 AM, Jane Darnell <jane023@gmail.com> wrote:
>
> > You can start by asking around in your own circle of aquaintance, and
> I'll
> > bet that such research will make you quickly realize that hard stats will
> > be very hard to discover, since in my circle, most of the women I know
> are
> > married and though their household contains a desktop, the desktop is
> owned
> > and operated by their husband, not them.
>
>
> I use (primarily) my carbon-fiber beast of a desktop, with my wife using
> primarily a laptop. The use of "desktop" to (presumably) refer to laptops
> is very confusing here, and would make accurate data gathering more
> difficult, not less.
>
> We both use a tablet and/or phone, but only when away from the real
> machines or for very quick stuff. Doing real work on a tablet/phone is a
> pain in the ass, not just on Wikipedia but for anything. If I have a decent
> amount of text to type, I'll take a real keyboard and two monitors, not one
> "keyboard" taking up half of a 4" screen, thanks very much. I can't even
> imagine trying to make a significant edit to an article on a phone, no
> matter how good we make the interface. Even in a visual editor, articles
> require the entry of a lot of text, not the Facebook-style "I'm here,
> having a great time!"
>
> That's a usage pattern that's very common with couples in my experience.
> It's apparently not in yours. That's why the plural of anecdote is not
> evidence.
>
>
>
> > In any official questionaire
> > served to them however, they are probably asked whether their household
> has
> > one, not whether they themselves are the primary user of one.
> >
>
> Why would they be? If we're trying to determine use patterns, it's silly to
> ask about the simple presence of something, but that's easy to fix.
>
> "What device do you primarily use when accessing the Internet?"
> (Alternatively, or as a followup, "What type of device do you routinely use
> to access the Internet? Check all that apply.")
>
> [ ] A desktop computer
> [ ] A laptop or notebook computer
> [ ] A tablet or smartphone
>
> Not that hard to design a question that addresses the user directly, by not
> just access to a given device but actual use of it. If we need that data,
> we ought to actually gather it.
>
>
> >
> >
> > On Thu, Aug 28, 2014 at 8:29 AM, Fæ <faewik@gmail.com> wrote:
> >
> > > On 28 August 2014 12:56, Jane Darnell <jane023@gmail.com> wrote:
> > > > I agree with Gerard, and would add that a good portion of the new
> > > readers and "missing female editors" do not own or operate a desktop
> and
> > > are only available on mobile and tablet, so this is not only where the
> > new
> > > readers are, but also where the "first edit" experience is for most
> women
> > > (and sadly, a corollary to that is that they don't try again after
> their
> > > first edit failure).
> > > mechanics of how this would work. We could do it, but reforming WMF is
> > >
> > > Every year we see many expensive surveys and funded research on women
> > > and Wikipedia, so presumably there are some verifiable statistics to
> > > support Jane's assertion that a significant difference between readers
> > > of Wikipedia is that men are significantly more likely to own or have
> > > access to a desktop compared to women that they might edit from.
> > >
> > > Can someone provide a link to the research that demonstrates this is
> > > more than apocryphal?
> > >
> > > Thanks,
> > > Fae
> > > --
> > > faewik@gmail.com https://commons.wikimedia.org/wiki/User:Fae
> > >
> > > _______________________________________________
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > Wikimedia-l@lists.wikimedia.org
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> > >
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> >
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
On 8/28/14, 2:55 PM, Jane Darnell wrote:
> You can start by asking around in your own circle of aquaintance, and I'll
> bet that such research will make you quickly realize that hard stats will
> be very hard to discover, since in my circle, most of the women I know are
> married and though their household contains a desktop, the desktop is owned
> and operated by their husband, not them.

This kind of analysis varies quite widely by country and community, so I
would be wary of making wide generalizations. You say that "most of the
women I know are married", but your experience would be unusual here
(Denmark), because the hard statistics show that most adult women (and
men) in the country are not married. Clearly other countries' statistics
(and statistics for demographic subsets of the same) will show other
numbers.

Best,
Mark


_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
On 30/08/2014, Mark <delirium@hackish.org> wrote:
> On 8/28/14, 2:55 PM, Jane Darnell wrote:
>> You can start by asking around in your own circle of aquaintance, and I'll
>> bet that such research will make you quickly realize that hard stats will
>> be very hard to discover, since in my circle, most of the women I know are
>> married and though their household contains a desktop, the desktop is
>> owned
>> and operated by their husband, not them.
>
> This kind of analysis varies quite widely by country and community, so I
> would be wary of making wide generalizations. You say that "most of the
> women I know are married", but your experience would be unusual here
> (Denmark), because the hard statistics show that most adult women (and
> men) in the country are not married. Clearly other countries' statistics
> (and statistics for demographic subsets of the same) will show other
> numbers.
>
> Best,
> Mark

I know widowers, unmarried people and same-sex married couples and
almost no heterosexual married couples; hetero marriage seems a lot
less popular these days. All the women I know either have their own
machine or are uninterested in accessing the internet.

I honestly cannot think of any women in my circle of friends and
acquaintances that rely on a husband or partner to access the
internet, it is something I would find truly weird and would worry
that the husband was being over-controlling. Though I have one friend
that relies on free public internet for his access for cost reasons.

I have a relative stuck long term in a London hospital where they
charge her 7 quid a day for internet access, which she cannot afford
so she relies on visitors to do stuff on the internet and will spend
her days reading books instead; I find that particularly shocking and
I have never heard of Wikimedia being a champion for the right to free
internet in hospitals - in the 1st world, that should be a lot easier
to negotiate than the internet zero stuff in the developing world.

Fae
--
faewik@gmail.com https://commons.wikimedia.org/wiki/User:Fae

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
Hoi,
Once people decide to leave, the situation is quite stark. There are those
that do and there are those that do not. In my previous mail it should have
been clear that I described the situation after the departure of many
malcontents. That IS a bi-polar state obviously.

That is not to say that the desktop is not important. That is not to say
that the tooling people use for advanced tasks is not important.

The point is very much that in a changing environment, tools that rely on a
stable environment are not stable by definition.You cannot insist on such
stability either. You cannot even insist that the tools that are usable are
well designed and easily adaptable to change. Take for instance gadgets. A
successful gadget it copied from Wiki to Wiki and in the process it needs
to be localised and preferably it should take advantage of any future
development. Work has been done to accomplish internationalisation and a
more centralised development model. Once this is finished one gadget may
exist on hundreds of wikis. That is a maintenance scenario.

Another disaster (IMHO) is that the wikidatafication of Commons is NOT the
wikidatafication of multi-media files. The point is NOT that Commons needs
to be done first, the point is that once Commons is "done", all other Wikis
who have local uploads of multi-media files need to be wikidatified as
well. There is NO reason why the result of the compromises reached in the
Commons process will "obviously" fit elsewhere.When it is clear from the
start that Commons is ONLY the first to be wikidatified, there is a better
chance of getting involvement from people who feel strongly about the
reasons why their Wiki does not upload to Commons. Their involvement will
be a reality check to the Commoners that their POV is exactly that.

The Multimedia Viewer did a good job at showing the extend to which local
edge cases like the German templates Fabrice mentioned in a recent list of
accomplishments pose problems for central development. They exist, they
need to be fixed and preferably only once. If not they will change in the
future again.

Several volunteers like Roan became employees of the WMF exactly because
they were pivotal in the dissemination of technology. When you look at the
work they do, bringing thing back together IS one aspect of their
accomplishments.

Things will break and when we do not want drama again and again, we need to
embrace change and accept that particularly high end tools will break down
regularly. My experience at Labs shows exactly that and it shows that as
things get better organised downtime becomes less of an issue. It also
shows that as our environment becomes more stable, the tools become more
sophisticated and consequently more in need of a well architected
environment.

What we have is the old problem of retro fitting architecture where chaos
reigned supreme. We can do this and this "we" is most definitely an
invitation to every Wikimedian.
Thanks,
GerardM


On 28 August 2014 14:50, ; ) <box@gmx.at> wrote:

> Hey Jane,
>
> as the desktop is sometimes characterised only as a legacy input
> device for old power editors, while the reading is done from mobile
> devices, often in the form of mash-ups and geo-apps, why is a
> compromise so hard to achieve?
>
> One solution that pops up would be to cache the content (as most
> useful wikipedia apps do anyway) in a light mobile version, while
> allowing an existing group of useful contributors their little island.
> This feeling of belonging makes those editors do all the dirty jobs
> noone wants to do on a regular basis - most of it fact and copyright
> checks that make the content so good it is useful to readers and keeps
> them coming back.
>
> You could create a newbie-friendly version with rich text editing
> optimised for different devices, more customisation in an easy way...
> if we are realistic that would be the way to go anyway, as you can
> start out much easier and with less baggage - and would be able to
> target groups on an individual basis in the process, too. When they
> evolve in the ("bitter-vet") power users and editors, they can switch
> to the still more useful but less pretty interfaces for large data
> manipulation, that the desktop offers.
>
> Shouldn't the focus be on the readers that read the content AND
> the editors that produce interesting content to make readers come
> back? Gerard in this regard seems to have a somehow bi-polar view of
> this process with his us - them characterisation ("the
> community that remains with the WMF will lose all of the
> separatists"). They will just no longer do the hard stuff, if they
> feel that they are not welcome - and finding such people is hard,
> really hard (speaking as a long-term gutenberg proof-reader).
>
> cheers,
>
> g
>
>
>
>
>
> Thursday, August 28, 2014, 1:56:38 PM, you wrote:
>
> > I agree with Gerard, and would add that a good portion of the new
> > readers and "missing female editors" do not own or operate a desktop
> > and are only available on mobile and tablet, so this is not only
> > where the new readers are, but also where the "first edit"
> > experience is for most women (and sadly, a corollary to that is that
> > they don't try again after their first edit failure).
>
> > Sent from my iPad
>
> > On Aug 28, 2014, at 4:30 AM, Gerard Meijssen
> > <gerard.meijssen@gmail.com> wrote:
>
> >> Hoi,
> >> Such separate hostings and ownership would not be that much of a risk to
> >> the WMF. The challenges will be first and foremost with the separatists;
> >> then again it is firmly their choice. There will be benefits on both
> sides
> >> as well. The community that remains with the WMF will lose all of the
> >> separatists and they will sadly see some of them go. It will allow for
> the
> >> influx of new people and new ideas. The people that go will get a
> reality
> >> check; they will find out to what extend the things they fought battles
> >> over are actually worth it. I am sure that both communities will
> benefit.
> >>
> >> When the people who talk about going their own way rethink their stance
> and
> >> start considering the other side of the coin it may lead to an
> equilibrium.
> >> However, the Visual Editor is not the only thing that will change the
> look
> >> and feel there is so much more happening and at that, a single community
> >> only considering its own is in effect a cul de sac.
> >>
> >> When numbers of readers are to be our main worry, it should be obvious
> by
> >> now that both for editing and reading they are happening on the mobile,
> the
> >> tablet. This is were our new readers are happening. Maybe not
> necessarily
> >> in Europe but certainly in the global south. They have by definition a
> >> different mode of operandi and consequently much of our current
> bickering
> >> is only distracting from putting our efforts in welcoming our newbies
> and
> >> building a full fledged environment for them.
> >> Thanks,
> >> GerardM
>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
Hi all,

Thank you Erik for your mail. It shows that the WMF is willing to
discuss rather than to impose its solution.

I am really shocked that the dispute reaches that level of
confrontation, and although some community members have a hard stance,
this is largely due to WMF actions, specially the creation of the
"superprotect" right. This is the worst possible step the WMF could
make to find a solution for this issue.

Initially I was quite neutral about the MediaWiever, but I became
increasingly skeptical. IMO it is hardly a priority, even for readers.
Even if I am a long term contributor of Wikimedia projects, I am also
a heavy reader of Wikipedia. I think that if a feature is refused in
masse for the most active contributors, there is something wrong
either in the feature itself, or in the way it is proposed to the
projects. The WMF can certainly bring useful new additions in term of
software development, but the implementation has to be done in a
partnership with volunteer contributors. I cannot understand that the
WMF in spite of its multi-million dollars budget is not able to
convince volunteer contributors that the new feature is beneficial to
the projects, either because it is technically very good, or that even
with some shortcomings, it would improve the reading experience.

I am quite willing to test beta software, and I think there is no
urgency to impose the MediaWiever now to everybody. I could be done
after some time, when all issues have been sorted out. In term of
media management, the most urgent and important thing is to fix the
UploadWizard. Viewing images with Mediawiki may not be optimal, but it
is not broken. The UploadWizard is broken.

Regards,

Yann

2014-08-20 0:42 GMT+05:30 Erik Moeller <erik@wikimedia.org>:
> Hi folks,
>
> This is a response to Martin's note here:
> https://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073936.html
>
> .. and also a more general update on the next steps regarding disputes
> about deployments. As you may have seen, Lila has also posted an
> update to her talk page, here:
> https://meta.wikimedia.org/wiki/User_talk:LilaTretikov#Working_Together
>
> I want to use this opportunity to respond to Martin's and other
> people's criticisms, and to talk about next steps from WMF’s
> perspective following discussions with Lila and the team. I’m also
> sending a copy of this note to all the stewards, to better involve
> them in the process going forward.
>
> I am -- genuinely -- sorry that this escalation occurred. We would
> have preferred to avoid it.
>
> I would like to recap how we find ourselves in this situation: As
> early as July, we stated that the Wikimedia Foundation reserves the
> right to determine the final configuration of the MediaViewer feature,
> and we explicitly included MediaWiki: namespace hacks in that
> statement. [1] When an admin implemented a hack to disable
> MediaViewer, another local admin reverted the edit. The original admin
> reinstated it. We then reverted it with a clear warning that we may
> limit editability of the page. [2] The original admin reinstated the
> hack. This is when we protected the page.
>
> Because all admins have equal access to the MediaWiki: namespace,
> short of desysopping, there are few mechanisms to actually prevent
> edit wars about the user experience for millions of readers.
> Desysopping actions could have gotten just as messy -- and we felt
> that waiting for a "better hack" to come along (the likeliest eventual
> outcome of doing nothing) or disabling the feature ourselves would not
> be any better, either from a process or outcome standpoint.
>
> Our processes clearly need to be improved to avoid these situations in
> the future. We recognize that simply rejecting a community request
> rather than resolving a conflict together is not the right answer.
> We’ve been listening to feedback, and we’ve come to the following
> conclusions:
>
> - We intend to undertake a review of our present processes immediately
> and propose a new approach that allows for feedback at more critical
> and relevant junctures in the next 90 days. This will be a transparent
> process that includes your voices.
>
> - As the WMF, we need to improve the process for managing changes that
> impact all users. That includes the MediaWiki: namespace. For WMF to
> fulfill its role of leading consistent improvements to the user
> experience across Wikimedia projects, we need to be able to review
> code and manage deployments. This can be done in partnership with
> trusted volunteers, but WMF needs to be able to make an ultimate
> determination after receiving community feedback regarding production
> changes that impact all users.
>
> - We are prepared to unprotect MediaWiki:Common.js on German Wikipedia
> and enter constructive, open-ended conversations about the way
> forward, provided we can mutually agree to do so on the basis of the
> current consistent configuration -- for now. We would like to request
> a moratorium on any attempts to disable the feature during this
> conflict resolution process. The goal would be to make a final,
> cross-wiki determination regarding this specific feature, in
> partnership with the community, within at most 90 days.
>
> With regard to the German Wikipedia situation, we’d like to know if
> stewards want to at all be involved in this process: In a situation
> like this, it can be helpful to have a third party support the
> conversation. Stewards are accountable to "valid community consensus
> within the bounds of the Foundation's goals" [3], which seems to be
> precisely the intersection of concerns at issue here. We would like to
> suggest an IRC meeting with stewards ASAP to talk about the specific
> question of stewards’ involvement, if any. If stewards prefer not to
> be involved, we understand, but it's probably a good idea to have a
> sync-up conversation regardless.
>
> I hope we can move forward in good faith from here, and find better
> ways to work together. As Lila has expressed, we believe there is a
> need for a clear understanding of our role. It is as follows:
>
> Managing software development, site configuration and deployment is a
> core WMF responsibility. The community leads in the development of
> content; the Wikimedia Foundation leads in the development of
> technology.
>
> Because these processes are deeply interdependent, we need to develop
> better protocols for timely feedback and resolution of disagreements.
> At the same time Lila’s and the Board’s statements make it very clear
> that the WMF will not accept RfCs or votes as the sole determining
> factor in global software deployments.
>
> This means that technology and UX changes should not be decided by
> vote or poll and then disabled at-will: where we disagree, we need to
> talk to each other (and yes, that means a more judicious application
> of RESOLVED WONTFIX on our end, as well!). We need to ensure a
> process where the community voice is heard earlier at critical
> junctions in the product development. All of this is consistent with
> the principle of "shared power" articulated in the Guiding Principles
> [4] approved by the Board of Trustees.
>
> At the same time, as noted above and earlier, the superprotection
> feature should be replaced with a better mechanism for code review and
> deployment in the MediaWiki: namespace. This is discussed in [5] and
> ideas and suggestions are welcome. Let’s be upfront about control
> structures for production changes to avoid misunderstandings and
> ambiguity in the future.
>
> We are exploring options on how to improve dispute resolution
> mechanisms -- whether it’s e.g. a standing working group or a better
> protocol for responding to RfCs and engaging in discussions. We've
> started a brainstorming page, here, which we hope will usefully inform
> the process of conflict resolution regarding German Wikipedia, as
> well, so we can arrive at a more concrete conflict resolution process
> soon. Your thoughts/suggestions are welcome, so we can (in NPOV style)
> look at different possibilities (e.g. workgroups, committees, votes,
> surveys) that have been discussed in the past:
> https://meta.wikimedia.org/wiki/Community_Engagement_(Product)/Process_ideas
>
> We’re absolutely not saying that WMF simply wants to be able to
> enforce its decisions: we completely understand there need to be
> mechanisms for the community to influence decisions and outcomes at
> all stages of the development and release of software. We need to
> arrive at this process together.
>
> Again, we are sorry that this escalation occurred - and we hope we can
> move forward constructively from here.
>
> Sincerely,
>
> Erik
>
>
> [1] https://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:Meinungsbilder/Medienbetrachter&diff=prev&oldid=132469014
>
> [2] https://de.wikipedia.org/w/index.php?title=MediaWiki_Diskussion:Common.js&diff=132938244&oldid=132935469
>
> [3] https://meta.wikimedia.org/wiki/Stewards_policy
>
> [4] https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Guiding_Principles#Shared_power
>
> [5] https://bugzilla.wikimedia.org/show_bug.cgi?id=69445
>
>
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
Legal position:

I have seen it claimed by legal and repeated here by Erik that the
"reasonableness" criteria means that we do not have to worry about the
CCBYSA-3.0 clause that says all copyright holders need equal attribution.
This is simply not so:

"The credit required by this Section 4(c) may be implemented *in any
reasonable manner; provided, however, that *in the case of a Adaptation or
Collection,* at a minimum such credit will appear*, if a credit for all
contributing authors of the Adaptation or Collection appears, then as part
of these credits and* in a manner at least as prominent as the credits for
the other contributing authors*."

There is no wriggle room here. * provided however that* means the following
is compulsory, and not subject to the lenience of the previous phraseology.




On 31 August 2014 16:59, Yann Forget <yannfo@gmail.com> wrote:

> Hi all,
>
> Thank you Erik for your mail. It shows that the WMF is willing to
> discuss rather than to impose its solution.
>
> I am really shocked that the dispute reaches that level of
> confrontation, and although some community members have a hard stance,
> this is largely due to WMF actions, specially the creation of the
> "superprotect" right. This is the worst possible step the WMF could
> make to find a solution for this issue.
>
> Initially I was quite neutral about the MediaWiever, but I became
> increasingly skeptical. IMO it is hardly a priority, even for readers.
> Even if I am a long term contributor of Wikimedia projects, I am also
> a heavy reader of Wikipedia. I think that if a feature is refused in
> masse for the most active contributors, there is something wrong
> either in the feature itself, or in the way it is proposed to the
> projects. The WMF can certainly bring useful new additions in term of
> software development, but the implementation has to be done in a
> partnership with volunteer contributors. I cannot understand that the
> WMF in spite of its multi-million dollars budget is not able to
> convince volunteer contributors that the new feature is beneficial to
> the projects, either because it is technically very good, or that even
> with some shortcomings, it would improve the reading experience.
>
> I am quite willing to test beta software, and I think there is no
> urgency to impose the MediaWiever now to everybody. I could be done
> after some time, when all issues have been sorted out. In term of
> media management, the most urgent and important thing is to fix the
> UploadWizard. Viewing images with Mediawiki may not be optimal, but it
> is not broken. The UploadWizard is broken.
>
> Regards,
>
> Yann
>
> 2014-08-20 0:42 GMT+05:30 Erik Moeller <erik@wikimedia.org>:
> > Hi folks,
> >
> > This is a response to Martin's note here:
> >
> https://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073936.html
> >
> > .. and also a more general update on the next steps regarding disputes
> > about deployments. As you may have seen, Lila has also posted an
> > update to her talk page, here:
> > https://meta.wikimedia.org/wiki/User_talk:LilaTretikov#Working_Together
> >
> > I want to use this opportunity to respond to Martin's and other
> > people's criticisms, and to talk about next steps from WMF’s
> > perspective following discussions with Lila and the team. I’m also
> > sending a copy of this note to all the stewards, to better involve
> > them in the process going forward.
> >
> > I am -- genuinely -- sorry that this escalation occurred. We would
> > have preferred to avoid it.
> >
> > I would like to recap how we find ourselves in this situation: As
> > early as July, we stated that the Wikimedia Foundation reserves the
> > right to determine the final configuration of the MediaViewer feature,
> > and we explicitly included MediaWiki: namespace hacks in that
> > statement. [1] When an admin implemented a hack to disable
> > MediaViewer, another local admin reverted the edit. The original admin
> > reinstated it. We then reverted it with a clear warning that we may
> > limit editability of the page. [2] The original admin reinstated the
> > hack. This is when we protected the page.
> >
> > Because all admins have equal access to the MediaWiki: namespace,
> > short of desysopping, there are few mechanisms to actually prevent
> > edit wars about the user experience for millions of readers.
> > Desysopping actions could have gotten just as messy -- and we felt
> > that waiting for a "better hack" to come along (the likeliest eventual
> > outcome of doing nothing) or disabling the feature ourselves would not
> > be any better, either from a process or outcome standpoint.
> >
> > Our processes clearly need to be improved to avoid these situations in
> > the future. We recognize that simply rejecting a community request
> > rather than resolving a conflict together is not the right answer.
> > We’ve been listening to feedback, and we’ve come to the following
> > conclusions:
> >
> > - We intend to undertake a review of our present processes immediately
> > and propose a new approach that allows for feedback at more critical
> > and relevant junctures in the next 90 days. This will be a transparent
> > process that includes your voices.
> >
> > - As the WMF, we need to improve the process for managing changes that
> > impact all users. That includes the MediaWiki: namespace. For WMF to
> > fulfill its role of leading consistent improvements to the user
> > experience across Wikimedia projects, we need to be able to review
> > code and manage deployments. This can be done in partnership with
> > trusted volunteers, but WMF needs to be able to make an ultimate
> > determination after receiving community feedback regarding production
> > changes that impact all users.
> >
> > - We are prepared to unprotect MediaWiki:Common.js on German Wikipedia
> > and enter constructive, open-ended conversations about the way
> > forward, provided we can mutually agree to do so on the basis of the
> > current consistent configuration -- for now. We would like to request
> > a moratorium on any attempts to disable the feature during this
> > conflict resolution process. The goal would be to make a final,
> > cross-wiki determination regarding this specific feature, in
> > partnership with the community, within at most 90 days.
> >
> > With regard to the German Wikipedia situation, we’d like to know if
> > stewards want to at all be involved in this process: In a situation
> > like this, it can be helpful to have a third party support the
> > conversation. Stewards are accountable to "valid community consensus
> > within the bounds of the Foundation's goals" [3], which seems to be
> > precisely the intersection of concerns at issue here. We would like to
> > suggest an IRC meeting with stewards ASAP to talk about the specific
> > question of stewards’ involvement, if any. If stewards prefer not to
> > be involved, we understand, but it's probably a good idea to have a
> > sync-up conversation regardless.
> >
> > I hope we can move forward in good faith from here, and find better
> > ways to work together. As Lila has expressed, we believe there is a
> > need for a clear understanding of our role. It is as follows:
> >
> > Managing software development, site configuration and deployment is a
> > core WMF responsibility. The community leads in the development of
> > content; the Wikimedia Foundation leads in the development of
> > technology.
> >
> > Because these processes are deeply interdependent, we need to develop
> > better protocols for timely feedback and resolution of disagreements.
> > At the same time Lila’s and the Board’s statements make it very clear
> > that the WMF will not accept RfCs or votes as the sole determining
> > factor in global software deployments.
> >
> > This means that technology and UX changes should not be decided by
> > vote or poll and then disabled at-will: where we disagree, we need to
> > talk to each other (and yes, that means a more judicious application
> > of RESOLVED WONTFIX on our end, as well!). We need to ensure a
> > process where the community voice is heard earlier at critical
> > junctions in the product development. All of this is consistent with
> > the principle of "shared power" articulated in the Guiding Principles
> > [4] approved by the Board of Trustees.
> >
> > At the same time, as noted above and earlier, the superprotection
> > feature should be replaced with a better mechanism for code review and
> > deployment in the MediaWiki: namespace. This is discussed in [5] and
> > ideas and suggestions are welcome. Let’s be upfront about control
> > structures for production changes to avoid misunderstandings and
> > ambiguity in the future.
> >
> > We are exploring options on how to improve dispute resolution
> > mechanisms -- whether it’s e.g. a standing working group or a better
> > protocol for responding to RfCs and engaging in discussions. We've
> > started a brainstorming page, here, which we hope will usefully inform
> > the process of conflict resolution regarding German Wikipedia, as
> > well, so we can arrive at a more concrete conflict resolution process
> > soon. Your thoughts/suggestions are welcome, so we can (in NPOV style)
> > look at different possibilities (e.g. workgroups, committees, votes,
> > surveys) that have been discussed in the past:
> >
> https://meta.wikimedia.org/wiki/Community_Engagement_(Product)/Process_ideas
> >
> > We’re absolutely not saying that WMF simply wants to be able to
> > enforce its decisions: we completely understand there need to be
> > mechanisms for the community to influence decisions and outcomes at
> > all stages of the development and release of software. We need to
> > arrive at this process together.
> >
> > Again, we are sorry that this escalation occurred - and we hope we can
> > move forward constructively from here.
> >
> > Sincerely,
> >
> > Erik
> >
> >
> > [1]
> https://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:Meinungsbilder/Medienbetrachter&diff=prev&oldid=132469014
> >
> > [2]
> https://de.wikipedia.org/w/index.php?title=MediaWiki_Diskussion:Common.js&diff=132938244&oldid=132935469
> >
> > [3] https://meta.wikimedia.org/wiki/Stewards_policy
> >
> > [4]
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Guiding_Principles#Shared_power
> >
> > [5] https://bugzilla.wikimedia.org/show_bug.cgi?id=69445
> >
> >
> > --
> > Erik Möller
> > VP of Engineering and Product Development, Wikimedia Foundation
> >
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>



--
Landline (UK) 01780 757 250
Mobile (UK) 0798 1995 792
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
Just in terms of the amount of everyone's time that MediaViewer,
Superprotect
and related issues are absorbing, this situation is a net negative for the
projects.
Also, the amount of emotional hostility that this situation involves is
disheartening.
Personally, I would like to see us building on each other's work instead of
feuding,
and I'm getting MediaViewer issue fatigue.

WMF's principal argument against letting projects make local decisions
about
configurations of MediaViewer seems to be that having a multitude of site
configurations is impractical for site maintainability and development of
new
features. The Technical Committee would be in a good position to make global
decisions on a consensus basis.

Pine
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
On Aug 31, 2014 11:46 PM, "Pine W" <wiki.pine@gmail.com> wrote:
>
> Just in terms of the amount of everyone's time that MediaViewer,
> Superprotect
> and related issues are absorbing, this situation is a net negative for the
> projects.
> Also, the amount of emotional hostility that this situation involves is
> disheartening.
> Personally, I would like to see us building on each other's work instead
of
> feuding,
> and I'm getting MediaViewer issue fatigue.
>
> WMF's principal argument against letting projects make local decisions
> about
> configurations of MediaViewer seems to be that having a multitude of site
> configurations is impractical for site maintainability and development of
> new
> features. The Technical Committee would be in a good position to make
global
> decisions on a consensus basis.
>
> Pine

I've heard the argument that it is difficult to maintain and develop for
having different default states of this setting across different projects,
and frankly, I'm not buying it, unless the setting is intended to be
removed completely.

Could someone explain to me how having a different default state for the
setting has much, or any, impact?

- Martijn
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
Hoi,
The argument is not at all about the MediaViewer. It is only the latest
flash point. Consequently the notion of how hard it is to set a default on
or off is not relevant really.

When you read the Wikipedia Signpost you read about one of the major German
players and it is found necessary to mention that his "tools" environment
was ended and it became WMF labs. For me it gives the impression of sour
grapes and a sense of failure because volunteers do not decide the agenda
and feel angry/frustrated about that.

Consequently my conclusion that it is not about the MediaViewer at all. The
next thing that comes along will be the next flash point. This is because
it is emotions that speak and not arguments.
Thanks,
GerardM


On 1 September 2014 08:11, Martijn Hoekstra <martijnhoekstra@gmail.com>
wrote:

> On Aug 31, 2014 11:46 PM, "Pine W" <wiki.pine@gmail.com> wrote:
> >
> > Just in terms of the amount of everyone's time that MediaViewer,
> > Superprotect
> > and related issues are absorbing, this situation is a net negative for
> the
> > projects.
> > Also, the amount of emotional hostility that this situation involves is
> > disheartening.
> > Personally, I would like to see us building on each other's work instead
> of
> > feuding,
> > and I'm getting MediaViewer issue fatigue.
> >
> > WMF's principal argument against letting projects make local decisions
> > about
> > configurations of MediaViewer seems to be that having a multitude of site
> > configurations is impractical for site maintainability and development of
> > new
> > features. The Technical Committee would be in a good position to make
> global
> > decisions on a consensus basis.
> >
> > Pine
>
> I've heard the argument that it is difficult to maintain and develop for
> having different default states of this setting across different projects,
> and frankly, I'm not buying it, unless the setting is intended to be
> removed completely.
>
> Could someone explain to me how having a different default state for the
> setting has much, or any, impact?
>
> - Martijn
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
The difficulty of working with multiple configurations is one of WMF's main
points, along with its opinion that readers prefer MV and that WMF should
prioritize what WMF feels the readers want. WMF also is making a point of
claiming soveriegnty over software configuration.

Meanwhile, many volunteers seem to view readership numbers as adequate with
the status quo, do not believe that MV adds value, disagree with the
design of Media Viewer, and are angered by WMF's undemocratic conduct and
arrogant comments.

This kind of situation is unlikely to have a happy ending without some
concessions and mediation.

Pine
On Aug 31, 2014 11:32 PM, "Gerard Meijssen" <gerard.meijssen@gmail.com>
wrote:

> Hoi,
> The argument is not at all about the MediaViewer. It is only the latest
> flash point. Consequently the notion of how hard it is to set a default on
> or off is not relevant really.
>
> When you read the Wikipedia Signpost you read about one of the major German
> players and it is found necessary to mention that his "tools" environment
> was ended and it became WMF labs. For me it gives the impression of sour
> grapes and a sense of failure because volunteers do not decide the agenda
> and feel angry/frustrated about that.
>
> Consequently my conclusion that it is not about the MediaViewer at all. The
> next thing that comes along will be the next flash point. This is because
> it is emotions that speak and not arguments.
> Thanks,
> GerardM
>
>
> On 1 September 2014 08:11, Martijn Hoekstra <martijnhoekstra@gmail.com>
> wrote:
>
> > On Aug 31, 2014 11:46 PM, "Pine W" <wiki.pine@gmail.com> wrote:
> > >
> > > Just in terms of the amount of everyone's time that MediaViewer,
> > > Superprotect
> > > and related issues are absorbing, this situation is a net negative for
> > the
> > > projects.
> > > Also, the amount of emotional hostility that this situation involves is
> > > disheartening.
> > > Personally, I would like to see us building on each other's work
> instead
> > of
> > > feuding,
> > > and I'm getting MediaViewer issue fatigue.
> > >
> > > WMF's principal argument against letting projects make local decisions
> > > about
> > > configurations of MediaViewer seems to be that having a multitude of
> site
> > > configurations is impractical for site maintainability and development
> of
> > > new
> > > features. The Technical Committee would be in a good position to make
> > global
> > > decisions on a consensus basis.
> > >
> > > Pine
> >
> > I've heard the argument that it is difficult to maintain and develop for
> > having different default states of this setting across different
> projects,
> > and frankly, I'm not buying it, unless the setting is intended to be
> > removed completely.
> >
> > Could someone explain to me how having a different default state for the
> > setting has much, or any, impact?
> >
> > - Martijn
> > > _______________________________________________
> > > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > Wikimedia-l@lists.wikimedia.org
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> >
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
I think you've hit the nail on the head here. It's not about MediaViewer
at all, it's about two things:

#1: The frustration of some volunteers that they feel their views are not
being adequately considered in major deployments of new software.
#2: A lack of confidence and faith in the WMF Engineering team to deliver
quality software.

The second is the more dangerous one at this point. After the catastrophic
aborted launch of the Visual Editor, complete with numerous bugs that
should have been picked up in even a cursory unit testing scheme or
regression testing scheme prior to being deployed to a productive
environment, there's not a good deal of faith left. The technical problems
with MediaViewer were not as serious, but since a significant portion of
the power user base was expecting a failure, they jumped on the flaws that
it did have, and here we are. To be honest, if Erik were to turn water
into wine at this point, people would still complain, and loudly, that he
had provided them with red when they wanted white.

I'm not sure that the solutions that have been offered; a new deployment
process, or a tech council, are going to be sufficient to correct the real
problem, which at this point is largely one of perception. Similarly, I
don't think that the WMF adopting a complete hands-off approach as some
seem to be demanding is going to lead to anything other than stagnation as
individual communities squabble indecisively over what changes should be
made. I do know that if it's not fixed, that pretty much every major
deployment of new features is going to follow this same pattern, which is
obviously highly undesirable.

What I'd suggest is that we leave the "emotional hostility" at the door and
try to be reasonable. Neither side is going to get exactly what they want,
and that is to be expected. To be honest, some of the invective that has
been directed at Foundation staff has been completely over the top; phrases
like "Taliban diplomacy" or honest-to-god comparisons to the Nazis don't
move us towards a solution or make one seem like someone that can be
intelligently reasoned with, they only harden feelings on both sides and
make a suitable arrangement being found less likely. No employee should be
made to receive that sort of harassment in the course of their job, no
matter how much you disagree with them.

Cheers,
Craig Franklin








On 1 September 2014 16:31, Gerard Meijssen <gerard.meijssen@gmail.com>
wrote:

> Hoi,
> The argument is not at all about the MediaViewer. It is only the latest
> flash point. Consequently the notion of how hard it is to set a default on
> or off is not relevant really.
>
> When you read the Wikipedia Signpost you read about one of the major German
> players and it is found necessary to mention that his "tools" environment
> was ended and it became WMF labs. For me it gives the impression of sour
> grapes and a sense of failure because volunteers do not decide the agenda
> and feel angry/frustrated about that.
>
> Consequently my conclusion that it is not about the MediaViewer at all. The
> next thing that comes along will be the next flash point. This is because
> it is emotions that speak and not arguments.
> Thanks,
> GerardM
>
>
> On 1 September 2014 08:11, Martijn Hoekstra <martijnhoekstra@gmail.com>
> wrote:
>
> > On Aug 31, 2014 11:46 PM, "Pine W" <wiki.pine@gmail.com> wrote:
> > >
> > > Just in terms of the amount of everyone's time that MediaViewer,
> > > Superprotect
> > > and related issues are absorbing, this situation is a net negative for
> > the
> > > projects.
> > > Also, the amount of emotional hostility that this situation involves is
> > > disheartening.
> > > Personally, I would like to see us building on each other's work
> instead
> > of
> > > feuding,
> > > and I'm getting MediaViewer issue fatigue.
> > >
> > > WMF's principal argument against letting projects make local decisions
> > > about
> > > configurations of MediaViewer seems to be that having a multitude of
> site
> > > configurations is impractical for site maintainability and development
> of
> > > new
> > > features. The Technical Committee would be in a good position to make
> > global
> > > decisions on a consensus basis.
> > >
> > > Pine
> >
> > I've heard the argument that it is difficult to maintain and develop for
> > having different default states of this setting across different
> projects,
> > and frankly, I'm not buying it, unless the setting is intended to be
> > removed completely.
> >
> > Could someone explain to me how having a different default state for the
> > setting has much, or any, impact?
> >
> > - Martijn
> > > _______________________________________________
> > > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > Wikimedia-l@lists.wikimedia.org
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> >
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
Warning, tl;dr rant below in which live my personal opinion.

On 09/01/2014 08:00 AM, Craig Franklin wrote:
> fter the catastrophic
> aborted launch of the Visual Editor, complete with numerous bugs that
> should have been picked up in even a cursory unit testing scheme or
> regression testing scheme prior to being deployed to a productive
> environment, there's not a good deal of faith left.

That /was/ a bad botch; and (IMO) the reason why that happened is that
someone set a hard deploy date that should never have been set in stone
and then held to it even though VE was clearly not ready. (It is *now*
at a point with rollout would have been plausible).

Clearly nobody at WMF Engineering is going to do *that* again.

But I also don't think that was causative in any way; the tension
between WMF holding the reins to the servers and (part of) the
communities was the same years before that. ACCTRIAL anyone?

The fundamental issue is that the WMF is attempting to provide some
direction, and the communities do not want any (for various and
divergent reasons).

I side with the WMF in this; not because they sign my paycheck (I'm in
Ops - I have zero to do with dev work) but because I've been a
Wikipedian for >10 years and I *see* that the communities have no
capacity for change - or that what little change manages to gather
micro-consensus is local and often shortsighted. The projects are
directionless, and it shows in the increasing stagnation and calcification.

Are all the attempts by the WMF at providing direction successes? Not
even close. Some of the things they tried ranged from merely misguided
to downright daft (also IMO, obviously).

The process *does* need community engagement. That'd seriously
increases the value of what (and how) the WMF does things, and likely
reduce the number of bad ideas from the outset.

But the community engagement it needs is one that is done in good faith;
something which I have yet to see more than exceptions here and there.
It also needs fewer reactionnary hotheads. Editing sucks. Reading is
lacking. Most of the tooling is crap. That X editors have gotten used
to it and have implemented piles of workarounds doesn't justify keeping
the old shit around.

MV is a perfect example. 99% of the problems it objectively has (we
ignore here matters of taste) derive from the difficulty of parsing the
multitude overcomplicated templates living on File: pages to work around
the fact that a wikitext page is complete and utter crap at storing
metadata. It's not an argument against MV, it's an argument for getting
rid of the horrid way we handle File: pages with ad-hoc workarounds.
The *correct* solution is to fix the damn image pages, not to remove MV.

How is it that the old saying goes? "'We've always done things this
way' is the most dangerous statement in any language?"

-- Marc


_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
On 01/09/2014, Marc A. Pelletier <marc@uberbox.org> wrote:
...
> metadata. It's not an argument against MV, it's an argument for getting
> rid of the horrid way we handle File: pages with ad-hoc workarounds.
> The *correct* solution is to fix the damn image pages, not to remove MV.
...

So, can you link me to a positive proposal to do the elemental
foundation of this, and point to a realistic (and Foundation
supported) proposal to the community to standardize licence templates
on Commons?

Do this and you are most of the way there.

As someone who has uploaded 400,000 images to Commons with a variety
of licences, I would welcome this proposal rather than doing it the
wrong way around. Right now a rationale of blaming underpinning
infrastructure not being ready for MV, after rolling it out, looks
like setting your house on fire in order to give your husband
sufficient motivation to check the smoke alarm.

Fae
--
faewik@gmail.com https://commons.wikimedia.org/wiki/User:Fae

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
On Mon, Sep 1, 2014 at 9:10 AM, Marc A. Pelletier <marc@uberbox.org> wrote:

> Warning, tl;dr rant below in which live my personal opinion.
>
> On 09/01/2014 08:00 AM, Craig Franklin wrote:
> > fter the catastrophic
> > aborted launch of the Visual Editor, complete with numerous bugs that
> > should have been picked up in even a cursory unit testing scheme or
> > regression testing scheme prior to being deployed to a productive
> > environment, there's not a good deal of faith left.
>
> That /was/ a bad botch; and (IMO) the reason why that happened is that
> someone set a hard deploy date that should never have been set in stone
> and then held to it even though VE was clearly not ready. (It is *now*
> at a point with rollout would have been plausible).
>
> Clearly nobody at WMF Engineering is going to do *that* again.
>

We've heard that before.

>
> But I also don't think that was causative in any way; the tension
> between WMF holding the reins to the servers and (part of) the
> communities was the same years before that. ACCTRIAL anyone?
>

Sure, for reasons I'll get to below. That contradicts the rest of what you
said here.


>
> The fundamental issue is that the WMF is attempting to provide some
> direction, and the communities do not want any (for various and
> divergent reasons).
>

I don't think it's that the communities don't want any direction. It's that
large, open projects historically managed by their volunteers are not
amenable to top-down, authoritarian direction. All that will do is start
fights, to the detriment of everyone and especially to the detriment of
said projects. None of us are out a paycheck if we scale back our activity
or walk away in disgust.


>
> I side with the WMF in this; not because they sign my paycheck (I'm in
> Ops - I have zero to do with dev work) but because I've been a
> Wikipedian for >10 years and I *see* that the communities have no
> capacity for change - or that what little change manages to gather
> micro-consensus is local and often shortsighted. The projects are
> directionless, and it shows in the increasing stagnation and calcification.
>

That's contradicted by, among other things, ACTRIAL as mentioned above. The
en.wp community came to a clear consensus for a major change, and the WMF
shrugged and said "Nah, rather not." When treated that way, do you think
the community has much appetite to continue discussing necessary changes
when the last time was a significant effort ultimately ending in futility,
not because of a failure on the community's part, but because of WMF's
refusal to listen?


>
> Are all the attempts by the WMF at providing direction successes? Not
> even close. Some of the things they tried ranged from merely misguided
> to downright daft (also IMO, obviously).
>
> The process *does* need community engagement. That'd seriously
> increases the value of what (and how) the WMF does things, and likely
> reduce the number of bad ideas from the outset.
>

As above, that's not going to happen if that engagement continues to result
in brushoffs. Look at Flow. One overwhelming message is "We don't want it
at all" (and that demands real consideration, not dismissive comments about
"resistance to change" and "power users"), but when asked what could at
least make it better, the answers of "Preserve ability for anyone to
refactor posts as needed, don't restrict to admins" and "Don't limit
indentation" have fallen on deaf ears. Again, if there's no one listening,
people are not going to continue talking to what by all appearances is a
brick wall.


>
> But the community engagement it needs is one that is done in good faith;
> something which I have yet to see more than exceptions here and there.
> It also needs fewer reactionnary hotheads. Editing sucks. Reading is
> lacking. Most of the tooling is crap. That X editors have gotten used
> to it and have implemented piles of workarounds doesn't justify keeping
> the old shit around.
>

Maybe. I don't really think it's crap. Reflinks wasn't crap. That doesn't
mean we can't do better, but we need to do actually better, not just "We
need to do something, this is something, so do it!"

Regardless, same again: That needs to be met with good faith on the other
side, to stop just plowing ahead when everyone's saying "WAIT, there's
serious problems here!". Engagement doesn't work if it's the classic
"suggestions box" positioned directly over a garbage can.


>
> MV is a perfect example. 99% of the problems it objectively has (we
> ignore here matters of taste) derive from the difficulty of parsing the
> multitude overcomplicated templates living on File: pages to work around
> the fact that a wikitext page is complete and utter crap at storing
> metadata. It's not an argument against MV, it's an argument for getting
> rid of the horrid way we handle File: pages with ad-hoc workarounds.
> The *correct* solution is to fix the damn image pages, not to remove MV.
>
> How is it that the old saying goes? "'We've always done things this
> way' is the most dangerous statement in any language?"
>

Change for the sake of change can easily be as dangerous. I think most
agree that some changes are necessary. As above, one of the historical
blowups was when the en.wp community came to clear consensus, asked for a
change, and just got a dismissive WONTFIX. If you want to drive engagement,
show real willingness to respond to that engagement with actions and real
changes, not yet another promise to do better next time, we really really
mean it now. Sometimes, that might mean doing things the person doing them
doesn't personally agree with.


>
> -- Marc
>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
On 09/01/2014 11:45 AM, Todd Allen wrote:
> On Mon, Sep 1, 2014 at 9:10 AM, Marc A. Pelletier <marc@uberbox.org> wrote:
> We've heard that before.

Oh, I'm pretty damn sure that the "stick to the timeline" idea isn't
going to get traction ever again. :-) But yeah in general recognizing
an error is not, in itself, proof against repeating it. Errare humanum est.

> I don't think it's that the communities don't want any direction. It's that
> large, open projects historically managed by their volunteers are not
> amenable to top-down, authoritarian direction. All that will do is start
> fights, to the detriment of everyone and especially to the detriment of
> said projects. None of us are out a paycheck if we scale back our activity
> or walk away in disgust.

There's that, but there's also the (unavoidable) issue that Wikipedia
was revolutionnary, so it attracted a great deal of people who had
little to no desire to abide "The Man". The problem is we /are/ "The
Man" now.

> That's contradicted by, among other things, ACTRIAL as mentioned above. The
> en.wp community came to a clear consensus for a major change, and the WMF
> shrugged and said "Nah, rather not."

That, IMO, is an example of what I call a shortsighted change. It
*might* have been a good local change, in the end, but it nevertheless
was a fundamental dent in the project values in order to solve an
extremely local problem. If I were the Foundation back then I probably
also would have refused to proceed without Licence-change-level
consensus and a long consultation process - at the very least.

Like or not, the Foundation is in the odd position of being the guardian
of the "Big Picture"; local projects are exactly that - local. What may
be a good local change may turn out to be globally disastrous (because
divergence, precedent, etc). But that's getting into a discussion of
federalism as a concept (and whether the projects are de facto
federated) which may be interesting in itself but is way waaaay
off-topic. :-)

> Regardless, same again: That needs to be met with good faith on the other
> side, to stop just plowing ahead when everyone's saying "WAIT, there's
> serious problems here!". Engagement doesn't work if it's the classic
> "suggestions box" positioned directly over a garbage can.

I don't think that's true. At least, from my privileged position (where
I see much of the "internal" dev chatter from the sidelines) that has
never seemed to be the case.

> Change for the sake of change can easily be as dangerous.

That's true, to a point, but I can say with quite a bit of confidence
that nobody at the Foundation ever said "Let's change this" without a
solid "This seems to be an improvement because" behind it (or, at the
very least "Y is demonstrably broken, we don't know what's the best way
to fix it, let's try Z".

They may be *wrong*; but every bit of development I've seen is based on
a rational desire to improve and from reasonable assumptions about what
will be an improvement.

And, honestly, it's better to try and possibly fail to fix than it is to
avoid trying and definitely stay broken.

-- Marc


_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
On Sep 1, 2014 5:10 PM, "Marc A. Pelletier" <marc@uberbox.org> wrote:
>
> Warning, tl;dr rant below in which live my personal opinion.

Thank you for that. A heartfelt rant feels a lot better than being told my
"call is important to you."

(snip)

> The fundamental issue is that the WMF is attempting to provide some
> direction, and the communities do not want any (for various and
> divergent reasons).

I don't really have all that much of a problem with direction. I have a
problem though with strong arming change, which is snap happened here.

(snip)

> The process *does* need community engagement. That'd seriously
> increases the value of what (and how) the WMF does things, and likely
> reduce the number of bad ideas from the outset.
>
> But the community engagement it needs is one that is done in good faith;

Yes, from both sides. The flow example cited in another email shows this
well. There is a large contingent of "thank you for your concern. We won't
do that because we believe x rather than y", effectively closing
discussion. That's not a great atmosphere to share ideas in. Another
frequent problem is saying in the early stages not to worry, it's only the
early stages, and all that will be fixed, just come back in a few months,
and you'll see how great it'll be, and when it isn't say that earlier
feedback would have helped, but nobody showed interest in the early stages.

> something which I have yet to see more than exceptions here and there.
> It also needs fewer reactionnary hotheads. Editing sucks. Reading is
> lacking. Most of the tooling is crap. That X editors have gotten used
> to it and have implemented piles of workarounds doesn't justify keeping
> the old shit around.
>
> MV is a perfect example. 99% of the problems it objectively has (we
> ignore here matters of taste) derive from the difficulty of parsing the
> multitude overcomplicated templates living on File: pages to work around
> the fact that a wikitext page is complete and utter crap at storing
> metadata. It's not an argument against MV, it's an argument for getting
> rid of the horrid way we handle File: pages with ad-hoc workarounds.

Yes! This must be said more often!

> The *correct* solution is to fix the damn image pages, not to remove MV.

The *correct* solution is to make MV bail completely on pages it fails to
parse, falling back to the known bad-but-sufficient behaviour, and maybe
adding a hidden category unparsable by MV to the image, so that it can be
addressed. If 10% of the effort spent on the long tail of template madness
was spent on implementing "when in doubt, bail" much debate would have been
unnecessary. Doing the right thing 90% of the time and nothing 10% of the
time is preferable over doing the right thing 98 % of the time and the
wrong thing 2%.

The same, by the way, goes for VE, which should have had "bail and give me
what you have now as wikitext" from the onset, and Flow which needs a "bail
and convert this thread to ye olde talkpage thread" (which I fear will be
batted away as reactionary crank talk, and "by the time flow will be done
unneeded anyway")

-- Martijn

>
> How is it that the old saying goes? "'We've always done things this
> way' is the most dangerous statement in any language?"
>
> -- Marc
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
On 1 September 2014 17:57, Martijn Hoekstra <martijnhoekstra@gmail.com> wrote:

> The same, by the way, goes for VE, which should have had "bail and give me
> what you have now as wikitext" from the onset, and Flow which needs a "bail
> and convert this thread to ye olde talkpage thread" (which I fear will be
> batted away as reactionary crank talk, and "by the time flow will be done
> unneeded anyway")


By the way:

Is Flow going to support the use case of cut'n'pasting a piece from
the article page to the talk page, as a lump of wikitext or as a piece
of rich text from VE?

'Cos if it doesn't, I predict that will be the sticking point with the
people who actually communicate on talk pages.


- d.

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
On 09/01/2014 12:57 PM, Martijn Hoekstra wrote:
> The *correct* solution is to make MV bail completely on pages it fails to
> parse, falling back to the known bad-but-sufficient behaviour, and maybe
> adding a hidden category unparsable by MV to the image, so that it can be
> addressed. If 10% of the effort spent on the long tail of template madness
> was spent on implementing "when in doubt, bail" much debate would have been
> unnecessary.

I don't think it's necessarily easy to even /detect/ that there is
something important that couldn't be parsed right; but this makes sense
to me indeed in principle.

-- Marc


_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
Hoi,
Dear Pine. I do not care a fig about what "some users" think. You either
support their view or you do not. When they consider that the current
number of readers is adequate, I want to appreciate what they think those
numbers are, what the trends are and how it is possible that their opinion
is so starkly different from the ones I know about. Readership is down on
computers and the current numbers are only supported because of tablets and
mobiles. The same thing can be said about new editors; they are mainly
arriving from mobiles and tablets.

Even "old timers" like myself loudly HATE the old crappy interface. So I am
really displeased that you voice what "some users" think; as far as I am
concerned it is "weasel talk". You either support the voices of "some
users" or you do not. When you do, say so and argue. Do not let it hang in
the air as if it has nothing to do with you.

Pine I know you know about research.. You know the numbers, you know how to
get them where to ask. You do not have an excuse.
Thanks,
GerardM


On 1 September 2014 09:34, Pine W <wiki.pine@gmail.com> wrote:

> The difficulty of working with multiple configurations is one of WMF's main
> points, along with its opinion that readers prefer MV and that WMF should
> prioritize what WMF feels the readers want. WMF also is making a point of
> claiming soveriegnty over software configuration.
>
> Meanwhile, many volunteers seem to view readership numbers as adequate with
> the status quo, do not believe that MV adds value, disagree with the
> design of Media Viewer, and are angered by WMF's undemocratic conduct and
> arrogant comments.
>
> This kind of situation is unlikely to have a happy ending without some
> concessions and mediation.
>
> Pine
> On Aug 31, 2014 11:32 PM, "Gerard Meijssen" <gerard.meijssen@gmail.com>
> wrote:
>
> > Hoi,
> > The argument is not at all about the MediaViewer. It is only the latest
> > flash point. Consequently the notion of how hard it is to set a default
> on
> > or off is not relevant really.
> >
> > When you read the Wikipedia Signpost you read about one of the major
> German
> > players and it is found necessary to mention that his "tools" environment
> > was ended and it became WMF labs. For me it gives the impression of sour
> > grapes and a sense of failure because volunteers do not decide the agenda
> > and feel angry/frustrated about that.
> >
> > Consequently my conclusion that it is not about the MediaViewer at all.
> The
> > next thing that comes along will be the next flash point. This is because
> > it is emotions that speak and not arguments.
> > Thanks,
> > GerardM
> >
> >
> > On 1 September 2014 08:11, Martijn Hoekstra <martijnhoekstra@gmail.com>
> > wrote:
> >
> > > On Aug 31, 2014 11:46 PM, "Pine W" <wiki.pine@gmail.com> wrote:
> > > >
> > > > Just in terms of the amount of everyone's time that MediaViewer,
> > > > Superprotect
> > > > and related issues are absorbing, this situation is a net negative
> for
> > > the
> > > > projects.
> > > > Also, the amount of emotional hostility that this situation involves
> is
> > > > disheartening.
> > > > Personally, I would like to see us building on each other's work
> > instead
> > > of
> > > > feuding,
> > > > and I'm getting MediaViewer issue fatigue.
> > > >
> > > > WMF's principal argument against letting projects make local
> decisions
> > > > about
> > > > configurations of MediaViewer seems to be that having a multitude of
> > site
> > > > configurations is impractical for site maintainability and
> development
> > of
> > > > new
> > > > features. The Technical Committee would be in a good position to make
> > > global
> > > > decisions on a consensus basis.
> > > >
> > > > Pine
> > >
> > > I've heard the argument that it is difficult to maintain and develop
> for
> > > having different default states of this setting across different
> > projects,
> > > and frankly, I'm not buying it, unless the setting is intended to be
> > > removed completely.
> > >
> > > Could someone explain to me how having a different default state for
> the
> > > setting has much, or any, impact?
> > >
> > > - Martijn
> > > > _______________________________________________
> > > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > > Wikimedia-l@lists.wikimedia.org
> > > > Unsubscribe:
> https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> > > _______________________________________________
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > Wikimedia-l@lists.wikimedia.org
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> > >
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
Thank you very much, Marc, for this clear and sound statement. It
seems to me that there are many discussions that are far away from the
real points, like the multitude of information on our pages. I once
counted how many links there are on the German main page of Wikimedia
Commons, I stopped when I reached 170...
By the way, I enjoyed your talk at Wikimania, and your enthousiasm
about many tools - actually, tools that often help to overcome the
downsides of our wiki pages.
Kind regards
Ziko





2014-09-01 17:10 GMT+02:00 Marc A. Pelletier <marc@uberbox.org>:
> Warning, tl;dr rant below in which live my personal opinion.
>
> On 09/01/2014 08:00 AM, Craig Franklin wrote:
>> fter the catastrophic
>> aborted launch of the Visual Editor, complete with numerous bugs that
>> should have been picked up in even a cursory unit testing scheme or
>> regression testing scheme prior to being deployed to a productive
>> environment, there's not a good deal of faith left.
>
> That /was/ a bad botch; and (IMO) the reason why that happened is that
> someone set a hard deploy date that should never have been set in stone
> and then held to it even though VE was clearly not ready. (It is *now*
> at a point with rollout would have been plausible).
>
> Clearly nobody at WMF Engineering is going to do *that* again.
>
> But I also don't think that was causative in any way; the tension
> between WMF holding the reins to the servers and (part of) the
> communities was the same years before that. ACCTRIAL anyone?
>
> The fundamental issue is that the WMF is attempting to provide some
> direction, and the communities do not want any (for various and
> divergent reasons).
>
> I side with the WMF in this; not because they sign my paycheck (I'm in
> Ops - I have zero to do with dev work) but because I've been a
> Wikipedian for >10 years and I *see* that the communities have no
> capacity for change - or that what little change manages to gather
> micro-consensus is local and often shortsighted. The projects are
> directionless, and it shows in the increasing stagnation and calcification.
>
> Are all the attempts by the WMF at providing direction successes? Not
> even close. Some of the things they tried ranged from merely misguided
> to downright daft (also IMO, obviously).
>
> The process *does* need community engagement. That'd seriously
> increases the value of what (and how) the WMF does things, and likely
> reduce the number of bad ideas from the outset.
>
> But the community engagement it needs is one that is done in good faith;
> something which I have yet to see more than exceptions here and there.
> It also needs fewer reactionnary hotheads. Editing sucks. Reading is
> lacking. Most of the tooling is crap. That X editors have gotten used
> to it and have implemented piles of workarounds doesn't justify keeping
> the old shit around.
>
> MV is a perfect example. 99% of the problems it objectively has (we
> ignore here matters of taste) derive from the difficulty of parsing the
> multitude overcomplicated templates living on File: pages to work around
> the fact that a wikitext page is complete and utter crap at storing
> metadata. It's not an argument against MV, it's an argument for getting
> rid of the horrid way we handle File: pages with ad-hoc workarounds.
> The *correct* solution is to fix the damn image pages, not to remove MV.
>
> How is it that the old saying goes? "'We've always done things this
> way' is the most dangerous statement in any language?"
>
> -- Marc
>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
> On Sep 1, 2014, at 8:45 AM, Todd Allen <toddmallen@gmail.com> wrote:
>
> That's contradicted by, among other things, ACTRIAL as mentioned above. The
> en.wp community came to a clear consensus for a major change, and the WMF
> shrugged and said "Nah, rather not."

That's... Not exactly what I remember happening there. What I remember was that a pretty good number (~500) of enwiki community members came together and agreed on a problem, and one plan for how to fix it and asked the WMF to implement it. The WMF evaluated it, and saw a threat to a basic project value. WMF then asked "what's the problem you're actually trying to solve?", and proposed and built a set of tools to directly address that problem without compromising the core value of openness. And it seems to have worked out pretty well because I haven't heard a ton of complaints about that problem since.

______________________
Philippe Beaudette
Director, Community Advocacy
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments [ In reply to ]
On Sep 1, 2014 3:21 PM, "Philippe Beaudette" <pbeaudette@wikimedia.org>
wrote:
>
> > On Sep 1, 2014, at 8:45 AM, Todd Allen <toddmallen@gmail.com> wrote:
> >
> > That's contradicted by, among other things, ACTRIAL as mentioned above.
The
> > en.wp community came to a clear consensus for a major change, and the
WMF
> > shrugged and said "Nah, rather not."
>
> That's... Not exactly what I remember happening there. What I remember
was that a pretty good number (~500) of enwiki community members came
together and agreed on a problem, and one plan for how to fix it and asked
the WMF to implement it. The WMF evaluated it, and saw a threat to a basic
project value. WMF then asked "what's the problem you're actually trying to
solve?", and proposed and built a set of tools to directly address that
problem without compromising the core value of openness. And it seems to
have worked out pretty well because I haven't heard a ton of complaints
about that problem since.

I don't agree with that assessment, but it's possible I'm missing some
elements of the process. Philippe, any chance you could full in the summary
with a few specifics, and maybe some links?

Pete
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

1 2 3 4 5 6  View All