mirror of
https://github.com/moparisthebest/Simba
synced 2024-12-22 15:28:50 -05:00
More on Doc TODO and added bugreport info.
This commit is contained in:
R0b0t1
parent
d7f664fc81
commit
ab6dcc2684
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -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?
|
||||
|
||||
|
||||
|
||||
@ -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!
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user