diff --git a/Doc/sphinx/TODO b/Doc/sphinx/TODO index 97d1211..4ba6000 100644 --- a/Doc/sphinx/TODO +++ b/Doc/sphinx/TODO @@ -1,9 +1,6 @@ # Change a minus to a plus when something is being worked on. # Remove it when you are done. - - - # GENERAL - Run spellcheck before you commit (make sure you ignore section names diff --git a/Doc/sphinx/bugreport.rst b/Doc/sphinx/bugreport.rst index efe941c..3bed13e 100644 --- a/Doc/sphinx/bugreport.rst +++ b/Doc/sphinx/bugreport.rst @@ -4,3 +4,33 @@ Reporting Bugs ============== Report all bugs at http://bugs.villavu.com/ + +Make sure you do a quick search for your bug to see if it already exist. If it does, +click its link and add any information you can into the comments. If your bug does not +exist, follow these steps: + +1. Upon opening that page, you should see a "Report Issue" link. Click this. +2. Now, you should select the project to report to. Use the following criteria: + - If the problem is with the GUI, choose "Simba". + - If the problem seems to be in the library, choose "MML". + - If the problem is not in one of the above or you know it is an SRL function + causing the problem, choose "SRL". + If you can not decide, choose "Simba". The developers can move the ticket as needed. +3. Now, choose the Category that the bug is in. This should be self-explanatory; choose + a topic related to what you were doing when the bug occured. Choose general if you + are unsure. Developers can, again, change the ticket if required. +4. Select the reproducability. If this is a request for a feature, choose "N/A". +5. Severity should be ranked according to how much the bug affects the program. + Crashes will be dealt with first, then blocks, etc. This step goes along with + priority, which should be chosen along with the severity. +6. Version, at this time, is not needed for Simba and MML issues. If the issue occurs + with an older script, choose "SRL 4 Compatibility". +7. Now write the summary of the bug. Choose something better than "Does not Work". If, + for example, you were experiencing a crash of the program when trying to use the OCR + to scan the character "~" on the 30th of February while you were woodcutting willows + with an iron axe, a suitable Summary might be "Crash While Using OCR on Specific Char". +8. Using the same example for above, a Description should explain the problem while being + concise. This field is not the field for technical details, simply describe the problem. +9. Include any technical details such as what exactly you did, etc. Use pictures if + possible. +10. Finally, hit submit. It should return successful. diff --git a/Doc/sphinx/docdoc.rst b/Doc/sphinx/docdoc.rst index 4ab4b55..1f8655e 100644 --- a/Doc/sphinx/docdoc.rst +++ b/Doc/sphinx/docdoc.rst @@ -39,7 +39,7 @@ http://docutils.sourceforge.net/docs/user/rst/quickstart.html As stated above, the markup language is not the hard part about writing documentation; the hard part is simply coming up with good content suited for -the documentation. +the documentation. Be sure to check :ref:`todo` Directory structure ~~~~~~~~~~~~~~~~~~~ diff --git a/Doc/sphinx/todo.rst b/Doc/sphinx/todo.rst index c1ef122..095c537 100644 --- a/Doc/sphinx/todo.rst +++ b/Doc/sphinx/todo.rst @@ -1,35 +1,20 @@ +.. _todo: + Documentation TODO ================== - -* bugreport. Put general ``rules`` for commiting bugs in there. - What to report, what not to report, - check if a bug already exists, what info should be - added, etc. - -* whatsnew. it's still very short, we could probably add some of the latest - features. perhaps some info about the script manager. - -* script manager (non technical) I (wizzup) will do this myself - -* script manager (technical) I (wizzup) will do this myself - -* extend getting started. this probably requires some script manager stuff - +* **WIP** - What's New. Changelog template added, fill it with stuff. +* *Wizzup* - Script manager (non technical). +* *Wizzup* - Script manager (technical). +* Extend "Getting Started". Include downloading scripts from the manager. * think of good chapters for the complete tutorial. (it should teach basic stuff, not document all features. script reference is for that - * write a lot more chapters for simba references. There's plenty to document. - -* add problems (+ solutions if any) to troublshooting. - * write working with files for scriptreference (or any other chapter) * Expand "Troubleshooting" - - And its subsection. + - And its subsection. * Expand "Feature Overview" - And its subs. There's like nothing in them, those are the type of pages I was talking about. Combine them under feature overview? - - diff --git a/Doc/sphinx/whatsnew.rst b/Doc/sphinx/whatsnew.rst index 6e1bcc4..4e8031a 100644 --- a/Doc/sphinx/whatsnew.rst +++ b/Doc/sphinx/whatsnew.rst @@ -6,3 +6,16 @@ You will probably notice some parts of the documentation aren't finished or are plain missing. So what's new in Simba? This documentation system. + +Simba is being updated almost every day. To see changes as they are added, view +http://git.villavu.com/?p=simba.git;a=summary. Each commit should be explained +tersely in one line, and the exact changes can be viewed with "commitdiff". This +is a very verbose list of changes, large features or changes will be listed below: + +Changelog for X.XXX:: + + - Did some stuff + - Important note about stuff here. + - Other stuff + - Jesus Christ even more stuff! +