[Wikimedia-l] Patience

Andrea Zanni zanni.andrea84 at gmail.com
Wed May 15 08:34:23 UTC 2013


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
>


More information about the Wikimedia-l mailing list