Release / testing / feedback plan for extensibility

[handrews]

@marksparkza I'd like to check in on how to manage the timeline for extensibility changes. I've had plenty of experience doing volunteer open source / open standards work, and am well aware of how hard it can be to get time for it. I'm not interested in rushing you in any way.

However, I have contracts and deadlines and need to choose how to make use of this proposed-but-not-approved code, and wanted to make sure you had input into that. (to be clear, I do not consider you in any way responsible for my commitments to my clients - I'll work with however you choose to manage things).

The current state of things:

• I've got a lot of things working and am using the oascomply-m2 branch in my fork to support my work on the OASComply project's Milestone 2
• To work within your time constraints, I think it's better for me to do a lot of real-world testing of these concepts and implementations before sending you more PRs
• The oascomply-m2 branch starts by rebasing most of the older PRs still outstanding, and then stacking various changes on top of that; some of that work is well-structured and unit-tested, but later commits are various fixes that probably need to be smoothed into design once I'm sure I've flushed out the bugs
• There is the question of whether the direction I'm going in is even one you would support; I'm not sure how to make that easy to assess

One option would be to have a call to discuss all of this- if you are interested in that, please email me to find a time (my email address is on my github profile).

Other than that, the options seem to be:

• Install directly from my branch from my fork (what I'm doing now, and my default approach if you don't suggest otherwise); pro: it's clear to those who look that it's my responsibility, not yours; con: they have to know how to look in the project dependency configuration to see that
• Some sort of preview release of jschon from you – this would be good if you were fairly confident of the direction and we wanted broader feedback, but I don't think the code is there yet even if the direction is right
• I publish a package named in some way that acknowledges that it' a derivative of jschon that may or may not get folded in to jschon proper in the future; pro: this would make it very clear that the code is my responsibility rather than yours to any future maintainer of / contributor to oascomply; con: it might look a bit like forking the projected on an ongoing basis, which is not what I want at all

I'm sure there are other options. These are just the ones that come to mind for me. Something that appeals about the last option is that I could also publish docs for the modifications under the modified package name; otherwise I probably need to incorporate docs for the jschon modifications into the oascomply docs for future oascomply contributors.

---

I started contributing to jschon before I had any sort of contract relating to it, and I expect to remain available to see these changes through to whatever resolution you ultimately decide on even after my oascomply contract is done (probably in November).

Anyway, my apologies for the somewhat rambling thoughts. I'm open to any suggestion/feedback on how to manage this. My priority between now and mid-November is oascomply, but after that I will likely have time to work on aligning the by-then-well-tested changes with your vision for jschon. And writing a new URI package.

[marksparkza]

@handrews Thanks for asking for my input on the usage of your proposed changes. Currently, my hands are full on both work and home fronts, and I'm unlikely to have an opportunity to review your PRs or take any decisions as to the direction of jschon development before your contract ends. I'll be happy with and will respect your decision as to the way forward for integrating jschon into OASComply.

[handrews]

@marksparkza my apologies for not responding! I just want to reply here for anyone reading - I very much appreciate your willingness to let me publish a jschon-experimental package (module name jschonexpr?). I do hope to be able to collaborate with you more in the future whenever you get back to jschon – I chose to work on this package rather than writing my own because it already had a solid design and idiomatic modern Python code. It has been good for me to work within someone else's architecture while modernizing my Python skills!

[handrews]

(I actually thought I had responded a while back and am a bit embarrassed to find that I did not 😬 )

[marksparkza]

No problem! Likewise, I look forward to collaborating further. It's great to have an active and enthusiastic contributor on board and particularly someone with a deep understanding of JSON Schema.

jschon-experimental package (module name jschonexpr?)

I'd suggest jschon_experimental as the module name, so if someone comes across an import and they're unfamiliar with the package they can easily identify it with pip list.