In other words the old intranet package gave some control over how you can let people (clients) into the system, controlling what they can see and can't see, what they can and can't do, etc.  Tie that with the SDM and you'd have something more useful for small consulting companies than bugzilla, I think, due to the nice possibilities that the rich OpenACS 4 datamodel makes possible.

And given that there are several small consulting companies in the community that would be nice, no?

And combined with the new portal package users would have a high degree of portal customization at their fingertips, too.

So ... obviously something like this in OpenACS 4 could be a world-class piece of software that might really enhance our visibility if it became at all possible.

The rub - resources.  Where are the resources to take on something as ambitious as this?

Has anybody looked at the 4.x port of SDM that ArsDigita made?

Don wrote:

And Malte wrote:

Denis and I decided to use OpenACS for our own site. As we rely heavily on Intranet, we will start porting the ACS 3.5 intranet when work has settled a little bit or some big company is willing to spare some if its money with us for doing it. So, nothing will start before May, but we definitly want to drive this ahead AND drive it in the direction Don has been talking.

It seems to me that dotLRN may provide the base for much of what you're talking about. It has (AFAIK) class and group scoping that could be turned into project and subproject scoping, admin, professor, TA, and student permissions that could be turned into developer, project manager, client, etc., full use of the new portals system, and a nice API that makes it relatively easy to tie new packages into the system. It's got event scheduling, bboard, file-storage, wimpy point, calendar, and other Intranet-like features already set up for it. It seems to me that dotLRN would be the right place to start in terms of building a new Intranet package. I'd love to see both SDM and ticket-tracker integrated with it.

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

• uses pseudo_contains from ecommerce package. If you don't have it installed you'll need to get it
• Has hard codes group numbers in various files. (It was that way when I got it). I think you should be a able to have different groups manage different projects and it doesn't seem to support that completely. There needs to be a way of assigning a group of developers to a project.
Here is what I have now SDM

Talli,

I'm not trying to act too happy about my own software development, but you should take a look at two package I have which will greatly speed up the very boring parts of development. Togeather these two packages handle most all insert update and delete code for acs packages.

The first package is my package-bulider package. I have not converted this to pg yet, but it is available for use by all at: http://multi.zmbh.com:8300/ which allow you to enter your table definition and build both oracle packages and a set of pg functions for insert/update/delete, essentially this creates the pkg.new, pkg.set_attrs, pkg.delete, pkg.reset_attrs and pkg.pkg_p functions for oracle and the correspondingly named functions for pg. For pg, it also creates the package delete script.

The second package called query-writer. This package allows you to create objects which have attributes. For each object you can define function prototypes based on a subset of the attributes. Also, each attribute is protected with respect to the operations that can be performed on it. These protections are grouped (not necessarily an OACS group). Right now I use two groups: admin and default. It is relatively painless to add groups to an object. This is a relatively simplified system: a user is in only one group at a time, and right now only system wide admins are in the admin group, while everyone else is in the default group. However, what this all boils down to is that developers can direct all insert/update and delete operations to one page. This page also takes a return_url variable. During the processing of this page, any number of objects can be worked on. You can insert 2, update 3 and delete 1, of any object defined in the system.

I have been using this package with my merchant-system package, and I have got this thing to elegantly do everything I have needed it to do so far. Another big plus, due to the security groups is that the single query processing page can handle both admin and regular pages.

If the pre-built page is not able to handle a difficult set of requirements, you can use the tcl api which also has several levels of access. This also means that most of your .xql files will only be for regular sql select queries, which self port for the most part.

Please let me know if you want to see the query-writer package in action.

http://www.joelonsoftware.com/articles/fog0000000029.html

Its a good starting point.

Cheers,

General Introduction

Since Lars is going to spend some time on this, I'll spend a minute describing what I like in issue tracking systems based on my experience running multiple projects with multiple clients at Civilution.

The openACS3.2 ticket tracker is pretty good and what I have been using for about 2 years. We made some major modifications to support logging of hours to tickets. If you want to look at how I use it, feel free to email me and I'll let you see some pieces of our system. Its far from ideal though, I haven't been able to do releases well and email notifications are sketchy at best.

