Straniu, Jimbo's comments in his keynote about forking concerned encouraging competent editors who can't work cooperatively with other people to fork in a way that would be better for everyone in the long run. I don't believe this disappointing confrontation between the WMF and volunteers were what Jimbo had in mind.
Pine On Aug 12, 2014 1:44 AM, "Strainu" <strain...@gmail.com> wrote: > Hi Gerard, > > Some answers (in a random order). > > 2014-08-11 12:20 GMT+03:00 Gerard Meijssen <gerard.meijs...@gmail.com>: > > You know our projects, you know our licenses. If you, the "community"do > not > > like what you have, you can fork. At Wikimania forking and leaving the > > community was very much discussed. Watch Jimbo's presentation for > instance, > > he may be aghast that I quote him here but in his state of the Wiki he > made > > it abundantly clear that it is your option to stay or go. > > I gave up watching Jimbo's keynotes a few years ago, as I would > invariably get pissed off. So, should we understand that the vast > ammounts of money and resources spent on editor retention are a waste > of our money? I sincerely hope this is a heat-of-the-moment argument, > just like the one about closing de.wp. > > > Hoi, > > Code review should be a strictly technical process surely. However the > > community CANNOT decide on everything. > > Agreed. How about letting the WMF decide for anonymous users and the > community decide for logged-in users? Presumably, the logged-in users > have access to a large panel of options and can make up their own mind > if they disagree with the consensus. Of course, discussions should not > disappear because of such a separation, but even become more active > and hopefully less aggressive. > > > > When you are in those conversations you realise that many > > complications are considered; it is not easy nor obvious. > > NB there is not one community, there are many with often completely > > diverging opinions. Technically it is not possible to always keep > backward > > compatibility / functionality. We are not backward we need to stay > > contemporary. > > As a software engineer in a publicly traded company, I understand the > reasoning behind more than 90% of the decisions made by the > Engineering staff - and this worries me terribly, because they *don't* > work for a company. Their objectives and approaches should be > different. > > There are three main wiki-use-cases that should receive similar levels > of attention: > * reading > * basic editing > * advanced editing > > The first two receive a lot of love, but the third one not so much, > it's even hindered by initiatives designed for the first two. I'm not > saying that we should keep backwards compatibility forever, but since > the WMF wants to deploy stuff early in order to get feedback, it > should begin by offering it as a beta (they do that now), then, when > reaching a decent level of stability, deploy it for anonymous users > and opt-in users and only when it reaches feature-parity with the > feature being replaced should it be pushed for everybody (keeping an > opt-out feature for some time - months or a couple of years). > > Take for instance the media viewer: the current version is useless for > editors, as it has basically no controls visible by default (without > scrolling). The future version, presented at Wikimania, has a lot more > stuff visible on the first screen, making it much easier to use for > editing. I believe that the media viewer should have been kept as > opt-in for logged in users until this future version arrives. > > Strainu > > _______________________________________________ > Wikitech-l mailing list > wikitec...@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimediafirstname.lastname@example.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>