Forum OpenACS Q&A: Response to How sould we setup bugtrackers for projects on the new openacs.org

This is my personal opinion and has not been cleared with the entire Sloan team, although as far as I know no one disagrees. :)

The audience for bug tracker is developers not decision makers.  The audience for .LRN/.WRK marketing should be decision makers, people with money.  We want them to understand we have a tool that has been successfully used to solve problems just like theirs.  They really shouldn't be all that interested in individual bugs.

It does not seem to me to be a problem if a developer working on a educational project see's the openacs brand when they goto bug tracker.  In fact, I think it would be very confusing to see one header when reporting a bug in dotlrn-forums/blah and then a different header when reporting a bug in forums/blah.

Also, if we separate the bug trackers what will we do when .LRN and .WRK want to share a package but its not really general enough for OACS?

The main goal of bug tracker should be for all developers, new and old, to easily report bugs and find other people's bug reports.  Thus to my mind the bug tracker should be organized more or less as a reflection of the file system as seen in a typical installation.

When you are looking an installation of dotLRN its very tough to figure out what part of the system a bug is coming from, especially for a novice.  We do not want to increase that complication.

I know I do speak for Sloan when I say we want to support not divide the developer community.  We want .LRN developers not only to know they are working with OACS code but be active contributors to the OACS community and code base.