trac-admin initenv should prompt for an email address (so that new tickets will be assigned to a real person)

[Jason Spiro <jasonspiro4@…>]

Current behavior

The trac-admin initenv command prepopulates the database with two components, named component1 and component2. But the owner field for those components is set to the invalid email address somebody. So, using Trac as shipped, new tickets aren't assigned to anyone. So, even after the Trac administrator turns on smtp_enabled, Trac doesn't send any notifications to developers.

Why that's bad

Joel Spolsky, author of "User Interface Design for Programmers", says "In a good bug tracking system, [bugs are] automatically assigned to the lead developer."¹ This makes developers much more likely to read and respond to bug reports. Bugzilla seems to follow Joel's rule: when a sysadmin installs Bugzilla, Bugzilla asks them for an email address and password for creating the first user². Trac is wonderful software, but doesn't follow Joel's rule.

Proposed fix

trac-admin initenv should prompt for the email address of the person installing Trac. It should set the owner of the two components it creates (component1 and component2) to that email address. (Later on, the person who installed Trac can change the owners to the actual developers of those components.)

Footnotes ^1. In his article "Painless Bug Tracking", posted at ​http://www.joelonsoftware.com/articles/fog0000000029.html ^2. I found that out from ​http://www.bugzilla.org/docs/3.0/html/useradmin.html#defaultuser . I haven't actually checked that Bugzilla sets the owner of the default product to that user, but it's safe to assume that it does.

[osimons]

I lean towards agreement with this. This default 'main' user(email) should then be stored in

[project]
admin = 

… a setting that is default empty on install.

[turbidostato <turbidostato@…>]

Replying to Jason Spiro <jasonspiro4@…>:

Current behavior

So, using Trac as shipped, new tickets aren't assigned to anyone. So, even after the Trac administrator turns on smtp_enabled, Trac doesn't send any notifications to developers.

I must admit that I haven't use Trac > 0.10, so I may be missed here but…

From the way it works on 0.10, the default install doesn't enable SMTP; it is the administrator the one that must make the active step to enable SMTP and as such, that's the moment to activate any other suitable SMTP-related properties (like the always-cc to and such).

If that's the way it still works on trac > 0.10, then I see current behaviour is good enough: after all, components, versions, milestones… are obvious example ones so it's expected that an example shouldn't annoy you (i.e.: with unwanted e-mail).

If, on the other hand, new web admin interface allows to activate SMTP and SMTP only then, yes, I think that can be considered a flaw: at very least a message should state something in the lines of "now that you activated SMTP, please be sure there's a proper e-mail configured to recieve them" or, if setting it from a web form, enough data is mandatory for a proper functional system as an output.

All in all, since it is expectable for a sysadmin (or any other term you want to attach to the Trac app master) to be concious about any collateral results from his actions (hummm… I'm enabling e-mail who is going to recieve them?), I don't think this is such a big problem, so I'll tune down severity from normal to minor. There're other tasks I surely would want to be fulfilled prior to this one.

[anonymous]

Trac allows you to set a default owner per component.

Log in as admin, and navigate to the admin tab. Now under 'Ticket Systems', there is a component option. Here you can add/delete your components, and each one has a default owner option.

If I understand your question correctly, it seems Trac already addresses your issue. It doesn't do it from creation… but you can later configure it to solve the problem.

Should this ticket be closed?

[Jason Spiro <jasonspiro4@…>]

Replying to anonymous:

Should this ticket be closed?

No. It's good the web UI can set a default ticket owner, but I want trac-admin initenv to set it. Remember: this makes developers much more likely to deal with all bug reports IMO.

By the way, who are you? You posted as anonymous.

[Remy Blank]

Replying to Jason Spiro <jasonspiro4@…>:

No. It's good the web UI can set a default ticket owner, but I want trac-admin initenv to set it. Remember: this makes developers much more likely to deal with all bug reports IMO.

Trac is not ready for direct usage OOTB, but must be configured according to your needs: creating components, milestones, and so on. So you will have to go through the components anyway, and that's a good time to set the default owners, in accordance with Joel's guideline. I see no good reason to have trac-admin initenv do that.

Maybe we shouldn't create any default components (and milestones and versions, for that matter) at all, as they will be replaced anyway.

Simon, did you have any other uses in mind for the [project] admin option?

[Thijs Triemstra <lists@…>]

Replying to osimons:

I lean towards agreement with this. This default 'main' user(email) should then be stored in

[project]
admin = 

… a setting that is default empty on install.

I also like that idea. Or at least put something like trac@localhost in there?

[Jason Spiro <jasonspiro4@…>]

Replying to Thijs Triemstra <lists@…>:

[…] Or at least put something like trac@localhost in there?

Personally, I don't like the trac@localhost idea. Remember, "in a good bug tracking system, [bugs are] automatically assigned to the lead developer."¹

^1. Joel Spolsky, ​http://www.joelonsoftware.com/articles/fog0000000029.html

[Jason Spiro <jasonspiro4@…>]

Replying to rblank:

Trac is not ready for direct usage OOTB, but must be configured according to your needs: creating components, milestones, and so on. So you will have to go through the components anyway, and that's a good time to set the default owners, in accordance with Joel's guideline. I see no good reason to have trac-admin initenv do that.

Trac should follow Mr. Spolsky's advice, even in the case where a team keeps the default components and milestones instead of properly configuring things. (I've seen such a case once.) The only way to handle that case is to make initenv prompt for an email address.

[Ryan J Ollos]

Replying to rblank:

Trac is not ready for direct usage OOTB, but must be configured according to your needs: creating components, milestones, and so on. So you will have to go through the components anyway, and that's a good time to set the default owners, in accordance with Joel's guideline. I see no good reason to have trac-admin initenv do that.

Right, component1 and component2 are just sample data. The reporter can use the TracAdmin component owner command if he wishes to set the component owner at the time of install. I don't see this as being an issue for many users, so I'm going to close the ticket. If we receive additional independent requests for the feature we can revisit.

On a side note, I'm now interested to know how FogBugz behaves out of the box, without input of project data. At the same time, I think it is a bit of an extrapolation to suggest that JS was saying a bug tracker doesn't need to be configured at all. A few minutes of project data input would make Trac conform to the stated definition of a good bugtracker.