Does this sound like a good commenting convention to add into our
devs' "best practices"? Or is it better left as just my thing, or left
out altogether?

That's fine I think, although most comments in the code are going to
be for developers, so it may be redundant:

It may be easier to recognize that a comment, is a comment, and
then state what it's for (optionally)

For example, I've also started to use the, "TODO" comment, for things
I haven't quite finished, for example, in mail cgi:

 # TODO - why isn't his here? Why aren't we reading it from the  

pref?! my $add_to_black_list = $q->param('add_to_black_list') || 0;

or:

 # TODO: these three lines need to be one
 my $test_test = $args{'-Bulk_Test'};
 chomp($test_test);
 unless($test_test == 1){

I can then Grok this and put it in my Big list of TODO's

 http://cvs
sourceforge
net/viewcvs
py/*checkout*/mojomail/ 

dada_mail_stable/dada/extras/developers/TODOlist txt?rev=1 43

Which is a horrid mess, but so is my desk :)

If you want to start using an optional label for comments
specifically for developers, I think we can do that, but I would
rename it something like, "DEVELOPERS" or, "DEV", but not,
"DEVCOMMENT" It's just that it's context is already a comment

We can also use the label, "HACK" :) For example, DADA::Mail::Send:

     #hack
     #Mail::Address should

 *Address* (pun) this, but it  

doesn't why? why? why? # Why, it's a bug in Mail::Address, and it's not getting
fixed grr!

     my $ln = $self->{list_info}->{list_name};
        $ln = DADA::App::Guts::escape_for_sending($ln);
     #/hack

Also, let's keep this optional :)

Making that change will be a bit more involved than a simple,
template-wide search-and-replace but for me that's a good thing, because the
other tweaks required [there's also a bit of code in a few of the
Perl files and in default_js js also, I think] will give me a better
feel for what's where in the program So I'm on the job :-)

OK, for the moment, I'd rather not have to use classes for each of
the different form widgets - it'll never ever get applied to every
single thing - the buttons are bad enough, but it makes you have to
stop and think I'd rather accept the consequences of the current
stylings, or take out the css that's causing it - whichever the
majority things it's best - I'm leaning towards accepting the
consequences, as IE 7 is coming out soon :)

P S - If anyone who's using Dada Mail 2 9 0 or later is looking for a short-term fix for the IE checkbox/radio-button border problem in
the meantime, the only solution, alas, is to remove all border
properties from the CSS file's "input" and "input:focus" selectors, and let the input controls just revert to their default styles

Although a hack, doesn't IE allow you to put conditional statement
commentss in css? It may not be worth the trouble, but we could state
the right way first and then the fallback way for IE (or the other
way around, who knows :) )

Justin Simoni