[Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

classic Classic list List threaded Threaded
146 messages Options
12345 ... 8
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

WereSpielChequers-2
"Proposing a solution to the community" should not be the start of the process of involving the community.

Developers are better qualified than non-developers to say whether a prom can be solved, and how it can be solved. But the most important steps in the process include deciding what could be improved or replaced, and crucially what priority various changes could have. Developers aren't necessarily the best people to decide that, sometimes their view is an outlier. For example someone took the decision that the Article Feedback Tool was a higherh. How many developers feel bitten when they have an edit conflict?

The first stage in the dialogue should be to discuss the coding philosophy. Currently we have some coders who believe that our mission is global, and that we need to support anyone who can get onto the internet; lets call that the EBay/Amazon/Facebook strategy. Others believe that our software should be the best that it could bewe are only going



Regards

Jonathan Cardy


>
> Message: 3
> Date: Fri, 22 Aug 2014 08:48:14 +0200
> From: Dariusz Jemielniak <[hidden email]>
> To: Wikimedia Mailing List <[hidden email]>
> Subject: Re: [Wikimedia-l] Next steps regarding WMF<->community
>    disputes    about deployments
> Message-ID:
>    <[hidden email]>
> Content-Type: text/plain; charset="UTF-8"
>
> one more general level solution would be having more steps: proposing a
> solution to the community (checking for support), inviting willing testers,
> after positive feedback introducing to all logged in users, and after
> positive feedback propagating on the site as a whole.
>
> Once the initial support for an idea is established, we can take for
> granted that the change should happen - but it should be up to feedback to
> see if the solution is ready, and not up to the developers' calendar (we've
> all seen what happens when the schedule is the in the case of visual editor
> premature launch).
>
> I think that WMF perhaps takes way too little use of our community as
> testers, commentators, supporters. If the community was more involved in
> development plans, it would also not be surprised by solutions which
> perhaps are important and wise in the log term, but still should not jump
> out of the box and be perceived as forced.
>
> I don't think it makes any sense to perceive WMF as just a servant. But how
> should we perceive the community? Is it a disorganized mass with no uniform
> voice, that should be shepherded into accepting solutions? Is it a valuable
> resource? Is it a full partner in planning, testing and implementing the
> solutions? I think that a lot of the latter is missing, and the fault is on
> both sides. But it is mainly up to WMF to change it, as WMF has the
> structures, staff, and resources to propose procedures there.
>
> just my two cents, anyway.
>
> dj "pundit"
>
>
> On Fri, Aug 22, 2014 at 7:54 AM, rupert THURNER <[hidden email]>
> wrote:
>
>> Am 22.08.2014 04:18 schrieb "Erik Moeller" <[hidden email]>:
>>>
>>> On Wed, Aug 20, 2014 at 12:32 AM, Pine W <[hidden email]> wrote:
>>>> I am curious to hear your thoughts about the proposed Technology
>> Committee.
>>>> That idea has some community support and had been discussed at some
>> length
>>>> on the WMF Board Noticeboard.
>>>

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

MZMcBride-2
In reply to this post by Erik Moeller-4
Thank you for a really good post.

Erik Moeller wrote:
>I know there are some who want to use this opportunity to cement a
>different relationship - "WMF as servant", without a say. ("You are
>the servant, not the master, and your opinion doesn't matter very
>much." [1])  I understand that - I think it's rational, and
>justifiable, and may even be the better direction in the long run. I
>personally happen to disagree strongly with that belief, and the
>organization's leadership certainly does, as well. I hope we can find
>a middle ground, and I know that some of this is also just a reaction.

I appreciate the candor here and the recognition that there are acceptable
yet radically different views of how the Wikimedia Foundation should fit
within the Wikimedia world.

>What's happening here is painful and difficult, and I'm sorry for our
>role in that. I do believe it's necessary that we work through this,
>and on a personal level, I honestly care more about doing that and
>achieving some clarity on our working relationship with each other,
>than about any specific outcome.

Re: https://meta.wikimedia.org/wiki/Limits_to_configuration_changes

The reality is that sometimes the wiki communities can make poor
decisions. But Sj and Brion and others have, in my opinion, tried to
stress that it's okay for people to be wrong and it's okay to try things
out. But it's always been a balancing act.

If there aren't technical, legal, or fundamental philosophical issues with
a wiki configuration change, when should and shouldn't it be allowed? And
who ultimately decides (e.g., stewards)? I think that's roughly what we're
looking at right now. The past process has sometimes relied on collective
and intentional deafness (via Bugzilla or mailing lists or whatever) and
that isn't really still suitable these days, I don't think.

Defining the third category (fundamental philosophical issues) is tricky,
but retaining open content licenses, the ability of people to easily
contribute, etc. are the types of things I'm talking about. Deeply held
shared values, not "I think Web users should always have a lightbox when
they click an image." That's an aesthetic choice that should probably be
left up to individual communities unless we can find a compelling reason
not to (e.g., having an identical user experience across Wikimedia wikis
by globally enabling MediaViewer is not a fundamental philosophical issue
and these types of aesthetic choices have never been considered as such).

>It's appropriate for WMF to take into account the full breadth and
>depth of devices that do exist and are in wide usage, more so than
>sites developed for users in rich countries. Hence a greater focus on
>things like image compression, overall page footprint, the
>no-JavaScript experience, etc. But that's still consistent with
>carefully updating the presentation. (Introducing a lightbox viewer in
>2014 is not exactly a radically new vision for user experience.)

Yes. Performance is important. Graceful degradation is important.

>People have cited WikiWand as an example of a third party improved
>reader experience. It's quite nicely done; I like a lot of the design
>choices they've made. It's far from a threat (though a more prominent
>"Edit" link would be nice, especially since the browser extension
>hijacks wikipedia.org views), but it's the kind of cool third party
>effort that keeps us honest. They recently raised about $600K in
>funding, which means that at least some people believe there's a real
>demand for a nicer, more modern default reader experience.

At <http://news.slashdot.org/story/14/08/21/216217/> Andreas Kolbe
discusses WikiWand. In Andreas' view, "the Wikimedia Foundation is afraid
it will lose readers to sites like WikiWand that offer Wikipedia content
as a pure consumable with a much more aesthetically pleasing interface.
The moment Wikipedia page views go down, the Alexa rank will go down and
donations will go down, as fewer people will see the fundraising banners."

Pi zero at <https://meta.wikimedia.org/wiki/Special:Permalink/9622503>
writes, "The non-Wikipedian sisters are the growth sector of the
wikimedian movement, and the WMF by dissing them is strangling the
wikimedian movement's best chance of having a vigorous future, with
Wikipedia embedded in a thriving ecosystem of wikimedian sisters
augmenting each other's strengths."

Meanwhile Lila has been repeatedly emphasizing priorities and
prioritization on Meta-Wiki (in seven distinct posts, by my count). There
are vague references to the "prioritization pipeline," but in addition to
the issue of deciding wiki configuration changes, discussed above, we also
need to clearly define what that pipeline looks like and how it behaves.
Pine and others have been discussing a Technology Committee that could
possibly bridge the Board, Wikimedia Foundation staff, and the editing
communities. But who knows if such an idea is viable or desirable.

There is lots and lots to think about right now.

MZMcBride



_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Gerard Meijssen-3
In reply to this post by Henning Schlottmann
Hoi,
I am so happy that you know so well that all the millions have been wasted.
As so often, an opinion is just that. When you want to learn about the
effect of the development done, it may be useful to look a bit further
afield. Mobile is one area where the development proves really effective.
Without it our numbers of readers would be down. It is also where the
number of new editors are happening.

When your idea of editing Wikipedia is business as usual, you have lost
many people because the experience is awful.

So when I am to accept your argument that the framework is wrong. I will
agree with you when it means that we migrate from the awful framework we
have used for too long. It is exactly the Visual Editor and the Media
Viewer that make sense to our users. Commons as it is is so bad as an
experience that people like me who are committed to WMF do not use it.

Now what do we aim to achieve? Keeping you happy or making sure we have a
public ???
Thanks,
       GerardM


On 22 August 2014 13:05, Henning Schlottmann <[hidden email]> wrote:

> On 22.08.2014 09:22, Erik Moeller wrote:
> >
> > - The MediaViewer rollout was very smooth until the deployments to
> > German Wikipedia, English Wikipedia and Wikimedia Commons. There could
> > be many reasons for that -- but it's a fact nonetheless. I do see
> > little evidence that users in other communities are especially unhappy
> > about the feature (leaving aside the politics of it now). I would be
> > very curious what reason people do attribute that difference to,
> > however (understanding that Commons is very different from the
> > Wikipedia use case).
>
> This may or may not correlate with a deep commitment to a) the licenses,
> b) quality.
>
> > - The criticism isn't just about that -- it's about a large number of
> > mostly individually small issues. Generally, the idea that we
> > effectively "munge" some of the metadata by displaying a
> > machine-readable subset below the fold is viewed very negatively,
> > because 1) it doesn't reflect all the available information, 2) it
> > makes it harder for users to discover the File: page, and potentially
> > edit it.
>
> If it does not reflect the license information it is broken.
>
> The license is paramount. We can not accept any kind of software that
> hands out "reuse information" that does not display the photographer's
> name and the license (with link to the license text).
>
> We do not want a default setting, that does not show extensive
> descriptions, map legends, image annotations and the like. All that is
> content we created for the readers. You must not block our readers from
> this content.
>
> MV is broken. It is not ready to be deployed. Not by far. Take it back
> and fix it.
>
> In theory I can see a working MV. I can even imagine a working Visual
> Editor, but am very skeptical about it. I can not imagine Flow to work,
> ever. This one needs to be abandoned now.
>
> Eric, your department has an abysmal record. You have wasted millions on
> software that started with the wrong framework and is not working after
> years and years of development. Please think about yourself, not about
> the communities if you want to understand about the conflicts at hand.
>
> Henning
>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Ziko van Dijk-3
Hello,

