one more general level solution would be having more steps: proposing a solution to the community (checking for support), inviting willing testers, after positive feedback introducing to all logged in users, and after positive feedback propagating on the site as a whole.
Once the initial support for an idea is established, we can take for granted that the change should happen - but it should be up to feedback to see if the solution is ready, and not up to the developers' calendar (we've all seen what happens when the schedule is the in the case of visual editor premature launch).
I think that WMF perhaps takes way too little use of our community as testers, commentators, supporters. If the community was more involved in development plans, it would also not be surprised by solutions which perhaps are important and wise in the log term, but still should not jump out of the box and be perceived as forced.
I don't think it makes any sense to perceive WMF as just a servant. But how should we perceive the community? Is it a disorganized mass with no uniform voice, that should be shepherded into accepting solutions? Is it a valuable resource? Is it a full partner in planning, testing and implementing the solutions? I think that a lot of the latter is missing, and the fault is on both sides. But it is mainly up to WMF to change it, as WMF has the structures, staff, and resources to propose procedures there.
just my two cents, anyway.
dj "pundit"
On Fri, Aug 22, 2014 at 7:54 AM, rupert THURNER rupert.thurner@gmail.com wrote:
Am 22.08.2014 04:18 schrieb "Erik Moeller" erik@wikimedia.org:
On Wed, Aug 20, 2014 at 12:32 AM, Pine W wiki.pine@gmail.com wrote:
I am curious to hear your thoughts about the proposed Technology
Committee.
That idea has some community support and had been discussed at some
length
on the WMF Board Noticeboard.
I think it has merits if it's mostly used as a dispute resolution body. I think we need to have conflict resolution and escalation protocols for technology issues. Ideally WMF and a group of community members (whether in all cases truly representative or not) who are in conflict about a certain issue or outcome should be able to come to a consensus _between each other_. But when that's not possible, a group that is designed to be accountable to both WMF's mission and the community's consensus may need to be called upon to make a final call that is binding. In the current governance structure, that could be a group like the stewards. But it could be something new created for that purpose, if the community supports it.
This all presupposes that we collectively sign up for this whole "shared power" idea. It's a Board creation, a guiding principle, and all that. But that doesn't mean the community of people who've spent much of their lives building Wikimedia's projects as volunteers do believe in it. Maybe we should ask them, as a group, offering the pros and cons of that approach. It's very different futures -- a WMF that exists purely to do what communities ask it to, or a WMF that exists - in part - to look forward, close gaps, and help anticipate where we want to be 3, 5, 10 years from now. Irrespective of what my own take might be, both approaches do truly have their merits.
If we sign up collectively for "shared power", then today, we lack the mechanisms to implement that principle effectively, which is why we have conflicts over power which is not shared. And a community elected committee (perhaps with some additional representation of external expertise) might be one such mechanism, but if we don't have agreement on the basic idea, no mechanism will work. If we do agree on the principle, we can try and play with different implementations.
erik, let me ask a little in a devils advocate style:
is the conflict not only triggered by a deliverable which was not good enough? it did not include the authors in its use cases. the deliverable e.g. did include one click more for the authors workflow. which make hundreds of million clicks more if you sum it up.
in a standard business world we would see two scenarios: one, the ecyclopaedia britannica model. the authors would own the web domain, and sue the one who delivers bad software. the design needs to be properly specified beforehand to do this.
two, the facebook model. a company providing software to author as primary goal, and some mechanism built in to count reads. it does everything to increase it and would right from the start not deliver a complicated author experience.
the wmf tries to play both models. and it then suffers schizophrenia. the one delivering insufficient software does not get punished.
the reason is very simple: wikipedias content is of such high quality that one might leave it with little updates for the next 20 years. also, the readers experience is of such high quality that one might leave it for 20 years.
as somebody delivering software i understand your feelings quite well. you get dug into a hole and do not know a good way to get out.
introducing additional levels of complexity is a well known strategy. but we all know from our daily lives that we do tend to not like these levels and bureaucracy.
erik, please can you tell me one good reason what hinders you to tackle the source of all this, and rework the mediaviewer use case(s)?
devils adcocate mode out.
rupert _______________________________________________ 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-request@lists.wikimedia.org?subject=unsubscribe