Perhaps a discipline can help us solve the problem: “Attack the DocumentMode.”
This idea is that we should orient our ThreadMode conversation towards one of two things:
“Tossing” refers to just throwing out the ThreadMode conversation when we’re done. If what we’re saying is chatter that won’t affect the page, we should say, clearly, “This is chatter. Please remove later.”
If it’s not chatter, and is meant to be reworked into the DocumentMode text, we focus the discussion on the DocumentMode text. When issues are resolved, we adjust the DocumentMode text, and delete the ThreadMode that led up to it.
If it’s not chatter, but it doesn’t fit on the present DocumentMode text, generally that means we need a new page. Move discussion to another page. If there are things that are mutually agreed, delete it from the ThreadMode, and write it quickly in the DocumentMode.
Do it fast! Remember that knowledge lives in our heads, not in documents. If you miss a detail, that’s okay. If it’s an important detail, someone will point out that you forgot to move it.
WriteForDocumentMode I have tried to write for DocumentMode, but it doesn’t always work out. That is what this bit of wiki text is meant to be: a formatted comment that is written, and “anchored”, to make it easy to include into the DocumentMode part of the page.
Alex and I were discussing this in the IRC channel. We both thought it was a good idea, where applicable. What do you think?
I never heard back from anyone about this. I don’t want to engage in “tossing” if it’ll offend anyone, though. Taking people’s comments and ripping them out- I don’t know.
Maybe we should establish some sort of expectations- “don’t toss comments that are less than 3 months old,” or something.
I think Tossing would help us focus on the DocumentMode.
At Wiki:DocumentMode, some people suggest moving signed comments to the homepage of the person who signed them, rather than deleting them. Your suggestion: “Move comments that don’t fit to a more-relevant page” is better (and works even with unsigned comments). – DavidCary
As lomg as you have space in your cellar - and we almost have infinite space there - what’s the use in throwing away anything at all I ask? Why do we copy real-life’s forgetfulness onto wiki when we actually do not need too. We have so many disadvantages here to direct communication, the lack of para-language for instance, why don’t we use the few ones we have? Our perfect memory. Why not leave the archive thread-mode intact and copy something, when it’s getting interesting again instead of moving it? We have the space, we have 10, 100, 1000 times the space. Clean, dry, rat-free cellar space for infinite archives. Our tread-mode is a protocoll how ideas evolve, they are precise due to the timestamps, a precious data-base for history and a couple of dozens of other sciences. Not now, but maybe already in a year.
We need a clever and practicabel syntax for archiving, that’s all. A little practize.
And either don’t say what you wouldn’t like your boss to hear, get rid of the boss, or - if you have the necessary admin-rights to do it - delete it. So far the noodles.
This page actually describes how I’d always hoped wiki would work – people reworking documents to be more to their liking directly than having discussions that maybe get worked into the documents. And as for “deleting” the discussions – I can see what Mattis is saying – a history of how the idea evolved is a good thing to have. However, doesn’t the wiki keep copies of the versions? So the discussions are saved, but take a little work to get to. This could encourage new people to participate, as opposed to seeing something like PainfulTalk / PainfulTalkHistory and feeling overwhelmed by the history there. Also, by making it a rule that threads get refactored or deleted, it could act as an incentive for people to work on the document directly, as opposed to making a comment and then having it thrown out. (P.S. If I don’t get blown away for this I’ll rework parts of it into the document section of this in a few days)
I’m fine with forever archives. I’m also fine with ForgiveAndForgetInSoftware.
For me, it’s:
I think ideally, we’d have both archival and ForgiveAndForgetInSoftware. If people wanted to nuke something, they could. But otherwise, things would just slip into the archives.
I imagine DocumentMode text should slip into some sort of archive as well; If it’s not edited in 9+ months, it should probably say so at the top of the page. Editing it would be enough to bring it to the fore.
As for DavidCary’s suggestion: Moving peoples text back to their page is, I believe, a slap in the face- at least, that’s how I’ve always interpreted it. I don’t know, it’s like: “Here’s your junk- you figure out what to do with it,” even if it’s not intended that way. (This is just my personal feeling.) More importantly, it takes a lot of labor on the part of the person doing the relocation.
Hidden in the multilingual experiment cluster - which has its own recent changes down at the end of the page (like every other cluster here) -, you find: How to archive pages? There’s a proposal for a syntax on it.
Yeah; I dunno…
I just wish it were automatic.
Keeping track of archives and naming pages and copying and pasting text and stuff- such a chore.
I won’t delete anyone’s old text, then, without archiving it. But, I think we suffer for it.
a slap in the face ? I suppose so, but I haven’t found any more-polite way to deal with text that obviously (to me) doesn’t belong to a page. (What alternative do I have ? (a) don’t touch it, just let pages grow and grow until they are so full of redundant and now-irrelevant stuff that they become useless; (b) move it to an archive-page, which becomes filled with now-irrelevant stuff that nobody reads; (c) simply delete it – even more rude).
Imagine my dog jumps the fence to my neighbor’s back yard. I’d much rather he move the dog (and anything the dog may deposit) back to my back yard, rather than simply shoot the dog.
I vaguely remember hearing about an elementary school that changed their standard report-card form. The old one had a blank “comments” field where the teacher could free-form write anything. Apparently some parents were mis-interpreting positive comments like “a good student” in a negative way: “Rather mediocre – intelligent, but he do a lot better if he wasn’t such a lazy bum”. The new form had a list of standard pre-printed comments. If your kid had the top comment check-marked, you knew that your child was doing great – no need to read between the lines. And if your kid had the bottom comment check-marked, you knew he was doing terrible – no matter how flowery the euphemism printed next to it.
When I move people’s text back to their homepage, I want to leave them with a polite impression something like “Your comment was so good that I thought it deserved a little extra bit of my time to preserve it. I think it was relevant at the time you posted it, but now the document mode on page __________ has changed enough that the comment would now be redundant. Many people have urged me to delete such text, but it was so beautifully written that I thought that would be a shame. If you think it’s still relevant, you are free to move (still-relevant bits of) that comment right back to the page to which you originally posted it. Or perhaps you can find an even more-relevant page for that comment.”
OK, I lied. I do know one more-polite way of dealing with it: “Move comments that don’t fit to a more-relevant page” myself.
I’d just huck it all. Old conversation from 3 months ago? Huck it.
Archiving comments would be cool, if it was automatic, like Google Mail. (Yes, this is something I’ve been thinking about: A wiki that lets you have conversations like Google Mail, and that lets you archive conversations just as easily.)
But if it takes effort to archive comments and stuff, then basically, for every single comment, you are guaranteeing that people must read it over and over and over again in the future, and figure out what to do with your words.
I really don’t want to be in the obligation-manufacturing business. The approach of trying to keep every single comment reminds me of that song- “Every comment’s sacred, every comment’s good…” It’s a bit Catholic.
I sense an article in the making… This is not unrelated to issues in Notebooks.
Ideally, we’d have easy gmail-style archival. However, until that day comes, I’d just wipe it.
I guess I’m very Shinto (forward-looking) in my Wiki approach.
For me there exists a lack of support of slow transformation of comments into DocumentMode.
I would like to keep the comments/talk as long, as I (or others) think, that there is something valuable therein, which was not included in this or other pages document mode. Some kind of annotation tools are missing, supporting a step by step transformation, something in between of black (keep it) or white (delete it), fading ideas out, which are tagged or commented as beeing reworked.
If I remember correct, this toppic has been discussed also on a different place (discussing the benefits of implementing single-comment = single-object / page ).
When comments are objects, and when TransClusion writes true pages, then we’ll be on our way.
WriteForDocumentMode I have tried to write for DocumentMode, but it doesn’t always work out. That is what this bit of wiki text is meant to be: a formatted comment that is written, and “anchored” to make it easy to include into the DocumentMode part of the page.
I’m new to CommunityWiki, and I haven’t even read a half of the conversations that took place here. Until I familiarize myself with the content of this wiki, I feel I’m just a visitor. But it takes a lot of time, and once in a while a page like this one will surface on the RecentChanges, and I discover something I didn’t know about before. Yes, it’s quite nice, but it’s also telling me to learn more before opening my mouth.
As for not removing things because important things may be lost – if you don’t remove anything, they are lost already. To create, you need to make decisions. These decisions are often very hard – and that’s good! The harder the decision is, the more value you add by making it. FeatureKarma works because of it. This especially applies to user interface design, but is also present in all forms of creation:
Hey, Michelangelo, how do you make these beautiful statues of angels?
That’s easy, you just remove all the pieces that don’t look like an angel.