I am very grateful for Gerards remarks.

Sometimes I see a lot of black/white-thinking in the Wikimedia
movement, with statements such as "this is all bad" (and,
occasionally, "this is all good"). I am more comfortable with shades
of grey, they don't have to be fifty, but at least 5 or 10. On a scale
to five, the Visual Editor might have been "2" in 2013, now it looks
to me like "3" or "4". Not good enough? :-)

Some people in the movement and especially in the communities have
found their way of doing things and are happy with it, they don't want
to have anything changed and don't see the need for it. That is a
legitimate feeling and attitude, but other people allow themselves to
point out the downsides. Some find it very difficult to tolerate that,
because they don't want their world to change.

Software is not the solution for everything, but sometimes it helps to
make some things better. Wikipedia editing will always remain a hobby
for a very small part of the general population. But those people who
want to edit should at least not find technology a treshold. There are
other tresholds, such as the often lack of civility in the
communities, but that is no reason not to tackle the technological
one. (People in my classes wonder why Wikipedia editing is so
antiquated, it reminds them of Word Perfect in the 90s.)

The real question to me seems to be: who exactly should decide on what
software is implemented, what would be a practicable solution that
keeps things going and includes the stakeholders.

Kind regards
Ziko













2014-08-24 11:07 GMT+02:00 Gerard Meijssen <[hidden email]>:

> Hoi,
> I am so happy that you know so well that all the millions have been wasted.
> As so often, an opinion is just that. When you want to learn about the
> effect of the development done, it may be useful to look a bit further
> afield. Mobile is one area where the development proves really effective.
> Without it our numbers of readers would be down. It is also where the
> number of new editors are happening.
>
> When your idea of editing Wikipedia is business as usual, you have lost
> many people because the experience is awful.
>
> So when I am to accept your argument that the framework is wrong. I will
> agree with you when it means that we migrate from the awful framework we
> have used for too long. It is exactly the Visual Editor and the Media
> Viewer that make sense to our users. Commons as it is is so bad as an
> experience that people like me who are committed to WMF do not use it.
>
> Now what do we aim to achieve? Keeping you happy or making sure we have a
> public ???
> Thanks,
>        GerardM
>
>
> On 22 August 2014 13:05, Henning Schlottmann <[hidden email]> wrote:
>
>> On 22.08.2014 09:22, Erik Moeller wrote:
>> >
>> > - The MediaViewer rollout was very smooth until the deployments to
>> > German Wikipedia, English Wikipedia and Wikimedia Commons. There could
>> > be many reasons for that -- but it's a fact nonetheless. I do see
>> > little evidence that users in other communities are especially unhappy
>> > about the feature (leaving aside the politics of it now). I would be
>> > very curious what reason people do attribute that difference to,
>> > however (understanding that Commons is very different from the
>> > Wikipedia use case).
>>
>> This may or may not correlate with a deep commitment to a) the licenses,
>> b) quality.
>>
>> > - The criticism isn't just about that -- it's about a large number of
>> > mostly individually small issues. Generally, the idea that we
>> > effectively "munge" some of the metadata by displaying a
>> > machine-readable subset below the fold is viewed very negatively,
>> > because 1) it doesn't reflect all the available information, 2) it
>> > makes it harder for users to discover the File: page, and potentially
>> > edit it.
>>
>> If it does not reflect the license information it is broken.
>>
>> The license is paramount. We can not accept any kind of software that
>> hands out "reuse information" that does not display the photographer's
>> name and the license (with link to the license text).
>>
>> We do not want a default setting, that does not show extensive
>> descriptions, map legends, image annotations and the like. All that is
>> content we created for the readers. You must not block our readers from
>> this content.
>>
>> MV is broken. It is not ready to be deployed. Not by far. Take it back
>> and fix it.
>>
>> In theory I can see a working MV. I can even imagine a working Visual
>> Editor, but am very skeptical about it. I can not imagine Flow to work,
>> ever. This one needs to be abandoned now.
>>
>> Eric, your department has an abysmal record. You have wasted millions on
>> software that started with the wrong framework and is not working after
>> years and years of development. Please think about yourself, not about
>> the communities if you want to understand about the conflicts at hand.
>>
>> Henning
>>
>>
>> _______________________________________________
>> Wikimedia-l mailing list, guidelines at:
>> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
>> [hidden email]
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
>> <mailto:[hidden email]?subject=unsubscribe>
>>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Dariusz Jemielniak-3
In reply to this post by Gerard Meijssen-3
hi,

