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
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Reply via email to