New package: PRASInterface v0.1.0

[JuliaRegistrator]

• Registering package: PRASInterface
• Repository: https://github.com/NREL-Sienna/PRASInterface.jl
• Created by: @jd-lara
• Version: v0.1.0
• Commit: dcb927a69268e3a776172e4c1c5d8bc83bfadaf2
• Reviewed by: @jd-lara
• Reference: NREL-Sienna/SiennaPRASInterface.jl@dcb927a#commitcomment-149447558
• Description: Interface to PRAS.jl maintained by Sienna\Ops

[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]

Thank you for submitting your package! However, please make sure to add some documentation before registering. At the very least, that would be a description of the package's purpose and a small usage example in the README.

It's not clear to me whether the name of the package is appropriate. I was not able to find the PRAS.jl referenced in the documentation. If it exists, PRASInterface seems like and unusual name (why would a Julia package need another Julia "Interface")?

[goerz]

Update: I was now able to guess at the URL for the documentation https://nrel-sienna.github.io/PRASInterface.jl/dev/

Please note that the docs badge in the README is currently broken. That will probably resolve itself once this registration goes through and there is a tagged version, but please confirm that it works at that point.

You'll also want to add the "About" info from the documentation to the main README.

Now that I've seen the documentation, I would recommend the package name PowerSystemsPRAS.jl. The current name PRASInterface only makes sense from the perspective of a PowerSystems user. It would be appropriate in an org-specific registry, or as a submodule name, but not for the wider audience of the General registry. There might be other orgs or packages that might want to interface with PRAS, after all. Moreover, since you already have PowerSystems, it is common practice and encouraged to use PowerSystemsSomething for "add-ons", where there is little scrutiny on the package name. You basically "own" that namespace.

[jd-lara]

Update: I was now able to guess at the URL for the documentation https://nrel-sienna.github.io/PRASInterface.jl/dev/

Please note that the docs badge in the README is currently broken. That will probably resolve itself once this registration goes through and there is a tagged version, but please confirm that it works at that point.

You'll also want to add the "About" info from the documentation to the main README.

Now that I've seen the documentation, I would recommend the package name PowerSystemsPRAS.jl. The current name PRASInterface only makes sense from the perspective of a PowerSystems user. It would be appropriate in an org-specific registry, or as a submodule name, but not for the wider audience of the General registry. There might be other orgs or packages that might want to interface with PRAS, after all. Moreover, since you already have PowerSystems, it is common practice and encouraged to use PowerSystemsSomething for "add-ons", where there is little scrutiny on the package name. You basically "own" that namespace.

Thanks for the comments @goerz, on the name we would like to keep the existing one since it is an interface to this package https://github.com/NREL/PRAS that isn't own directly by us. This package is an interface between our data library PowerSystems.jl and PRAS that's where the names comes from. The difference is that the authors of PRAS decided not to register it in the general Julia registry.

I will update the README and the registration request.

[goerz]

Thanks for updating the README!

on the name we would like to keep the existing one

Like I said, I don't think the name PRASInterface is appropriate in the context of General. Is there something that you find objectionable about PowerSystemsPRAS?

Of course, I don't have any special authority, so you could also ask for other people's opinion on Slack. If there's a broad consensus in the community that the name is okay, I'll be happy to unblock.

[jd-lara]

Thanks for updating the README!

on the name we would like to keep the existing one

Like I said, I don't think the name PRASInterface is appropriate in the context of General. Is there something that you find objectionable about PowerSystemsPRAS?

Of course, I don't have any special authority, so you could also ask for other people's opinion on Slack. If there's a broad consensus in the community that the name is okay, I'll be happy to unblock.

The objection is that PowerSystemsPRAS doesn't reflect the true usage of this library, if we develop our own Probabilistic Resource Adequacy capability then there will be name confusion. This is not the correct package convention in our organization.

The name we want to use is reflective of what the package actually does: an interface to PRAS.jl, similarly we registered in the past PowerModelsInterface.jl. It's an interface between our data model and another Julia modeling library period. The difference is that in the case of PRAS.jl, a common library for users in the Resource Adequacy space, our team doesn't have the mechanism to make the authors register it to General.

I don't understand the need to request community feedback for the registration of this package that follows the conventions of our organization that already have plenty of registered packages in the power systems modeling space.

[adienes]

I think it is important to note that the name PRAS.jl would also likely be rejected from General. Recall rule 1 on the naming guidelines:

1. Avoid jargon. In particular, avoid acronyms unless there is minimal possibility of confusion.

so the fact that PRASInterface.jl is related to PRAS.jl is kind of irrelevant because PRAS.jl only exists in a private registry.

On another note, I'm wondering if this should be a package extension rather than a standalone? it seems like the functionality here only exists in the context of PowerSystem.jl and PRAS.jl together, and it does not have any function as an independent package.

