Hoi,
I am getting so pissed off.
Let us be realistic. The user experience sucks ... It sucks big time and
even though the "community" is comfortable with it, it impedes the use by
the people we do it all for. They are the READERS.. they are not the
editors and the least this is done for are the people who are so indignant
because their experience changes.
When you look at the last year, the biggest changes are driven by the
development for mobiles. The projections make it plain this is where our
customers will be. The existing Wikipedia with its monobook and what have
you skin will not be seen, used or be relevant to them. Our traffic is
transitioning to mobile. Editing starts to happen on mobile and if it is
not clear to the "community" that future development will be in this
direction they live under a rock or they are in denial.
Have a look at a Commons page on a mobile.. It is beyond bad and beyond
useful. With the Multimedia viewer it becomes useful. (NB there are things
in there that are brain dead but that is a different story)
WAKE UP. Our world is changing. Trying to shame the WMF development in a
different direction is counter productive, ill considered and even
destructive. When you are the "community", and when this is new to you, I
hope you will sit back for a moment and consider this. When this does not
make a difference to you, there is always the right of departure. In my
brutal opinion we have no option but to move towards a more mobile centred
appreciation. The alternative is stagnation and irrelevance. That does not
need to happen when we accept that the world changes around us.
Thanks,
GerardM
On 14 August 2014 17:28, Tim Davenport <shoehu...@gmail.com> wrote:
> Re: Erik Möller's remark: "In general, though, let's talk. The overarching
> principle we're not
> going to budge on is that this process is really not acceptable:
>
> 1) The UI changes
> 2) A subset of users is upset and organizes a poll/vote
> 3) The poll/vote closes with a request to undo said UI Change and a
> request is filed
> 4) WMF offers compromise or says no
> 5) A local hack is used to undo said UI change
>
> That's no way to develop software, and that's no way to work together...."
>
> =========
>
> I could spend 10,000 words on this. I'll try to keep it (comparatively)
> short.
>
>
> The reason this dysfunctional situation develops, Erik, is because there
> are no steps A, B, C, D, E, F, and G preceding #1 on the list.
>
> As things currently stand, this is the way the software development process
> at WMF seems to me to work:
>
> * Engineers collecting paychecks obviously need something to do.
> * Someone comes up with a bright idea that sounds good on paper.
> * Engineers decide to make that idea a reality and start work.
> * Inadequately tested software, sometimes of dubious utility, is
> unilaterally imposed on volunteers.
> * If new software is problematic enough, volunteers revolt by any means
> necessary.
> * WMF forces changes down throat of volunteers by any means necessary.
>
> This is truly "no way to develop software" and "no way to work together."
>
> -----
>
> Here is the way the process SHOULD begin:
>
> * WMF staffers, plural, identify by user names/IP addresses the 10,000 or
> so very active volunteers across all projects and database them.
>
> * WMF staffers further divide this group into coherent "types": content
> writers, gnome-type copy editors, structural adapters (template people, bot
> operators, etc.), quality control workers (NPP, AfD), vandal fighters,
> behavioral administrators (ArbCom, Ani, the various Admin pages), and drone
> bees who do nothing but Facebook-style drama mongering. Multiple categories
> may apply to single individuals and this list is not necessarily
> exhaustive.
>
> * Once identified, WMF staffers frequently and regularly poll very active
> users in each category about WHAT THEY NEED. Different surveys for
> different volunteer types.
>
> * Software development starts ONLY when a real need is identified.
>
> * Software should be introduced on En-WP, De-WP, or Commons ONLY when it is
> Alpha-grade, debugged and ready to roll. (Test things on the smaller Wikis
> first).
>
> -----
>
> Moreover, there should be some polling mechanism to summarize and analyze
> what the 500 million or whatever readers worldwide feel that they like and
> feel they are missing. "User experience" changes with primary impact on
> readers rather than volunteers (such as MediaViewer) should be made with
> them in mind first and foremost; editing and structural tools should be
> made to actually assist the active volunteers, not created on a whim.
>
> Sometimes the needs of the Readers and the needs of the Volunteers are
> different, let us frankly say. In no case should WMF assume the views and
> criticism of the latter are insignificant or wrong simply because
> 500,000,000 > 10,000.
>
> Remember this because according to the same logic: 10,000 > 240.
>
> -----
>
> We all agree that we need a bigger pool of very active volunteers. Most
> readers are never going to be very active volunteers, nor do we want them
> to be, since we need specialized skill sets. Most people using the editing
> software are only going to make one or a very few changes a year and they
> are never going to even "see" the backstage world of Wikipedia. That is
> normal and fine.
>
> We do need expert contributors on esoteric topics and we need solid
> contributors from the developing world and we need to replenish the people
> doing copy editing and quality control work.
>
> We don't need tools that nobody asked for and nobody wants shoved down our
> throats just because engineers needed something to do.
>
>
>
> 240 Paid Staff + 10,000 Serious Volunteers + 500,000,000 Readers and
> occasional minor contributors
>
> Three groups with differing needs.
>
>
> Tim Davenport /// "Carrite" on WP /// "Randy from Boise" on WPO
> Corvallis, OR
> _______________________________________________
> 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>
