Add in a contributors document outlining the repo's process.

[Julian]

trafficstars

This document is undoubtedly incomplete and can be iterated on.

It represents, to the best of my knowledge, the existing process I have followed myself since the repository's inception, with only minor tweaks (back then lots of GitHub UI features didn't even exist!).

Of course over the years it may not have been followed by everyone, nor even possibly by myself, but putting it here should hopefully make it clearer to everyone what the baseline is, in case we wish to make changes.

There are some differences here from processes followed in other JSON Schema org repos -- whether this is an issue or not is of course constructively debatable.

[Julian]

Thanks. This document was meant to be more about process than a test style guide (which is #439) -- though I did start to get into some of that topic by adding the test modification section it seems, so happy to try to address some of those here.

[handrews]

I'm concerned about the various bits that allow merging or directly committing to main outside of the GitHub UI. It's important for the community to have visibility, and we get that through GitHub notifications. For example, I'm fine with merging trivial fixes more-or-less immediately (we do that on the web site repo, and in rare cases even on the spec repo if a trivial fix is blocking something bigger). But if someone does take too expansive of a view of "trivial", we'll never know without the GitHub notifications. Most people don't continuously pull a local copy and scan the commit log for commits that didn't go through GitHub PRs.

Also, merging a PR outside of GitHub leaves GitHub in a very confusing state as I discovered when asked to look at such a PR a while back. I could not figure out what had gone on at al and had to ask to have it explained. And I'm not exactly a git or GitHub novice. This would be even more confusing for a less experienced person watching the repo, who might be less comfortable asking.

I don't think it's a huge burden to do things through the GitHub UI, and it adds a lot of community value.

[Julian]

The request was to document the current process. We can certainly discuss changes to it but what I've written down is what's been done until now. GitHub notifications are a way, and maybe one that works well for you personally, but not the only one -- as I say though, we can discuss changes certainly.

[Julian]

@karenetheridge added those, thanks. Have another look.

[Julian]

Thanks all -- going to merge, but will mention again step 1 was to just write this down, so certainly now if anyone feels strongly about changing things feel free to bring it up in a discussion or issue or whatever.

[Julian]

Oh -- in exchange I'll also ask that if something comes up in a PR that seems like it belongs in here (because we forgot to add it, say) please make that note on said future PR when it happens!