Sometimes 'None' is a misleading word in select lists.

Say you have an field called Security Impact, a select list with possible values Yes, No and Unsure. You want to force users to consciously pick an option, so you mark the field 'Required' in the field configuration. JIRA displays this as:

Knowledge Base > Removing the 'None' option from JIRA select lists, or why radio buttons may be better > jira_required_selectlist.png

JIRA has added a fake 'None' option at the beginning, meaning "No value has yet been selected".

In most cases the word "None" makes sense (e.g. Priority: None), but not here: "None" is identical in meaning to our real option, "No".

How do we make "None" go away? There are 3 options I know of.

Add a fake whitespace option, and mark it the default

When a select list is marked required, and has a default value, then 'None' disappears (https://jira.atlassian.com/browse/JRASERVER-3666). So the idea here is to add a select-list option with value " ", and mark it the default.

This works, but breaks JIRA's enforcement of the field's required'ness. Users can create issues with the default value " " selected.

This problem can be avoided using ScriptRunner Behaviours, setting an error on the field if its value is " ". This works, but Behaviours is bypassed by the REST API and Automation for JIRA.

Hack JIRA's select list template to replace 'None' with ''

In a better world, Atlassian wouldn't have used 'None' to mean "no value has been selected": they would have used a blank line:

Knowledge Base > Removing the 'None' option from JIRA select lists, or why radio buttons may be better > jira_required_selectlist_hacked.png

You can get exactly this if you don't mind tinkering with JIRA source. Here is the diff:

diff --git a/atlassian-jira/WEB-INF/classes/templates/plugins/fields/edit/edit-select.vm b/atlassian-jira/WEB-INF/classes/templates/plugins/fields/edit/edit-select.vm
--- a/atlassian-jira/WEB-INF/classes/templates/plugins/fields/edit/edit-select.vm
+++ b/atlassian-jira/WEB-INF/classes/templates/plugins/fields/edit/edit-select.vm
@@ -5,7 +5,7 @@
         <option value="-1">$i18n.getText("common.words.none")</option>
     #else
         #if ( !$configs.default )
-        <option value="">$i18n.getText("common.words.none")</option>
+        <option value=""></option>
         #end
     #end
     #foreach ($option in $configs.options)

(You can find similar advice at https://confluence.atlassian.com/jirakb/how-to-remove-none-from-a-select-list-custom-field-144212308.html, but that KB article removes 'None' altogether, leaving the top option the default, which is wrong)

Don't be tempted to use a JIRA translation plugin to map common.words.none to '', as that will break many other uses where 'None' is the correct meaning.

Use radio buttons instead of a select list

Normally the choice of radio buttons vs. select lists is cosmetic, bot not here. When marked required, radio buttons behave correctly, with no option selected by default:

Knowledge Base > Removing the 'None' option from JIRA select lists, or why radio buttons may be better > image2018-1-26 23:19:45.png

Radio buttons don't have the "something must always be selected" behaviour that HTML select-lists do, so Atlassian didn't have to add a "no value selected" option (and get it wrong).

Conclusion

In order of preference:

If you use JIRA Cloud, or don't want to maintain a JIRA hack, using radio buttons is the way to go (tip: ScriptRunner has a built-in script to migrate field types).
If you don't mind maintaining a source hack, fixing the .vm file is the cleanest option.
If you really have to, a fake blank option can work, as long as you don't mind the extra implementation work, and the limitation of the Behaviours plugin.