[goerz]

The name we want to use is reflective of what the package actually does: an interface to PRAS.jl

Maybe I'm confused. An interface between PRAS and what else? Whatever that "what else" is should be part of the package name. I thought this package was an Interface between PowerSystems and PRAS, hence the suggestions.

similarly we registered in the past PowerModelsInterface.jl

At the time that was registered, there weren't as many volunteers reviewing package submissions. Thus, things slipped through the cracks. The name PowerModelsInterface has the same issue as PRASInterface: an interface is between two things, and the name does not indicate what those two things are. That package would probably not have been merged by today's standards.

I don't understand the need to request community feedback

The General registry is a community resource, so all registrations will be reviewed

for the registration of this package that follows the conventions of our organization

You are moving a package from the context of a specific organization to the General registry that addresses the entire community. For people internal to NREL-Sienna the name PRASInterface makes perfect sense. Someone in the general public does not have that context, so it is not clear what is interfacing with PRAS here. This wouldn't be a problem if packages in Pkg included the org name. That's something I'd love to have in Julia 2.0, but it's not what we have now. If this package is an interface between PRAS and general code inside your organization (rather than between a particular package like PowerSystems and PRAS), then probably SiennaPRASInterface would be the appropriate name.

P.S.: Just reread your original response

This package is an interface between our data library PowerSystems.jl and PRAS that's where the names comes from.

So I didn't just make this up. If what you say is true, there is no question that PowerSystemsPRAS is pretty much the only correct name for the package.

[goerz]

PRAS.jl would also likely be rejected from General

Yes, or at least it would receive some pushback. I'm actually not sure how exactly PRASInterface manages to avoid an explicit dependency on PRAS. There appears to be some vendored code…

It does seem like a problem to have a registered package interfacing with PRAS when PRAS is not registered. There's a reason that dependencies of registered packages also have to be registered. If PRAS ever were to be registered, I can't guarantee that it would manage to get an exception from the naming guidelines, even though I'm open to it. If PRAS had to change names, PRASInterface would have a problem.

It would be good for @GordStephen to clarify what kind of plans there might be for a registration of PRAS, and/or whether NREL can guarantee that PRAS will exist as a permanent name.

Side node: if PRAS ever were registered, even if we make an exception for the name (which we very well might), the repository URL has to be changed to end with .jl. I'd recommend doing that anyway, as early as possible

[jd-lara]

PRAS.jl would also likely be rejected from General

Yes, or at least it would receive some pushback. I'm actually not sure how exactly PRASInterface manages to avoid an explicit dependency on PRAS. There appears to be some vendored code…

It does seem like a problem to have a registered package interfacing with PRAS when PRAS is not registered. There's a reason that dependencies of registered packages also have to be registered. If PRAS ever were to be registered, I can't guarantee that it would manage to get an exception from the naming guidelines, even though I'm open to it. If PRAS had to change names, PRASInterface would have a problem.

It would be good for @GordStephen to clarify what kind of plans there might be for a registration of PRAS, and/or whether NREL can guarantee that PRAS will exist as a permanent name.

Side node: if PRAS ever were registered, even if we make an exception for the name (which we very well might), the repository URL has to be changed to end with .jl. I'd recommend doing that anyway, as early as possible

I can get behind using SiennaPRASInterface if it moves the conversation forward. Please just confirm so I can change the name.

BTW, reading your reponse I have to feedback that comments like "So I didn't just make this up. If what you say is true, there is no question that PowerSystemsPRAS is pretty much the only correct name for the package." aren't really a suggestion.

[rayegun]

@goerz please avoid statements like:

So I didn't just make this up. If what you say is true, there is no question that PowerSystemsPRAS is pretty much the only correct name for the package.

You do not decide the "only correct name" for a package. While you correctly state that you are not the final arbiter of names here, your tone and frequency of activity often suggests otherwise. Statements like this are far too aggressive, and factually incorrect. Please maintain a more conciliatory and suggesting rather than demanding tone.

The registry is an initial point of contact for many users and groups in the Julia community, and the tone of naming disputes like this one is a source of frequent complaints directed to me and other folks in community facing roles. Remember that by helping to maintain our naming guidelines you are representing the Julia community which we want to be a welcoming, kind place.

Since the author has agreed to a potential alternative name I will not rebut any of the other statements, and support their bid to use that name.

[noblock]

[goerz]

@rayegun Point taken. That phrasing was indeed out of line. I apologize.

[goerz]

We talked this out on Slack. @jd-lara will check to see if renaming to SierraPRASInterface is easy to do. If the internal procedures within NREL make a rename too cumbersome (we're talking about a government agency, after all), we'll just stick to PRASInterface and I'll unblock.

[jd-lara]

This PR can be closed given #120172