Project governance

[cburgmer]

I realised that I have been making a lot of changes lately without garnering feedback. Now, this project was started as an individual, then got contributions via new queries, new implementations, bug fixes and a lot of feedback via issues. The best time to formalise contributions was when this started, the second best time is now.

I propose to align and document how contributions are preferred by the community so this project can see healthy contributions in the future.

We might want to discuss:

• The goal: is it clear, do we agree?
• How to get feedback on changes. Does it always have to be PRs or can we define categories of changes, like adding new queries/implementations, changing Proposal A, changing the goal of the project, changing the way we build the comparison, ...
• ...

What do you think?

[glyn]

I think the goal for now is clear: compare the behaviour of multiple JSONPath implementations.

As we see a JSONPath standard emerging, it is important to include reference implementation(s) in the comparison. One reference implementation has already been added. When the standard and reference implementation are complete, it may then be beneficial to change the goals of this project to compare the other implementations against the Compliance Test Suite rather than, or maybe as well as, against the computed consensus, as this will help implementations move towards the standard should they wish to.

I would have thought that issues and PRs are the best way to get feedback. I don't think it's necessary to formalise the project governance beyond this. Are there specific examples where you think more formal governance would help?

[danielaparker]

Regarding proposals, would you be open to accommodating an alternative proposal, a Proposal B, as it were?

[glyn]

Regarding proposals, would you be open to accommodating an alternative proposal, a Proposal B, as it were?

What would be the goal of adding an alternative proposal?

[danielaparker]

Regarding proposals, would you be open to accommodating an alternative proposal, a Proposal B, as it were?

What would be the goal of adding an alternative proposal?

When one does stuff for free, is it necessary to have a point? But perhaps as a point of reference. I have some thoughts on the syntax and semantics that differ somewhat from Proposal A, some thoughts on a full specification of comparative and arithmetic expressions that are not present in proposal A, and some thoughts about some non-breaking extensions to the JSONPath syntax, some with precedents. Such thoughts may be of interest, or not. But in any case, the existence of an "A" almost demands a "B"!

[glyn]

Thanks @danielaparker. The reason I asked was to determine whether another proposal or another reference implementation of the evolving internet draft was most appropriate. The former turns out to be the case. I'm personally comfortable with that as it would shed more light on the problem space.

@cburgmer wdyt?

[danielaparker]

As we see a JSONPath standard emerging ...

Do we, though? Is JSONPath a protocol that the IETF can realistically take ownership of? Is a "full standards" IETF RFC likely to emerge? Is there a compelling reason that JSONPath implementations must interoperate?

I'm starting to think that the answer to these questions is no. I think it's more realistic to concentrate on historical comparisons and experimental proposals.

[bwl21]

Is there a compelling reason that JSONPath implementations must interoperate?

yes there is.

• If I am using JSONPath expressions in configuration files which aim to be used in various Implementations those expressions should be uinversal
• I am using an interactive tool https://extendsclass.com/jsonpath-tester.html to investigate expresions. The such developed expressions should work in other implementations as well.