The team should not be expected to recommend a disposition of an FO

[palemieux]

The Formal Objection Council Guide suggests that

[...] the Team prepares a detailed report with an analysis of the decision, objection, and its attempt to find a consensus. That report may also contain a recommendation to favor either the decision or the objection._

The team should not be asked to recommend a disposition of an FO, since making such a recommendation will necessarily put the Team at odds with some members, perhaps even a majority, which makes the work of the team harder and reduces engagement by members.

If one exists, a team report should be strictly factual, e.g. include a timeline of the events, links to relevant documents, etc.

[plehegar]

To be clear: there is no expectation that the Team makes a recommendation on the outcome of an FO. The current wording does indicate that the Team MAY do so.
It's also easy to separate4 the facts from a recommendation in a report, by clearly labelling the sections. So, I don't see any harm in allowing the Team to provide a recommendation and, if such recommendation exists, it's better for openness to have it capture in the report rather than having the Team providing feedback through the AB and the TAG.

[dwsinger]

If the team has a recommendation, the Council needs to, and will, hear it. Whether it's in the report, or they ask "well, what do you think?", the Council will want to know. The team has been handling it from filing through the attempts to resolve. So saying it MAY be in the report is harmless.

[palemieux]

@plehegar @dwsinger You failed to address the concern raised in the issue: by providing a recommendation, the team necessarily chooses one member's position of another: this is not desirable in a member-driven organization and creates a very basic conflict of interest.

[dwsinger]

It doesn't create a conflict at all. They report the facts and background, their attempts to find a consensus solution, and, if they can and wish, what they think may be the best way ahead. They have by this point worked the problem for weeks or even months.

[palemieux]

It doesn't create a conflict at all.

@dwsinger A team member arguing against a W3C member is akin to an attorney arguing against their client, or you arguing against Apple.

[plehegar]

Just because one company is a Member does not mean that we're not entitled to have opinions and, again, it's better to have those opinions in the record rather than telling the team to use other means to convey an opinion. We still have to act fairly to all of our Members and make sure that their opinion is properly represented, even if the Team disagrees with it.

As a reminder, the Team is counted as a participant in Groups and, as such, is also entitled to have opinions within Groups. As a side, the Director did require team contacts to have his approval before raising a formal objection in a Group. I'd expect we would replace this constraint with a new team internal process. The reality is the Team has not raise a formal objection for years.

[dwsinger]

@palemieux The team is not "arguing against a member". This not not a court of law, and we arrived at an FO because there was a difficult conflict between members in the first place (a decision that was objected to), so whatever they say will be aligned with some members and not with others. We are not trying to decide right or wrong, or who is right and who is wrong. We are trying to work out what's best for the world-wide web and the consortium.

[palemieux]

Just because one company is a Member does not mean that we're not entitled to have opinions and, again, it's better to have those opinions in the record rather than telling the team to use other means to convey an opinion.

I am not sure what you are referring to. Can you clarify?

As a reminder, the Team is counted as a participant in Groups and, as such, is also entitled to have opinions within Groups.

I am not sure how you jumped from "not providing recommendation to the FO council" to "not having opinions within groups".

To be entirely clear, my proposal is to limit team input to the FO council to strictly factual information: timeline of the events, links to relevant documents, etc.

The reality is the Team has not raise a formal objection for years.

The Team has certainly opposed (publicly) members in the past, as you know.

[palemieux]

We are not trying to decide right or wrong, or who is right and who is wrong. We are trying to work out what's best for the world-wide web and the consortium.

@dwsinger The outcome of the FO council is a "yay" or "nay" so it is literally "right" or "wrong".

[plehegar]

Just because one company is a Member does not mean that we're not entitled to have opinions and, again, it's better to have those opinions in the record rather than telling the team to use other means to convey an opinion.

I am not sure what you are referring to. Can you clarify?

You're effectively asking the Team to not put its opinion on the record but the Team can always provide input to the AB and the TAG. Nothing in the Process prevents that.

If we're in a situation where the Team feels strongly about the outcome of a Council, I'd rather have it in the report rather lost in the middle of AB/TAG minutes. Since nothing prevents a Member to provide input to the Council, I believe it should be the same for the Team.

To be entirely clear, my proposal is to limit team input to the FO council to strictly factual information: timeline of the events, links to relevant documents, etc.

