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 <[email protected]>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 <[email protected] >> >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 >>> [email protected].****org >>> <[email protected].**org<[email protected]> >>> > >>> 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 >> [email protected].**org <[email protected]> >> Unsubscribe: >> https://lists.wikimedia.org/**mailman/listinfo/wikimedia-l<https://lists.wikimedia.org/mailman/listinfo/wikimedia-l> >> >> > > > ______________________________**_________________ > Wikimedia-l mailing list > [email protected].**org <[email protected]> > Unsubscribe: > https://lists.wikimedia.org/**mailman/listinfo/wikimedia-l<https://lists.wikimedia.org/mailman/listinfo/wikimedia-l> > _______________________________________________ Wikimedia-l mailing list [email protected] Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