On Sun, Aug 24, 2014 at 11:07 AM, Gerard Meijssen <[hidden email]
> wrote:

>
> Now what do we aim to achieve? Keeping you happy or making sure we have a
> public ???
>

simply put: both. We need readers just as much as we need the free labor of
editors/volunteers.

I don't think it makes any sense to have a discussion about the "wasted
millions". First, in software development there is always some inevitable
waste, just because of the nature of this endeavor. Second, many projects
which start with mixed reception are getting better (and I have high hope
that the visual editor is one of them!). Third, for an IT organization of
this caliber and traffic, as well as the budget, there are impressive
results in many areas (including, but not limited to, mobile website - at
least for viewers, as editing is a different story).

The real problem here, in my view, is creating an organizational framework
that will allow to incorporate the community much more into planning, early
development, alpha and beta testing, and finally implementation of all new
features and tools (in a way which does not rely on IT schedules only, but
also on feedback from the communities). It is up to WMF to create and
provide such framework, as our community as a whole does not have any
institutionalized representation or voice (which is part of the issue; one
the one hand it is easy to discard whatever people from the community say,
as they are random individuals, and on the other it must be deeply
frustrating to never be sure what the community reaction will be). Some
people are suggesting stewards as the good group to start with - I'm afraid
stewards are not the best ones to go to. Stewards act mainly as highly
trusted, experienced individuals. They do not represent their local
communities in any way. Also, they do not necessarily have the best skills
for the task, and they do not form a cooperating team, in general.

One of the unbearable signs of bureaucracy is setting up committees, but
here a volunteer-driven, democratic task force could actually make some
sense, perhaps. Look at it this way - we elect admins, crats, checkusers,
oversighters, stewards. All these roles are only technical. Perhaps at some
point we should think of community representation as well (and not in the
sense of leadership, but in the sense of liaisons, testers, people
responsible for smoother communication).

My experience within the FDC has shown that volunteer-driven bodies are
quite effective at such tasks, when provided with necessary organizational
support.

best,

dariusz "pundit"



--

__________________________
prof. dr hab. Dariusz Jemielniak
kierownik katedry Zarządzania Międzynarodowego
i centrum badawczego CROW
Akademia Leona Koźmińskiego
http://www.crow.alk.edu.pl

członek Akademii Młodych Uczonych Polskiej Akademii Nauk
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

David Cuenca Tudela
In reply to this post by MZMcBride-2
On Sun, Aug 24, 2014 at 4:38 AM, MZMcBride <[hidden email]> wrote:

> Pi zero at <https://meta.wikimedia.org/wiki/Special:Permalink/9622503>
> writes, "The non-Wikipedian sisters are the growth sector of the
> wikimedian movement, and the WMF by dissing them is strangling the
> wikimedian movement's best chance of having a vigorous future, with
> Wikipedia embedded in a thriving ecosystem of wikimedian sisters
> augmenting each other's strengths."
>

Thanks MZMcBride for bringing attention to Pi Zero's insightful comment,
which actually correspond with how big companies devise strategies to be
successful. They do not promote only one brand, they promote several with
the hopes that, if one dies, they will have another one (or several) to
take up its place. If you look at companies that failed in the past, most
of the ones that could have avoided their fate didn't or couldn't, because
they had over-commited to a single product, and when that failed they had
no back-up plan with products better adapted to the new conditions, and
someone else had occupied that market slot. It is always wise to have
several baskets where to put eggs.

The biggest asset of the Wikimedia stream is not that its community can
materialize around a digital encyclopedia, but that it can do so around
many other projects that are also aligned with the mission of sharing and
opening knowledge. And those opportunities have *increased* over time.

There are people who are concerned about public spending, others that are
concerned about creating reliable medical information, others about
adapting information for schoolchildren, others about collaborative and
open science, etc. if you look at the past proposed projects or adoption
requests the list goes on and on, and of those many only one was adopted.
It is never sure which one is going to be succesful, but if several are not
tried, then for sure they will fail because they lack leverage.

I think the biggest fear in the past was to stretch too much, or to not be
able to re-integrate the generated information into a central space (like
Wikipedia), but that is now less so. Wikidata is starting to become the
central information backbone, and what in the past looked disperse, now can
be put back together with little effort, no matter where one contributed.

One of the ideas I liked the most in Wikimania is that we could have
several projects adapted to the interest of each person or community, with
a fresh start, without so many rules, with new tools deployed there, and
generating information that can be merged back into a central space if
wished so. What is stopping us of having medical.wikipedia.org? Or
education.wikipedia.org?

I think the recent drama around MV shows that you can't teach an old dog
new tricks, or at least not as fast as the changing situation requires. If
the existing strategy is not working, and if after these years the editor
decline couldn't be stopped. Why not to try something different?

Thanks
Micru
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Gerard Meijssen-3
In reply to this post by Dariusz Jemielniak-3
Hoi,
In the metrics meeting, a presentation was given that showed that mobile
editing is really starting to happen. It is happening to the extend where
new editors are predominantly mobile editors.

When I asked my question "do we need to keep you happy" I specifically
targeted the vitriolic parts of our community. In my experience it it the
part that is conservative, not willing to listen, not open to change and
not willing to consider what is important to others.At Wikimania one of the
presenters indicated that he was willing to contribute to Wikidata. This
was not accepted because "someone in the community is really involved in
this subject and he had to have a say". This was one major person probably
walking away for ever who is hugely important in science and open data. The
user interface for selecting fonts is abysmal because the "community"
decided that what was implemented looked cluttered. Only seven percent of
the world population is dyslexic and they do NOT find Wikipedia easier to
read as a result.

Really, what is important to some people in the "community" is not
necessarily beneficial at all. The lack of conversation the ease of making
demands and not appreciating that our aim is to "share in the sum of all
knowledge" means that many retarded points of view abound.

Erik indicated that he is willing to talk and come to a workable
compromise. However, we do need change and we need it badly. When this is
not understood, I am sorry to say, those who fail to understand this are a
problem, a problem that is increasingly cancelling out their future value.
Thanks,
    Gerard


On 24 August 2014 12:49, Dariusz Jemielniak <[hidden email]> wrote:

