About RFEs
Bugs and Request For Enhancements (RFEs) are the two primary ways the Tikiwiki Development community gets new tasks. The public and team members are encourgaged to submit Bugs and RFEs as often as neccessary, so that the team can build the best quality and most feature-rich product.
The Tikiwiki Development Team makes extensive use of SourceForge's "Tracker" system to maintain bugs and RFEs. Because we have a lot of activity, these trackers can quickly get very big, very quickly, and become a nightmare to manage. As such, we've imposed a bit of self-organization on the tracker entries, namely with Groups and Categories.
- RFE sourceforge page
http://sourceforge.net/tracker/?group_id=64258&atid=506849
Filling out a Proper Bug Report or New RFE
Please Remember: The more information you log on a Bug or Feature Request, the faster it will get attention and the quicker it will run through the development and release process!
Do see if your item has already been reported / requested, and add your comments onto that one.
Do set the proper Group and Category for your item.
Don't give something a Group or Category if you aren't sure - set them to "Unknown" instead.
Do log in to SourceForge before you add or update an item - so we know who you are and can contact you if needed.
Do give all information you can, what you were doing when it broke, screen shots, detailed information about your new feature idea.
Groups and Categories Explained
The Tikiwiki Team uses tracker Groups and Categories extensively to properly sort and query Bugs and RFEs. Having the proper groups and categories is critical to make sure your item is seen by the right person and gives it a better chance to be fixed or added. Don't worry - we constantly groom the trackers to make sure that entries have the proper values, so if you don't know, please set them to "Unknown".
RFEs: Groups
RFE Groups represent the "type" of Feature Request:
| Group | Description | |
| Compost | a partially good idea, but not something that is directly applicable. "Compost" items should be closed, with a nice note and then routinely gone back through to gain good ideas. The analogy is that like organic compost you take "dead" ideas and use them to make other ideas grow | |
| Documentation | Documentation ideas | |
| Feature Enhancement | Enhancing a currently existing feature - adding something to it, tweaking it, etc. | |
| Installation | Request for a change to installation | |
| Need More Information | Something to use to send back to the person who asked for it, to get more information from them. Perhaps if they dont get back in a few weeks, these should probably be closed, or composted | |
| New Feature | Brand new, top level feature. (I want Tiki to have a text to speech component so I can download MP3's of CMS articles or I want Tiki to butter my bread each morning) | |
| Refactor Code | If a developer has ideas on how to refactor portions of the co | |
| Unknown | The fall back group when all else fails. | |
RFEs: Categories
RFE Categories represent the feature "area" that the request is about:
| Category | Description | |
| Administration | Administration modules / reports | |
| Themes and User Experience | The themes and any usage flows / user experience type of requests | |
| Unknown | Anything that doesn't fit into one of the other categories | |
Note: RFE categories are not complete. We'll be adding more of them as we go through and process the RFE's that we do have, or that people suggest. If you have other RFE Category suggestions, please share them on the tiki-devel list.