Forum OpenACS Development: Response to Software Development (Bugs, QA, etc) and OACS

I think that the central question for me, at least, is what should SDM and/or ticket-tracker be? I listed a few items that in hindsight may be completely different systems.

For instance, it may very well be that Bug tracking, QA tools and Support tools are totally different beasts. An initial, and incomplete, user-perspective requirement list for each package may be:

  • Bug Tracking
    • Need to list bug
    • Is the bug a security issue?
    • What is the priority of the bug?
    • Who found the bug?
    • Who will fix the bug?
    • Is there a fix for the bug?
    • Once the bug is fixed where does it go?
  • QA
    • Who submitted the piece for QA?
    • Who is testing the piece for QA?
    • What is the problem?
    • Who does it get routed to?
    • What is the hypothesis for the problem?
    • Where does the piece go when the problem is fixed?
  • Support tool
    • Who is accessing the support tool (client or developer)?
    • What is the problem?
    • What is the priority of the problem?
    • Is it a feature or a bug?
    • Is it a helpdesk question or a bug?
    • Who should the problem be routed to?
    • How long did the fix take? (track hours in order to charge client)
    • There should also be a bboard instance for clients to post questions.
When I think of what each of these pieces need, I think they look a lot like what SDM is now. But in practice, I have a sense that there are subtleties in their requirements that aren't really consistent throughout. In fact, I kind of think that QA is much different than Support and Bug tracking, at least from what I've written down.

So whether this stuff is accessed via a portal interface or its own page flow is a very minor question right now. The big deal is, as Don mentioned, whether we can muster the resources to work on this.

IMHO, this kind of software could be huge for the community, as SDM currently is. But SDM's interface is lacking as I don't feel it's terribly user friendly as is. Better than most systems, but as often is the truth, it can be improved alot.

As Malte promised and since this is pretty important for our business if we're going to charge clients for support, I'd be willing to devote developer resources to help a community wide effort.

talli