The Confluence Metrics graphs are quite interesting! It would be great if the "Grace Period" could be better defined, in particular, how do you qualify the start of a grace period?
Is it when the defining standard reaches a certain level of document maturity? E.g. W3C Recommmendation or at least Candidate Recommendation?
Or given the qualification "can reasonably assume are still a part of the web platform", is it based on there existing some number of Web Platform Tests for the API, and 2+ browsers passing them (in the same way)?
Either way it would be great to have a (at least somewhat) measurable / objective criteria, especially since the graphs make it look like the data is quite precise.
I agree with your stated goal and scope of "make the process doc easier to understand for all W3C stakeholders". The current content certainly helps with that goal, and I am hoping that re-ordering the content as I am suggesting would help even more.
I stand by the title suggestion: W3C Process Document for Busy People should start with how to make specs
I believe this will serve all W3C stakeholders as you described, and here is why (additional thinking compared to initial issue description).
(I wrote a version of this shortly after this morning’s meeting in IRC, and will repeat here to help move this forward.)
The very name of "Process Doc for Busy People" implies that *time* (or lack of it - being busy) is the prime priority (saving time in particular) and design center of the document.
Thus beyond *who* it is for, if we recognize that some things in the process happen far more often (and thus require referring to the process more frequently) than others, we can take that prime priority of saving time, and implement it by ordering process section by frequency of use, thus saving more people more time more often, since they will take less time to find their more frequent uses.
E.g. iterating on specs happens more often than AC votes on transitioning specs happens more often than AC votes on WG (re)charters happens more often than votes on TAG/AB elections, happens more often than host agreement(s) being iterated, happens more often than change of Director. (illustrative, not exhaustive list)
This is roughly similar to (though not the same as) the order I initially listed, yet this updated thinking is based on more objective criteria.
Thank you for the invitation to raise a PR.
If this line of thinking (ordering sections by frequency of use, most to least) sounds appealing, I can work on a new explicit section list order accordingly, and presuming that has consensus, can work on a pull request for it, all while maintaining the narrative style so the whole document still flows well.
Goal: Process Document for Busy People should be tailored to key busy people: technical editors and contributors. They most often need to know how to make progress on a spec. This doc should start there and describe how everything else is in service of it.
tl;dr start with the actual work product of the W3C, specifications, then go meta one step at a time, section by section. Rough outline:
Making specs to improve the web is why we are here (how are they made? and updated? flow charts)
WGs are in service of making specs within a particular area (Charter scope) that are ready (incubation - link Rec Track Readiness)
The TAG is in service of making sure specs make sense across WGs.
IGs/CGs are in service of incubating proposals towards specs, either to hand-off when ready to an existing WG, or to motivate a new WG. Members can also submit things in service of incubating proposals.
Anyone can help start a CG, the W3C Team drives creating IGs, WGs
The AC is in service of prioritizing (voting) which WGs and IGs should be created or continue to exist and worth spending W3C resources on. Also voting for the TAG.
The AB is in service of the making/updating the process of all the above as efficient and consensus based as possible. The AB is also elected by the AC.
Appendix: Other random FYI W3C stuff that doesn't directly impact how specs are made, or the groups that support that: e.g. Communications, Workshops, Liasons.
Ran #Yasso fast yesterday at #track #Tuesday that I started to glow apparently, group photo 📷 @butteronadonut. Shout out #accountabilibuddy@micheleperras. #NPSF #Kezar #runners #novemberproject #tracktuesday #runner #nofilter
Workout: 6-8x(800 Yasso, 400 rest as long as the 800) I did: WU 400, 5x(800 Yasso, 400 rest + stretches), 400, abs, CD
Ran just a little under my usual pace, but at 44°F! Happy with 4:42 4:30 4:12 4:17 4:07 800s and still being able to breathe (without a buff) at that temperature. At least it wasn’t raining or windy.
↪ In reply to tantek.com’s postThere is also the counterpart: 'untag-of' posts (https://indieweb.org/untag) which are more of a brainstorm at this point, but I figured worth pointing out as a future enhancement, in case that helps generalize the code for 'tag-of' support.
Problem: currently you have to use Github’s web UI to remove a label from an issue.
If you could post an 'untag-of' response to a GitHub issue, and Bridgy Publish recognized that, it could call the GitHub API to (attempt to) remove the respective label from that issue.
The current brainstormed markup is similar to that for a 'tag-of' post, but with class name 'untag-of' instead.
I realize it would be even more helpful to have a real-live tag-of post permalink to refer to (preferably to a GitHub issue), so I will work on that next. I’m hoping this is enough to at least get started though.
It would be great if Bridgy Publish could 1. recognize that tag-of post to a GitHub issue, 2. add the respective label to the issue.
Beautiful weather at #RnRSanFrancisco, much nicer than Monday’s #BostonMarathon. I haven’t seen weather like what they had since the Kaiser SF Half Marathon of 2014, my first half^1.
Also this was probably the second happiest I have been near mile 12 of a half marathon (happiest was I think during the Mt. Tam Trail Half last November^2). Slower than expected^3, yet maybe happier was the right trade-off, having not really trained for this particular road/distance race (been training for longer distances on trails).
Note that the preceding paragraph also has visible plaintext markup - "data" tag, escaped in the original: tantek.com/2018/107/b1 thus it should also be escaped and displayed in the copy of this issue on GitHub.
HTML2text should (maybe?) handle this, or if not, Bridgy Publish could escape any visible '<' (less than), '>' (greater than), and '&' (ampersand) characters from the source before publishing to GitHub.
For absolute URL values, the parser should just pass the value through, no processing or validation required.
For relative URL values, presumably "document's language's rules for resolving relative URLs" already handles making sure the base URL is valid.
Thus resolving a relative URL value could at most require URL escaping, which we could consider adding. However I’d rather first see an actual example markup that demonstrates how you could pass an "invalid [relative] URL" to the mf2 parser before adding another processing requirement (URL escaping) to the spec. Otherwise I'd prefer to close this issue with no changes needed.