The Elephant in the Director-free Room

[mnot]

In the director-free branch, almost all of the powers of the Director are transferred to the Team (including the CEO in some cases). This includes:

• Convening Workshops
• Starting Charter development
• Approving Group creation
• Assessing consensus of the AC
• Appointing Chairs
• Closing Groups
• Requiring a Group to stop work on a specification
• Specification advancement (or declining to do so)
• Publishing a Recommendation
• Rejecting a Submission Request

Although the Team and the CEO have the trust -- and even affection -- of the community overall, they are not Tim Berners-Lee, and simply running s/Director/Team/g does not result in an equivalent organisation -- even though Tim has delegated his responsibilities to them in the past, this was done with the knowledge that there was still recourse to him in exceptional cases.

And, while the appeal mechanism is one counterbalance against Team powers, it's notable that many of these actions are not appealable in the negative; for example, an AC rep can only appeal the creation of a WG, not the decision not to create one.

So, I think it's appropriate to examine the list above and determine what the appropriate decision-making mechanism is. In some cases, it might be good to invest the TAG with a role, or to give it some oversight capacity. In others, it might be perfectly acceptable to leave it with the Team.

Leaving the details aside for the moment, I think the decisions need to be principled. I'd suggest we need to design a process where:

• People making decisions that have significant impact on the Web are accountable to the community, using a practical mechanism (e.g., being elected)
• Decisions are resistant to being captured by any one member, industry sector or interest group
• Decisions are separated from the "business side" of running the W3C

[chaals]

I suggest we rename the issue to something more descriptive, such as "how to assign each of the director's roles".

I believe there is a clear understanding among the AB of the importance of this issue and an effort to ensure that each of the roles Tim currently formally has are assigned deliberately, rather than the s/Director/Team/g approach you rightly suggest is inadequate.

There is a tendency for the AB to discuss, in its meetings that are not open to general participation, various aspects of the process such as this. This happens because the AB is ultimately responsible for proposing changes to the process document, but it has the unfortunate side-effect that participants in this community group may not be able to see what is being proposed. I will repeat my request to the AB that such meetings are generally open to, and their minutes published to, this group, so we don't have the same work happening in parallel and in ignorance of the other efforts.

[dwsinger]

Hi Mark, all

though I share some of your concerns in principle, our initial triage was based on what is, in effect, happening today; quite a lot of what is done in the Director's name is, in fact, delegated with little to no check by the Director. We've discussed (at length) various scenarios in which this goes wrong, and the general thought is that if the team/CEO is behaving in ways the membership finds problematic both (a) we have a much deeper problem than these process steps and (b) we'll have recourse to appeal to the Board of Directors.

The TAG, and to a lesser extent the AB, have been resistant to being inserted any more than they have to in formal/mandatory roles, as well. Generally, we're trusting that a well-behaved CEO+team will of course only take controversial steps after due consultation, even if the ultimate decision is theirs.

Having said all that, I (and I think the AB, though I speak here personally) would like to hear if there is a reasonable backstop we can state.

[mnot]

It's good to hear the AB has been discussing this, but I very much agree that it needs to involve the wider community, not just be talked about behind closed doors.

I think this change (director-free) is an opportunity -- perhaps the only opportunity -- to refactor the W3C into a more community-led organisation. There are of course pitfalls in taking that path, but the goal is a worthy one, and would (IMO) result in a stronger W3C.

It's disappointing that the TAG is resistant to taking on more responsibility; I think that's a failing of the current members and their focus on reviewing specifications. If the community invested them with these powers, I would expect that it would produce suitable candidates in the future to make sure that they were not misused.

[jeffjaffe]

@mnot I initially shared many of your concerns, but I believe that @dwsinger accurately describes the tone and substance of the AB discussions - which have made me more comfortable with this direction.

I would be curious if you could itemize which of the items assigned to the Team feel most problematic. We can then work that out in individual issues.

[mnot]

My .02 -

I feel like workshops should be able to be convened by the Team and the TAG; that's probably the easiest adjustment.

The following need some discussion:

• Starting Charter development
• Approving Group creation
• Closing a Group
• Requiring a Group to stop work on a specification
• Specification advancement (or declining to do so) -- including REC

It might be interesting if the Team were still the locus of these decisions, but a body like the TAG were able to formally ask the team to do one of the above, and they were also consulted by the Team beforehand (or at least notified). That would start to make the TAG slightly more involved in the technically important decisions of the organisation, without putting the full weight onto them.

The following have the backstop of the council-driven appeal process, so can probably be left in the hands of the Team:

• Assessing consensus of the AC
• Appointing Chairs
• Rejecting a Submission Request (check - is not rejecting a submission appealable?)

[michaelchampion]

Having recently left the AB, I have been dismayed to realize how much of this discussion is now happening out of my (and the rest of the community’s) view. The fact that most the Director ‘s nominal roles have been gradually assumed by the Team has not caused a major problem yet, but this has fundamentally changed the character of the organization. “W3C” has come to mean “the team”, not “the membership” or “the community”.

In my view, the Team provides the infrastructure for the community to find consensus on the topics in @mnot’s Needs Discussion list, it shouldn't make those decisions.

[dbaron]

I share the concerns Mark has raised here. That many of these functions have been exercised recently by the Team doesn't mean that the Team should be the one exercising them, or that the Team's exercise of those functions will be viewed the same way when they're not exercised in the name of Tim as Director.

In practice, the area where I've had the most concern is the process of chartering (or not) new work. Of the items in Mark's list, a few cover chartering (mainly the first three and some bits of the others), and those are among the ones that happen frequently. (A number of the major disputes over specification advancement in recent years were really relitigation of the charter at the end of the process -- which is both unfair to the participants who put all the work in in the interim, and also perhaps a sign that the chartering process didn't get the level of community review it needed.) I think chartering is also an area that is particularly central to the third of Mark's goals (separation of technical decisions from the business side of W3C).

The Director-free changes to the process are likely to be the one opportunity to rethink how these things should work for a long period of time, so I think it's worth doing so carefully in order to get it right.

[jeffjaffe]

Thanks @dbaron . I agree that the Team cannot exercise chartering functions in exactly the same way in a Director-free consortium.

Today, if there is a formal objection to a Charter the objection goes to the Director. Under delegation from the Director, the Team often processes the objection. The Team can even overrule an objection if they have the Director's delegation. In the current design of Director-free, that is not possible. The Team may try to resolve the objection, but if they cannot, it must go to the W3C Council.

An additional feature of Director-free is that the AB is preparing a companion document (for the Process document) which characterizes clearly and precisely how objections must be processed by the Team. This is to ensure (among other things) that if the Team feels that an objection has been resolved - that there is indeed clear agreement on the Charter.

These two features of Director-free may not fully address your concerns, but hopefully it illustrates the care that is going into this project.