> hi,
>
> On Sun, Aug 24, 2014 at 11:07 AM, Gerard Meijssen <
> [hidden email]
> > wrote:
>
> >
> > Now what do we aim to achieve? Keeping you happy or making sure we have a
> > public ???
> >
>
> simply put: both. We need readers just as much as we need the free labor of
> editors/volunteers.
>
> I don't think it makes any sense to have a discussion about the "wasted
> millions". First, in software development there is always some inevitable
> waste, just because of the nature of this endeavor. Second, many projects
> which start with mixed reception are getting better (and I have high hope
> that the visual editor is one of them!). Third, for an IT organization of
> this caliber and traffic, as well as the budget, there are impressive
> results in many areas (including, but not limited to, mobile website - at
> least for viewers, as editing is a different story).
>
> The real problem here, in my view, is creating an organizational framework
> that will allow to incorporate the community much more into planning, early
> development, alpha and beta testing, and finally implementation of all new
> features and tools (in a way which does not rely on IT schedules only, but
> also on feedback from the communities). It is up to WMF to create and
> provide such framework, as our community as a whole does not have any
> institutionalized representation or voice (which is part of the issue; one
> the one hand it is easy to discard whatever people from the community say,
> as they are random individuals, and on the other it must be deeply
> frustrating to never be sure what the community reaction will be). Some
> people are suggesting stewards as the good group to start with - I'm afraid
> stewards are not the best ones to go to. Stewards act mainly as highly
> trusted, experienced individuals. They do not represent their local
> communities in any way. Also, they do not necessarily have the best skills
> for the task, and they do not form a cooperating team, in general.
>
> One of the unbearable signs of bureaucracy is setting up committees, but
> here a volunteer-driven, democratic task force could actually make some
> sense, perhaps. Look at it this way - we elect admins, crats, checkusers,
> oversighters, stewards. All these roles are only technical. Perhaps at some
> point we should think of community representation as well (and not in the
> sense of leadership, but in the sense of liaisons, testers, people
> responsible for smoother communication).
>
> My experience within the FDC has shown that volunteer-driven bodies are
> quite effective at such tasks, when provided with necessary organizational
> support.
>
> best,
>
> dariusz "pundit"
>
>
>
> --
>
> __________________________
> prof. dr hab. Dariusz Jemielniak
> kierownik katedry Zarządzania Międzynarodowego
> i centrum badawczego CROW
> Akademia Leona Koźmińskiego
> http://www.crow.alk.edu.pl
>
> członek Akademii Młodych Uczonych Polskiej Akademii Nauk
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Pine W
I have heard very few people say "don't ever change the interface." I have
heard people say "don't force an interface change on me that I don't think
is an improvement."

VE was a good example. The sentiment of the community wasn't that VE''s
concept is wrong, it's that the implementation and rollout had major
deficiencies.

The MV issue is larger than than the usual editor-focused interface change
because it impacts readers as well as editors, and there were issues with
the display of licenses to readers. Personally I feel that the MV issues
are fixable but the rollout should have been handled differently, and I am
glad that the community and WMF both want to avoid repeating rollout
problems again and again.

Pine


On Sun, Aug 24, 2014 at 4:48 AM, Gerard Meijssen <[hidden email]>
wrote:

> Hoi,
> In the metrics meeting, a presentation was given that showed that mobile
> editing is really starting to happen. It is happening to the extend where
> new editors are predominantly mobile editors.
>
> When I asked my question "do we need to keep you happy" I specifically
> targeted the vitriolic parts of our community. In my experience it it the
> part that is conservative, not willing to listen, not open to change and
> not willing to consider what is important to others.At Wikimania one of the
> presenters indicated that he was willing to contribute to Wikidata. This
> was not accepted because "someone in the community is really involved in
> this subject and he had to have a say". This was one major person probably
> walking away for ever who is hugely important in science and open data. The
> user interface for selecting fonts is abysmal because the "community"
> decided that what was implemented looked cluttered. Only seven percent of
> the world population is dyslexic and they do NOT find Wikipedia easier to
> read as a result.
>
> Really, what is important to some people in the "community" is not
> necessarily beneficial at all. The lack of conversation the ease of making
> demands and not appreciating that our aim is to "share in the sum of all
> knowledge" means that many retarded points of view abound.
>
> Erik indicated that he is willing to talk and come to a workable
> compromise. However, we do need change and we need it badly. When this is
> not understood, I am sorry to say, those who fail to understand this are a
> problem, a problem that is increasingly cancelling out their future value.
> Thanks,
>     Gerard
>
>
> On 24 August 2014 12:49, Dariusz Jemielniak <[hidden email]> wrote:
>
> > hi,
> >
> > On Sun, Aug 24, 2014 at 11:07 AM, Gerard Meijssen <
> > [hidden email]
> > > wrote:
> >
> > >
> > > Now what do we aim to achieve? Keeping you happy or making sure we
> have a
> > > public ???
> > >
> >
> > simply put: both. We need readers just as much as we need the free labor
> of
> > editors/volunteers.
> >
> > I don't think it makes any sense to have a discussion about the "wasted
> > millions". First, in software development there is always some inevitable
> > waste, just because of the nature of this endeavor. Second, many projects
> > which start with mixed reception are getting better (and I have high hope
> > that the visual editor is one of them!). Third, for an IT organization of
> > this caliber and traffic, as well as the budget, there are impressive
> > results in many areas (including, but not limited to, mobile website - at
> > least for viewers, as editing is a different story).
> >
> > The real problem here, in my view, is creating an organizational
> framework
> > that will allow to incorporate the community much more into planning,
> early
> > development, alpha and beta testing, and finally implementation of all
> new
> > features and tools (in a way which does not rely on IT schedules only,
> but
> > also on feedback from the communities). It is up to WMF to create and
> > provide such framework, as our community as a whole does not have any
> > institutionalized representation or voice (which is part of the issue;
> one
> > the one hand it is easy to discard whatever people from the community
> say,
> > as they are random individuals, and on the other it must be deeply
> > frustrating to never be sure what the community reaction will be). Some
> > people are suggesting stewards as the good group to start with - I'm
> afraid
> > stewards are not the best ones to go to. Stewards act mainly as highly
> > trusted, experienced individuals. They do not represent their local
> > communities in any way. Also, they do not necessarily have the best
> skills
> > for the task, and they do not form a cooperating team, in general.
> >
> > One of the unbearable signs of bureaucracy is setting up committees, but
> > here a volunteer-driven, democratic task force could actually make some
> > sense, perhaps. Look at it this way - we elect admins, crats, checkusers,
> > oversighters, stewards. All these roles are only technical. Perhaps at
> some
> > point we should think of community representation as well (and not in the
> > sense of leadership, but in the sense of liaisons, testers, people
> > responsible for smoother communication).
> >
> > My experience within the FDC has shown that volunteer-driven bodies are
> > quite effective at such tasks, when provided with necessary
> organizational
> > support.
> >
> > best,
> >
> > dariusz "pundit"
> >
> >
> >
> > --
> >
> > __________________________
> > prof. dr hab. Dariusz Jemielniak
> > kierownik katedry Zarządzania Międzynarodowego
> > i centrum badawczego CROW
> > Akademia Leona Koźmińskiego
> > http://www.crow.alk.edu.pl
> >
> > członek Akademii Młodych Uczonych Polskiej Akademii Nauk
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > [hidden email]
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?subject=unsubscribe>
> >
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Marc-Andre
On 08/24/2014 11:19 PM, Pine W wrote:
> I have
> heard people say "don't force an interface change on me that I don't think
> is an improvement."

I do not recall a recent interface change deployment that wasn't
accompanied with, at the very least, some method of opting out.  Did I
miss one?

-- Marc


_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Todd Allen
I've found one very recently, actually, or at least if there is an opt-out
it's very opaque.

