Tooling Requirements

[fantasai]

Tooling across WGs is fragmenting severely, and is sometimes resulting in inaccessible WG operations. We should include in our Process some of the core requirements, e.g. archived for posterity, accessible to participants with disabilities and in different countries, documented so that newcomers and observers can find discussions, etc. (And put in a separate policy document details / best practices / Team support status / etc. that can be maintained by the systeam to reflect the current state of the world.)

Some initial thoughts on this topic have been drafted into https://www.w3.org/wiki/W3C_Tooling_Policy https://www.w3.org/wiki/Tooling_Considerations https://lists.w3.org/Archives/Member/w3c-ac-forum/2020AprJun/0137.html and https://github.com/w3c/AB-memberonly/issues/30

[fantasai]

Agenda+ against the PR #436

[samuelweiler]

accessible to participants with disabilities and in different countries

I'm fine with requiring accessibility for disabilities.

I don't want to see our groups' tooling choices held hostage by any nation's censorship choices. Censorship violates the "web-for-all" principle cited in the draft statement in the wiki. Even when it's just a single tool being blocked, we should not let censorship keep groups from using the best tools for the job.

Unfortunately, it's not a single tool being blocked. This weekend we saw reports of China blocking all traffic using certain recommended security mechanisms (namely TLS 1.3 with ESNI).

I'm tempted to suggest we should not complicate process with this at all. The Process is already too complicated. But if we're going to do it, this should not be a piece of the whole.

[fantasai]

I don't want to see our groups' tooling choices held hostage by any nation's censorship choices.

I don't want to see participants excluded because of what country they live in.

Censorship violates the "web-for-all" principle cited in the draft statement in the wiki.

The Web can't be for "all" if we exclude the participation of entire populations based on their residency. Being inclusive to all participants is more important than being convenient to all participants. A tool simply cannot be the best tool for a Working Group to do its job if some of its members are unable to use it and are thereby excluded from participation.

[dwsinger]

I see both sides (at least two sides) of this. I don't want to see the W3C hamstrung by having to avoid tool X because it's inaccessible in a country Q, tool Y because it's banned by some employers (e.g. Zoom), and so on. But nor do I want to see chairs deciding to use a tool and saying they don't care that some members or prospective members become second-class members of their group.

I think there comes a point where a tool shouldn't be used if there are 'enough' members who can't use it, and for something critical to the group's operation, 'enough' might be 1 or even 0 (i.e. no-one now, but if we were to adopt the tool, people from P would not be able to participate in the group's decisions or products at all).

It would be imprudent to allow employers or governments to take tools off the table completely. But it would be rude and contrary to our principles to use tools without assessing whether the tool puts some of our users into second-class status, and whether they are equally acceptable alternatives that don't.

[xfq]

the tool must meet basic internationalization requirements;

This requirement looks good to me, but I'm afraid many tools we use now do not satisfy this requirement. For example, GitHub has a lot of i18n issues. I often read non-English Markdown files on GitHub, but since the pages are in lang=en, the glyphs are often not the correct ones. (There're other issues as well, but I won't list them all here.)

[fantasai]

@dwsinger I make a distinction between countries and employers. It's possible to use a different computer to access an employer-blocked tool. And if the employer wants, it can change those policies so that its W3C reps can do their jobs. But if a tool is blocked by an entire country, there's no workaround except leaving the country, which is not reasonable for us to require. And it affects the entire population of that country, which is not a reasonable population to block.

[fantasai]

@dwsinger I also want to point out that the PR as drafted (and this is why I wanted precise wording to discuss here), distinguishes between active or wanting-to-be-active participants and people in general. E.g. a WG that has nobody participating from China can use tools blocked in China for its internal operations (so long as it meets the other requirements about making its output and discussion records broadly accessible), but only until someone from China asks to join at which point it must make some accommodation or switch tools.

[dwsinger]

The distinction is relevant and reasonable, but I think it's a question of degree. Even small amounts of country-blocking is problematic, whereas we can't change tools because of one or two employers. But if large numbers of employers forbid use of a tool, such that it would be a major impact to the group, and then again we should try to find an alternative.

[fantasai]

But if large numbers of employers forbid use of a tool, such that it would be a major impact to the group, and then again we should try to find an alternative.

