New package: FSMoshd v0.1.0

[JuliaRegistrator]

• Registering package: FSMoshd
• Repository: https://github.com/jannefiluren/FSMoshd.jl
• Created by: @jannefiluren
• Version: v0.1.0
• Commit: 9ed2b47b64bd60cbad14496c1f3a51aa1891ffa3
• Reviewed by: @jannefiluren
• Reference: jannefiluren/FlexibleSnowModelOSHD.jl@9ed2b47#commitcomment-178480395

[jannefiluren]

[noblock]

See old pull request and related discussion: #149511

This package is a variant of the Flexible Snow Model (FSM) developed by the Operationeller Schneehydrologischer Dienst (OSHD) at the WSL Institute for Snow and Avalanche Research SLF in Switzerland.

We acknowledge the guideline that “package names should be sensible to most Julia users, even to those who are not domain experts.” However, in this case, both acronyms (FSM and OSHD) are de facto standards in the scientific literature and are widely recognized at all relevant conferences. For the intended target audience of this package, the current naming is therefore both meaningful and appropriate.

OSHD has developed its own variant of FSM, which is implemented in Julia as FSMOSHD.jl. This name is consistent with established terminology and will be immediately understandable when presenting the model in scientific publications and at conferences. We therefore hope you agree that this package name is justified and suitable.

[github-actions]

Hello, I am an automated registration bot. I help manage the registration process by checking your registration against a set of AutoMerge guidelines. If all these guidelines are met, this pull request will be merged automatically, completing your registration. It is strongly recommended to follow the guidelines, since otherwise the pull request needs to be manually reviewed and merged by a human.

1. New package registration

Please make sure that you have read the package naming guidelines.

2. AutoMerge Guidelines are all met! ✅

Your new package registration met all of the guidelines for auto-merging and is scheduled to be merged when the mandatory waiting period (3 days) has elapsed.

3. To pause or stop registration

If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment.

Tip: You can edit blocking comments to add [noblock] in order to unblock auto-merging.

[goerz]

Please don't use the letter of the guidelines to violate the spirit of the guidelines. That spirit is that we don't want opaque acronyms as package names, and probably much less two concatenated opaque acronyms. Changing the uppercase just to make the automerge checks happy is arguably worse: If an acronym is a part of package name, then it should remain in all-caps.

It's totally fine to have an acronym as part of a package name, since as you say, acronyms are often recognizable to experts in the field; but they should be paired with more explanatory names. You could definitely do FactorialSnowModelOSHD, and that would be my recommendation if you want to highlight that this is a particular variant of FSM developed by OSHD.

You can of course still use the acronym FSM in your README and documentation, which should help with Google and any users that miss the connection from "Factorial Snow Model" to FSM. You can also recommend usage of the package as something like

import FactorialSnowModelOSHD as FSM

Of course, if you want to persist in the argument that the acronyms and only the acronyms would be recognizable to your users, you can try to find other Registry maintainers willing to merge #149511 (or this PR), but I myself would be extremely hesitant about either FSMOSHD or FSMoshd.

[jannefiluren]

Sorry. My mistake. I should have commented on the first pull request, whether FSMoshd was an option as a package name, instead of creating a new pull request. It was never my intention to "try to sneak under the radar" by using lower case letters for the second acronymn (didn't know this would be accepted automatically); this name was decided as an option after a looong team discussion. For us, FlexibleSnowModelOSHD would work well. Is that good for you @goerz? If so, should I change the package name and issue a new pull request?

[goerz]

It was never my intention to "try to sneak under the radar"

No worries!

For us, FlexibleSnowModelOSHD would work well. Is that good for you @goerz?

Absolutely! That should pass all the automatic checks as well. You can go ahead, and I can close both of the existing PRs in favor of the new one when it pops up.

Thank you for taking the package naming guidelines seriously. I understand that Julia has a quite a different naming philosophy ("long and descriptive") from most other language communities and that this can sometimes be a source of frustration or at least consternation. But I think it's a good approach at the end of the day, and that the name FlexibleSnowModelOSHD will in fact make your package more approachable to the wider Julia community (and even domain experts) than FSMOSHD would have.

[goerz]

Closing in favor of #149626

[jannefiluren]

Thank you very much for your help @goerz with registring this package. I hope I did everything correct with the third pull request. All the best, Jan

[goerz]

Looks good! #149626 should auto-merge after the usual waiting period