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