I've been thinking about writing a issue tracking system myself, because I feel the existing options are all too complicated for my needs. I'm a Python fan, so Trac was first on my list. I figure Trac will either support the workflow I want in my issue tracking system or I can find ways to contribute and customize Trac.
In a sentence: I'm looking for a system to help organize tasks among several users and several projects, and the system should serve as an archive for discussions and files related to these tasks. More telling is that I don't need any features related to programming and source code, timelines, roadmaps, a wiki, etc. All the issue trackers I'm aware of just have too many features given prominent display when they're not needed. Users complain that there's 20 fields on the screen and they only ever use 2 or 3. The system I've envisioned is build with 3 key concepts, which I'll explain: Users - A user account, email, password, etc. A user interacts with the issues they have access (permission) to. A user may have access to an issue either directly or through a group membership. Groups - A group of users. A group can have many users, and a user can belong to many groups. Permissions granted to the group are granted to the groups members. A group can also contain other groups. (I've seen "roles" distinguished from groups in some systems, by allowing groups to contain other groups you can have complex multilayer grouping. If an administrator insists on using "roles" then they can create these roles as groups.) Issue Types - A definition or template of a specific issue type. Issues are all instances of an Issue Type. Each Issue Type can have several attributes or fields. Each attribute has fine grained access controls, so you might allow a user to only see a certain attribute, and only have read access to that attribute. Attributes would be things like "pick list", "user pick list", "text field", "discussion", "file". Creating Issue Types would be the most complex task in the application, but wouldn't need to be done often. An example Issue Type might be a software bug. You define a software bug to have a title (a free form text field), assigned to (user pick list), and priority (pick list, with "high" and "low"), estimated work required (a free for text field), discussion (a place for discussion, similar to typical web forums). You make the estimated work required field editable by developers only, since only a developer is qualified to make that estimate; yet the manager could still view the estimate once it was made. The ultimate goal of this system would be to minimize the amount of irrelevant information users have to see. My system wouldn't directly support multiple projects, but through managing permission and properly organizing users and group you could achieve the same thing. Users of the Project_1 group would see only Issue Types relevant to them, and likewise for Project_2. The two projects could be complete separate, or have some overlap in the issues they could view. I mention this last point because we previously abandoned Trac at my place of work because it didn't support multiple "projects" but I wondered if this could be worked around using permissions similar to what I have proposed? I post this hoping to have some helpful advice from the Trac community. Hopefully Trac can solve my problems and save me some work, otherwise I'll consider creating my own solution. I also post because I believe people should attempt to improve an existing project before blindly starting yet another project, but sometimes new projects are necessary. -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com. To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.
