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