chore: update links from RICG to WICG

[tomhodgins]

I'm up and running in bikeshed, and updated the document ownership and Github links from RICG -> WICG

---

Preview | Diff

[tomhodgins]

^ What's the best way for me to bring this PR into our repository?

[marcoscaceres]

What's the best way for me to bring this PR into our repository?

Not entirely clear what you are asking here? could you please clarify which repository you mean?

[tomhodgins]

I've just updated this with your changes, glad to see Github knew I was intending it for this PR.

What I meant was process-wise, should I be the one requesting and merging PR's like this? Should every change be done via PR, or is it okay to update this repository directly?

And technology-wise, which of these options is best for what we're doing here:

[marcoscaceres]

What I meant was process-wise, should I be the one requesting and merging PR's like this? Should every change be done via PR, or is it okay to update this repository directly?

No, always ask for review. I know these are simple changes, but you should never merge your own stuff.

I'll set up github to enforce that.

And technology-wise, which of these options is best for what we're doing here:

Once you have a at least one review tick (✅), always, "squash merge" unless there are multiple commits we want to keep. It's generally a good idea to prefix commits with, for example, "chore:", similar to the Angular ones: https://gist.github.com/stephenparish/9941e89d80e2bc58a153

The labels I generally use:

• chore: broken links, etc.
• fix: real bug fix
• editorial: spelling, grammar

And generally don't use a label for normative changes.... though we could use "normative: added x and y"

[marcoscaceres]

Ok, I've set up some enforcement. I've removed the merge option, and now require review.

@tomhodgins, see my feedback. You may opt to reject my suggestions (we can do them later), which is ok.

[marcoscaceres]

@tomhodgins, All, Pro Tip: if you have write access to this repo, it's best to make branches directly in the repo, instead of working from a fork of the repo... that allows other Editors to easily make changes on top of yours. That's sometimes helps move things along faster, as other Editors can then fix nits, without needing to ask the person making the PR to do it.

[tomhodgins]

Thanks, I'm new to this workflow for PRs :D I appreciate the tips

[marcoscaceres]

No problem - this is a great start. Thanks for enduring all my nit picking :)

[marcoscaceres]

@tomhodgins, from yesterday's meeting, @hereinthehive agreed to help edit, right? If so, let's add him now.

[marcoscaceres]

@beep or @eeeps, if the above is correct, could you please grant @hereinthehive "write" access to the repo.

@hereinthehive can you kindly review this so we can merge.

[tomhodgins]

Yes, I didn't want to speak for him in Slack but by all indications he's desiring to help us edit! :D

[beep]

(@hereinthehive now has write access.)

[hereinthehive]

@marcoscaceres @beep Just to confirm workflow...who should be responsible for merges: @tomhodgins and I or @eeeps & @beep?

[beep]

@hereinthehive Great question. I believe primary responsibility for merges falls on you and @tomhodgins, but @eeeps and I can step in if need be.

(@marcoscaceres can confirm later if I naffed that up.)