[Wikimedia-l] Patience

Wed May 15 13:41:14 UTC 2013

True

Yet... on the other hand... on many "private" wikis, there is
- either no one to do that job of curation/tagging/cleaning (in which 
case the wiki ends up being... a collection of disparate elements with 
no benefits in terms of "gaining time when looking for information")
- or that job is done by an appointed person (in which case, the wiki 
ends up being organized based on the mindset of one person rather than 
based on the actual thought processes of most users).

In both cases, the promise of "fast" search (fast find) fails.

Flo

On 5/15/13 10:34 AM, Andrea Zanni wrote:
> I don't know if relates opn what you said,
> but I'd add that a wiki is a great way to work on different, related
> documents at the same time,
> and it's useful t tag/categorizes them, and to have a bunch of integrated
> documents
> all together. Writing all together a single document is difficult also on
> Etherpad,
> because, well, people don't share their minds.
>
> Aubrey
>
>
> On Wed, May 15, 2013 at 10:29 AM, Dan Rosenthal <swatjester at gmail.com>wrote:
>
>> 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>
>>>
>> _______________________________________________
>> Wikimedia-l mailing list
>> Wikimedia-l at lists.wikimedia.org
>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
>>
> _______________________________________________
> Wikimedia-l mailing list
> Wikimedia-l at lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
>