I don't think we need to write that into the Process, though. WGs will swing away from such tools for practical reasons, and it's a judgement call whose guidelines go into the policy document IMHO, not here. This issue is about Process-level requirements only.

[dwsinger]

we need a holistic picture of what's in the process and what's in guiding material.

[samuelweiler]

I don't want to see our groups' tooling choices held hostage by any nation's censorship choices.

I don't want to see participants excluded because of what country they live in.

And I don't want to see a country succeed in making a massive downgrade attack. When we were talking about one tool being blocked here or there, it might have been a different story. When we're seeing blocking of key pieces of the security stack, used (or that we hope will be used) by most sites, a requirement to bend that that blocking is unreasonable.

We might be able to find some common ground by offering groups non-binding guidance, ideally that guides them to particular tools with properties that we like (e.g. good accessibility) and calls out problematic tools.

(Fantasai, I mistakingly edited your post above rather than replying to it. I think I fixed that.)

[frivoal]

It's not realistic to think any country will ban a tool or a piece of the stack for the specific purpose of pushing W3C discussions to a different forum. If that was a risk, we might want to push back against such things to avoid being bullied, but that's clearly not the situation we're facing. What w3c says in its recommendations has a fair chance of impacting the overall trajectory of the platform, and we should not easily bow to undue pressure there. But when it comes to the tools we use to conduct our own discussions, that will not have any impact on any country's policies, and we should be pragmatic and inclusive.

If some participants or would be participants are excluded from the discussion due to our choice of tools, we need to make an effort to allow them to participate. Even when the reason why they cannot use those tools is something we find regrettable.

[frivoal]

But if large numbers of employers forbid use of a tool, such that it would be a major impact to the group, and then again we should try to find an alternative.

When many/most people find a tool to be impractical, they won't chose it, and there's no need for rules to guard against that.

The situation that's interesting is what to do when many/most find a tool to be desirable and usable, but a small minority cannot use it. Do we favor convenience/comfort of the majority, or inclusion? I'm pretty strongly convinced we should go for the latter.

I guess there is an intermediate situation, where a sizable minority finds the majority's tool of choice to be possible to use, but inconvenient. If they were a majority, they'd switch without needing any rule. If they were unable to use it, the rule I am in favor of would force the group to change. But if it's just a preference, then what? It depends on many factors (how much of a convenience is this for those who like it? how much of an inconvenience is it for those who dislike it? Is it a matter of individual circumstances, or does it disproportionately affect an already under-represented group…) I think this is not a situation that calls for rules, and that this is a matter of good chairing and nuanced judgement. Guidelines and examples might help, but I think rules would be impractical and excessive.

[dwsinger]

@frivoal re:

When many/most people find a tool to be impractical, they won't chose it, and there's no need for rules to guard against that.

The person making the choice is often the chair; the people finding it impractical are the group members. I have had chairs that say "I like X and it serves the purpose and I have decided we're using it" and don't even bother to think about whether members have problems with it.

I'm not sure that this needs to be a 'rule' in the process, but it does need saying somewhere (e.g. in the guidance): yes, you really should pay attention to whether group members can actually access and use the tool.

[wseltzer]

I suggest we avoid absolutes: tooling choices, like others, involve tradeoffs. Groups aware of the general guidance should be able to seek/make exceptions and report on their reasoning and experience. Too many MUSTS may constrain us from using tools that would serve our overall purposes better.

Also added in Notes to wiki, https://www.w3.org/wiki/W3C_Tooling_Policy#Notes_for_discussion_.2F_incorporation_in_policy

[dwsinger]

I agree we need to minimize "must"s but I don't think we should avoid them entirely. it would be bad to lose a chunk of history because a group used a tool that vanished and we didn't have a backup, for example.

[samuelweiler]

I would rather see this sort of guidance in the Guide. Here's an issue that starts to touch on it...

[fantasai]

@samuelweiler That issue is way too specific for the Process, and I agree that kind of guidance belongs in the Guide as guidance. But nobody is proposing to include that level of detail here.

[samuelweiler]

In August I wrote:

I don't want to see our groups' tooling choices held hostage by any nation's censorship choices. Censorship violates the "web-for-all" principle cited in the draft statement in the wiki. Even when it's just a single tool being blocked, we should not let censorship keep groups from using the best tools for the job.

Unfortunately, it's not a single tool being blocked. This weekend we saw reports of China blocking all traffic using certain recommended security mechanisms (namely TLS 1.3 with ESNI).

