Find a better name for Graylist

Personally I think "Graylist" is a good naming. I wouldn't change it.

What about "Split configuration" (blacklist) and "Overridden configuration" (gray list)? Together with the improved descriptions from [#2822974: Document greylist/blacklist differences in admin form] I'd say it couldn't get any clearer than that.

Hi!
Isn't the current graylist more like the .gitignore file used in git to say do not include these files in the repository?

Graylisting email means that the mail server receives an email from an email address that it has never seen before tells the sending server it is temporarily unavailable. If the mail server is configured properly it will try back after a wait period (it is in a spec somewhere). Spam mail servers will many times try the backup mail servers right away or the same server. After the first email from an email address gets through the graylisting their emails are accepted the first time.

The graylisting on this module is nothing like this.

I think that Ignore list is a better term for this. I also think that the help text should warn users that if the ignore configuration this way it will be lost when new code is deployed unless they in their deployment export this configuration split, so that it can then be reimported with the new configuration.

I would be interested to hear what others think about this.

Frederick

Yes, "Gray list" is probably not the best name. Hence, this issue :)

The configuration is not being ignored (you'd want config_ignore module for that). It is split off into the split, like the black list. The only difference is when the same configuration items are present in the main sync directory; for black list, the configuration will be removed from the main sync. For gray list, the configuration will be kept as-is in the main sync. When importing, the configuration from the split will get priority over that in the sync. Hence my suggestion to call it "Overridden configuration", because that is what is happening.

+1 for 'Ignore list' or similar suggested by frederickjh. 'Graylist' didn't make much sense to me at the start. Also, 'Ignore list' is the same in en-GB and en-US :)

Like I said in my previous comment, 'Ignore list' is very inaccurate. Maybe more so than Gray/grey list, which is "just" vague. "ignore" is plain wrong (sorry).

+1 for the suggestion from eelkeblok in #4.

Here is a patch that implements that suggestion (though I renamed "Graylist" to "Configuration overrides" instead of "Overridden configuration"). The patch also includes suggestions for changes to the descriptions of form elements on the configuration page. This removes any references to the terms 'blacklist' and 'graylist' on the page. I did not change the machines names of the fields for now: I only made changes to the interface texts, so we can purely focus on that.

Cool. I was just thinking the last time I looked into this issue that it needed more patches :) Hopefully I'll have a chance to review next wednesday.

Just brainstorming here, what about something like 'Hard Overrides' and 'Soft Overrides' (in place of Blacklist and Graylist, respectively)? That's at least consistent with the idea that they both do a similar thing, one is just a little more forcefully than the other.

True, the concept of 'Configuration overrides' already exists, but the word "override" aptly describes what config split does (i.e. general configuration is used by default, but any configuration that is part of the active split takes precedence over, or overrides, those defaults. Blacklisted config just means there's no default value allowed).

The other idea I have is to keep the existing "colorful" naming, which is not entirely bad, and add a very short description to the headings themselves like this:
Blacklist (Removes default config)
Graylist (Overrides default config)

something like Overrides would be years light bettername, IMHO. I just started to work with this module and blacklist intuitevely tells you the opposite to what it does:

"blacklist this modules on this environment",

when what it really does is "whitelist" those modules and install them on the environment you are specifying. Am I wrong here?

My two cents :-)

@alexmoreno, I have to agree that the terms Blacklist and Graylist are confusing. In my opinion they never should have been used as they do not fit the use case. In the end if this project holds on to them they will continue to cause confusion at best, at worse they will lower the rate of adoption.

Blacklist, Whitelist and Graylist are terms from the email server realm. White list means this list of email address always get through. Blacklist means this list of email addresses never get through. Graylist is not really a list, unless you consider all the email addresses that a mailserver has had prior contact with a list. Graylist means if the server has never seen you before you need to wait a bit before I will accept your mail, plus you must follow the standard rules regarding a "temporarily unavailable" response. Which of course spammer do not.

How these terms even remotely should be applied to Configuration Splits is beyond me. Just because the developer has gotten use to terms does not mean that the users will. I will have a look at the documentation and see what I can contribute there in an effort to bring clarity to this issue.

(Sorry, comments crossed. If you would still like me to open a new issue, let me know).

Sounds good. Sorry, but while we're at it I have some more suggestions to clean up the screen. Patch is attached (against HEAD, so it serves as an interdiff as well). I hope you're not too tired of this issue yet :)

- I removed the terms in parentheses from the field label, I would suggest those should be kept as clean as possible.
- To reduce further confusion, I've only left the terms graylist and blacklist (in the descriptions), to help users familiar with the old terminology. The other alternatives I've dropped, since it feels like trying to shower users in terms to hope one of them sticks and makes the concept click for them. I doubt that is helpful.
- I've tried to make the descriptions a bit more concise. Same reasoning, basically. Lets try and come up with a short and concise explanation of what it does.
- I've changed some of the labels for the fields within the fieldgroups, since they were partially redundant (both "Modules" and "Blacklist" within the "Blacklist" fieldgroup) and tried to make labels and descriptions more consistent.

What I'm not entirely sure of is what the text fields do. I've now given them the label "Filter rules", since IIRC they make it possible to filter entire "classes" of configuration items. If specific configuration items are listed, I believe there is no difference between it and the select box (correct me if I'm wrong).

Ah, that makes a lot of sense. Thanks for accepting the patch.