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.meijs...@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 <martijnhoeks...@gmail.com> > wrote: > > > On Aug 31, 2014 11:46 PM, "Pine W" <wiki.p...@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-requ...@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-requ...@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-requ...@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-requ...@lists.wikimedia.org?subject=unsubscribe>
