JSON API Weekly Meeting - June 22nd, 2015

#1

Determine how we want to share weekly meeting notes on jsonapi.org.

  • Posted in a thread on discuss.jsonapi.org
  • Meeting notes should be posted via the twitter account (need access to that)

Determine how we announce discuss.jsonapi.org

  • Do a PR for a CONTRIBUTING.md file, that contains details about what communication channels should be used.
  • Remove Google Group link too in PR — ping steve first to see what the history is there
  • Add to About page under channels

Determine how we want to handle support requests

Determine critical features for 1.1.

  • Embedding / creating multiple related resources in a single request
    • Create an issue that outlines every use-case we are trying to support (with a range of desirability for the feature to be supported)
    • Close all other issues related to this with a reference to the aforementioned issue.
  • Extension support

Determine critical features for 1.2

  • Extension registry (for promotion/extension discovery)
  • More robust hypermedia support

Determine which meetings will be open to the public.

  • The last Friday of each month–August 28th will be the first.

Determine what release schedule we want to use (and consequently, a release date for 1.1)

  • We will maintain a beta branch and push all accepted changes at the end of each quarter.
  • 1.1 release day is September 30th

Review normative statement template system.

  • Ethan suggests using html to mark up the format.md file so we can extract the normative statements, this would eliminate contributors having to edit the normative statements file. Tyler will attempt this.
#2

Upon reflection, I think we need to tweak our release schedule to allow for a beta period in which the spec is pretty stable. This will allow implementations to really try the beta features and ideally provide enough time to incorporate feedback.

So, let’s say that 1.1 beta is prepared in the 3rd quarter and released on September 30. We could allow another quarter for implementations to catch up and release 1.1 final on December 31. 1.2 beta could be developed during the fourth quarter and also released on December 31.

I’m not sure if quarters are the right time periods here, but I have a feeling that our feature list for 1.1 will probably take that long to develop, and it seems fair to allow that much time for implementations to catch up.

#3

:+1: from me. This sounds like a great plan. Quarters feel like a reasonable starting point to me. I’m curious, are you thinking of wanting a faster or slower cycle?

#4

Yeah, I was thinking quarters at least as well. I would prefer a longer time, generally speaking.

#5

I agree with you and Steve that quarters are a reasonable starting point. And if we’re going to take a quarter to fine tune each beta, I think it’s only fair to give implementors the same amount of time to adopt it.

#6

I agree with all of the above (though I haven’t thought about this in too much detail, because I think that at the end of the day we’ll have to play it somewhat by ear regardless).