pvl as a potential example of a PlanetaryPy-Affiliated Package

This topic has come up in another Issue (#3), and as part of an agenda item in the December meeting, but I think we need to 'chew' on it as a specific example, because I think it raises some questions that we need to decide how to tackle as we consider other Affiliated Package applications as we (and others) attempt to use our Procedures to submit or review such packages.

Firstly, I'll try and be careful in this Issue to write 'we' and 'us' to mean the PlanetaryPy TC or the PlanetaryPy Project, and attempt to write 'pvl developers' to mean the people who commit to the pvl repo and maintain it. For the purpose of thinking about how we review things, I think it is important to think of those as two separate groups of humans (even though there is significant overlap).

That being said, I'm going to do a brief gedanken review here, following our Procedures, this might be the consensus review I'd write for pvl today, as is:

Gedanken Review of `pvl`

Functionality/Scope
Since the PDS and ISIS heavily use PVL, a `pvl` package definitely qualifies as 'general.'
Integration with PlanetaryPy ecosystem
This is red because there is currently no 'core' PlanetaryPy package that yet exists. Of course, the criteria for 'Green' is just 'Uses PlanetaryPy core or affiliated packages wherever possible.' One could argue that this should be green because there are no places where this is currently possible.
Documentation
No further comments
Testing
There's only one test that currently fails, but there really aren't any unit tests, the existing tests are focused on the user-facing functions, but one could argue that since they pass, and this package already has wide usage, that this is in a pretty good state.
Development status
The `pvl` repo does have a CONTRIBUTING document, but it doesn't have a code of conduct nor a guiding document for how the 'pvl project' operates. In order to re-invigorate this package, the pvl developers need to establish some additional practices. One way to do that would be to use the (not-yet-updated-for-the-modern-PlanetaryPy-Project) PlanetaryPy package template, which, in addition to establishing software-focused templates, also includes templates for a developer charter, a code of conduct, etc.
Python version compatibility
The package currently is written with the `six` compatibility library to serve both Python 2 and Python 3 users. It would be nice to see the pvl developers free themselves from Python 2 and update the package using language features in Python 3.6.

The software is currently listing its version as 0.3.0 with a development status of 'Development Status :: 2 - Pre-Alpha' and given its widespread usage, I'd recommend the pvl developers embrace the fact that they're out of development, and that its next release be 1.0.0 (and that the developers follow the Semantic Versioning 2.0.0 approach to versioning).

Summary/Decision: According to the review guidelines, this review has some red, so we wouldn't accept it. However, I think we might talk ourselves around to it being green or at least 'not applicable' given that we currently have no core package upon which to really evaluate this. Then we're down to looking at a review that is mostly green with some orange, and therefore this package meets the review criteria for affiliated packages, so we would list it.

@michaelaye had a concern about pvl having open PRs and Issues, but we'll never accept anything if we require that there be zero PRs and Issues. I suspect that his concern is more about the fact that pvl isn't really 'active' right now. The Procedures that we copied from Astropy seem to indicate that this is okay, as long as it is functional and useful to the community. Are we okay with that? I think we should be.

The other thing that came up for me during this process is that there is no criteria category about a package's 'community,' and by that I mean the elements that we now recognize as being important to a healthy open source project: a charter, a code of conduct, a contributing document, or a requirement for an open source license (basically the stuff that the PSO recommends). I am of two minds about this:

These should be criteria: we could establish a red / orange / green spectrum
They should not be criteria (otherwise we would not be able accept software that has a devstatus of 'Functional but unmaintained' or 'Functional but low activity.' Those would change from orange to red).

I think I'm leaning towards the second one. I know that might seems antithetical to what we're about, but I am advocating an approach below that doesn't bar entry on these criteria, but does include a mechanism for ejecting bad actors.

Firstly, we 'encourage' packages to follow this model by including templates for these kinds of documents in the package template, and I suspect those that do will be more successful in generating and maintaining community than those that don't.

For those Affiliated Packages that we accept but that don't have these documents, we clearly indicate that a set of 'default' versions of these documents apply to them (or we just point to the templates in the Package Template and be clear that if you don't have them in your repo, those generic ones apply to your repo anyway). If an Affiliated package doesn't conform to those rules (for example, a previously unmaintained project that was admitted comes back to life, but the repo owner doesn't allow people to contribute or something), then we try and help them deal with it, or delist them (but we don't make the absence of these documents a bar to entry in the first place).

I also wondered about what this might mean for our potential 'status' as a Planetary Software TLP, and have logged an Issue on their repo: planetarysoftware/TSC#75. So we might get some guidance from that.

planetarypy / TC