-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Intro: State some high-level goals related to WGs and their specs #894
Conversation
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
@sideshowbarker Can you file an issue explaining what this PR is solving? We've gotten a lot of pushback that the Process document is too long, so it would help to know what's the trade-off for adding / not adding this text here in particular (rather than, e.g. in /Guide or on the w3.org marketing pages). |
No, with respect, I think raising an issue in addition to this PR is unnecessary, andb sold just split the discussion. The context and rationale for the PR seem to me to be relatively well stated in the PR description. |
I agree. It is reasonable to list the PR for discussion. In any event, I think the contentious part of this is the first one: There is clearly value to many people in publishing things at W3C (even a CG) without having to get the full endorsement of W3C given to a Recommendation. That value comes from the strength of the things W3C endorses (on average - we don't always get it right). It is likely that making it easier to collect that value, without a corresponding insistence on the obligations that are placed on W3C-endorsed Recommendations, will be most attractive for work that doesn't meet the same high standards, and therefore dilutes that value over time. I am very sympathetic to the general desire to make it easier to do work - but it should not be "too eaasy". For example publishing a Rec involves getting through horizontal review, if not by actually fixing problems identified at least having them publicly identified and described. If we make it easier to put something up with W3C's name, but never have to go through Horizontal Review, we end up diluting one of our core value propositions. So while I recognise that people want this ability, and it is something we can offer in the short term to bring work in, I think it is a strategic mistake to take that on as a goal without careful thinking about the quid pro quo to ensure it doesn't end up damaging the brand itself. |
With regards to @fantasai, I think the key point isn't so much opening a separate issue, but (re)starting with a problem statement. I understand what the proposed text says, and I understand the context / discussions which Mike had that result in these descriptions. But what are we trying to achieve by writing this down? What problem is meant to be addressed by adding this text (and by adding it here)? |
My question about this PR is why it belongs in the Process document. It's all useful information, but why do I need to know it when I'm figuring out how to move to CR or how an election works? |
I’ve had recent discussions with a handful of different chairs and editors and some other Working Group key members, to try to identify what specific things they want to get from the W3C — in other words, their reasons for choosing to do their work at the W3C, rather than somewhere else.
So the three high-level goals that this patch adds to the Introduction section represent the three key reasons that those people have actually expressed to me for choosing the W3C as the home for their work.
The “Enable Working Groups to publish their Technical Reports (that is, their specifications and guidelines) on the W3C’s Technical Reports page” goal may seem like something obvious that’s not necessary to state — but it is in fact the main reason that some people have told me they’ve chosen the W3C.
Specifically, some have said — for better or worse — that they don’t care about the getting the RF licensing commitments, and they don’t care about getting the endorsement of the W3C and the Membership for their specs.
Those people seem to see having a spec published with a W3C URL as a carrying more authority than a spec published elsewhere — greater market recognition (or however would be a good way to word it).
But some other people have said they (and their companies, and their companies’ lawyers…) do place very great value on getting the RF licensing commitments at the W3C. (And incidentally, some have said they believe the RF licensing commitments and disclosure obligations that can be secured at the W3C are much stronger than any that they might get by publishing their specs elsewhere).
Anyway, I hope all that helps to clarify the context for this PR.
Preview | Diff