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.thur...@gmail.com> wrote: > Am 22.08.2014 04:18 schrieb "Erik Moeller" <e...@wikimedia.org>: > > > > On Wed, Aug 20, 2014 at 12:32 AM, Pine W <wiki.p...@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-requ...@lists.wikimedia.org?subject=unsubscribe> > -- __________________________ prof. dr hab. Dariusz Jemielniak kierownik katedry Zarządzania Międzynarodowego i centrum badawczego CROW Akademia Leona Koźmińskiego http://www.crow.alk.edu.pl członek Akademii Młodych Uczonych Polskiej Akademii Nauk _______________________________________________ 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>
