_   _ 
| \ | |
|  \| |
| . ` |
| |\  |
\_| \_/
       
       

         
|\     /|
| )   ( |
| |   | |
( (   ) )
 \ \_/ / 
  \   /  
   \_/   
         

         
         
  #####  
 ##  ##  
 ##  ##  
  #####  
     ##  
     ##  

 ##      
 ##      
 ##  ##  
 ## ##   
 ####    
 ## ##   
 ##  ##  
         

  _   _ 
 | | | |
 | |_| |
 |  _  |
 |_| |_|
        

IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now.


Visit Preferences to set your user name
Summary of change:
'''This page collects common misconceptions, fear, uncertainty and doubt related to wiki''' ---- If you want to read or speak to the other side of the spectrum, see ForumVsWiki. ---- 19th century: '''When the telephone was invented, most asked this:''' Why would I want to talk to someone who is not there with me ? '''People did not understand first that there is point in passing over information geographically.''' Most didn't have relatives living far, and just thought that they can easily walk to anyone who they want to talk to. 21st century: '''People will take more time to understand that there is point in passing over information in time''' ( for future, persist it in a sane way). Most think that anything can be looked up in the list archive (forum) anyway. Wiki is the tool that helps summarize and persist the best bits of information instead of burrying it among noise. I felt the same why-s with wiki (as 19th century people) before I realized its potential and learnt more (easy) ways of usage (including how it can completely substitute older ways of info-storage). * the team has some clear ProjectGoals. Many nice features, to many people, affordability; more fun than keystrokes * the only cost here is time: required manhours must be minimized. Additional costs must be added too (eg. time needed to explain sg. new to people). It seems many think that additional benefits (that can themselves absolutely justify the related additional costs) are hard to account for (eg. the way of organizing information can be used beyond EFI-land). This is not for comparison of people in any way. It is '''purely''' for '''comparison of time required for a given (complex) task'''. Because of the nature of the issue, some causes (why we tend to like L despite L is scientifically proven to be inferior) must be understood. It does not make sense to take it personally. ---- '''Mailing lists are used''' - see ListsAndForums Because some people prefer mailing lists for different reasons (such as an aggressive firewall they cannot remove, or maybe without any good reason). For any good invention, it took a while before people realized how it can be used for their own benefit (and some might never realize it or not admit). Please consider saving yourself and others a huge amount of time and use tools that make more efficient collaboration possible. Remeber that '''one can do anything with wiki that one can do with a forum''': * Any '''page can be used as a BLOG''' (weblog). This means information is '''organized chronologically'''. Often a horizontal line is used, the date is written and optionally the author. This is 100% mimicing the "one message after the other" way of mailing lists and forums * every '''such wiki page is the equivalent of a mailing-list or forum thread''' * RecentChanges shows what changed (new pages and edits). This provides the push-media feature of email, enables following actions on a day-to-day basis without missing anything. Historical information can be retreived, for any page, between any 2 revisions. With a mailing list one usually misses a lot if not following for a few days, and reads much obsoleted stuff if he wants to be sure to not miss anything. With wiki this is not the case. These provide the '''same working model as mailing lists''' (or forums), '''with the same serious problems:''' * high level of duplication * most of it outdated information * incomplete: lotsof merging is needed to extract uptodate status * almost impossible to search (searches will mostly hit outdated, incomplete info): you end up reading 10x more and merging several posts as you read to get uptodate status Note that these are '''very inefficient ways to work'''. ---- But '''email and chronological forums have these inherent shortcomings''', they cannot do better. Why do people still love email and chronological forums ? Because '''mailing lists and chronological forums have some miserable properties that fit human nature perfectly''' '''Feeling important''' - This is the primary factor. * one, who asks a question that gets answered feels that he is important. * the one, who answers a question feels important too. On a mailing list it is considered helpful to answer even if it's just repetition of info from others from old mails. * there is lot of place to show up without any useful content. "me-too" mails or endless discussions that forget about the idea to come up with something useful (solution/compromise/result) and just focus on arguing. The good side of wiki is that it can also provide someone the 'feeling of importance', actually with content (maybe just his own project) that's worths to read for others and at a later time too. '''Neglegance''' * one usually does not care if others need to work more or less. * after I found out what I need (my question answered), who cares about anyone coming after? (with the same questions) * I organize info for myself, but won't help others: they should organize their own. '''Lazyness''' * it's easiest to ask questions without doing suitable searching * it's easiest to just answer to an email list (often changing topic without changing to a descriptive subjects, of course): '''thinking''' about where some information belongs can be '''hard'''. This thinking '''does not pay back instantly''', only in the long run - and maybe not pay back directly at all, but useful for others (see neglegance above). '''Property''' * I '''won't correct or improve what other's wrote''', and '''they should not change what I wrote'''. There can be many causes (like laziness, neglegance or feeling of importance) behind this. But using other's work and refusing to improve it intentionally (when given the chance) is parasitic. Such attitude can contribute information either in wiki (usually with slighty inferior, redundant usage) or email, but only indirectly: '''building the knowledge base almost always require to update/improve what others wrote''' (so best done in wiki). '''Certainty''' With a mailing list, it is very clear how to reply: trim old message to the reasonable minimum and answer each part at the bottom of that part. This is the best that can be done, still far from good. With wiki the same is possible, but there are better ways and it forces a choice: what to do with the work of other people? Don't worry, anything you do is better than it would be in email. Do what you feel appropriate, this will get easier after some practice. In most cases the questions should not be answered with an answer, but rewritten as a statement (question goes away). Atleast in the main Wiki (under MembersPage we often leave it on the owner to do a summary and cleanup from time 2 time). If answer is short, look around if it can be grouped with other similar issues. For long answer, consider if it needs a paragraph or even a page of it's own. If you try to answer to your best, noone can take it as offense or taking away credit. These characteristics that make a mailing list appealing can be understood, but it would be poor to justify bad ways of working and communications by these. Communications made human from the animal, and we should not stop looking for more advanced and time-saving tools. Of course '''forums and email can be used until a user understands how his project must be summarized properly''' so he can get the best results and best support. But we should not pretend that it's a good way, and kindly propagate to do it properly - at the minimum with '''answer at the right place (in wiki) and provide just links to the forum'''. Useful info just into a forum (without entering into the wiki knowledge-base) is a mistake: consider the forum what it is: a junkive, work down the drain. '''other reasons''' * one with a hammer, tends to see everything as a nail. Email is everywhere, and firewall administrators often make more harm than use - "God forgive them, they know not what they are doing." '''Patching the Mailing list''' - not a perfect solution but make the bad usable * to try to keep down duplication, a searchable knowledge base must be maintained for every mailing list: FAQ + some organized information page maintained by self-sacrificing individuals * abstracts like the wonderful example of [http://www.kerneltraffic.org/kernel-traffic/latest.html kernel-traffic] These concepts are useful in wiki too, but require much less effort: a properly used wiki is converging to a knowledge base naturally. ---- '''GenBoard/Manual''' is very important. Some people misunderstand this, so better to state it clearly: there is no such question like "wiki or manual is better". Manual is a (knowledge base) "product" which is clearly needed . Wiki is a tool that can be used to create that product. Mailing list cannot be used to create it (only to assist) but wiki is more efficient in assistance too. There are good tools that help in any case. ---- Wiki is not a miracle tool that creates value by itself. '''Wiki just provides methods that''' (when used properly) '''make a higher value out of the same amount of input effort. The exact same usage patterns that are available in wiki's competitors''' (forums and mailing lists) '''are available in wiki as well'''. As long as just these usage patterns are applied (and advanced ones are neglected), the wiki will be the same trash efficiency as the competitors. Wiki cannot ensure that sufficient work is put into a certain subject. Wiki can only guarantee that the results will not be worse than with a forum given the '''same amount of effort (manhours)'''. Either way, one needs some cleanup sooner or later to provide anything useful and permanent. Fortunately, '''cleanup is easier in wiki and least likely to be forgotten''' (not needed in the ideal wiki case but practically needed). ---- more advanced '''Version Tracking Systems''' Wiki can be considered a "version tracking system", with some embedded formatting. The above advantages can be utilized in other version tracking systems as well. There are more advanced version tracking systems (like CVS, GenBoard/FirmWare/CVSUsage ). Programmers use them all the time, average persons rarely. Since they're just a storage / version tracking tool, users are free to choose usage rules, formatting, semantics. There is nothing about them that couldn't be learnt from IQ > 95 (Bush could learn it easily, so you too), but it is just not widely known. VEMS uses CVS for firmware, and SVN (subversion, another similar version tracking system) will most likely be used for storing the manual source in the future. While wiki is about 10 times more efficient (measurably) than mailing list, the difference between wiki and other version tracking systems is marginal. The info a '''given team can organize in wiki in 10 man-year would cost about 100 man-years with a mailing list''' (since the mailing list does not converge to a useful book-like set of pages, some people will need to sum up from time to time: but most of the resources are just burnt when reading outdated, badly formatted info and searching inefficiently). The difference, 90 man-years is about 9 million dollars. You can easily find mailing lists in EFI (or other) topic (with over 1000 subscribers) that burnt more resources than that. I wish they used better tools... ---- '''New tools needed''' most likely XML Version tracking by itself is just not enough. We have proof :-) By doing all the Q&A in the wiki we have a bunch of trash all over the place and constant maintenance is required. Unfortunately this is true. Draining resources with absolutely inefficient forums would make the problem much much much worse. The clutter would be missing but so would 90% of useful info (at least if we fairly compare 10 manhours of maintenance L way to 10 manhours W way). The only '''good solution is to mark the information as Q&A while editing so it can be hidden from users at will'''. XML comes to mind. Some believe that to get all of the discussion and questions outside of the wiki would serve to clean it up and make it a better tool. It would worht to name the ''outside wiki'' part. If it's forum or mailing list, it's easily proven that this belief is just wrong. Someone who cannot do in wiki cannot do it with mailing list either (remember to compare fairly - same manhours). Remember that anything that's possible in a mailing list is possible in wiki the very same way in every case. The only solution that was proposed and seem to attack these issues is markup, eg. XML. Some of the clutter should just be removed. It's no use to put it anywhere. It remains in history if needed for any reason. '''Are there other secret tools that HELP THESE PROBLEMS NOT MAKE THEM WORSE ?''' - let's name them If someone feels the need for something better for day to day chat and tech help, it would worth to mention something that is better. The only good way is scientific (in this case pure economy) comparison. Try to tell your boss that solution L) costs a million bucks more than W) and takes longer, but you want to do A) because ... feel ... and collegues like it also... Good luck.
Optional: Add document to category:
Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.