Skip to content

Commit

Permalink
Script updating archive at 2024-05-21T01:15:51Z. [ci skip]
Browse files Browse the repository at this point in the history
  • Loading branch information
ID Bot committed May 21, 2024
1 parent f6173c2 commit 1a93f39
Showing 1 changed file with 24 additions and 3 deletions.
27 changes: 24 additions & 3 deletions archive.json
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"magic": "E!vIA5L86J2I",
"timestamp": "2024-05-12T01:20:57.298783+00:00",
"timestamp": "2024-05-21T01:15:48.713300+00:00",
"repo": "ietf-wg-jsonpath/draft-ietf-jsonpath-base",
"labels": [
{
Expand Down Expand Up @@ -17192,7 +17192,7 @@
{
"number": 521,
"id": "I_kwDOEIqrgc6HjUV8",
"title": "Building a JSON Path community - an invitation to Slack",
"title": "Building a JSON Path community - an open invitation to Slack",
"url": "https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/issues/521",
"state": "OPEN",
"author": "gregsdennis",
Expand All @@ -17201,7 +17201,7 @@
"labels": [],
"body": "Before the IETF took over the specification effort, Glyn created a [Slack workspace](https://join.slack.com/t/jsonpath-standard/shared_invite/zt-2ib70i0vk-z5YmH18OjXQhrDymHB1HKg) 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.)\r\n\r\nNow, 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.\r\n\r\nWith the publication, the IETF WG has disbanded, and I think the effort to start building a community around the standard is long overdue.\r\n\r\nMailing 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.\r\n\r\nJSON 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:\r\n\r\n- one-off questions\r\n- chat about tangential tech\r\n- chat about completely unrelated things\r\n\r\nDiscussions 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.\r\n\r\nHowever, 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.\r\n\r\nA 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.\r\n\r\nGlyn 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.",
"createdAt": "2024-05-01T20:52:33Z",
"updatedAt": "2024-05-08T21:36:25Z",
"updatedAt": "2024-05-21T00:21:24Z",
"closedAt": null,
"comments": [
{
Expand Down Expand Up @@ -17259,6 +17259,27 @@
"body": "JSON Schema uses both GH Discussions and Slack, but they're used differently.\r\n\r\n### GH Discussions\r\n\r\nJSON Schema uses GHD primarily for large org-level or spec decisions that need to be public. The benefits of this are:\r\n\r\n- the discussion is in the open\r\n- the discussion is well documented\r\n- anyone (with a GH account) can participate\r\n\r\nHere's an example: https://github.com/orgs/json-schema-org/discussions/671\r\n\r\nSome 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).\r\n\r\nOverall, 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:\r\n\r\n![image](https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/assets/2676804/d21a6b1e-2583-430d-b97c-567cd773b22a)\r\n\r\nSecondly, 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.\r\n\r\nI recognize these are minor things, but they can be annoying, and I just prefer the Slack/Discord experience.\r\n\r\n### Slack / Discord\r\n\r\nJSON Schema uses Slack for general, real-time conversation.\r\n\r\nWe have channels for all kinds of things:\r\n\r\n- #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.\r\n- #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.\r\n- #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.\r\n- _... and so much more!_\r\n\r\nUltimately, it's more social, but the topic of conversation is technical.\r\n\r\nI'd prefer not to have both Slack and Discord. They serve the same purpose: real-time conversation.\r\n\r\nPersonally, right now, I'd prefer Slack. I already have several integrations set up:\r\n\r\n- Github update from\r\n - this repo\r\n - [json path compliance test suite repo](https://github.com/jsonpath-standard/jsonpath-compliance-test-suite)\r\n - [iregexp spec repo](https://github.com/ietf-wg-jsonpath/iregexp)\r\n- stack overflow RSS feed for json path questions\r\n\r\nI'd have to set those up in Discord. It probably can be done, but I'm less familiar with Discord admin.\r\n\r\n> How about discord, I can actually access it with a VPN - @He-Pin\r\n\r\nIf you can access Discord with a VPN, you should be able to access Slack with a VPN.",
"createdAt": "2024-05-08T21:36:23Z",
"updatedAt": "2024-05-08T21:36:23Z"
},
{
"author": "gregsdennis",
"authorAssociation": "COLLABORATOR",
"body": "If @glyn, @cabo, and @goessner don't object, I'd like to set up GH Discussions here as another channel for people with questions.",
"createdAt": "2024-05-20T21:37:29Z",
"updatedAt": "2024-05-20T21:37:40Z"
},
{
"author": "glyn",
"authorAssociation": "COLLABORATOR",
"body": "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).",
"createdAt": "2024-05-20T23:35:16Z",
"updatedAt": "2024-05-20T23:35:16Z"
},
{
"author": "gregsdennis",
"authorAssociation": "COLLABORATOR",
"body": "Good callout @glyn.\r\n\r\nRef: https://www.securityweek.com/user-outcry-as-slack-scrapes-customer-data-for-ai-model-training/\r\n\r\nI have requested opt-out for the JSON Path workspace.",
"createdAt": "2024-05-21T00:21:23Z",
"updatedAt": "2024-05-21T00:21:23Z"
}
]
}
Expand Down

0 comments on commit 1a93f39

Please sign in to comment.