https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6155
--- Comment #20 from Justin Mason <[email protected]> 2009-08-27 03:52:29 PST --- (In reply to comment #19) > I feel like we have too little diversity in the type and number of ham > contributors. This rescoring would be a big improvement from our scores from > two years ago and we definitely should do it. yes. > But after 3.3.0 I would like to learn how I can become more involved in order > to revamp the score update process. > > * I'd like to learn how to operate the GA. > * I want to continue recruiting other nightly masscheck participants. I want > to recruit contributors of non-English languages and non-technical users. Great! As long as they keep the ham out of the spam and vice versa, and we can occasionally get in touch for eyeball-verification of odd-looking FPs, that'll be very useful ;) > * I am thinking about writing a toolkit (in RPM and DEB packages) that would > make it easier for participants to join masschecks. The current documented > process is very unclear and confusing, and I want to clean this up as well. It certainly is. We've been meaning to improve this for several _years_ now, but it's never been a high enough priority. mass-check is very dev-oriented, and it should be something bundled (and documented) at a similar level to the sa-compile or sa-update scripts. Here's history on the historical attempts which ran out of steam halfway through: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=3096 https://issues.apache.org/SpamAssassin/show_bug.cgi?id=2853 BTW please ensure that changes in SA (which there will definitely need to be) are submitted back upstream; IMO this functionality should be part of the core package. ;) > With more diversity in masscheck participants, perhaps we can do complete > rescoring more often than 2 years. Yes. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
