New section on tooling #436
Conversation
frivoal
removed
the
Agenda+
There was a problem hiding this comment.
This is a very good start, thanks for capturing one of our important working principles explicitly. There are a couple of things I'd suggest improving before landing this.
1: s/without cost/without cost, tracking, or other client computation requirements unrelated to the direct use of the tool
Specifically, a "free" tool that uses user-privacy invasive tracking (e.g. but not limited to all 3rd party trackers) should be considered as unacceptable as a tool that requires a paid subscription. Or a tool that uses a Javascript Bitcoin or other crypto/blockchain mining to steal client compute cycles. Or tools that make excuses for it like "please mine these crypto blocks as a anti-bot login measure".
2: We should explicitly list w3.org and all its subdomains as exempt from the geographical access requirement. That is, groups are not required to find tools to route around countries which in any way ban or restrict access to w3.org or any of its subdomains or specific ports on those (sub)domains like for IRC. I would consider expanding to also include github.com and github.io and any of their subdomains because use of those has become so commonplace at W3C that requiring groups to not use them would be too big of a burden at this point.
|
I'm tempted to generalize what Tantek says: that in general we can presume that the world-wide-web is a world-wide-tool, not just w3.org, though it's worth calling w3.org out explicitly. (This is closer to Sam's position, I think). I'm trying, until we get through AB/team, review, to keep the big picture in one place on the Wiki, so I took the liberty of adding Tantek's point to the General section. Feel free to adjust. |
|
one clarification question: Does "must be published on a W3C-controlled domain" exclude and w3c.github.io (and related)? If yes, does it mean that all editor's drafts must be replicated. Since we don't check the content, we'd probably have to isolate them from www.w3.org to avoid same-origin leaks) ? Same question for drafts.csswg.org . cc @vivienlacourba . |
No, because the clause applies to final deliverables only: "All reports, publications, or other deliverables produced by the group for public consumption" not work-in-progress. Also, the phrase is ambiguous; I think the requirement is that they be addressed by w3.org URLs and backed up by the W3C, so that we could, if needed, host them elsewhere (e.g. natively) and retain the addressing, if the selected service goes away or is no longer appropriate for use. Finally, this doesn't appear this way in the wiki, which tries to keep the big picture in one place. This PR is head of the game. |
@plehegar Yes, it excludes w3c.github.io and it would exclude csswg.org unless someone at W3C has edit access to the DNS records such that W3C can take over hosting if the current provider shuts down.
I think that depends on whether the editors' drafts are being used as internal scratch space (equivalent to comments in an issue tracker) or if they are being widely referenced. The Process 2020 changes were intended to help us shift us back to using w3.org/TR for referencing of our specs, by making it possible to keep those documents in sync with the ED sources. But e.g. the TAG and i18n have a number of other documents hosted on github.io and are using those URLs to refer people outside the group to those documents. These would be non-compliant. I know that right now it seems like github.io will never shut down... but I'm sure the OpenType folks at ISO thought Yahoo would keep its groups hosting infrastructure up forever, and they just shut down in January; we had 30 days to rescue the ML archives, and several of them were corrupted. It is irresponsible for us to rely on external services without the ability to handle their demise. |
|
|
About the ban on crypto-mining, tracking, etc, I think it would be good to find a brief and high level way to state it in the Process itself. I feel that details about how that principle would speficically apply to crypto-mining, tracking, embedded advertisements, etc, do belong in a companion/explainer/policy document that's not as formal as the Process, but the abstract principle feels it would belong, as I don't think this is currently implied by any of the things listed in this PR. |
|
I added "must not cause members any direct costs (pay for use, etc.); and should not incur cost, tracking, or other client computation requirements unrelated to the direct use of the tool;" to the Wiki |
|
How does this proposed policy apply to ReCaptcha, which uses people's work to build a particular company's competitive advantage over rivals? |
|
@chaals I'd say something like reCaptcha would not be acceptable on specs and other deliverables, archives, or any kind of output we refer people to. As for whether it is OK on interactive tools we use while working (as opposed to outputs), I'd leave that outside of the bounds of the formal process, to Chairs discretion, possibly advised by a non-binding policy document. (Personal feeling on what that policy should be: it is a tolerable negative, better avoided if all other things are equal, but not that strong a concern). |
|
I recommend offering some guidance around accessibility instead saying must be accessible to people with disabilities. Perhaps instead recommend WCAG AA compliance or something similar. This allows for accessibility for those who might not technically have a disability but who have situational or temporary disabilities (e.g. broken arm, scratched cornea). The phrase "Note: If a new participant joins who cannot use the tool, this can require the Working Group to change its tooling or operate some workaround." puts the burden of shifting to a new tool on a new member who is unlikely to voice their needs. This is not acceptable. |
|
@TzviyaSiegman wrote:
This is a vexed problem I think. I agree that expecting a newcomer to a Group to say "by the way, you use a tool that I cannot use effectively nor learn to use for some reason intrinsic to the tool" is a recipe for having people instead silently decide not to participate. If there were more obviously great tools around, groups could simply choose tools that actually work for people and won't raise issues. But my observation of reality is that the available tools tend to have some advantages for a given set of users at the expense of not working for others. So we cannot expect Working Groups to pick a tool that won't cause problems, because there aren't any. Making clear that Working Group tooling is temporary, chosen as a current answer to competing requirements and constraints, and MUST be reconsidered whenever a new participant joins may bring pushback from existing participants, because it potentially imposes a notable burden on them. I think that the burden imposed is the inevitable price of ensuring a welcoming and inclusive environment for the diverse range of stakeholders whom W3C wants as participants. If this solution, or something like it, is what we decide we want, it might be easier to successfully implement by holding substantial discussions among Working Groups and gaining broad acceptance of the idea before we consider making it something the Process imposes. That discussion is also a burden on Groups. I think asking them to consider what inclusion and diversity requires of them in practice is an imposition that Working Groups are likely to accept reasonably readily. If they don't think about it, and believe the Process is adding "bureaucratic busywork" without a good reason, they are more likely to simply work around or ignore what they consider a barrier to effective work. |
We may need to improve the phrasing, but putting the burden on the new members is not the intent of the text. The point isn't that we expect newcomers to need to ask for accommodations. Groups should pick tools that are newcomer friendly, without needing to be asked. Precisely what it means to pick good tools is a complex trade off between various dimensions of usability and accessibility, and seems more suited to guidelines than mandatory rules. But if someone does ask, then the group must accommodate. Telling someone to go away because "we like it this way, too bad you cannot deal with it" is not acceptable. That's not sufficient for a good tooling policy, but it seems like a minimum requirement that can be elevated to MUST status. |
|
I agree with @frivoal . I don't think we can require groups to anticipate every need, or to avoid every possible pitfall — that's impractical. But I also see agree with @TzviyaSiegman ; imagine we had a participant who has a need that they consider somewhat private (e.g. "I have severe dyslexia and this tool doesn't permit my text-entry assistant to work"); this sentence asks them to break privacy. We can't require all groups to be aware of all tools and the populations that might not be able to use them. This does suggest, however, that maintaining a set of modern, approved, tools, that groups are encouraged to use, makes sense. How can we improve? |
The intro email sent to the new member when joining a Group can encourage the new member to signal to the Chairs/Team if they have any accessibility requirements, and begin an initially private conversation about whether the Group's tools meet their needs. This would put the onus on the Chairs/Team to understand the needs of the participants and to propose changes if needed, without new members feeling that they have to share all their requirements with the whole Group. This review of needs could even be a private WBS poll (or similar) with limited read access to the results, and a really neat thing would be if Chairs and Team have visibility of the results collated across the whole Group. Members should be able to signal (privately, again) changes to their accessibility needs over time. There should also be a way for prospective participants to check in also. There should not be a strong requirement to meet all the needs of all the members in every respect, because it may not be practical to do so. But there should be a commitment to get as close as possible. This does leave room for more improvement though. It still feels not quite right, somehow: W3C members who are not members of a particular WG but who may want to join a meeting for some reason, for time to time, may not have their needs met. For example care would need to be taken in joint WG meetings. |
|
@nigelmegitt yes, I think we need to make it clear that the onus of making sure that the rules are followed is on the team contact and chair. Whether we need to get formal about it, or simply state it and allow it to be quoted when needed, I am not sure. |
| by all active or would-be active group participants | ||
| to allow their effective participation | ||
| regardless of disability | ||
| or geographical location. |
There was a problem hiding this comment.
I think a really hard question here is not so much about geographical location as much as administrative prohibitions of usage, many linked to governmental decisions (loosely bound to geographical locations), but some linked to very different authorities (e.g. organizational ban on certain tools).
I think the rule in the process needs to address that aspect more than geography (which as far as I know is rarely an issue); and the associated separate guidance should probably hints to how far a group needs to adapt the many edge cases that arise when applying the rule.
There was a problem hiding this comment.
I think we mainly care about geographical restrictions. I don't think we can mandate accommodating all of the IT teams of the world (though we can certainly take that into account voluntarily). But I think we should take into consideration the governmental bans, because there's no way practical around that.
There was a problem hiding this comment.
And I think we must not be held hostage to government bans, lest they become a means for a downgrade attack..
I wonder if it would help to have people who have experienced this sort of blocking weighing in directly on these discussions, because I suspect that neither @fantasai nor I experience this routinely. Perhaps those who suffer from the pain would be in the best place to describe the accommodate that would best help them, or define a threshold for us to consider accommodating a proposed downgrade attack.
There was a problem hiding this comment.
Not being held hostage to government bans is a nice idea. But for an organisation that works primarily with organisations who are subject to various local government rules, it makes no sense in practice.
We should pay attention to the concerns of actual people who are unable to use tools because their employer (or similar) will not allow it. The workarounds I have dealt with often involve having to set up a separate machine (which has a direct cost), an alternative email system which works poorly with the general W3C assumption that we can identify who represents what member, and other inconveniences that add up to a notable barrier to participation. For someone who is concerned their issues are likely to be very hard to move forward anyway, this is a pretty significant disincentive to participation.
There was a problem hiding this comment.
I agree with @chaals' first paragraph in the comment above.
As for the situation discussed in the second one, I think this is one where being accomodating is good, but I don't think we want to constrain it with RFC2119 language in the Process. It probably does make for a relevant discussion in /Guide though.
There was a problem hiding this comment.
I agree with Sam for a couple of reasons. First if your tool choice is determined by how authoritarian censors behave then you're at the whim of dictatorial decision making. Second you might be inadvertently trading off better access for some over others. There will be those in places where blocking and filtering uses one tactic (TLS 1.3 blocking, for example), and those in places where blocking and filtering uses another tactic that the same protocol makes the tool resistant to censorship (DNS/domain blocking, respectively in this example).
Suggest thinking of proactive anti-censorship mechanisms that provide blanket privacy, and therefore censorship resistance, to the most people, like tools that provide an onion service, or actually the W3C participating in the Tor network through bridges and relays (if it doesn't already).
There was a problem hiding this comment.
It's phrased as a 'should' so that we (a) can think about and examine hard cases and (b) decide, when appropriate, not to follow it. So there may be cases where we regretfully decide that some members will have problems, but it's the right choice. But that should be a conscious decision; we do not want the case where some members can't access, and no-one cares or has thought about it.
index.bs
Outdated
| All reports, publications, or other deliverables | ||
| produced by the group for public consumption | ||
| (i.e. intended for use or reference outside its own membership) | ||
| <em class=rfc2119>must</em> be published and promoted at a W3C-controlled URL, |
There was a problem hiding this comment.
in general, must statements benefit from being in the active form and applied to an agent - I don't know how systematically the Process Document follows that practice (although from a cursory glance, it does it often); I think it would be preferable to rephrase the MUST in this PR to say who (the group? the team? the chairs?) has what requirements .
There was a problem hiding this comment.
on the specific W3C-controlled URL piece, it would probably be useful to evaluate how this rule would apply to Web Platform Tests (where a non-insignificant amount of W3C groups effort gets invested)
There was a problem hiding this comment.
I agree in general, but it's a mix of the team contact working with the chair, editor(s), and systeam here. We could say that the [team contact | chair] must work with those people to ensure that …
?
There was a problem hiding this comment.
I agree with dsinger, the subject in an active sentence of the same meaning would be too vague to state here. Also, although this is stated in the passive voice, the actor is clearly identified because it is not a stative verb but an active one: the actor is whoever is doing the publishing or promoting. I don't think we need a change here.
(We could say at the end of the list that the W3C Team MUST help our groups adhere to these rules; but I also think it's fine without such a statement.)
There was a problem hiding this comment.
What does "and promoted" mean in this context? (Is it unnecessary verbiage that can be cut?)
There was a problem hiding this comment.
It means that if (as likely will happen) you get a proxy from a W3C URL to github.io, then you satisfy the "published at" (there is a w3c URL); but you must also give out the W3C URL and not the github.io one when you talk about it, at least outside your group.
There was a problem hiding this comment.
"Groups must publish all content intended for public consumption at..."
The key being to know who was responsible if it went wrong, and therefore whom to talk to about fixing it.
There was a problem hiding this comment.
If a group decides to publish something elsewhere, that is an invalid decision because it falls outside the scope of what the group is authorised to do. The Staff contact is responsible for noticing that, the Chair is responsible for ensuring it doesn't happen.
| produced by the group for public consumption | ||
| <em class=rfc2119>must</em> follow best practices for accessibility worldwide | ||
| and for persons with disabilities. | ||
| Network access to w3.org itself may be assumed. |
There was a problem hiding this comment.
the rule above is on "W3C-controlled URL" which is distinct from w3.org (and not just in theory); it may be useful to align the phrasing and the intent.
There was a problem hiding this comment.
I think we were careful here. If a firewall or other device blocks access to w3.org, you can ignore that problem, is what we're saying. but if we re-direct, then you need to consider whether the target is reasonably reachable.
There was a problem hiding this comment.
W3C-controlled (as opposed to w3.org) was intentional. We want to allow other domains, provided systeam has the keys.
There was a problem hiding this comment.
I think the "systeam has the keys" may hide quite a bit of complexity; I know from experience that some of the non w3.org servers don't have the same level of reliability, and I don't think there is much the systeam can do about it, nor is it clear they would know how to replace the said servers should that be needed.
(this may be fixable, and the details of fixing it lies outside of the process; but if we want to endorse that type of approaches, I think there needs to be more operational details as to what they entail)
There was a problem hiding this comment.
Sure, but details like that don't go into the Process. :) The key point is that systeam can take over hosting if it the hosting service goes down permanently.
There was a problem hiding this comment.
Some recent events in IETF where "who owns the infrastructure" (beyond DNS) is having pretty consequential impact
There was a problem hiding this comment.
There was a problem hiding this comment.
The view expressed there seems fine by me. If W3C controls the domain, it doesn't matter who operates the service under that domain, they merely operate it, not own it.
As for the bigger point about assuming network access to $FOO, I actually agree with @dontcallmedom. The rule, as phrased, would imply that if a country blocks both w3.org and W3C-controlled foo-drafts.org, we'd have to move the stuff from foo-drafts.org to w3.org, even though it doesn't make anything better. So let's align the phrasing to “W3C-conrolled URL”.
index.bs
Outdated
| <li> | ||
| All reports, publications, or other deliverables | ||
| produced by the group for public consumption | ||
| <em class=rfc2119>must</em> follow best practices for accessibility worldwide |
There was a problem hiding this comment.
is there a link for what those best practices are?
There was a problem hiding this comment.
WCAG? not sure what the equivalent is for i18n
There was a problem hiding this comment.
I think we should point to /Guide (which should point to WCAG and i18n equivalents) once that section of /Guide exists, and that we can leave this as is in the meanwhile.
Keeping retention of decisions as must. Per AB advice.
2 points on this:
|
|
re editors draft &
Once you have that, it's not clear groups would have any reason to push back |
|
It’s not clear me what actual problems would be solved in practice for the vast majority of our spec editors and for users of our specs by doing what seems to be proposed here — that is, by creating (I guess) some w3.org subdomain that editors are required to use for their current drafts — or, short of being required, something that we try to corral them into using. I recognize there are some people other than the majority of our spec editors and actual users of our specs who’d apparently like to see us make some change here, but I think it’d be a very big mistake to optimize for the needs of those other people. The current https://w3c.github.io/ way for delivering current spec drafts has basically been wildly successful — and is widely (nearly universally, in my experience) appreciated by spec editors, by implementors, by the key stakeholders such as the MDN maintainers, by web developers, and by pretty much everybody using the specs to solve an actual information need. Maybe some people forget that we previously did have almost exactly what seems to be being proposed anew here. It was called https://dev.w3.org/. We maintained it for years at a considerable resource expense — including considerable costs of time for W3C staff (e.g., me) in maintaining it and working around (on our own) all its quirks. It was not fun and was highly suboptimal with respect to meeting the needs of our editors and the actual users of our specs But eventually we had the good sense to dig ourselves out of that, and move to using GiHub and https://w3c.github.io/ — which has been immeasurably better at meeting the needs of our editors and the users of our specs, and significantly reduced the costs we were wasting on having W3C staff maintain something which, after the advent of GitHub, was essentially a (retroactive) re-inventing of the wheel, very poorly. So I hope my lack of enthusiasm about the prospect of getting back into that business is understandable. And along with all that, as @plehegar points out in #436 (comment), editor’s drafts have (thankfully so far) never been a formal part of the W3C Process. And trying to unilaterally make them part of the Process without getting very strong buy-in from all the editors doing the actual editing work — and all the working groups supporting that work — is not going to fly well. And so I can imagine that the next logical place this discussion would necessarily take us is into is some proposal to update the Process document to make editor’s drafts a formal part of the process. And pursuing that would really complete the foundational hole-digging for ourselves that I think what’s being proposed here would end up leading us into. |
|
By the way, if part of what’s implied here is that we’d have a drafts.w3.org (or whatever) domain that mostly just proxied w3c.github.io, there are a lot of reasons why that’s not a good idea. Among those reasons such proxying would be bad are: Consider what happens when some w3c.github.io/foo/ goes 404 (which is not hypothetical — it happened a lot recently when branches were switched over to What would happen when a w3c.github.io URL went 404 is that our drafts.w3.org proxy would probably start showing users a 502 error — in which case, the users are reasonably going to assume something’s broken at the W3C, and start trying to figure how/who to report that to at the W3C. Which means the W3C and the W3C systems team now start having to deal with blame/fixing for problem they can’t actually solve. Users who instead go to that w3c.github.io/foo/ URL directly still get a 404 of course — but that’s gonna be a lot more familiar to them than the arcane W3C 502 would be, and the users are much more likely to have encountered that error before with other projects hosted at GitHub using GitHub pages, and they’re much more likely to be able to figure out that they need to go raise a bug in the github.com/w3c/foo/ repo to report, Hey, your GitHub pages stuff seems to be broken right now. And if the proposal here is to instead do have the drafts.w3.org domain be something more than just a w3c.github.io proxy, then like I said in my previous comment, we would be buying into a much bigger set of problems and permanent costs — that would amount to basically regressing back to the state of things in the bad old dev.w3.org days. |
|
@sideshowbarker I sort-of agree with you, in that I would like to get back to the state where groups maintain their working draft actively, and that that is the official w3.org-URL-addressed resource, and that editor's drafts have only slightly more status than anyone else's forks. The WG accepts changes from forks into their active WD. I think that the changes we're making, to allow WGs to maintain their WD in the WG's repo and have a URL that proxies to that repo from w3.org should remove the barriers to and impediments that mean that groups are bad at maintaining their WD. I note that it's a group decision over how closely they manage their editor and what the editor commits to the group's WD. In the early stages of a project, that can be quite loose, and might only need to tighten up as the project completes. So, rather than spending our energies formalizing EDs, I'd rather spend them on getting WGs back to having a clear concept of the WG's working draft. |
I think this is a misunderstanding of what is being proposed here. Using github.io as your tech stack is fine, and there is no suggestion to move away from it. If it works for you (and it works for almost everybody), great, no need to rehost into something similar to what dev.w3.org was. However, using github.io as your URL is not fine for long lived documents / output of a working group. It's fine for now, but github is a commercial company with no obligation to keep the service available or free of charge. So the request here is that any deliverable of the WG produced for other people's consumption, you may serve it from github.io if you want to, but if so, you need to get w3c to proxy it through some W3C controlled URL (presumably under w3.org), and refer people to that URL. This does not require any body to do anything different from today after an initial set up step for the repo. Sure, that feels like a (tiny) hassle in the short term, because it doesn't make much of a difference to reading the document right now. However, if 5 years down the road, gihub.io discontinues its free service and all our links break, this will be a giant nuisance. Fixing internal links after the fact will be a massive pain. Fixing the links of everybody else in the world will be impossible. Even if we have archives of everything that was published there, we won't be able to restore the content in place unless we control the domain through which it is being accessed. |
Nothing in the text is ED specific, or even mentions them. It's just being generic about documents "produced by the group for public consumption (i.e. intended for use or reference outside its own membership)". If you don't do that with your EDs, then the rule doesn't apply to them. But for outputs of the group that are being "produced by the group for public consumption", the rule matters, regardless of whether it's an **** Draft, an explainer, a finding, a disposition of comments, an Implementation report, an article, a best practice… Cool URLs don't change, and you cannot guarantee that if you let a third party be in charge of your URLs. |
Actually, at this point I’m very clear on what exactly it being proposed here. And I think it’s a bad idea.
I recognize you’re asserting that’s not fine. But, with respect, that doesn’t make it so. It’s not axiomatic.
An editor’s draft is by definition not output of a working group. The current Process document intentionally says nothing about editor’s drafts. I recognize that this proposal wants to make the Process document say something about editor’s drafts — essentially, I guess, to redefine editor’s drafts as “output of a working group”. But that is not what the current Process document actually says. We already have w3.org/TR URLs for all documents that the Process document actually recognizes as output of a working group. And those URLs already provide the persistence being sought for here. What instead seems to be getting proposed here is to to create URLs in some w3.org subdomain for documents that … what? That don’t have w3.org/TR URLs yet because they’re not yet recognized by the Process document as output of a working group? Or at some w3.org subdomain in addition to and redundant with the w3.org/TR URLs?
Editor’s drafts are not deliverables of the WG. Documents published at w3.org/TR URLs are deliverables of the WG — at least per the Process document. An editor’s draft is something that may have content which will eventually be published by the group as meeting its criteria for one of its chartered deliverables — after the working group makes a formal decision to publish it as such. But until then it’s simply an editor’s draft.
In fact it does require multiple parties to do something very different from what they are doing today. The proposal here creates significant new work and new obligations for editors, for working-group chairs, and for W3C staff — both for working-group team contacts and for the W3C systems team.
No, not just tiny, and not just short term. Knowing what I know intimately well from years of handling publication tasks for a variety of working groups, what’s being proposed here feels to me like something that is in practice going to end up being a very big hassle, and a very long-term one. The proposal would in practice create significant work, for all of our editors and chairs and team contacts — and for a long time, because enshrines it into the Process document forever. And it will create all that new work without actually solving any problem that the vast majority of our spec editors and actual users of our specs recognize as a real problem — but instead will be trying to solve a problem that none of them are actually asking us to try to solve.
So to be clear: The problem this proposal is really trying to solve doesn’t actually exist today, nor is it anticipated that the problem will ever be a real problem any time soon — if it ever actually becomes a real problem at all. And that is a big if. It’s by no means certain that the anticipated problem is ever going to actually occur. At least I’ve so far not seen anyone assert that it’s certainly going to happen. And in fact, I think very many or even most people might believe that anticipated problem is very unlikely to actually occur. |
If the intent of the proposal isn’t to have the Process document require it for EDs, then the proposal needs to be updated to explicitly and unambiguously state that — “This requirement does not apply to editor’s drafts”, or something like that. Or otherwise is there a serious assertion being made here that it only applies to EDs if the EDs are “produced by the group for public consumption (i.e. intended for use or reference outside its own membership)” — as if there actually are such EDs? Are we aware of any actual cases of EDs not produced for public consumption and not intended for use or reference outside a group’s own membership? It occurs to me now that the proposal seems for some reason to be intentionally written without explicit reference to EDs, but with the apparent intent that it will in practice be applied to all EDs — since all EDs are in practice “produced for public consumption”. And if that’s the case, then it’s disingenuous to not be explicitly including EDs in the concrete text of the proposed Process document change. If it’s believed that the requirement will in practice actually be placed on EDs, then it seems to me you have an obligation in principle to update the language of the proposal to explicitly mention EDs — so that everybody reading the proposal can clearly understand what the actual effect of the change is going to be in practice. |
|
@sideshowbarker we're trying to deal with a simple problem. At the moment we have documents that purport to be W3C work that are referred to by the WG, and people outside the WG are asked to refer to, using URLs that are not W3C URLs and sometimes (often?) don't even have any mention of the W3C in their name. Since anyone can fork a W3C repo, and keep the W3C logo on the document, this is a strange place to be. So when someone sees a document at .github.io, what are they supposed to understand? That's it's a working fork of someone who wants to make a pull request. Have a look at https://immersive-web.github.io/webxr/ The URL has nothing in it that assures the reader it's published by the W3C or has any status at all, so simply from an address point of view it's unclear. The status section says
and
which are confusing. Working drafts are produced by Working groups; Editor's drafts are produced by Editors. Editor's drafts are not even endorsed by the Working Group. It's fine for a WG to decide to defer the update of the WD to the editor, of course (and catch 'in arrears' when the Editor makes a mistake), but that then is the WG's WD. This is not an isolated example. We need to clean up. If a W3C group is maintaining/developing a document, and they want to give a reference to it to anyone else — inside the W3C, and particularly outside — then we ask that it be a W3C URL that they use. "Our current working draft is at ." "Our editor maintains a forward-looking document that contains matters for the WG to consider, but we don't look for group consensus on the editor's drafts." "We have a requirements document and roadmap at ." Now, I'd also prefer that we separate ED and WD better conceptually, but that's separate. |
No, it does not want to do this.
The intent is that it neither applies to EDs on virtue of them being EDs, nor does it exempt them on virtue of being EDs. It depends on what the working group does with them. If they are the documents that the working group promotes to the general public, that the working group sends for TAG review or horizontal review, or that sort of things, then the working group is treating them as its output, and the rule applies to them. If the WG does all these things using the TR publication, and the ED just happens to be a publicly visible scratch space that the WG does not promote as the version of the work people should look at, then it does not apply. The text doesn't single out EDs. That's not out of a desire to mislead, but to be generic. Things that are published on TR satisfy these criteria automatically. If individual WG participants want to publish whatever wherever, they may do so. But if the WG collectively produces something that it wants the world to look at other than the things it puts on TR, whatever these things are, they need to have stable URLs, which can only be guaranteed if they are w3c controlled. "whatever these things are" would cover EDs to the extent the group itself chooses to treat the ED as the document it promotes, and it would cover things like implementation reports, Disposition of Comments, Explainers, Articles…
Really? Have a look at https://drafts.csswg.org/ All it takes for this large pile of documents to comply with the proposed rule is for the person maintaining that server to give admin access to the DNS records to the w3c team, which I believe has been done already (and if not, is trivially fixable). How does that create "significant work for all our editors and chairs and team contacts — and for a long time"? As for github.io specifically, a minimal but sufficient solution would be to build a form where you can put a github.io/foobar url, which sets up (automatically, except for a Team approval step) a foobar.drafts.w3.org proxy, then we're done. (And all that needs creating is this set up form, we already have the proxy.) How does that create "significant work for all our editors and chairs and team contacts — and for a long time"?
The time to put your seat-belt on is not after the accident has started. github.io, or any other third party service, cannot be depend on to be available and free forever. Once upon a time, it would have seemed outlandish and far fetched to suggest that Yahoo Groups would ever shut down. A great service, offered by a company widely regarded (at the time) as one of the pillars of the web, relied upon my so many. Of course it'll stay up. That's a perfectly reasonable place to do standardization work, say about fonts, under the MPEG group: https://groups.yahoo.com/neo/groups/mpeg-OTspec/info Oops, it's gone. What about Google Code? That's a great service used dependably by many and offered by a very respectable company… Except it's gone too. Well, maybe, but surely github is different, and they wouldn't discontinue popular free services… Just because a service is popular today does not force the service provider to keep providing it forever. For things that are short lived, whatever. For things that are supposed to be referenceable in the long run, it's not fine that |
|
I wonder if instead of focusing on rules for inclusion in the Process 2021, we should focus on the underlying goals we want to achieve and work toward getting these goals implemented (e.g. by the end of 2021). Based on the lessons from trying to achieve these goals, we may then look into encoding what is confirmed as necessary rules. In other words, it feels we lack implementation experience and enforcing rules in these conditions is likely to backfire. Once it's clear the goals we have in mind are correct and implementable, it might be easier to see where rules are necessary to avoid regressing. |
|
@dontcallmedom That's the conversation that we had over the last year, and these rules are intended to be the basic principles indeed. The only one people seem to be struggling with is "use W3C URLs to reference W3C documents that are referenced outside their group". The obvious two reasons for that are (a) we might change the service we use, either generally, or for specific cases; Github might change in a way we don't like, for example; (b) to establish branding, and make clear the difference in status between a W3C document and a fork. These seem pretty uncontroversial to me. |
|
To be clear, I'm not pushing back on the quality of the conversations, and I think the basic principles identified sound reasonable; but before enshrining them in the process (which is hard & slow to change), I think we should learn from adopting these principles and delay putting them in the Process Document until they've been tested in the wide diversity of W3C groups. In terms of adoption too, it feels much better to have groups do their part in building the policy by testing & implementing it, rather than having it mandated suddenly. I guess I'm advocating for an incubation approach here… |
|
@dontcallmedom That's why they're written with SHOULD in almost all cases. Putting them in the Process makes sure that we are absolutely clear about what we're aiming for, and that we're serious about it and expect all groups to make an effort towards conformance. But we have leeway for time to get there and for figuring things out. If the rules need adaptation after experience, then we can adjust them next year: the Process isn't set in stone. Consider the SHOULD as a CR phase: we're done with the design phase, and now we're asking for implementation. As for incubation, we already have groups who are largely in conformance with these requirements. We are past incubation. This is Call for Implementations time. |
|
The Revising W3C Process CG just discussed
The full IRC log of that discussion<fantasai> Topic: Tooling<weiler> q+ <fantasai> github: https://github.com//pull/436 <fantasai> dsinger: I think we're settling on MUSt only for recordkeeping <fantasai> dsinger: We've got continued debate on geographical restricitons <fantasai> dsinger: nobody is on either extreme of the argument <fantasai> dsinger: Somewhere between those two polar opposites is where we need to land, and that's what RFC2119 SHOULD is about <weiler> q? <fantasai> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there <fantasai> may exist valid reasons in particular circumstances to ignore a <fantasai> particular item, but the full implications must be understood and <fantasai> carefully weighed before choosing a different course. <fantasai> florian: If country has citizens has people who want to participate cannot, is a problem <fantasai> dsinger: Does that automatically mean we can't use the tool even if no viable alternative? <fantasai> ... find a workaround for them? <dsinger> q? <fantasai> dsinger: other opinions? <dsinger> ack weil <fantasai> weiler: interesting geographical and political <fantasai> weiler: In the interest of moving the overall section forward, may I suggest we strike geographical bit? <fantasai> weiler: and argue over it for another year? <fantasai> weiler: You don't have consensus over geography text <fantasai> weiler: Would want ppl who are affected involved <dsinger> ack fant <fantasai> florian: we've had such peeople involved <jeff> scribe: <jeff> Fantasai: We need to take geographic restrictions into account when selecting our tooling <jeff> ... people would like that considered <jeff> ... we made it a SHOULD so it could be a consideration <dsinger> q+ <jeff> ... striking this and never putting it back would be unacceptable <jeff> ... can you live with a SHOULD? <jeff> ... people in regions affected would like an effort to include them. <fantasai> weiler: No, I can't live with this. <florian> q+ <fantasai> weiler: I might if some caveats around it, but don't want even with a SHOULD. <jeff> q+ <fantasai> dsinger: [quotes text] <fantasai> "Any tooling used by the group for producing its documentation and deliverables or for official group discussions should be usable without additional cost by all who wish to participate, to allow their effective participation regardless of disability or geographical location." <fantasai> dsinger: We can leave out "regardless of disability or geographical location" <fantasai> dsinger: Sentence would have same impact, just draw less attention to it <dsinger> q? <dsinger> ack ds <fantasai> dsinger: thoughts on that? <dsinger> ack flo <fantasai> florian: I think that approach might work. personally I'm also satisfied with a SHOULD. But to go in Sams' direction, I can imagine additional phrasing that would make a difference <weiler> [also need to take it out in the previous section re: worldwide, but same idea] <fantasai> florian: We could say things like, "however, access to electricity may be assumed" <fantasai> florian: can't require participation by snail mail <dsinger> q? <fantasai> florian: Need to have general means of electronic communications available <dsinger> ack jef <fantasai> dsinger: Might just be able to delete words though <fantasai> jeff: I want to know Sa's reaction to dsinger's proposal <fantasai> weiler: I'm fine with it <fantasai> fantasai: I can live with it <dsinger> q? <wseltzer> +1 <fantasai> dsinger: OK, we'll just stop the sentence early <dsinger> q? <fantasai> florian: I'll just do it <fantasai> weiler: There's multiple places <fantasai> weiler: There's a reference to worldwide in the other section <fantasai> weiler: in item 2 <fantasai> fantasai: I'm OK with dropping from item 2 <fantasai> jeff: can we just say for all? <fantasai> dsinger: Maybe replace "worldwide" with "internationalization" <fantasai> florian: We're just saying "follow best practices", why is this a problem? <fantasai> [debate over where we're editing] <dsinger> q? <fantasai> weiler: Replace with "internationalization" <fantasai> dsinger: OK <dsinger> q? <fantasai> fantasai: I have concerns actually with the earlier edit, I think it makes the sentence unclear, but I suggest we merge in and ask the AB about it <fantasai> RESOLVED: Merge PR with the edits above: end item 4 before "regardless" and switch "accessibility worldwide" to "internationalization and accessibility" |
frivoal
added
Closed: Accepted
Somehow missed a few consensual tweaks to the tooling section when merging it. Adding them back in, with chair's approval. Part of #436
Taking a first stab at solving #435. This is derived from https://www.w3.org/wiki/W3C_Tooling_Policy. It includes the abstract version of the most critical requirements listed there. The intent is that more details about how to do that in practice, as well as the things that are more best practices than strict rules, should be detailed in a (to be written) companion policy document.
Preview | Diff