Building a JSON Path community - an open invitation to Slack

[gregsdennis]

Before the IETF took over the specification effort, Glyn created a Slack workspace for collaboration and community building. Once the effort became an IETF project, the Working Group decreed that Slack was an unacceptable place for discussion because it was ephemeral and could not be archived by IETF. Thus all discussion was confined to the IETF mailing list and GitHub issues. (GitHub issues were actually only hestitantly included because those updates could be archived via some other IETF process.)

Now, as a result of that decision, there is no community for JSON Path, and the new RFC 9535 seems to have gone relatively unnoticed, except for the few places where I've advertised it, like with tooling providers and StackOverflow.

With the publication, the IETF WG has disbanded, and I think the effort to start building a community around the standard is long overdue.

Mailing lists and Github issues are fine, but email is archaic, and newer developers prefer more real-time communication. This is my experience of ~10 years working with JSON Schema.

JSON Schema's community has thrived by using a combination of GitHub issues/discussions and Slack (no mailing lists). Participants don't care whether their conversations are archived because it's generally:

• one-off questions
• chat about tangential tech
• chat about completely unrelated things

Discussions around actual spec development are redirected to GitHub, where it's a bit more "official" and public. But that's not to say that offline conversations can't also be had, so long as the result is posted back to an issue.

However, building a community around JSON Path isn't about discussing the direction of the spec. It's about providing help to those trying to use and implement the spec. This kind of discussion doesn't need to be archived (it's probably better than it's not), and it needs to be more real-time.

A community needs a space to have these kinds of conversations, and restricting all conversation to email lists and GitHub actively prevents such a space from forming.

Glyn has left the Slack workspace to me, and I intend to grow the community there. I invite anyone who wants to join for some conversation.

[cabo]

On 1. May 2024, at 22:52, Greg Dennis @.***> wrote:

Slack was an unacceptable place for discussion because it was ephemeral and could not be archived by IETF.

N.B.: The “because…” was the killer argument, but it is not the only reason Slack is unacceptable for some. (What you have been describing is typically done in a much better way by stackoverflow. And by ChatGPT :-)

Grüße, Carsten

[gregsdennis]

The “because…” was the killer argument...

These are not spec-development topics! They don't need to be archived. The argument is saying that every conversation about JSON Path needs to be archived specifically by IETF. That's simply not true.

I'm merely providing a communal space for such conversations.

What you have been describing is typically done in a much better way by stackoverflow. And by ChatGPT

StackOverflow is a question/answer site, yes, but it can't build a community; neither can AI bots, which were just becoming a thing when the topic came up before.

I'm doing this to provide a space for users and tooling maintainers to have conversations, not just post a single question and get a selection of variable-quality answers.

JSON Schema does this. OpenAPI does this. .Net does this (but with Discord). There are a lot of specifications which have communities built around them, and the WG refused to acknowledge the value that community provides.

What I don't understand is the opposition. If you don't want to participate, then don't. But no one has the authority to say that I'm not allowed to do this, not even the IETF or specification authors.

[cabo]

On 2. May 2024, at 01:08, Greg Dennis @.***> wrote:

What I don't understand is the opposition. If you don't want to participate, then don't. But no one has the authority to say that I'm not allowed to do this, not even the IETF or specification authors.

I’m not opposing that you are building your Slack channel. I just wanted to clarify that the IETF requirement for archiving the communication wasn’t the only reason we didn’t go for Slack earlier. Don’t feel constrained in your personal activities by my 2¢ of information …

Grüße, Carsten

[He-Pin]

slack is not available in China:(

[gregsdennis]

From what I can tell, the app is legal but it's blocked by China's firewall. Maybe use a VPN?

Looks like Discord is actually banned.

@He-Pin do you have a recommendation for a community app?

[danielaparker]

@gregsdennis , why not just create a github community repository and enable discussions?

[He-Pin]

How about discord, I can actually access it with a VPN

[gregsdennis]

JSON Schema uses both GH Discussions and Slack, but they're used differently.

GH Discussions

JSON Schema uses GHD primarily for large org-level or spec decisions that need to be public. The benefits of this are:

• the discussion is in the open
• the discussion is well documented
• anyone (with a GH account) can participate

Here's an example: https://github.com/orgs/json-schema-org/discussions/671

Some people do start discussions to ask questions, but usually that kind of thing shows up in Slack. GHD does have an "answer" mechanism, but I don't see it used much. Generally, questions like "does JSON Schema support X?" don't need the three benefits above (certainly not the "well documented" one).

Overall, the UX is okay, but I find it a bit clunky at times. When trying to reply to threads, I often end up creating new ones because the text boxes are just stacked. I see others having this problem as well. Here's one instance where someone corrected this mistake:

Secondly, the UI doesn't update immediately when a comment is made, which makes real-time conversation difficult. It seems to cater more to async communication, which can be fine.

I recognize these are minor things, but they can be annoying, and I just prefer the Slack/Discord experience.

Slack / Discord

JSON Schema uses Slack for general, real-time conversation.

We have channels for all kinds of things:

• specification - Discussion/questions about the specs. This is generally questions like "what does the spec say about X?" But we also will have preliminary discussions about potential changes, which may or may not lead to an issue being opened. If anything does need to change, though, we always open an issue for it and recap/link any discussion.

• implementers - Channel for maintainers of JSON Schema tooling. Often discussion here is more geared toward things like "How do people implemented X from the spec?" Having the comradery of other maintainers makes for better tooling and a better ecosystem.

• in-the-wild - Where are we finding people using JSON Schema? This really just serves to edify the community and show the kind of impact we're making.

• ... and so much more!

Ultimately, it's more social, but the topic of conversation is technical.

I'd prefer not to have both Slack and Discord. They serve the same purpose: real-time conversation.

Personally, right now, I'd prefer Slack. I already have several integrations set up:

• Github update from
  • this repo
  • json path compliance test suite repo
  • iregexp spec repo
• stack overflow RSS feed for json path questions

I'd have to set those up in Discord. It probably can be done, but I'm less familiar with Discord admin.

How about discord, I can actually access it with a VPN - @He-Pin

If you can access Discord with a VPN, you should be able to access Slack with a VPN.

[gregsdennis]

If @glyn, @cabo, and @goessner don't object, I'd like to set up GH Discussions here as another channel for people with questions.

[glyn]

I'm neutral on GH Discussions, but going off Slack rapidly because of their default AI scraping policy (and hence the negative privacy and environmental implications).

[gregsdennis]

Good callout @glyn.

Ref: https://www.securityweek.com/user-outcry-as-slack-scrapes-customer-data-for-ai-model-training/

I have requested opt-out for the JSON Path workspace.

[gregsdennis]

Received this in response to my opt-out request:

Thank you for reaching out to Slack support. Your opt-out request has been completed.

For clarity, Slack has platform-level machine learning models for things like channel and emoji recommendations and search results. We do not build or train these models in such a way that they could learn, memorize, or be able to reproduce some part of customer data. Our published policies cover those here (https://slack.com/trust/data-management/privacy-principles), and as shared above your opt out request has been processed.

Slack AI is a separately purchased add-on that uses Large Language Models (LLMs) but does not train those LLMs on customer data. Slack AI uses LLMs hosted directly within Slack’s AWS infrastructure, so that customer data remains in-house and is not shared with any LLM provider. This ensures that Customer Data stays in that organization’s control and exclusively for that organization’s use. You can read more about how we’ve built Slack AI to be secure and private here: https://slack.engineering/how-we-built-slack-ai-to-be-secure-and-private/.

[He-Pin]