On 2020-08-01 21:23, bugzilla-dae...@spamassassin.apache.org wrote: > https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826 > > --- Comment #58 from Kevin A. McGrail <kmcgr...@apache.org> --- > (In reply to John Hardin from comment #57) (In reply to Kevin A. McGrail from > comment #55) > > This isn't a plugin to disable features (i.e. deprecate), it's to enable > them. > So name it "EnableDeprecatedTerminology.pm" > > I second the objection to "RaciallyCharged.pm". Doing that is essentially > scolding anyone who enables backwards compatibility features.
The RaciallyCharged plugin doesn't enabled deprecated terminology, it enables the racially charged language. It's used in the rules specifically for this issue and the tests as well for backwards compatible. It won't be suitable as a generic plugin. The plugin describes exactly what the plugin does and I stand by the name. People should stop using the language. As you cannot fail to be aware if you read even a fraction of the list messages on this topic, there is absolutely no consensus that blacklist/whitelist etc. are racially charged terms. Some perceive them as such, sure, but others disagree, and indeed some disagree rather strongly. It would seem fitting to avoid a divisive name for re-enabling the terms. What is indisputable is that the project has chosen to deprecate the terms, regardless of the reasons for that deprecation. It is equally indisputable that the plugin is for backward compatibility reasons. So how about EnableDeprecatedTerminology or EnableBackwardCompatibilityTerminology, which would be accurate and far less divisive names. I suppose it might be argued that another plugin might be needed in the future for enabling terms deprecated for other reasons. If that is a worry, then call this one EnableDeprecatedBlackWhiteTerminology or EnableBackCompatBlackWhiteTerminology. -- John
