Fog Creek Software
Discussion Board




email options

i tried to edit a user to do 2 things:
  1. remove their email address & phone number
  2. turn off their email-notification

i discovered that you get a server error if you try to save a user with a blank email address.  the add-user screen gives you a Javascript popup error if you try to add a user w/  no email address, but the update page fails if you try to remove the email address.

i reported this, and Michael said he'll fix it, but (and here's a perfect example of the difference between a bug report and a feature request)... *after* the obvious bug is fixed, i STILL think i should be able to have a user with a blank email address... why can't i?  if i have email notification turned off, what is the email address *needed* for?  a primary key?

also, a related semi-bug, tho its mostly just a cosmetic change: when a user's email-notification is OFF, they *still* get a page after adding a new bug that says, "You will get email when the bug is fixed... etc"  But in fact they will not.

I know this is a result of my not wanting to use the email notification even though the program explicitly condemed this practice to my face as "a bad idea", but a) it was my idea and i'm offended that a machine teels me my ideas are bad, and besides, i'm just evaluating it.  i am the only user using it at the moment, and so for now i don't want email notifications sent out.  even tho i'm adding real bugs while logged in a as various real users, assigning them (as administrator) to myself, resolving them as me, and then closing them as the user.  so i'm logging in and out a lot :-)

anyway i think other methods of notification might be possible in the future (think chat :-) ),  and valid cases where notification might need to be off permanently (think: system moving a thousand bugs a day like Mozilla.org) so the dependence on email notification possibly could be re-thought.

</rant>

David Kaufman
Friday, October 26, 2001

<replying to="self">
re-reading my post, it sounds pretty critical.  that wasn't the tone i intended!  FogBugz is great!  So i just wanted to add some paise, and propose some solutions here, instead of stopping at pointing out problems...

<praise>
The nicest thing about FogBugz to me is it's simplicity.  By keeping the paradigm simple, it makes it the only choice for tracking bugs in projects where the testers are non-technical users such as, in my case, clients :-)

other systems include so many technically-termed fields as to overwhelm non-programmers and effectively prevent them from using the system.  FogBugz has a user-friendly, attractive UI and an easily understood process model that (i'm hoping) even the great unwashed masses (paying customers) will find useful and easy to use.

also, the two simple accountability rules: the hot-potato metaphor, and the rule that only the person who reported the bug can close the bug, enforce a clean and effective best-practice work-flow!

</praise>

<solution>

re: the email-notifications issues i raised

one effective alternative (to floods of email) corresponds to another way of using FogBugz.  i'd like to set my default filter to show me "new" bugs assigned to me, and hide bugs i've already "seen".

i implemented such a system on a web-based discussion board once, which was kind of neat, by storing the date of the last logn, and the id's of the messages viewed during this session, in a cookie, the display was able to reflect "read" vs "unread" messages much the same way users are familier with their email programs doing (i.e. unread messages are bold)

anyway it's just one way "notifications" could be generalized, for groups that do not want slews of email, but can be assumed to ve logging in and using the system regularly, who still need to be able to tell new stuff from old stuff.

</solution>

</replying>

David Kaufman
Friday, October 26, 2001

<an easily understood process model that (i'm hoping) even the great unwashed masses (paying customers) will find useful and easy to use.>

Yikes!  Do you mean that you're going to allow your customers to access your bug tracker? Or did I misunderstand something?

In any event, your praise is on target.  We settled on FB largely due to its simplicity and to the clean "one person accountable" model.  With a few minor complaints, everyone seems to be quite happy so far.

Chris Dunford
Friday, October 26, 2001

In larger organizations, I've always regretted even having an option for opting out of email. It was intended as a way for people who spend the whole day checking FogBUGZ to avoid the noise in their inbox. In practice, what happened is that the people who used FogBUGZ the *least* --- occasional users from distant departments --- turned off the email notification, thinking they were being ever-so-clever and avoiding "spam." But in reality, they were just destroying the usefulness of the workflow system because bugs assigned to them got ignored.

Anyway, I like to think that one of the nice things about FogBUGZ is that it's NOT too flexible. The value of FogBUGZ out-of-the-box should be that it encourages you to use a particular methodology of bug tracking that I have found over the last 10 years works best. There are certain small details (like the fact that a bug MUST be closed after it is resolved, allowing the opener a chance to confirm that the bug was fixed) that I think are very helpful to real bug-tracking. But time and time again, new customers who have never done bug tracking before and are installing FogBUGZ for the first time will ask if they can customize FogBUGZ so that a bug is closed automatically when it's resolved. And I have to say, this is a valuable state, just accept it and you'll discover, as I have, that about 15% of your bugs are NOT really fixed when the developer says they are, and you'll thank me for having this extra state :)

Anyway, I've waxed a little bit philosophical here. On a practical level, if you're using the system by yourself, click on SITE and type NONE for your SMTP server and you'll never see email again. And for the next release we'll fix the bug about user's being told they'll get a message when they won't, and being required to enter an email address when they've turned off email.

Joel Spolsky
Friday, October 26, 2001

*  Recent Topics

*  Fog Creek Home