___________________________________

Common Issues Documentation Archive
___________________________________

DISCLAIMER:
    This archive has been made privately by me (Artex) and each documentation here follows the
    standards I set for them. The documentations inside were done for the sole purpose of educating
    beekins or users on various issues they might not be aware of and they come to suggest ways to
    solve these issues. These files in no way dictate the manner a beekin helper should handle a
    help call in.

    The documentations in this archive were NOT verified with Dragon's Eye Productions (DEP) and were
    not validated by them! They are in no way official and should be treated as a suggestion to keep
    in mind. Should you wish to follow the instructions described in these files, you are doing so at
    your own discretion and risk. I should not be held liable for the loss of helper privileges, should
    following these instructions be against DEP's beekin policy!

    The text in this archive comes to help the user and the beekin and would normally not be considered
    "illegal", but if you are unsure with this and are worried to lose your access, you can always
    check with a group head if following the suggestions here is an acceptable thing to do.


OVERVIEW:
    This documentation archive has been created and is hosted by Artex for the purpose of general
    beekin (or user) education. It contains a list of various Furcadia-related issues that have been
    brought up in front of the author and various information about them.

    Each file is divided into four parts:
        1) The document header, containing the "serial number" of a particular case (it's pretty much
           meaningless, just easy to address problems in a big list), the documentation author info,
           creation and (optionally) modification timestamps, stating what version the document
           currently is. The rest of the data is the group relation (which beekin group this particular
	   issue normally belongs to), problem section (some sort of group to which the problem can be
           associated) and a brief title of the problem itself.

        2) The problem description - this part contains a simple description of what problem does the
           user have and how would they generally describe it to the helper. This section aims to give
           general information on what would bother the user and how would they commonly explain
	   themselves in order to describe this particular case. (Known as the "What?" section)

        3) Problem itself - this part describes what exactly is wrong in this particular case and what
           happens inside the system to cause the inconvenience the user would like to report. This
           section aims to give information to the helper on what's truly going on and shows them on
           how would one explain the user's particular problem. (Known as the "Why?" section)

        4) Solution to the problem - this part contains detailed instructions on what to do with the
           user in order to work around the problem they face. It suggests various ways on how to
           handle the problem and what to suggest the user to successfully solve the help call and
           this case. (Known as the "How?" section)

    The file list itself has no particular order - the case numbers raise as soon as a new one is
    written, regardless of where the case belongs. The sorting will (hopefully soon) be done by the
    relation or problem groups in a dynamic website.
    
    You are welcome to share the information provided here with your friends or the others, I hope it
    can be as useful to the rest as it was intended to be in the first place.


COPYING/SHARING:
    Should you ever want to copy the material stored in this archive and use it somewhere else for
    whatever purpose you see fit, share it or publicly expose it, feel free to do so under the following
    conditions:
        1) You are to leave a credit to the original author of the documentation as a token of respect
           towards him and his work. Under no circumstances you are to claim that the documentation is
           your personal work! It is a bold lie and simply shows that you can't do absolutely anything
           on your own, relying on others to steal credit from.
        2) Should you need to reformat the text in the documentation in order to fit a certain website
           layout or another format standard you'd like to have, feel free to do so. However, you may
	   not modify the text itself! Should you see a need to do the modifications in question, it
	   would be greatly appreciated if you could ask for permission first. You are expected to
	   leave a note that the data was modified by yourself so you will not be impersonating the
	   original author by adding/changing things that they wrote.
        3) [Optional] If you ever find the information here useful, it would be appreciated if you could
           leave a note to the author, stating so. Knowing that the work is actually being useful to
           someone greatly encourages further development and improvements in it. Suggestions and
           feedback is also welcome.
___________________________________