I'm tempted to suggest we should not complicate process with this at all. The Process is already too complicated. But if we're going to do it, this should not be a piece of the whole.

It's not just China. Russia wants a piece of the TLS-blocking game, too.

[jeffjaffe]

Looking at https://www.w3.org/wiki/W3C_Tooling_Policy and https://github.com/w3c/w3process/pull/436/files I find myself, personally, in strong support of the proposed tooling policy, but concerned about implementation. Will individual groups who have not been involved in these discussions provide strong pushback? Will it take too long to move into compliance - causing a group to be instantly out of compliance with a Process Document MUST?

I propose that for Process 2021 we make all of the MUST's into SHOULD's with the expressed declaration that we intend to change the SHOULD's into MUST's for Process 2022. That will give groups a full year to move into compliance. It will also give time for all groups to absorb the new requirements, determine if they have major issues with the new requirements, and engage with our process efforts before this becomes a MUST in Process 2022.

[fantasai]

I support @jeffjaffe’s suggestion! That seems like a good idea. :)

[nigelmegitt]

@jeffjaffe to be clear, are you proposing that all of the list items under the Tooling heading become SHOULDs? Perhaps it is worth keeping some of them as MUSTs and making others SHOULDs. In particular, I think the first, third and fifth ones are better kept as a MUST.

I agree that all of them do need to be MUSTs at some point, the sooner the better, but I think we have a Very Bad problem immediately if the following are not already the case (paraphrasing):

• public reports, publications etc are published at a W3C URL and backed up by W3C;
• meeting minutes and records of decisions archived by W3C;
• tools and records are documented to allow members to find them easily.

The 2nd and 4th bullets, about accessibility, reachability and cost/usability are important, but I imagine that in some cases a significant amount of work would have to be done to meet them, and agree that adequate time needs to be allowed.

[dwsinger]

I would much prefer introducing the rules we need, and being respectful and reasonably patient about getting groups on board.

[fantasai]

@nigelmegitt I agree that these are critical, but there are a lot of groups that are not currently conforming. It's going to take time to bring everyone in line. Yes, it's a Very Bad problem; that is why we have this issue open. But not one we can fix instantaneously, as Jeff points out.

@dwsinger I think having clear guidance on what's expected is going to help get groups on board. I support Jeff's suggestion to make these all normatively RECOMMENDED practices in the Process while we bring everyone on board.

[dwsinger]

I see no formal difference between saying what we mean ("must") and being considerate and patient about getting people into line, and saying "should" for a while and then "must". But there's a big psychological difference; in teh former, everyone knows that that they are striving to meet a rule, and in the second, it's "only" a should. I simply don't see the point in misleading about our intent.

[jeffjaffe]

If we say "must" but are considerate and patient, there is not a bright line which forces people to comply, they can delay interminably. If we say "should", but signal that it is becoming a must - then once we are ready to call it a "must", we can be more rigorous about insisting on compliance.

Saying "should" with an expressed declaration that we are moving to "must" in the next round (as I proposed above) does not mislead about our intent. Quite the contrary, it expresses exactly what our intent is.

[dwsinger]

But we can as easily write "must" and convey that we intend to make sure that groups are in line within a year.

[wseltzer]

A reason I favor the strong SHOULD over MUST is thinking through the enforcement consequences.

Anyone can use Process faults as grounds for Formal Objection. With a long and potentially challenging tooling transition, we're likely to see many inadvertent and good-faith Process faults. Even though the Director has discretion to override Formal Objections, and could say that blocking publication or stopping a WG was a disproportionate response to that fault, it still seems problematic.

[dontcallmedom]

I think part of the MUST/SHOULD considerations relates to my comment on the pull request itself that an RFC keyword is much easier to understand when applied to an agent rather than a state: who is it that MUST/SHOULD do something (rather than what MUST/SHOULD be); it also helps identify what the recourse path might be.

[nigelmegitt]

@fantasai wrote:

Yes, it's a Very Bad problem; that is why we have this issue open. But not one we can fix instantaneously, as Jeff points out.

