Closed rbeyer closed 4 years ago
Regarding those Affiliated Packages that don't have 'governance documents' that will be resolved if #23 is merged.
Other than that, there hasn't been any discussion on this gedanken review, and the real test of this mechanism is to exercise the real application process. So if #23 merges, I'll close this issue.
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
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.
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 thatpvl
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:
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.