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