Here are the 2 team reports that were provided:
https://www.w3.org/2022/03/WebAppSec-FO-Analysis.html
https://www.w3.org/2022/03/prapi-fo-report.html

While they did not contain recommendations from the Team, let us know if you believe some of the information in them was problematic.

[palemieux]

Since nothing prevents a Member to provide input to the Council, I believe it should be the same for the Team.

Isn't there a significant difference between Members and the Team if the W3C is member-driven?

[palemieux]

BTW, my suggestion is not to prohibit the Team from providing input, but to instead limit the scope of that input.

Example of information that the team can provide:

• timeline of the events
• links to relevant documents
• legal issues
• HR issues
• PR/marketing issues

[dwsinger]

um, a limit is a prevention. If the team has a recommendation, then the Council will get to know it; it's best if it's in the report for all to see.

We surely do not want the Council operating in ignorance of the team's suggestion, if they have one – it is the team that has been trying to find a consensual exit.

[palemieux]

We surely do not want the Council operating in ignorance of the team's suggestion, if they have one – it is the team that has been trying to find a consensual exit.

The membership should be interested in the team not taking sides on issues that is outside their scope.

[ed.: This of course my assumption. Perhaps a vast majority of members want the Team to play an intimate and active role in shaping the technical direction of the W3C. Happy to be proven right or wrong.]

[dwsinger]

At the moment, we hire technical experts on the team. True, they no longer write code or specs, but they are deeply involved in technical direction. You might envisage that they are more like other trade associations, where the staff facilitate but are otherwise neutral. That is not where we are today.

[palemieux]

but they are deeply involved in technical direction.

I am not convinced it is good idea (for the reasons stated above and based on my experience within and without the W3C), but could be convinced otherwise.

If this is not going to change in the foreseeable future, then this should be captured clearly in the process/mission statement/charter/bylaws, if for no other reason than it is very different than pretty much all other organizations.

Maybe this is already captured somewhere?

[mnot]

The Team aren't here to serve the community, they're here to serve the Web. While their influence does need to be carefully thought about and at places limited / balanced against, that doesn't imply that they need to be strictly 'neutral' (which is an impossible goal).

Furthermore, as has been said if they're going to state an opinion, it'd be much better if it were transparently reported.

[palemieux]

The Team aren't here to serve the community, they're here to serve the Web. While their influence does need to be carefully thought about and at places limited / balanced against, that doesn't imply that they need to be strictly 'neutral' (which is an impossible goal).

@mnot is it stated explicitly in the bylaws/charter/etc.?

It is extremely unusual for SDOs.

Furthermore, as has been said if they're going to state an opinion, it'd be much better if it were transparently reported.

Ok, It is however not the matter in this issue :)

[chaals]

I agree with @palemieux that team member's opinions can, and I believe occasionally do, push discussions strongly in one direction or the other.

That said, the Team are required to be vendor neutral, but not issue neutral. I think the Team providing a formal statement of what they think, if they have an opinion, is a reasonable thing to do. As @dwsinger notes, people who have been working on a problem for a number of weeks probably have an informed opinion, which is useful to know. As @plehegar and @mnot suggest, I think it's better if that goes through a formal channel and is more visible than if it is just communicated in private conversations.

If the team have a recommended disposition of a Formal Objection, they should share it, and most importantly the rationale behind it, with the AC as input to the Council. If they have internal disagreement, they should share that, too.

[nigelmegitt]

If they have internal disagreement, they should share that, too.

This is important and often missed, I think.

The default response when there is a range of incompatible views within the team would most likely be to say nothing, but it would be more useful, if saying anything about the team's views, to be transparent about the range of views rather than only saying something if there is team consensus.

There is also the related "team has views but feels it would be more politic to stay quiet". I'd prefer a consistent response across all FO team reports, rather than this: either the team should always hide their views or never do so.

[palemieux]

While the desire for transparency is good, it is impossible to compel team members to share their opinion, especially on a controversial topic that might affect their employment, reputation, etc.

It is also impossible to differentiate vendor-neutral from issue-neutral when vendors are divided on the issue. As a practical matter, members will not react positively if employees of the member-driven organization they fund at great cost takes a position against them.

Team input is however required on some topics, e.g. legal, marketing, etc.

So perhaps team input should be explicitly limited to specific areas of responsibilities.

[frivoal]

