Assembling a Technical Committee

[TotalTechGeek]

Hey folks 👋🏻

A bit of an update about how we plan to streamline the proposal process and drive the momentum of this initiative forward: we’ll be assembling a Technical Committee (TC).

The Technical Committee will play a role in representing the interests of the JSON Logic community. It'll be responsible for managing and voting on proposals, and ensure that community-driven ideas are thoughtfully reviewed and actively progressed.

While the TC will help with decision-making and maintaining momentum, every member of this initiative is encouraged to contribute ideas and participate in discussions. The TC is not a gatekeeper but a structure designed to facilitate collaboration, resolve roadblocks, and ensure proposals move toward actionable outcomes.

This initiative thrives on the voices of its members, and we’re committed to maintaining an inclusive and transparent process.

With that expressed, if you’re passionate about the future of JSON Logic and have a desire to contribute to the process as a member of the TC; we're looking for active volunteers.

We're aiming for a core group of about 3-6 folks; representing different stakeholder groups (Maintainers, Users).

</Formal Speak>

The more voices in this initiative -- the better.

The formation of a TC is to help us move forward even as folks start to get busy.

All input will be appreciated and respected, and the TC group will likely rotate members.

[TotalTechGeek]

Ah; I'll start tagging major announcements -- @json-logic/core

[gregsdennis]

I'm happy to contribute, though my involvement may be more sparse than desired.

I'm currently the primary author of the JSON Schema specification (this, my day job, and my family take up my time), and I was a major contributor on RFC9535 JSON Path.

I also have implementations of each as well as JSON Logic and a few others on my json-everything project.

I'll keep watch, participate in discussions, and offer advice from time to time, but someone else should take point on spec authorship and management.

[dslmeinte]

I'd be happy to contribute on a structural basis if I wasn't already member of another “TC-of-sorts” (https://lionweb.io/). So, I'll stick to keeping in touch and offering my advice from time to time — at least for now.

[codetiger]

Am happy to contribute. I have implemented DataLogic-rs the Rust library for JSONLogic and also maintaining the Compat tables repo, test suite for all implementations in this Org. Right now, my knowledge on JSONLogic is more on the implementation side, and am slowly getting better on the spec side.

[TotalTechGeek]

@json-logic/core

TC Selection

Hey folks: I'm looking for one more active maintainer to join the TC, but here is the current selection.

GitHub	Name	Background
@TotalTechGeek	Jesse Mitchell	Project Maintainer; Initiative Organizer
@codetiger	Harishankar Narayanan	Project Maintainer; Working on Compat Table
@gregsdennis	Greg Dennis	Project Maintainer; Active in multiple RFCs
@toddbaert	Todd Baert	JSON Logic User; OpenFeature TC Member
@jwadhams	Jeremy Wadhams	JSON Logic Creator

@jwadhams We'll try to respect your mixed availability; but you've a seat if you're interested.

---

Proposal Process

Here is the process I believe we'll begin with, but we can ratify changes:

3 Phases for Proposals

• Phase 0: Proposal Status
• Phases 1-2: Validation / Implementation Status
• Phase 3: Accepted

In Phase 0, Proposals are introduced to this organization as discussions.

Proposals that influence JSON Logic must attach a test suite in the format described here.

Each proposal should describe relevant background, use cases, and explore potential roadblocks.

Proposals must not break backwards compatibility with the original tests.json (This will probably be one of the first discussions that the TC ratifies)

During Phase 1 Proposals will be implemented in a few JSON Logic runtimes. If we encounter significant friction in Phases 1-2, or there is a reasonable community concern raised, we can pull the proposal back to Phase 0.

For an item to move to Phase 3, a # of implementations (to be decided by the TC) must have support.

Voting Process

For a Phase 0 Proposal to move to Phase 1, it must receive 3 TC Approvals and no TC Vetoes.

For now, members are allowed to vote on their own proposals.

If there's a community member (non-TC) concern / veto, then we should try to address that concern.

If we're unable to reach consensus, then 4 TC approvals must be received for the proposal to proceed.

Issue #7 has been updated to recommend we add a document for this.

[toddbaert]

A proposal I'd be interested in putting forward would be some kind of basic observability/tracing/logging support.

One challenge for us has been teams using OpenFeature failing to supply contextual information which their own flag evaluation rules (written in JSONLogic) operate on - the data that they extract with the var operator is therefore missing and it's pretty difficult to surface this easily across many different teams and language implementations.

[TotalTechGeek]

I'm a bit hesitant at this stage to embed that into "JSON Logic Core", as I perceive that as more of an implementation detail of the engine rather than a feature of the AST.

Don't get me wrong -- I see the use-case for the feature, but I'm not sure if I'd embed that into the RFC.

--

Not exactly suggesting this as a solution, just thinking through how I'd handle it,

If I was stuck in user-space with no built-in engine hooks, I'd potentially set up a shim like engine.methods.var = trace(engine.methods.var) where trace intercepts the input and output for calls made to the operator.

Basically allowing you to subscribe to operators you believe would help glean additional information for your use-case.

Assuming most implementations allow you to substitute operators, in theory we could have an org member maintain an observability shim monorepo. This would not be a part of JSON Logic Core / the RFC initiative.

[rmannibucau]

The observability has two comments from my side:

1. it must be observability friendly in terms of backbone (for example i have a case i'm adding a http operator and i want it to surface)
2. it means the API must be reactive friendly somehow (not sure it lands in the spec, maybe not while it stays json only but this is something to keep in mind),
3. the decoration pattern always works since it enables to forward the context (ThreadLocal, AsyncLocal, ... highly depends the techno) but must be kept usable, ie you should be able to decorate operators easily and reference built-in operators easily.

However it can't really be done at JSON level since it needs the techno insights (where is the context, how to do a decorator etc), so maybe something to put in an appendix of the spec as a "nice to have" in implementations only?

[gregsdennis]

This doesn't sound like a concern of the spec to me. This operator decoration is not inherent to how JSON Logic works; it's an interaction with an implementation.

I think this better fits in documentation as part of an "Implementers' best practices" document.

[toddbaert]

Don't get me wrong -- I see the use-case for the feature, but I'm not sure if I'd embed that into the RFC.

so maybe something to put in an appendix of the spec as a "nice to have" in implementations only?

I think this better fits in documentation as part of an "Implementers' best practices" document.

Ya I'm not prescribing anything - It's just a challenge that impacts all implementations I'm familiar with. I understand that the specification itself would primarily concern itself with operators and their behavior, but I'd hope that "orthogonal" concerns like this (even if they weren't "binding" in the same way as operator behavior) would be something this community could help with, perhaps with appendixes or other tangential documents.