Well, for more background info I am not suggesting this purely whimsically, I went through a debugging session a month or two ago where I was trying to understand message acceptance. After an hour, I figured out "Oh, stupid, it's not that this user has default processing! No. They are using defaults. Quite different."

Not sure what an analogy is. A car dealership which has two red cars, and distinguishing them using the terms "red automobile" versus "red car" to keep them separate.

Even now, I think "You can choose either default processing, or default processing, but don't get those mixed up."

About implying "modifiable",

we often use the terms "settings" or "configuration" without explicitly adding the adjective "modifiable". Many variables and configurations in technology are modifiable. That does not always need to be stated outright. If "processing" occurs, it does not imply unmodifiable.

The terminology appears in drop-down lists within Hyperkitty, so more than only docs.

I don't understand why you are confused.

I understand now, and I'm not confused. However before, when I was learning about this topic, I encountered a problem, and it's worth trying to make it easier. Even now that I 'understand', the issue continues.

It's about terminology and language, and not about the functioning of mm3.

There are distinct choices. You'd like to easily remember them, in your mind, and be able to quickly explain to yourself, or to someone else.

• "list default". I would just think "Ok, clearly that's the default. Look at the name there. List default. The default."

• "default processing'. I would just think "Ok, clearly that's the default. Look at the name there. Default processing. The default."

Yes, we know they're different. What is the mnemonic device to remember each one. Couldn't they be named differently?

99% of the time, you can remember "a config file", "the executable", "the bin directory", you can remember a thing based on what it's called, and those don't conflict with each other.

But if you name both of your sons "Michael" even though you understand they are separate people, it causes headaches.

If you choose a naming scheme such as "the red automobile" versus "the red car", and then ask the person "don't you understand, those are two different things for us. Why are you confused? They are two separate things. You know that. Why are you confused." Answer: the problem is the choice of naming.

So ask the question is "default processing" the only compelling name for that functionality? The word "default" is already used for "list default". Why use it again? Why not "Standard Processing -- run additional checks and accept the message." Or "Regular Processing". "Typical Processing". Anything besides "default". Invent a new word: quark-spark processing. (well, don't use 'fallback' because it's just a synonym.)

well, just trying to answer "why you are confused". maybe I am being too repetitive already.

Gerald Vogt writes:

People tend to choose "Accept immediately (bypass other rules)".

How about "Accept immediately (no spam check)"?

I do wonder somehow if there is really a use case where you would actually need "Accept immediately".

"Need", probably not. However, for people who integrate things like Spamassassin into Mailman rather than the MTA, it's often much easier (and possibly less risky, depending on the importance of that sender) to trust the sender ID rather than adjust the filter rules. (This is a good reason to integrate Spamassassin in the MTA, but providers....)

We could also reorder the list and put "default processing" at the top. And/or add more explanatory text.

it's not totally clear to me what the default processing rules do exactly...

Here's the complete list:

https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rules/docs/...

Which rules are checked for a given post depend on the outcome of previous checks as well as the list configuration.

-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

Sam Darwin via Mailman-users writes:

• "list default".
• "default processing'.

and "member default".

Three different names, just as "Samuel Darwin" is a different name from "Charles Darwin".

I would just think "Ok, clearly that's the default. Look at the name there. Default processing. The default."

"The" default? There's a cascade of options that are controlled by subscribers, owners, and site admins, with the lower level option values becoming defaults for the upper levels. And there's a side cascade of defaults for subscribers: user-wide defaults, address-wide defaults, and the per-subscription option values.

But if you name both of your sons "Michael" even though you understand they are separate people, it causes headaches.

Sure, but as shown above we didn't. I really don't think this is going to be a common problem. You seem to attach a connotation of uniqueness to the word "default". It simply doesn't apply to the cascade of defaults Mailman uses, while most Mailman administrators and subscribers seem to understand this aspect of how Mailman works.

So ask the question is "default processing" the only compelling name for that functionality?

That's not a useful question to the developers, though. What we ask are, "Are there better names for that functionality?" (arguable) and "Are any sufficiently compelling to warrant a change?" (not to me).

Why use it again?

• Because the functionality is a default in a cascade of defaults.
• Because at the level the issue presented itself, it's what people *should* use in the absence of a specific reason for using one of the other options.
• Because it's already there and at least 35 people are involved in changing it, it's not obvious that the change will be easy for all of them, and it's likely the changes will spill over to several more files, mostly unidentified at this point.

Abstract arguments supported by only one person's experience won't overcome the third point for me, so until you do address that point or a few folks chime in to agree that this is confusing[1], I'm out of this thread.

Footnotes: [1] I hope those who do agree will speak up. There's an awful lot of individual opinion about language flying around here. "Disagree" is not so useful since it appears that's the developers' bias anyway and we don't need a pile-on, but you all are welcome too. :-) Especially if you report similar but different issues, as we've already seen.

-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

Sam Darwin via Mailman-users writes:

His answer: "the user is set to 'list default'. Isn't that right??" No. It should be 'default processing'.

Notice the reasoning. he just thinks "default", and that's all, which is a mistake.

Sure, and it wouldn't have happened if he'd been instructed more precisely. The options are very nuanced. I doubt most untrained moderator candidates would be able to state the differences between "discard" and "reject", or "accept" and "default processing", and there are reasons why each of those options might be the preferred policy for the moderator's action on a given list. The list owner should explain these things to a new moderator.

Perhaps some kind of documentation (popup help on mouseover, for example) could be added to the moderation page template. I think that's the most plausible improvement, and a merge request would likely be approved.

There isn't a mnemonic device where the settings have different names.

The problem isn't that the names aren't mnemonic. It's that the moderator doesn't understand the semantics, and has nothing for a mnemonic to refer to. Any names that reflect the semantics ("list fallback" for "list default", "standard processing" for "default processing") are going to have the same problem, although possibly not to the same degree.

You're welcome to submit a merge request to change to alternative names, but I will be -1 if they don't reflect the semantics, Most likely I will be negatively biased because (a) I think properly educating moderators is important, which would likely eliminate the problem, and (b) I don't want to make work for the translators (who also are frequently not native speakers of English and might not understand why the change was made, and the proper translation!)

But it brings up another idea also. When accepting a held moderated message, could there be an option, which is enabled by default, so it just works, that is "and switch this user from moderation-action1 to moderation-action2. That is, from 'list default' to 'default processing', at the same moment as accepting a message, and even without further mouse clicks. Then there would need to be an option, which is clickable, when accepting a message, "keep this member in moderation".

This is a more plausiable suggestion, but it's clearly inadequate (or perhaps the last part is redundant). The "accept", "discard", and "reject" options are present for reasons, so they must be available as well as "do nothing" (which is not exactly the same thing as "keep in moderation"). I am concerned about whether "bad things" could happen if a moderator clicks "and switch this user from moderation-action1 to moderation-action2" when one of the other options should have been chosen. It seems you envision that "moderation-action1" and "moderation-action2" could be configurable, or that there might be several such options. I wonder how that would look.

In your merge request, please document how you address those design considerations.

-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan