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>