I use the desktop interface on my mobile. I've no intention of ever
changing that. There used to be an option that permanently disabled mobile
interface for a given browser (I presume via a persistent cookie, as it
worked even when I wasn't logged in), but now I have to switch back to
desktop every day or so. There are several requests at
https://en.wikipedia.org/wiki/Help_talk:Mobile_access#Turn_mobile_access_off
for a way to disable the mobile interface, but no answers as to how to do
that or if that's even supported anymore.

I'm sure I could hack around it by changing useragents or the like, but I
shouldn't -have- to use some hacky solution to it. If I don't ever want to
use the mobile interface, provide a way for me to say that and leave the
change permanent (at least until I decide otherwise).

So either I'm missing something (and I'm not the only one), or yeah, you
missed one.

Todd


On Sun, Aug 24, 2014 at 10:07 PM, Marc A. Pelletier <[hidden email]>
wrote:

> On 08/24/2014 11:19 PM, Pine W wrote:
> > I have
> > heard people say "don't force an interface change on me that I don't
> think
> > is an improvement."
>
> I do not recall a recent interface change deployment that wasn't
> accompanied with, at the very least, some method of opting out.  Did I
> miss one?
>
> -- Marc
>
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Dan Garry
That sounds like a bug to me. Have you filed a bug in Bugzilla to be sure
that the Mobile Web team is aware?

Dan


On 24 August 2014 21:13, Todd Allen <[hidden email]> wrote:

> I've found one very recently, actually, or at least if there is an opt-out
> it's very opaque.
>
> I use the desktop interface on my mobile. I've no intention of ever
> changing that. There used to be an option that permanently disabled mobile
> interface for a given browser (I presume via a persistent cookie, as it
> worked even when I wasn't logged in), but now I have to switch back to
> desktop every day or so. There are several requests at
>
> https://en.wikipedia.org/wiki/Help_talk:Mobile_access#Turn_mobile_access_off
> for a way to disable the mobile interface, but no answers as to how to do
> that or if that's even supported anymore.
>
> I'm sure I could hack around it by changing useragents or the like, but I
> shouldn't -have- to use some hacky solution to it. If I don't ever want to
> use the mobile interface, provide a way for me to say that and leave the
> change permanent (at least until I decide otherwise).
>
> So either I'm missing something (and I'm not the only one), or yeah, you
> missed one.
>
> Todd
>
>
> On Sun, Aug 24, 2014 at 10:07 PM, Marc A. Pelletier <[hidden email]>
> wrote:
>
> > On 08/24/2014 11:19 PM, Pine W wrote:
> > > I have
> > > heard people say "don't force an interface change on me that I don't
> > think
> > > is an improvement."
> >
> > I do not recall a recent interface change deployment that wasn't
> > accompanied with, at the very least, some method of opting out.  Did I
> > miss one?
> >
> > -- Marc
> >
> >
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > [hidden email]
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?subject=unsubscribe>
> >
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>



--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

svetlana
In reply to this post by Pine W
On Mon, 25 Aug 2014, at 13:19, Pine W wrote:

> I have heard very few people say "don't ever change the interface." I have
> heard people say "don't force an interface change on me that I don't think
> is an improvement."
>
> VE was a good example. The sentiment of the community wasn't that VE''s
> concept is wrong, it's that the implementation and rollout had major
> deficiencies.
>
> The MV issue is larger than than the usual editor-focused interface change
> because it impacts readers as well as editors, and there were issues with
> the display of licenses to readers. Personally I feel that the MV issues
> are fixable but the rollout should have been handled differently, and I am
> glad that the community and WMF both want to avoid repeating rollout
> problems again and again.
>
> Pine


This instance is not new; https://meta.wikimedia.org/wiki/Limits_to_configuration_changes is a historical list of similar pattern in the relationship.

They already told you that they are doing this to not lose readers, so that fundraising keeps working. Tops you can do is, like the WMF folks remarked earlier, is have community work on what it needs "from the bottom up" "grassroots" etc.

A first step here, I believe, is have the Teams track bugs in the open; from my own experience, the Flow and Multimedia folks track bugs somewhere else where I can't even view or comment (and even if I could, it being different from Bugzilla would make things harder). I'm not sure what about migration to Phabricator, but I think it's an operations style of thing (I'm yet to figure out how to get involved, but it'd make it easier for anyone to work on the new features - they are really documented on-wiki (thankfully they only internalise only bug tracking atm), although so far only in English mostly).

svetlana

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Todd Allen
In reply to this post by Dan Garry
Dan,

Filed as 69967 on Bugzilla. I'm glad you clarified that; to be quite
honest, the timing here (starting about a couple weeks ago) looked to me to
be yet another "You'll use it and you'll LIKE IT!", especially given the
lack of response at the documentation page. Sorry if I jumped to a
conclusion.

Todd


On Sun, Aug 24, 2014 at 10:19 PM, Dan Garry <[hidden email]> wrote:

> That sounds like a bug to me. Have you filed a bug in Bugzilla to be sure
> that the Mobile Web team is aware?
>
> Dan
>
>
> On 24 August 2014 21:13, Todd Allen <[hidden email]> wrote:
>
> > I've found one very recently, actually, or at least if there is an
> opt-out
> > it's very opaque.
> >
> > I use the desktop interface on my mobile. I've no intention of ever
> > changing that. There used to be an option that permanently disabled
> mobile
> > interface for a given browser (I presume via a persistent cookie, as it
> > worked even when I wasn't logged in), but now I have to switch back to
> > desktop every day or so. There are several requests at
> >
> >
> https://en.wikipedia.org/wiki/Help_talk:Mobile_access#Turn_mobile_access_off
> > for a way to disable the mobile interface, but no answers as to how to do
> > that or if that's even supported anymore.
> >
> > I'm sure I could hack around it by changing useragents or the like, but I
> > shouldn't -have- to use some hacky solution to it. If I don't ever want
> to
> > use the mobile interface, provide a way for me to say that and leave the
> > change permanent (at least until I decide otherwise).
> >
> > So either I'm missing something (and I'm not the only one), or yeah, you
> > missed one.
> >
> > Todd
> >
> >
> > On Sun, Aug 24, 2014 at 10:07 PM, Marc A. Pelletier <[hidden email]>
> > wrote:
> >
> > > On 08/24/2014 11:19 PM, Pine W wrote:
> > > > I have
> > > > heard people say "don't force an interface change on me that I don't
> > > think
> > > > is an improvement."
> > >
> > > I do not recall a recent interface change deployment that wasn't
> > > accompanied with, at the very least, some method of opting out.  Did I
> > > miss one?
> > >
> > > -- Marc
> > >
> > >
> > > _______________________________________________
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > [hidden email]
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > <mailto:[hidden email]?subject=unsubscribe>
> > >
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > [hidden email]
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?subject=unsubscribe>
> >
>
>
>
> --
> Dan Garry
> Associate Product Manager, Mobile Apps
> Wikimedia Foundation
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

