Mr. Steve,
Currently you have an issue tracker on the site. Is it like the plone forums, such that the data is not stored in a retrievable database system?
Also, it does lists things in certain categories but we are somewhat limited there. Some issues might have several categories they fit under, as yours currently allows. Also though there might be more categories, and even relations between issues.
Consider as an example one of the issues I am going to post is, "All Items set by INI files.". So this is a request to take everything that is in the standard dataface and allow it to be set with ini files, rather than things like delegate classes. Well in that case we will definitely have things below that request. Such as Title set in ini. Menu position set in ini. Further it might be broken down by which INI. Though not necessarily. Even if not, later on, as the issue begins to be dealt with, it will need to be moved to the appropriate ini file. Consider the system we are having you work out for us this week. The AJAX tree. We could use that, mingled with some changes to my current planning system to achieve the following:
+Bugs
-Requests
-User Interface
-All Dataface settings set by INI files
-Title set by ini
-Logo set by ini
-Menu Position set by ini
-Field CSS #ID set by ini
-Fields.ini Settings
-Field CSS #ID set by ini
+Data Logic
+SQL Stored Procedures
This I think is possible now because the current Issue Tracker only has 19 items on it. So it is easy enough to move those to Dataface itself (if not already stored within dataface). Or, the other option if you are preferring to not consider moving to a Dataface Based Issue Tracker, is that I can start to input into this tracker, than give you the data in a format that yours can import from (CSV?). And lastly if this would not be an option then I can simply start to enter all of these issues into the current system.
I think the advantages of this Dataface Based system would be:
1.As feature requests fulfilled, they are moved to the fulfilled requests tree.
2.This is then would be very very easy to copy over into the documentation tree.
3.Changes in the future are a snap.
4.Certain Developers could be assigned to these one off tasks much more easily.
5.Code snippets for the fix could be attached right into a text field. This to be used
when Dataface is Updated.
6.The state of integration with the Dataface Codebase could be noted.
7.Someone (myself, NJW, another) could volunteer and be assigned to check the forums daily, moving issues from there to the Issue Tracker. So we dont have to wait months to do it, and we dont lose track of which issues are answered and which are not. (Also the same person would put a link from the forum to the issue.
8.Since the issue could then be moved to documentation, we would have a list of answers for singular issues. So if someone wanted to know how to set a field to do such and such, in the forum we would just link them to the Tracker docs.
9. We could add keywords so that in searching, if someone wanted to know all the SQL examples..there it is, or all the field examples..there they are. (All of this is still seperate from the actual Dataface Users Guides, Programmers Handbooks, References and so on..just one off explanations albeit in a tree format so that we can drill down.)
There are other advantages of course, since it would be in MySQL and Dataface directly. I already have much of the Dataface ini code ready for this. And with your tree list, I think it would complete another good portion. I just have to add the fields that you have on the issue tracker. Of course my goal is, to have as much Dataface Developement features, created with Dataface itself. This would be one of those first steps to moving in that direction.
