Thanks for bringing it up! I hadn't been thinking very carefully through such matters, Following Fabian's original thread
, I think anything in mapschool.io
is fair game for inclusion in JuliaGeo; and if there's any lingering doubt, ask (on this mailing list)?
I had been looking mostly at the design and organization of packages in Python (because they seem like the language of choice for the GIS developers I've been following), but will be happy to see things from a different perspective (e.g. from people who work with R/databases/etc).
For a start, I'm willing to continue to have a discussion over every new package that comes along (even bike-shedding over names
), just to make sure we're converging towards a common objective (as an organization). We can always list some common guidelines later (put things into a wiki, etc), if we find ourselves repeating the same points.
Maybe it's easier to have standards on the "eventual quality standards" of packages in JuliaGeo. I had been implicitly looking out for
- a clear scope/vision of what the package is trying to achieve, that
- is relevant to the organization, and
- is orthogonal in contribution to existing packages
- doesn't imply/require more effort* on my part (to get it "up to speed"), than I'm willing to put in
And so the priority (to me) at the moment isn't whether it has tests/docs/etc, but whether it is easy enough for others to follow what's happening. If the code is complex, provide an API. If the API is complex, provide some minimal working examples. If there's more examples/things-that-needs-to-be-explained, then I think it's fair for others to ask you for having tests/docs up before consideration for inclusion in JuliaGeo?