John Mark Vandenberg
In reply to this post by Marc-Andre
On Mon, Aug 25, 2014 at 2:07 PM, Marc A. Pelletier <[hidden email]> wrote:
> On 08/24/2014 11:19 PM, Pine W wrote:
>> I have
>> heard people say "don't force an interface change on me that I don't think
>> is an improvement."
>
> I do not recall a recent interface change deployment that wasn't
> accompanied with, at the very least, some method of opting out.  Did I
> miss one?

Did you try opting out of MediaViewer on the mobile version?

I think the response that I received confirmed it wasnt possible.

Per-user opt-out aside, the WMF was still forcing an interface change
onto the community at large.  With VE, the WMF needed the community to
add TemplateData to all templates to help the newbies who were using
VE; with MV, the WMF needed the community to 'tag' images which
shouldnt be shown in the MV, and there is an ongoing need for the
community to 'fix' the image page syntax in order for the information
to display correctly to the end users in MV.

In both cases, significant amounts of volunteer time is required to
avoid a bad user experience.
WMF needs 'buy-in' for that, if it wants volunteers to be happy
volunteers while doing mundane work to make the new software suck
less.

--
John Vandenberg

_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Dan Garry
In reply to this post by Todd Allen
On 24 August 2014 21:36, Todd Allen <[hidden email]> wrote:
>
> Filed as 69967 on Bugzilla.


Great, thanks! I suspect this is a problem with MobileFrontend, so I've
moved the bug into that product so that people will see it. I'll keep my
eye on the bug, either way.

I'm glad you clarified that; to be quite
> honest, the timing here (starting about a couple weeks ago) looked to me to
> be yet another "You'll use it and you'll LIKE IT!", especially given the
> lack of response at the documentation page. Sorry if I jumped to a
> conclusion.
>

The Mobile Apps team typically receives messages from volunteers through
the Village Pumps (in which case the Community Liaisons know to ping me) or
by email directly into mobile-l. I personally never would've thought to
check that talk page for comments and questions. I suspect the same is true
of the Mobile Web team.

I'll update the header on that talk page to point to [[WP:VPT]] so that
people leave their comments in the right place.

Dan

--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Gerard Meijssen-3
In reply to this post by Pine W
Hoi,
Given that it is pathetically easy to opt out of the MultimediaViewer, the
amount of vitriol spouted by some is way out of proportion to the problem.
If you do not want it, opt out. But thermonuclear was was threatened,
people were to lose their job over this.

No the excuses are too little and too late. When people think that the
change is not good for them opt out. What was said was a disgrace. It has
never been in doubt that problems would be tackled.

Finally do not expect that much maintenance will be done on what is so
lightly discarded. It is fine for you to stay with your "Internet 6".
Improvements and subsequent development is just not for you.
Thanks,
    GerardM


On 25 August 2014 05:19, Pine W <[hidden email]> wrote:

> I have heard very few people say "don't ever change the interface." I have
> heard people say "don't force an interface change on me that I don't think
> is an improvement."
>
> VE was a good example. The sentiment of the community wasn't that VE''s
> concept is wrong, it's that the implementation and rollout had major
> deficiencies.
>
> The MV issue is larger than than the usual editor-focused interface change
> because it impacts readers as well as editors, and there were issues with
> the display of licenses to readers. Personally I feel that the MV issues
> are fixable but the rollout should have been handled differently, and I am
> glad that the community and WMF both want to avoid repeating rollout
> problems again and again.
>
> Pine
>
>
> On Sun, Aug 24, 2014 at 4:48 AM, Gerard Meijssen <
> [hidden email]>
> wrote:
>
> > Hoi,
> > In the metrics meeting, a presentation was given that showed that mobile
> > editing is really starting to happen. It is happening to the extend where
> > new editors are predominantly mobile editors.
> >
> > When I asked my question "do we need to keep you happy" I specifically
> > targeted the vitriolic parts of our community. In my experience it it the
> > part that is conservative, not willing to listen, not open to change and
> > not willing to consider what is important to others.At Wikimania one of
> the
> > presenters indicated that he was willing to contribute to Wikidata. This
> > was not accepted because "someone in the community is really involved in
> > this subject and he had to have a say". This was one major person
> probably
> > walking away for ever who is hugely important in science and open data.
> The
> > user interface for selecting fonts is abysmal because the "community"
> > decided that what was implemented looked cluttered. Only seven percent of
> > the world population is dyslexic and they do NOT find Wikipedia easier to
> > read as a result.
> >
> > Really, what is important to some people in the "community" is not
> > necessarily beneficial at all. The lack of conversation the ease of
> making
> > demands and not appreciating that our aim is to "share in the sum of all
> > knowledge" means that many retarded points of view abound.
> >
> > Erik indicated that he is willing to talk and come to a workable
> > compromise. However, we do need change and we need it badly. When this is
> > not understood, I am sorry to say, those who fail to understand this are
> a
> > problem, a problem that is increasingly cancelling out their future
> value.
> > Thanks,
> >     Gerard
> >
> >
> > On 24 August 2014 12:49, Dariusz Jemielniak <[hidden email]> wrote:
> >
> > > hi,
> > >
> > > On Sun, Aug 24, 2014 at 11:07 AM, Gerard Meijssen <
> > > [hidden email]
> > > > wrote:
> > >
> > > >
> > > > Now what do we aim to achieve? Keeping you happy or making sure we
> > have a
> > > > public ???
> > > >
> > >
> > > simply put: both. We need readers just as much as we need the free
> labor
> > of
> > > editors/volunteers.
> > >
> > > I don't think it makes any sense to have a discussion about the "wasted
> > > millions". First, in software development there is always some
> inevitable
> > > waste, just because of the nature of this endeavor. Second, many
> projects
> > > which start with mixed reception are getting better (and I have high
> hope
> > > that the visual editor is one of them!). Third, for an IT organization
> of
> > > this caliber and traffic, as well as the budget, there are impressive
> > > results in many areas (including, but not limited to, mobile website -
> at
> > > least for viewers, as editing is a different story).
> > >
> > > The real problem here, in my view, is creating an organizational
> > framework
> > > that will allow to incorporate the community much more into planning,
> > early
> > > development, alpha and beta testing, and finally implementation of all
> > new
> > > features and tools (in a way which does not rely on IT schedules only,
> > but
> > > also on feedback from the communities). It is up to WMF to create and
> > > provide such framework, as our community as a whole does not have any
> > > institutionalized representation or voice (which is part of the issue;
> > one
> > > the one hand it is easy to discard whatever people from the community
> > say,
> > > as they are random individuals, and on the other it must be deeply
> > > frustrating to never be sure what the community reaction will be). Some
> > > people are suggesting stewards as the good group to start with - I'm
> > afraid
> > > stewards are not the best ones to go to. Stewards act mainly as highly
> > > trusted, experienced individuals. They do not represent their local
> > > communities in any way. Also, they do not necessarily have the best
> > skills
> > > for the task, and they do not form a cooperating team, in general.
> > >
> > > One of the unbearable signs of bureaucracy is setting up committees,
> but
> > > here a volunteer-driven, democratic task force could actually make some
> > > sense, perhaps. Look at it this way - we elect admins, crats,
> checkusers,
> > > oversighters, stewards. All these roles are only technical. Perhaps at
> > some
> > > point we should think of community representation as well (and not in
> the
> > > sense of leadership, but in the sense of liaisons, testers, people
> > > responsible for smoother communication).
> > >
> > > My experience within the FDC has shown that volunteer-driven bodies are
> > > quite effective at such tasks, when provided with necessary
> > organizational
> > > support.
> > >
> > > best,
> > >
> > > dariusz "pundit"
> > >
> > >
> > >
> > > --
> > >
> > > __________________________
> > > prof. dr hab. Dariusz Jemielniak
> > > kierownik katedry Zarządzania Międzynarodowego
> > > i centrum badawczego CROW
> > > Akademia Leona Koźmińskiego
> > > http://www.crow.alk.edu.pl
> > >
> > > członek Akademii Młodych Uczonych Polskiej Akademii Nauk
> > > _______________________________________________
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > [hidden email]
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > <mailto:[hidden email]?subject=unsubscribe>
> > >
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > [hidden email]
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:[hidden email]?subject=unsubscribe>
> >
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Pine W
The issue is not just that individual users may want to opt out, it's
whether it should be activated by default for readers. There is also the
matter of licensing information.