I have also spent some time looking at the Fog Creek FogBUGZ tracker, and some other proprietary ticket trackers. As a reference implentation I have very few complaints with FogBUGZ.
http://www.fogcreek.com/FogBUGZ

I find that the workflow for features and defects is similar enough that we have been able to track both very successfully in a ticket tracker. There are some subtle distinctions between them, and its helpful to be able to filter for one or the other. But the general flow is the same.

So onto specific requests:

Major Datamodel Elements

You should be able to separate tickets and people into distinct projects. At Civilution, we had two projects for each client (one to track billable tickets and one for unbillable tickets, though I wouldn't do that again) and an assortment of internal projects like: Biz Dev, Overhead Tasks, Sysadmin, Codebase.

Its nice if projects have some kind of subdivision like area that you could use to partition a project into documentation, graphic design, and other major ares.

Its nice to have a good sense for versions of projects. We didn't do a very good job of this, but its really nice to notice which version a defect was found in and assign it to be fixed by a certain version. (At some companies if a feature is deferred more than N versions it is dropped where N is typically 2-3)

Users

Users were attached to projects. We only had Administrators and Users, we didn't get any value from the common separation of internal and external users and I wouldn't waste time on it. Everything should be logged and we trusted our clients so it wasn't worth the bother. The 3.2x ticket tracker seems to offer a way to hide comments from the external users, but I don't think this secrecy adds any value to the client relationship so we never used it (except by accident).

Tickets

• Should always have one person who is responsible for moving it to the next state.
• Should notify people via email when they become responsible for an issue. Good email notification is probably the single biggest success factor in using the ticket tracker. It encourages people to open tickets if the KNOW that they will be notified of major state changes.
• Should only be closed by the person who opened it.
• Should naturally display the history of the ticket. (see FogBUGZ demo for a great example)
Other nice features for tickets:
• Ability to subscribe to defects and get email notifications of all updates as it moves through the cycles. This is a big wishlist item for me.
• Attach Files to tickets. Useful files include screenshots, test data that shows the ticket or links to documentation about what it should do.
• Estimate Tracking: How long will this ticket take to finish from its current state? This is especially helpful for distributing the estimation of a project or figuring out how busy people are.
• Work tracking: How long did someone spend working on a ticket. At Civilution we modified the intranet and the ticket tracker to do all hour logging through tickets. We then made a new class of ticket call ongoing that never closed (issues like company meetings) and everyone would log hours to those tickets. This worked pretty well.

Hints for using tickets in an org:

• Make the Severity ratings mean something and only use Severity ratings with meaning. There is no magic bullet for this, you have work out what the levels mean for your organization and think about ways to teach people.
• As a developer, refuse to work on issues that are not in the ticket tracker. If it can't be fixed while you are on the phone with the client, it should be tracked. The ticket tracker needs to be the canonical place for issues.
• Give people an easy why to see: Issues assigned to them and issues that they opened. These are my two favorite views for chasing down tickets.
Workflow

The basic workflow is pretty easy:

Someone, lets call him Client Chester, requests a feature or reports a defect. This ticket gets assigned to Project Manager Mary who is responsible for that area.

Mary may fix the ticket, assigned it to Denny Developer to fix, schedule it for a future version (getting it off the immediate plate), request clarification, or decide that its not worth fixing. (FogBUGZ has a pretty elaborate system of Sinks, We just closed tickets and didn't pay to much attention to if they were closed because it was by design or we just weren't going to fix it.)

After a Mary or Denny "fixes" the ticket, it goes back to Chester who is responsible for closing it and being satisfied with how the situation is resolved.

This basic system works great for features too, a someone can request a feature and they have to review that the feature was implemented satisfactorily before they can close the ticket on that feature.

We had a couple of other tweaks here at Civilution. Hot fixes to production servers had a slightly more complicated workflow:

Client would open a ticket.

Dev would fix on dev server.

Client would approve on dev server.

Dev would prop to production.

Client would optionally test on production.

Conclusions

Just to sum up, If you have good email notifications, reasonable ways to divide tickets across projects and across time (with versions or releases), and simple reliable workflow, I will probably be happy.

Thank you Musea for investing some resources in this.

Cheers,

Here's another scenario:

I'm in charge of verifying that bugs marked as "fixed" are, in fact,
fixed before they're closed out.

And a random thought:

One of the things I like about bughost.com is that it's pretty
configurable. Here are some things I can configure:

- I can define my own roles

- I can set priviliges (view, read, and write) on pretty much every
field.

- I can also set fields as required or optional (with contingincies
in case the person viewing does not have write privileges) and
set defaults on some fields.

- For fields like "severity" and "when this will be fixed," I can
define the choices in the pull-down menu.

In my book, having flexibility, i.e. --the ability to shut a field off or
change the range of choices-- is often more important than
having a huge number of fields. The system should allow you to
make your workflow as streamlined and simple as possible
given the needs of a particular team/project.

Thats almost exactly how we used our ticket tracker and we talked about implementing the stopwatch interface but never quite got around to it. Having played with punchclock on my Palm for a bit, I think that the UI for doing that kind of time tracking would be pretty straight forward.

One implementation is to add an [out] button by each bug/issue/feature/dev task in the open issues list. Clicking it, starts running the clock on that feature. (In punchclock the line turns bold and the button turns to [IN]. We just had a log hours button by each ticket.

Cheers,

The problem with Jabber is that you have to program both the clients and the component side to get this idea to work. Most clients come with only a very simple interface and it isn't dynamically expandable like a web page. There is no simple thing like an encoded url you can choose. I experimented in using the 'thread' tag of the message namespace to hold a url, and it works fairly well, but this does not provide anything to choose, the user still has to type in some text response. Jabber should be more useful for machine to machine for this kind of thing. So my assessment is that Jabber would have a disadvantage in that programming has to be done on both ends.

I'm not saying this shouldn't be done; this sort of feature goes over well in presentations even if no-on ends up using it.  But if anyone is actually taking notes here, I'll put in my vote for having simple buttons for those of us with good web connections, along with whatever more spiffy solution you choose.

Michael & Janine,

Jabber can be used as Michael suggests, the apm package I wrote shows examples of this type of use. However, I would agree with Janine in that it is quite a hack, and very ugly. Why would someone choose to operate by typing in commands instead of clicking on a link or button, assuming both were available? Maybe the point is that you cannot click on a mobile device? I don't know about that. As a protocol, Jabber is not more reliable than HTTP, but rather less. If you need reliability for disconnection, email would be the best, since it was designed for intermediate storage of messages. Jabber will store messages at the receiver end, but that is probably where the component is located anyway.

Lars

Your summary looks great, any word on the data model to support this?

• easier to tap into for other packages who want to talk to BT
• no real query overhead for simple rel-types. Though you should probably subtype acs_rels to add semantic value to the relationship type, there is no need for your subtype's table to have any new columns, and even less need to join against it. Of course if your new rel-types carry attributes, and you subtype your subtypes, you can get a bunch of joins pretty quick.
The disadvantages:
• Object instantiation/deletion overhead if you have to do a lot of them
• Ups the object count. I'm hoping this is pretty much not a problem anymore.
For what you describe, acs-rels seem like the right thing to do with one exception. I would side with the part of you that suggested using perms instead of acs-rels to define a replacement for the module_users table. The downside for the perms approach would be that if a large number of modules existed within a project, you'd be hitting the db pretty hard on the permissions check for the module list page. I haven't got a good feel for how slow that could make things on the latest OACS, but the flexibility and standardness of using perms like that would be an worth it, if it doesn't hurt too bad under real world conditions.

What is "sdm_module_users" actually used for? Do you have to be a "user" of a module to be able to submit bugs in the module? Or to be assigned bugs to?

If the latter, does someone who's a global bug fixer guru have to be registered as a user of every single module?

I'm probably missing something lame here.