I should have said prioritized for rather than tailored to. 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.

I should have said prioritized for rather than tailored to.

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.