I'm not aware of where "thermonuclear was was threatened". There were, and
continues to be, discussion about forking. MV is merely the latest
occurrence of products with major problems being pushed into production and
made default. That needs to be addressed, and the fact that the problems
with MV happened after AFT5 and VE *and* after the creation of the
Engineering Community Liaisons suggests deep, long-term problems with
product development. I believe that Lila said that the Board wants her to
transform WMF and I am glad that there seems to be agreement that Product
will be an early subject of transformation. I have reservations about
forking for reasons that I can explain if necessary. It would be a lot
easier if WMF would transform itself, starting with Product, and Lila
appears to intend to make this happen. I hope that the processes for
Product will be democratic and consensus-based. Grantmaking has already
demonstrated the effectiveness of community-based decision making with FDC
and IEGCom, and I hope to see a similar model emerge for Product. If it
doesn't, there is enough anger in the community, especially on DEWP, that a
fork is possible. The community is smart enough collectively to figure out
a way to make a fork happen, and some of us have been discussing the
mechanics of how this would work. We could do it, but reforming WMF is
preferable. I hope that Lila can and will do this. Internal transofmration
is preferable to replacing WMF.

Pine
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Gilles Dubuc
In reply to this post by svetlana
>
> from my own experience, the Flow and Multimedia folks track bugs somewhere
> else where I can't even view or comment
>

Bugs and tasks are public for the Multimedia team. If you mean "bugs" in
the bastardized sense of the term which is "things filed in bugzilla", then
yes, the Multimedia team doesn't usually file building/refactoring tasks in
bugzilla, we use mingle instead, which is public and can be commented on by
everyone: http://ur1.ca/i1x3g We regularly link to our mingle cards on our
mailing list updates, it's never been a secret area. I find that the
mailing list is a better place for discussion, though, and we summarize in
regular threads what tasks we're working on or planning to work on. In
practice that's what's always happened anyway, people interested in what
we're up to will reply to the detailed mailing list updates rather than
comment on Mingle. Probably because Mingle's comment support is terrible.

As for actual bugs (defects) on products the Multimedia team is responsible
for, they are currently tracked on bugzilla like everything else. It can
happen ocassionally that we fix a bug and forget to file it in bugzilla,
but generally speaking a bug/defect tracked in Mingle has a bugzilla
counterpart. The existing disconnect and the fact that we sometimes forget
to file a counterpart is one of the reasons we want to have a unified tool
to do all the things people currently use bugzilla, mingle and trello for.

Our team will be one of the first to migrate to phabricator when the
migration starts, because it will allow us to treat tasks, workload and
defects in a single place. It will also give a much clearer view of what's
going on to casual observers. The only reason why our team uses Mingle
instead of Bugzilla for building tasks and triage is that Bugzilla offers
no workload management and is often a poor fit for things that aren't
defects. We're definitely not using Mingle to get things out of view (since
it's public and regularly linked to), it's just that in the status quo
Bugzilla alone didn't offer what we needed. I'm sure other teams use Trello
and other tools for similar reasons. This is all coming from needs not
covered by Bugzilla and we know very well how much that sucks in various
ways, including the introduction of signup hurdles for people who want to
interact with us, and the lack of discoverability, despite linking to
Mingle every time we can. We certainly hope that the move to phabricator
will make help people see and comment on what we're doing. Feeling like
we're the only ones active on a particular tool is unhealthy for our
projects, that's definitely not what we're looking for with phabricator, on
the contrary.


On Mon, Aug 25, 2014 at 6:19 AM, svetlana <[hidden email]> wrote:

> On Mon, 25 Aug 2014, at 13:19, Pine W wrote:
> > I have heard very few people say "don't ever change the interface." I
> have
> > heard people say "don't force an interface change on me that I don't
> think
> > is an improvement."
> >
> > VE was a good example. The sentiment of the community wasn't that VE''s
> > concept is wrong, it's that the implementation and rollout had major
> > deficiencies.
> >
> > The MV issue is larger than than the usual editor-focused interface
> change
> > because it impacts readers as well as editors, and there were issues with
> > the display of licenses to readers. Personally I feel that the MV issues
> > are fixable but the rollout should have been handled differently, and I
> am
> > glad that the community and WMF both want to avoid repeating rollout
> > problems again and again.
> >
> > Pine
>
>
> This instance is not new;
> https://meta.wikimedia.org/wiki/Limits_to_configuration_changes is a
> historical list of similar pattern in the relationship.
>
> They already told you that they are doing this to not lose readers, so
> that fundraising keeps working. Tops you can do is, like the WMF folks
> remarked earlier, is have community work on what it needs "from the bottom
> up" "grassroots" etc.
>
> A first step here, I believe, is have the Teams track bugs in the open;
> from my own experience, the Flow and Multimedia folks track bugs somewhere
> else where I can't even view or comment (and even if I could, it being
> different from Bugzilla would make things harder). I'm not sure what about
> migration to Phabricator, but I think it's an operations style of thing
> (I'm yet to figure out how to get involved, but it'd make it easier for
> anyone to work on the new features - they are really documented on-wiki
> (thankfully they only internalise only bug tracking atm), although so far
> only in English mostly).
>
> svetlana
>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Erik Moeller-4
In reply to this post by Henning Schlottmann
On Fri, Aug 22, 2014 at 4:05 AM, Henning Schlottmann
<[hidden email]> wrote:

> > - The criticism isn't just about that -- it's about a large number of
> > mostly individually small issues. Generally, the idea that we
> > effectively "munge" some of the metadata by displaying a
> > machine-readable subset below the fold is viewed very negatively,
> > because 1) it doesn't reflect all the available information, 2) it
> > makes it harder for users to discover the File: page, and potentially
> > edit it.

> If it does not reflect the license information it is broken.
> We do not want

