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 <swatjes...@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 <anthe...@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 <wikipe...@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@lists.wikimedia.****org <Wikimedia-l@lists.wikimedia.
**org<Wikimedia-l@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@lists.wikimedia.**org <Wikimedia-l@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@lists.wikimedia.**org <Wikimedia-l@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@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
_______________________________________________
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
_______________________________________________
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