Seems to me that the decision here comes down to how bad a problem it is, independently for each item on the list, and whether the consequence of imposing a change with no notice outweighs the risk of allowing the problem to persist any longer. And that assessment is something that very likely needs understanding from a legal perspective (happy to see @wseltzer is here) and possibly a CEO-level call (obviously this proposal to make the MUSTs into SHOULDs has been made by @jeffjaffe so he has already made that call!). It possibly isn't a committee-type decision. And it possibly does have an impact on transitioning to a legal entity, since the ownership and liability relating to risk may change, I guess: I Am Not A Lawyer!

Another degree of freedom here is to consider "when does it need to be fixed by?" Perhaps a year or so is too long for the problem to persist: it would be possible to state a grace period from the date of publication of the next Process document, after which the SHOULD becomes a MUST, rather than depending on the next + 1 Process document, whose publication timeline is rather less predictable.

[dwsinger]

The problem with a should is that it's a "unless you have good reason". And I think that groups would claim that their reason is "good enough". I would urge a read of RFC6919, which, while humorous, is one of the more pointed of the April 1st RFCs. Even if we had a formal objection, I would expect that the mitigation would be that the group has to work with teh systeam to get into line in some defined interval. I doubt that the Director or anyone would force a group to stop makign decisions, or stop making WD revisions, until their tooling is in line. And even then, it would be hard to get the group to e.g. send a copy of their minutes to w3-archive, or reflect their Git repo into the W3C space.

[mallory]

The distinction is relevant and reasonable, but I think it's a question of degree. Even small amounts of country-blocking is problematic, whereas we can't change tools because of one or two employers. But if large numbers of employers forbid use of a tool, such that it would be a major impact to the group, and then again we should try to find an alternative.

Agree that there is some threshold, and it will be important to define it well. It's not simply about scale, and scale /of what/ matters, too. All TLS 1.3 traffic is in one dimension a very large scale even if only 2 countries filter it out. This is not to mention the scale of population affected by it, though only a subset would be W3C contributors. A threshold might also consider duration, as some blocking or inaccessibility could be temporary (YouTube has been famously blocked more than once in various places, for example).

Lastly I will just add that the mere act of choosing a tool for W3C international standards setting work raises the bar for censoring that tool. The presence of W3C's work makes a tool, in general, more resilient overall because economic and national interests, in China and elsewhere, are tied to global tech industry players participating in global standards.

[cwilso]

I have to admit, I was unaware of the TLS issue previously. I am concerned about making the statement as strong on geography as we have, due to the vagaries of governments choosing to disable network security. I am sad to say, this seems to flip me into SHOULD territory.

[dwsinger]

I think we are heading towards an agreement on 'should' for everything except possibly 'addressed by a W3C URL'

[samuelweiler]

I think we are heading towards an agreement on 'should' for everything except possibly 'addressed by a W3C URL'

Particularly given @dswinger's and @jeffjaffe's words above about pushing these 'shoulds' towards 'musts' in the future, I am not in agreement re: having even a SHOULD for the two geography items, and it sounds like I'm not alone.

Censors who are bold enough to block core pieces of our security stack know that they will cause pain. They go into that blocking decision with their eyes wide open. Indeed, our tooling choices are unlikely to influence such a bold censor.

I am not seeking to influence the censors. I am, however, seeking to limit the censors' influence. I am seeking to avoid them effecting - and us capitulating to - a worldwide downgrade attack, which may even have a side effect of others being cut off.

It is possible that someone could craft some qualifier text that would satisfy me. Absent that, I would like the geography references removed from both relevant line items.

[dwsinger]

I think that if we write 'should' we should mean 'should'. I am strongly opposed to writing something and meaning something else.

And in this case, should is exactly what we do mean. "Adopt tools that the general membership can use, unless you have good reason to the contrary."

A good reason might indeed be that it's by far the best tool for the purpose, and though it's regrettable that the King of Ruritania has a personal dispute with the owner of the company, and it's therefore banned in Ruritania, we don't see that that means we should avoid it.

We absolutely should not permit adoption of tools without thinking about this, and justifying the choice. Silence is not good enough.

[jeffjaffe]

When I said Should, moving to Must - I did not ever mean blindly moving to Must. I meant moving to Must as a goal, presuming that we don't discover issues along the way. Certainly if the Should experience raises issues which make Must a mistake, we would not progress from Should to Must.

There was nothing automatic intended in #435 (comment). The expectation was that after being in the process as a Should, the process community would have an opportunity to propose, evaluate, approve, defer, or reject in the next round.