Changes between Initial Version and Version 1 of FAQs/WhatInformationShouldIProvideForTheMailingList

Show
Ignore:
Timestamp:
01/07/10 14:27:57 (16 years ago)
Author:
DanWilson (IP: 65.190.16.149)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • FAQs/WhatInformationShouldIProvideForTheMailingList

    v1 v1  
     1== Before asking the question == 
     2 
     3    * Check the FAQ (http://docs.model-glue.com/wiki/FAQs) to see if it answers your question. 
     4    * Search the docs at http://docs.model-glue.com/wiki/ to see if you can find the answer. 
     5    * Search the documentation and the mailing list here: [http://www.model-glue.com/blog/page.cfm/ModelGlue-Support-Search Model-Glue Support Search]  
     6 
     7 
     8== Required Information for support == 
     9 
     10    * What version of Model-Glue you are using? (look in the README.txt in /ModelGlue) 
     11    * What CFML Engine you are on, and what version it is? 
     12    * What Operating System you are on? 
     13 
     14== Required information if an error has occurred == 
     15 
     16    * The URL of the request 
     17    * Where the webroot is 
     18    * Which webserver you are using 
     19    * The FULL error trace, including all templates, the line the error occurred, and the full error message. (This does not need to include the Java Stack trace, unless we specifically ask for it, or it is the only error details you have) 
     20    * The surrounding code that the error is occurring at, along with an explanation of what it does 
     21    * The relevant configuration XML (this can be done as an attachment, or pasted at [http://modelglue.pastebin.com] if the email is already quite large)  
     22 
     23== Some things to consider == 
     24 
     25    * There can never be too much information in a support request 
     26    * Make sure you search all available resources first - including this google group.  Asking a question that has been answered a zillion times tends to irritate people, and irritated people don't tend to give out help. 
     27    * If you are not in front of the error / issue / computer, its probably better to wait until you are, because you are just going to get asked for more specific information, e.g. an exact copy paste of the error. 
     28    * If you're not sure if you should write something down, write it down anyway, in case it is actually needed 
     29    * Feel free to dig into the framework and see if you can work out what the issue is, in fact, its encouraged 
     30    * If it is a complicated issue, a small test bed available for download which shows off the issue/bug is highly appreciated 
     31    * Nobody on this list gets paid to help out, so 'Be Excellent to Each Other'.  It pays off in the long run. 
     32 
     33* this document was created by re-purposing large swaths of the most excellent [http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer How To Ask Support Questions On Transfer] by [http://www.compoundtheory.com/ Mark Mandel]