__      __
 \ \    / /
  \ \  / / 
   \ \/ /  
    \  /   
     \/    
           
           

 ___   
(  _`\ 
| ( (_)
| |___ 
| (_, )
(____/'
       
       

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

______ 
| ___ \
| |_/ /
|  __/ 
| |    
\_|    
       
       

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

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 lists instructions that are easy to follow, but they can save many of your hours and headaches''' * organize thematically, not chronologically (it's OK to keep a blog, but keep it separate, and don't depend on it). * keep info updated (so you'll see what's open) * keep related info together (not necessarily on one page, a set of pages is usually better if the topic is longer than 3..4 paragraphs and there is a nice dimension to slice according) * keep separate info separate * use exact reference (links) where possible ---- '''extra info just wastes bandwidth''' * construct a message that your engine does not start up. Be sure to '''not include any logs'''. The best, if you don't even link to the setup, because it is more fun for the reader to find the relevant info. * the '''comments in the mcd files are plain stupid'''. Maybe good for kids only. For experts, it is trivial to look up the relevant info about injector sizes and number, and do the calculation in head; so putting the calculation in comments just wastes valuable bandwidth. ---- '''formatting makes the webserver wear faster''' * try to mix everything about your engine in one paragraph. '''Don't make separate sections for injection and ignition, as they would just confuse the reader''' * if you think something would be useful (like FETdrivers, diodes for flyback), '''don't make a list. Try to hide that info in the middle of the text'''. A list would make it too easy for others to send you the stuff (let it be HW or maybe a link). ---- '''references are harmful''' * NEVER write "Summary of change" in the wiki - that's just wasting bandwidth * If you write ''Summary of change'', make sure it doesn't summarize the change. If you just add a link, don't make a ''Summary of change'' like "GenBoard link" because that would make it possible for others to see the change and open the new page directly. When moving info from one page to another, don't write "moved .. to" or "moved .. from" into the summary, that would make it easy to overview what's going on. * don't set the preferences when editing pages. That would reveail your identity; better kept secret. * refer to files in emails sent earlier. It doesn't matter if they were sent months ago, and there was no clear indication if they really received it. Don't mention filenames and dates, sizes, those are not necessary to identify files at all. * when you ask a question, '''don't ever show what research you've done, what you found, where you would expect the answer;''' But beware: if you post just the question (especially if on a nonrelevant page), someone will just provide a link. Eg. just ask what is value of C23, someone will refer to a schematic or datasheet. If you say I looked up appnote ... (link, pagenumber) example schematic has 100nF but I'm unsure that suits my install, someone might confirm the issue. * '''make new empty pages. Don't link the pages relevant to that topic, and don't move information there.''' A perfect way for confusing anyone who looks for info => finds the new empty page and probably stops looking further - disappointed (without finding the relevant page). ---- '''history vs. keeping uptodate''' * a history of what happened is always enough (even if it's different messages, even if it's email, even if some might have been lost), as '''it is always trivial to merge info and reconstruct the current state from the history'''. * the best idea is to have outdated and new, hot information on one page, without any indication of the outdated stuff. * when your plans are realized, make sure they are not updated, but kept to seem like plans. * in general, '''don't try to keep an uptodate page of the ''latest'' state''' of the project, that would make it too easy for the Russians to copy and improve. '''We would hate if they get to Mars earlier than we, wouldn't we'''? * when you send around files in email, always add some mystery: compare to "version a long time ago", without adding version numbers. Do not add short description of what the binary file contains (such as "2-part frontplate with pegs"). The best way is to mixmatch filenames with other products, such as frontplate/endplate (is it really so hard to name frontplate frontplate and endplate endplate? I can't believe that even several developers get it wrong!) ---- See also: TermsOfAgreement
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.