Coordinated workflows between spec changes and doc updates

[dontcallmedom]

It would be great to set up workflows whereby a developer-impacting change in a spec would flag the need to update the corresponding MDN article(s).

Ideas to accomplish this include:

• have a tracker somewhere (github? bugzilla? google spreadsheet?) where these requests can be collected (ideally, semi-automatically)
• have tools that can automatically detect some of the developer-impacting change in a spec (e.g. when the WebIDL fragments change?)

A possible inspiration for such a workflow is the one set up whereby some groups have committed to always file issues or pull requests on the relevant test suite whenever a change is made in a spec, known as "Test as you commit".

[chrisdavidmills]

We have already had a similar discussion over at WHATWG about doing something similar:

https://github.com/whatwg/meta/issues/62

I think monitoring a specific label on certain issues/PRs in some way works quite well. We could pull them into a spreadsheet, or just manually look at a list periodically.

[domfarolino]

have tools that can automatically detect some of the developer-impacting change in a spec (e.g. when the WebIDL fragments change?)

I'd say this probably isn't too feasible, as it is tough to determine, even without an IDL change, what shifting of things around results in an editorial or normative change.

I agree with the monitoring of labels, I'll go ahead and submit a PR to the whatwg/meta thread that @chrisdavidmills linked to, so WHATWG can get an official label for MDN to track in the mix.

[chrisdavidmills]

@domfarolino nice, thanks.

[chrisdavidmills]

This is working fairly well on the WHATWG side; repeating on the W3C side would perhaps be a little repetitious?

[chrisdavidmills]

^ I take back this last comment. This would be good to replicate over at W3C.

[jpmedley]

I would like to volunteer for this one as well.