First, I think it's worthwhile in these discussions - in a context of
a project where consensus is important - to remember that there are
actually many different perspectives on Media Viewer in the community.
Even in German Wikipedia, 72 community members voted _against_
disabling Media Viewer (more in absolute terms, incidentally, than
voted for disabling it on English Wikipedia's RFC).

German Wikipedians have blogged about the fair amount of FUD that
specifically surrounds licensing and attribution issues, pointing out
that already, Media Viewer makes it far easier for re-users to
consistently attribute authorship and license information, and
provides more prominent copyright notices right below the image.

http://lieselsartikel.wordpress.com/2014/08/25/die-unwahrheiten-der-wmf-mediaviewer-hasser/
http://erinnerungshort.de/blog/eine-lanze-fuer-den-medienbetrachter/

So if we care about consensus, why pretend these voices _in the
community_ are irrelevant and wrong, rather than listening to their
reasoned arguments?

And that's the current state. I think with a little bit of effort, we
can deliver improvements that will give re-users concise hints that
are far more effective at conveying the information hidden in walls of
text today.

To be clear: The CC license text makes allowances for "reasonableness"
- and in automated re-use, whether it's in Media Viewer or elsewhere,
referring to the File: page in the absence of machine-readable data is
an absolutely defensible, reasonable decision (and one which was
vetted by WMF's legal team).

We certainly must work together to clean up the mess that is metadata
on Commons, but to block all re-use that does not include an exact
replica of the beautiful insanity of File: page templates until such a
time that every piece of information contained therein is exactly
represented in well-structured property/value pairs that can be
predictably extracted is .. unreasonable.

In any case, many of your favorite examples of de.wp local uploads
correctly display the author name and license now, e.g.:
https://de.wikipedia.org/wiki/Olympiastadion_Athen#mediaviewer/Datei:2014_-_Olympic_Stadium_(Athens).JPG

This is thanks to community members who worked with us to update the
respective templates to add machine-readable data :). As I mentioned
earlier, it's a totally fair criticism that our outreach efforts on
this front were insufficient. There are still some templates left to
be updated, and Gergo is preparing a more comprehensive cross-wiki
assessment of templates in other languages/projects.

> We do not want a default setting, that does not show extensive
> descriptions, map legends, image annotations and the like. All that is
> content we created for the readers. You must not block our readers from
> this content.

Again, the idea that software is not complete until it parses this:

[[:en:William Thomas Green Morton|William Thomas Green Morton]]
{{ImageNoteEnd|id=1}}
{{ImageNote|id=2|x=173|y=363|w=65|h=110|dimx=1600|dimy=1153|style=2}}
[[:en:James Bogardus|James Bogardus]]
{{ImageNoteEnd|id=2}}
{{ImageNote|id=3|x=235|y=365|w=78|h=108|dimx=1600|dimy=1153|style=2}}
[[:en:Samuel Colt|Samuel Colt]]
{{ImageNoteEnd|id=3}}
{{ImageNote|id=4|x=310|y=360|w=90|h=110|dimx=1600|dimy=1153|style=2}}
[[:en:Cyrus Hall McCormick|Cyrus Hall McCormick]]
{{ImageNoteEnd|id=4}}
{{ImageNote|id=5|x=370|y=365|w=68|h=95|dimx=1600|dimy=1153|style=2}}
[[:en:Joseph Saxton|Joseph Saxton]]
{{ImageNoteEnd|id=5}}
{{ImageNote|id=6|x=573|y=510|w=90|h=98|dimx=1600|dimy=1153|style=2}}
[[:en:Charles Goodyear|Charles Goodyear]]
{{ImageNoteEnd|id=6}}
{{ImageNote|id=7|x=588|y=430|w=85|h=93|dimx=1600|dimy=1153|style=2}}
[[:en:Peter Cooper|Peter Cooper]]
{{ImageNoteEnd|id=7}}
{{ImageNote|id=8|x=650|y=510|w=80|h=80|dimx=1600|dimy=1153|style=2}}
[[:en:Jordan Lawrence Mott|Jordan Lawrence Mott]]

is unreasonable. If that's your standard of "broken" and "abysmal
track record", your rhetoric is a bit exaggerated, but perhaps the
reference to "black uniforms and heavy boots" in an earlier message
was a dead giveaway.

Image annotations loaded via the community-created gadget are a
beautiful hack (indeed one of my favorite gadgets of all time), and if
the current implementation can be rendered in MediaViewer without
negative performance impact and at reasonable cost, we'll get there.
If not, let's migrate these annotations to a more supportable system
in the long run and treat it as a File: page feature for now.

The more reasonable thing to ask for (which we've already implemented
in the prototype) is a more prominent link to the File: page which
encourages people to go down the rabbit hole if they want to, while
giving them a quick image preview to begin with.

Erik
--
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
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
Reply | Threaded
Open this post in threaded view
|

Re: [Wikimedia-l] Next steps regarding WMF<->community disputes about deployments

Gerard Meijssen-3
In reply to this post by Pine W
Hoi,
Actually the issue is no longer only that. It is also very much about how a
subset of people high jack the conversation by their uncompromising stance.
When they feel they might leave, I personally prefer it when they stop
their posturing and decide either way.

When they want to stay, they do not need to be welcomed, they are part of
us. When they go, they are welcome and they can take with them everything
we have in the sense of data and software. It is then for them to show that
their proof is in their pudding. In the mean time WMF will continue to
engage in best practices both technically and socially and when they cook
something nice, what is on offer is there for the eating as well.

As far as I am concerned, put up or shut up.

It has been advertised widely that bugs will be squashed. It is also
advertised widely that changes will be considered as long as they are
reasonable and do not interfere with our prime directive.  Again, it is
about the readers not super users.
Thanks,
      GerardM


On 25 August 2014 11:16, Pine W <[hidden email]> wrote:

> The issue is not just that individual users may want to opt out, it's
> whether it should be activated by default for readers. There is also the
> matter of licensing information.
>
> I'm not aware of where "thermonuclear was was threatened". There were, and
> continues to be, discussion about forking. MV is merely the latest
> occurrence of products with major problems being pushed into production and
> made default. That needs to be addressed, and the fact that the problems
> with MV happened after AFT5 and VE *and* after the creation of the
> Engineering Community Liaisons suggests deep, long-term problems with
> product development. I believe that Lila said that the Board wants her to
> transform WMF and I am glad that there seems to be agreement that Product
> will be an early subject of transformation. I have reservations about
> forking for reasons that I can explain if necessary. It would be a lot
> easier if WMF would transform itself, starting with Product, and Lila
> appears to intend to make this happen. I hope that the processes for
> Product will be democratic and consensus-based. Grantmaking has already
> demonstrated the effectiveness of community-based decision making with FDC
> and IEGCom, and I hope to see a similar model emerge for Product. If it
> doesn't, there is enough anger in the community, especially on DEWP, that a
> fork is possible. The community is smart enough collectively to figure out
> a way to make a fork happen, and some of us have been discussing the
> mechanics of how this would work. We could do it, but reforming WMF is
> preferable. I hope that Lila can and will do this. Internal transofmration
> is preferable to replacing WMF.
>
> Pine
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> [hidden email]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[hidden email]?subject=unsubscribe>
>
_______________________________________________
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[hidden email]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:[hidden email]?subject=unsubscribe>
12345 ... 8