[Wikimedia-l] Patience

Wed May 15 08:29:25 UTC 2013

Florence,

I agree with you almost completely, but I would also note that it is also
partially about the user's thought processes and business norms that
determine how "fast" it is. My employer, for instance, has a wiki that's
meant to be a collaborative resource where disparate elements from across
the (several thousands of persons with access) organization can quickly
iterate on a document the same way we make revisions to our wikis. In
practice, however, we are so accustomed to a high level "waterfall style"
process as you describe, with a primary author and several interested
parties "clearing" the copy, it completely loses any benefit of the process
and becomes no different to me than a Sharepoint site with slightly better
UI.

-Dan

Dan Rosenthal

On Wed, May 15, 2013 at 11:16 AM, Florence Devouard <anthere9 at yahoo.com>wrote:

> Just yesterday during a meeting, a working partner of mine said that he
> really could not understand why on earth we were insisting so much that
> "wiki" meant "quick". Whilst the edit itself maybe done very quickly, it
> actually lead people installing wikis to believe this will accelerate the
> production process (=increase productivity).
>
> It is actually incorrect; In most cases, collaborative editing using a
> wiki does actually take MORE time than the traditional back and fro of a
> document written on a desktop editor and forwarded to others by email (or
> dropbox or whatever). Traditional way of doing things is actually so boring
> than most multi-authored documents end up being essentially written by one
> and lightly copyedited by others, a process which is often much quicker
> than the slow and laborious co-writing process on a wiki.
>
> Of course, the second is likely to result in a better document, so that
> the argument to use a wiki should be "better documents" rather than
> "quicker process".
>
> (No reference to conflict here. It is just a side thought emerging from my
> mind as I read this post about patience)
>
> Flo
>
>
>
>
> On 5/15/13 9:31 AM, Chris Keating wrote:
>
>> Thank you Michael for the thoughtful post!
>>
>> I very much agree. I read somewhere (don't ask me for a citation!) that
>> the
>> physiological effects of anger - increased levels of adrenalin and
>> cortisol, high heart rate, and the like - take about 30 minutes to return
>> to normal after something happens that makes you angry.
>>
>> Back in the day if you received a letter that made you angry, you would
>> have several hours to write an immediate response, which would then
>> probably take several more hours to reach its recipient, who would
>> probably
>> respond the next day... plenty of time for the physical reaction of anger
>> to subside.
>>
>> Email, usenet, PhPBB, wikis and the like means there is a technological
>> method of ensuring that responses can be written and shared instantly (and
>> angrily) and, indeed, in heated threads you can quite happily exchange
>> messages which provoke an emotional response quickly enough that your
>> flight-or-fight reflex is being triggered repeatedly over a period of
>> hours
>> with every ping of your inbox.
>>
>> So basically; yes, I agree.
>>
>> Regards,
>>
>> Chris
>>
>>
>>
>> On Wed, May 15, 2013 at 7:45 AM, Michael Snow <wikipedia at frontier.com
>> >wrote:
>>
>>  I originally wrote this message last year on a nonpublic list. It seemed
>>> to be well received, and some people asked me to share it publicly, but I
>>> didn't get around to it then. I think this would be a good time to share
>>> it
>>> here now. It is not specifically directed at recent issues here, but I
>>> think it does have some relevance. (I have some thoughts more directly
>>> related to those matters as well, which I hope to share when I have time
>>> to
>>> write them down. That might not happen until late Friday, which is
>>> probably
>>> not the best time for it, but based on recent history perhaps I can still
>>> hope some people will be reading then.)
>>>
>>> Internet technology is known for letting things happen much faster than
>>> they did before we were all so connected. This speed now seems normal to
>>> us
>>> and, being immersed in that culture, we have come to expect it. Wikis, as
>>> one aspect of that culture, have the feature of making that speed a
>>> personal tool - you can make something happen right away. How many of us
>>> got involved because we saw a mistake and figuratively couldn't wait to
>>> fix
>>> it? And when we discovered that we literally didn't have to wait, we were
>>> hooked.
>>>
>>> One result of this is a culture that caters to impatience, sometimes even
>>> rewards it. And that's why we are often tempted to think that being
>>> irritable is a way of getting things done. We imagine: this problem
>>> should
>>> be instantly solved, my idea can be implemented right away, I will be
>>> immediately informed about whatever I care about. But as our culture
>>> grows
>>> in scale, none of that remains true (and perhaps, we get more irritated
>>> as
>>> a result).
>>>
>>> I wish I could say that because it's a matter of scale, technology will
>>> take care of things because that's how we handle scaling. However, the
>>> issue is not about whether the technology will scale, but whether the
>>> culture will scale. On a cultural level, scaling issues are not handled
>>> by
>>> technology alone. They are handled by establishing shared values (be
>>> bold,
>>> but also wait for consensus), by agreeing upon standard procedures (which
>>> provide important protections when designed well, but also introduce
>>> delays), and by dividing up responsibilities (which requires that we
>>> trust
>>> others).
>>>
>>> That last bit is critical; people have repeatedly suggested a certain
>>> mistrust underlies the repeated flareups. Well, the reason that mistrust
>>> has grown so much is because we are often impatient, and take shortcuts
>>> in
>>> order to "get things done" (or so we believe). The impatience manifests
>>> on
>>> all sides--to illustrate: volunteers get impatient about the effort
>>> needed
>>> for any kind of policy change, chapters get impatient about requirements
>>> to
>>> develop internal controls and share reports on their activities, staff
>>> get
>>> impatient about time involved in consulting with the community. Everyone
>>> thinks it would be so much better if they were free to just do things and
>>> not have to deal with these hassles. But in every one of these scenarios,
>>> and I'm sure I could come up with many more, if we let impatience guide
>>> us,
>>> inevitably more trust will be drained out of the system.
>>>
>>> Patience as a virtue is in short supply on the internet. It is not native
>>> to our culture, but we must apply it in order to scale. Fortunately, it
>>> is
>>> simply a matter of maturity and self-control at appropriate moments. I
>>> encourage us all to practice it.
>>>
>>> --Michael Snow
>>>
>>>
>>> ______________________________****_________________
>>> Wikimedia-l mailing list
>>> Wikimedia-l at lists.wikimedia.****org <Wikimedia-l at lists.wikimedia.**org<Wikimedia-l at lists.wikimedia.org>
>>> >
>>> Unsubscribe: https://lists.wikimedia.org/****
>>> mailman/listinfo/wikimedia-l<https://lists.wikimedia.org/**mailman/listinfo/wikimedia-l>
>>> <h**ttps://lists.wikimedia.org/**mailman/listinfo/wikimedia-l<https://lists.wikimedia.org/mailman/listinfo/wikimedia-l>
>>> >
>>>
>>>  ______________________________**_________________
>> Wikimedia-l mailing list
>> Wikimedia-l at lists.wikimedia.**org <Wikimedia-l at lists.wikimedia.org>
>> Unsubscribe: https://lists.wikimedia.org/**mailman/listinfo/wikimedia-l<https://lists.wikimedia.org/mailman/listinfo/wikimedia-l>
>>
>>
>
>
> ______________________________**_________________
> Wikimedia-l mailing list
> Wikimedia-l at lists.wikimedia.**org <Wikimedia-l at lists.wikimedia.org>
> Unsubscribe: https://lists.wikimedia.org/**mailman/listinfo/wikimedia-l<https://lists.wikimedia.org/mailman/listinfo/wikimedia-l>
>