In my view, in this issue and a few others you've raised about this, you're attempting to make the Council and the Team activities before it into a legalistic, largely deterministic, bias free system. I think that's a mistake, because it would effectively boil down to one of two things, both of which would be bad ideas:

• When there is a formal objection, that in itself shows we don't have consensus, and since there's no objective truth about why anybody feels any particular way, there's no objective way to determine whose views are best for the Web, so anything with a Formal Objection is dead and there's nothing you can do about it. It would be predictable and non arbitrary, but I don't think anyone, you included, want that.

• When there is a formal objection, either you can prove beyond reasonable doubt, free of undue influence, and based on written rules only, that the originating Working Group did something that isn't allowed, in which case you must block things, or you cannot prove that, in which case you must accept publication.

I think the second one would be a profound change to how W3C work, to a point where I am not sure we'd recognize the result as being W3C.

Because all the work we do is about producing standards that will be voluntarily implemented by anyone who does, and because we want to make sure that the web caters to all constituencies, we try to take everyone's input into account, and don't consider ourselves done until we have reached a point where approximately everyone, if they aren't outright happy with it, can at least live with it.

It doesn't matter if someone has followed all the rules, if people still cannot agree that what they produced, then we're not done.

If we were trying to evaluate strict adherence to objective criteria, I'd probably agree that we should refrain from risking swaying things due to subjective bias from involved parties, such as the Team. But we're not. We're trying to find the best way forward when we've reached the point where we've failed to make everyone happy. What we're looking for at this point is insights from knowledgeable people, so that we can make a principled and well informed decision.

Team input, in this context, is valuable even if it isn't neutral.

[palemieux]

@frivoal Thanks for detailed input, but let's go back to the issue at hand: whether the team should be expected to recommend a disposition of an FO.

You have not addressed my specific concern: requiring the team to make a recommendation to favor either the decision or the objection necessarily puts the team in a position to favor a set of members over another set of members. This has practical consequences:

• how will a member react when the very team they are funding publicly voice their opinion against them?

• how will a team member act when they are asked to publicly take a position against a member that may affect their current and future employment?

My proposal remains to narrow the scope of the team input to factual information.

[ed.: I am happy to have a discussion on the broader topic of governance, but this is probably better done live and/or through other issues.]

[fantasai]

@palemieux The Team is not required to provide a recommendation, the guide only states that they MAY do so if they feel it's appropriate...

[palemieux]

The Team is not required to provide a recommendation, the guide only states that they MAY do so if they feel it's appropriate...

My proposal remains to narrow the scope of the team input to factual information to avoid the possibility that an opinion is provided which would result in the issue described above.

[chaals]

@palemieux:

My proposal remains to narrow the scope of the team input to factual information to avoid the possibility that an opinion is provided which would result in the issue described above.

I am opposed to your proposal. I think it would be a bad idea.

[frivoal]

Will link to the AB minutes when available, but until then, here's the resolution:

RESOLVED: The AB believes the Team should be allowed to make a recommendation in the Report, but they are not required to do so.

[css-meeting-bot]

The Revising W3C Process CG just discussed Proposed to Close, and agreed to the following:

• RESOLVED: Close 629

The full IRC log of that discussion

<fantasai> Topic: Proposed to Close
<fantasai> github: https://github.com//issues/629#issuecomment-1340387346
<fantasai> plh: AB met to discuss some of the issues
<fantasai> ... and one of those was whether Team should be allowed to make a recommendation in its Team Report or not
<fantasai> ... and AB resolved that the Team MAY do so but is not REQUIRED
<fantasai> plh: I believe there's nothing left for us to do here
<fantasai> florian: Yes, AB minutes are delayed because Ralph is busy (for obvious reasons)
<fantasai> ... full text of resolutions should be available soon
<cwilso> +1
<fantasai> florian: since we're operating under delegation from the AB, right thing to do is close the issue
<fantasai> plh: Any objections to closing the issue?
<fantasai> RESOLVED: Close 629

[frivoal]

@palemieux for the purposes of the DOC, it would be good to know if despite the group disagreeing with your proposal, you accept that the discussion reached a reasonable conclusion, or if you reject that conclusion.

[palemieux]

@frivoal Thanks for the reminder. I plan to provide a reply by Friday next week.

[palemieux]

@frivoal It looks like the prose with which I had expressed concerns was not incorporated in the Process document, so this issue is moot (or resolved).