Continuously enforce place name normalization

[leovegoda]

Is your feature request related to a problem? Please describe. We introduced place name normalization at the presentation layer in https://github.com/peeringdb/peeringdb/issues/1452. This ensures that a search for a place name can return all results for that place name.

We did not introduce a process to continuously enforce place name normalization. The result is that well meaning object owners can adjust a normalized place name, unintentionally disrupting the search experience.

We should introduce a process for continuously enforcing place name normalization for search.

Who is affected by the problem? PeeringDB users.

What is the impact? Incomplete search results leading to users conducting more searches, which costs them time and PeeringDB compute and database resources.

Are there security concerns? No.

Are there privacy concerns? No.

Describe the solution you'd like

1. Attempts to change a normalized place name should result in a warning dialogue box explaining that the presentation of the name has been normalized to improve search quality.
2. The user should be able to a) revert to the normalized place name, or b) submit a notification to support@peeringdb.com explaining why the normalization is not correct, what the preferred normalization is, and citing a naming authority where that exists.
3. Notifications that are validated by the @peeringdb/ac should be applied consistently on all relevant objects.

Do you think this feature will require a formal design? Yes. We will need to carefully design of the dialogue box and make sure it can submit a ticket to support@peeringdb.com without requiring the user to send mail.

Describe alternatives you've considered Allow the data quality to degrade.

Could this feature request need support from the Admin Committee? This feature would create a feedback loop through the @peeringdb/ac. They'd need to develop processes for receiving notifications and deciding whether they are legitimate. Legitimate notifications would need to be incorporated into the ongoing naming normalization code.

What is the proposed priority? Up for discussion.

Provide a rationale for any/all of the above PeeringDB users have consistently placed search quality as a top priority.

[ynbrthr]

+1

[jackcarrozzo]

Does it make sense to do this normalization "on the fly" like this, and have the user send an email to support, or would it make more sense to allow the user, with a warning, to input the values however they see fit, then provide the AC a page of "misfits" and allow their reversion or acceptance?

[leovegoda]

Does it make sense to do this normalization "on the fly" like this, and have the user send an email to support, or would it make more sense to allow the user, with a warning, to input the values however they see fit, then provide the AC a page of "misfits" and allow their reversion or acceptance?

Allowing de-normalization followed by @peeringdb/ac review would seem to place a considerable additional burden on volunteers. We definitely need a process for improving normalization where its automated application fails but getting the correction by mail means we can apply it across the board, improving the quality of search output.

[grizz]

I think all we need to do is not allow users to enter addresses that we can't find and normalize. For places that "don't exist" in maps yet, the AC can step in.