Charter Approval #651
Comments
|
We've got a PR trying to cover this (and related topics) already. Hope you like it: #646 |
frivoal
added
the
Director-free (all)
(emphasis added) This language is problematic; it puts authority to call consensus in the hands of the Team. While their hands are tied somewhat by the presence of a FO, this langauge gives them significant leeway in what's allowed if there is no FO:
(emphasis added) If the determination of sufficient support were able to be independently calculated without any judgement by the Team, that would be one thing; here, they have considerable discretion. In other places this mechanism is specifically a 5% threshhold -- why is that not used here? It's odd that we're so specific elsewhere but not here.
Again, there seems to be considerable discretion here. |
|
The set of pull requests that are setting-up director-free already considerably reduce the amount of discretion given to the Team. Agreed, it's not reduced to zero, but we've experienced a number of cases where that discretion is warranted, so we're not introducing purely mechanical rules. We could spend more time to try and assign that responsibility to someone else, but I don't think that should stop us from making these improvements. The primary goal here is not "let's revolutionize everything about how we work", but "let's stop pretending we don't know how to opperate without a director". I'm not opposed to considering further steps later, but I do want us to make steady progress. |
|
@frivoal I don't know what to take away from that -- you're making general statements, not addressing the specific issue that I've raised. |
|
Also I do want to note that the Team often drafts up policy guidelines for itself, and I think that's a better way to handle this than hard-coding automatic rules such as a 5% threshold into the Process. |
|
It has been suggested that it should be possible for the community to cause an WG closure vote to happen; I suggest that we should similarly make it possible to cause an AC vote to happen on a Charter if the team is declining to present it to the AC. This presumes a Charter text has been written and could be adopted, and the reasons that the team is declining may be practical, so this will take thought. But there should be a 'safety valve' here |
|
The safety valve is already present: if no Charter is approved then when the current Charter expires the group will no longer be chartered. I don't believe anything more is needed.
Could you provide a pointer please? |
(Verbal in the AB meeting at least) |
|
OK, thanks. It looks like there is not yet a summary of the most recent AB meeting, which I understand was earlier this week. In lieu of anywhere else to register any reaction to the suggestion that the community could cause a WG to close ahead of its active Charter end point, it seems like an incredibly bad idea to me. The idea that a mob of folk uninterested in some particular WG's work get to close down the work in which others are actively participating seems like the cultural opposite of the W3C's historical approach. |
Yeah, but the question is whether W3C's historical approach is fit for the purpose of stewarding the evolving web. While I am not convinced there is a pressing problem that having a way for the community to shut down a WG would solve, it seems like a useful thought experiment. For example, what if W3C had, amidst the "web3" hype a year or so ago, recruited some of the more egregious Ponzi schemers as members and chartered WGs intended to bolster the credibility of things like proof-of-work blockchains, NFTs, or other stuff that now has an unsavory reputation. It might be appropriate to have a mechanism for the community to say "ooh, bad idea, let's pull the plug now rather than waiting for these WGs to fail." (Or waiting for those WGs to tarnish W3C's reputation with something that ends up as snark fodder on https://web3isgoinggreat.com !) Still, I'm more interested in tightening the process and culture so currently popular but possibly unsound ideas don't get into chartered WGs until they have been incubated well enough to show that a real community of users and implementers are productively engaged. And not giving them the imprimatur of Recommendation until there are interoperable implementations that solve the problems the group was chartered to solve. W3C's deliberate process, and possibly inadvertent refusal to jump on various Next Big Thing! bandwagons that went nowhere, may have saved it from needing to close down work that should never have been chartered. |
Um, Nigel, that's a strawman; you're attacking something that (as far as I know) no-one has said. Please can you also avoid words like "mob of folk uninterested", it comes across as pejorative? One scenario that concerns us is when there is, from the community point of view, a really problematic WG that most think should be closed, but there are one or more members of the team that like it, and those team members prevent team consensus to close, so even though most in the team and most in the community want it closed, the team doesn't propose it for closure, and since there's no "decision", it's not clear a formal objection can be filed, or an appeal. It's a little too strong for preserving status quo, perhaps. It seems that there should be a way for it to be brought to the AC for debate and decision. That's all. |
@dwsinger it was you who said it had been said, in #651 (comment) - I accept that I built on that, but it didn't seem like a big step. |
The implication is that between a WG being chartered and that Charter expiring, usually within 2 years, something significant changed that made the WG seem like a bad idea. I'd contend that the first step is to address whatever it is that seems bad about the WG first, before attacking the WG's existence itself. The second step is, whenever the WG tries to transition a Rec track document associated with whatever bad thing is going on, submit appropriate review feedback and objections. Give the WG a chance to resolve the problems first, and if they can't, they're essentially prevented from publishing anyway. I'm arguing that we have sufficient safety valves already, and I'd be interested to know if there are scenarios where that is not the case. |
I think converting "It has been suggested that it should be possible for the community to cause an WG closure vote to happen" into "a mob of folk uninterested in some particular WG's work get to close down the work in which others are actively participating" was a very big step indeed. |
|
Is it a big step? It seems like a logical inference to me. Help me see it a different way. Existence of WG implies some group of people are participating, which implies support. If they weren't, there'd be nothing to worry about. (ok, non-participation for too long possibly is the one good reason to close a WG down, but since doing nothing will have the same impact, it would be pointless busy-work) Community wanting to close a WG down: "Community" implies "those people not participating", which in almost all cases will outnumber those who are participating. At that point, you have one big group of people trying to close down the work of a smaller group of people. In most walks of life, when you're trying to mind your own business and a big group of people actively tries to stop you, that feels like a mob. I don't mean this is in a pejorative way: it's a reflection of the proposed scenario. |
|
I'd have to agree with David that it was a big step, though I can see how you got there. In short, given that the ultimate authority here would be the AC, I don't see your concern - if a larger group of AC members believe work should shut down, over a smaller group who believe it should continue, that sounds like a lack of consensus by ANY measure - and the charter would not have been approved if it came up again. |
|
Leaving to one side the worry that the AC might change its mind about whether a WG should exist or not within a period of (usually) 2 years, I agree, that what's being described here is a lack of consensus. In this situation the baseline state is "WG exists with a Charter" and the proposal is "close the WG" and there is a lack of consensus for the proposal. So the proposal is rejected, and the WG continues, right? |
|
I would presume, yes. |
|
Let's see. "mob" is a pejorative term, implying people who are uninformed and out with pitchforks, which you further emphasize with "uninterested". Take the possibility that a WG is straying into territory that could bring the W3C moral or even legal problems. "We should simply stop this work before the situation gets worse" could be a very well-informed and considered opinion. Other examples include work that is contrary to our values (e.g. intended to make collection of personal data easier and more widespread). And yes, we should be able to force a debate in the membership about the work, expose the issues and considerations, and make an informed decision as a community. |
|
Again, we already have mechanisms for dealing with both bad behaviour and technical reports that could bring the W3C into bad repute, including the CEPC, wide review, horizontal review and ultimately AC review. I'm struggling to see how a WG could manoeuvre itself past all of those checks into a situation where the only feasible resolution would be to close it down ahead of its Charter expiry. Perhaps we should be exploring where the openings are in the process and working methods of W3C that might allow a "bad actor" to, say, publish something bringing W3C into moral or legal problems, before creating a new sanction. |
|
I think we're seriously off track here. We already have the possibility that the Director can close a group prematurely. We're moving to a member-led consortium, and it seems imprudent to leave this power solely in the hands of the team (who are not the founding Director). I suspect we should fork this into two issues, separate from this general one: is there a mechanism for bringing a charter to AC vote, if the team does not bring it to vote? Is there a mechanism for the members to vote on closing a WG before charter expiry, if the team does not bring it to a vote? (Another example might be a WG that is dysfunctional, such that we end up with only one organization in it, chairing it, and driving it, because everyone else gave up and left). |
+1 to moving the decision away from the team alone. ... but also that the criteria for terminating an activity should be extremely high: complete lack of participation/progress or deliverables that will necessarily fall outside the scope of the W3C. The mere fact that a majority of members is not interested in (or do not "like") an activity should not be caused to terminate it if it is in scope of the organization and it is marking progress. Open standards organizations have a bad track record at predicting which standards will be ultimately successful. |
Indeed it should not, but all is good because nobody has suggested majority. The text of the process for closing a WG is an AC Review, and these are very much not majority votes. We're not suggesting adding a alternate majority vote process, but the ability for someone other than the Director/Team to initiate an AC Review. |
Yes, in very specific prescribed conditions, rather than by an AC Review or such-like, and not due to some sense of moral or legal danger. And there's an opportunity for an AC Appeal. I would trust the team to recognise if those conditions are met. |
That's the problem. There is not an opportunity for AC Appeal when the Director (or whoever replaces the Director in this function) doesn't do anything, because there is no announced decision to hang it on. And the team works (at least today) by consensus, and consensus favors the status quo, and so one influential team member could cause stasis. I continue to think that the AC should be able to opine, in a formal way, on closing a working group, if it wishes, even if the team seems unable or unwilling to act. |
That would move the problem of "one member causing stasis" from the Team into the AC, without particularly solving anything, wouldn't it? |
|
I'm being swayed by the argument that we need a mechanism to close groups, without a Director to decide, and without consensus by the Team. The current process notes the Director my close a group when "There are insufficient resources to produce chartered deliverables or to maintain the group, according to priorities established within W3C." I can more easily imagine a situation where a group is marginally useful and making some progress toward a low-priority goal that W3C no longer has the resources to pursue, than a situation where a WG needs to be shut down before it causes serious harm. But in that insufficient resources scenario, It's easy to imagine a Team member blocking consensus that "their" group's mission is low priority. I don't have a proposal for exactly who should be able to shut down groups. The CEO, accountable to the Board and subject to a potential Appeal to the AC maybe? I can't really imagine a scenario where there would be AC consensus to shut down a WG without the CEO's agreement, but I wouldn't object to putting some AC-initiated mechanism in the Process. [Ahh, I see we've wandered into #653 which has a resolution -- the AB or TAG as well as the Team/CEO can propose closing groups. SGTM] |
This is exactly the sort of comment that makes me react strongly against the idea that the AC should have any powers to initiate a WG shut-down at all. Who is defining that utility is "marginal" or that the goal has low-priority, or that W3C does not have the resources, given a situation where the AC already approved the group's Charter? Only people who are either uninterested in the group's goal or would like to pursue a counter-interest outside W3C. I see this as representing a push towards a less plural, narrower and frankly poorer view of what W3C should be doing than the view that I value: W3C should be able to take a holistic view of all the ways in which people interact using the web, and the technologies that are needed to support them. If there's going to be an AC-initiated mechanism to begin the process of shutting down a group ahead of its Charter end date, then the potential reasons for allowing that mechanism to be triggered need to be very tightly tied down, much as they are for the Director today. Perhaps the best middle ground here is to say that the AC should have a way to hold the Team to account, so if someone in the AC perceives that the shut-down criteria are met, but the Team is not taking appropriate action, then at that point they should have an escalation mechanism. |
We're probably wandering far from the actual issue here, but I see it quite differently: Lots of the ways people are using the web are somewhere between sleazy and criminal; W3C REALLY MUST NOT enable such people in the name of holism / pluralism / decentralization / whatever. |
|
That's a completely orthogonal issue - of course I'm fine with both wide and horizontal review of specifications and Charters to prevent standardisation of specifications that we can identify as enabling or encouraging immoral behaviour. |
|
I'd like to point out that the issue of CLOSING groups is #653 and not this issue, which is about APPROVING charters, and you are therefore all off-topic. (Nigel, you even commented in 653 so you should know better than to hijack this issue!) Please move your discussions to the appropriate issues. I will delete any further off-topic replies in this issue; it is already enough of an unmanageable mess. Thanks. |
|
Soooo, what is left in this issue? It seems just the question of whether #646 (which has been merged) is "enough" in terms of hardcoding rules? |
|
Thank you for returning to the actual issue. The heart of #646 is:
I have every respect for the members of the Team; I count several of them as dear friends, and I believe they collectively have the best interests of the Web at heart. Having said that, giving them the power to 'assess consensus' -- i.e., make decisions -- is potentially problematic. In particular, no matter how much we as individuals in the community might respect and trust the Team, from an outside perspective more is required. A new vendor joining doesn't have that trust; neither does a regulator when they're determining how much weight to give to our process. If legitimacy can't rely on personal trust and respect, what can provide it? What keeps the Team accountable? Julia Black has one of my favourite defintions here:
One common answer is democratic legitimacy -- having people elected to represent the stakeholders, and having the power to remove them if they displease too many. The Team doesn't have that; it reports to W3M, who reports to the BoD, who are partially selected by the Members. That's far too indirect to count as democratic; it's unrealistic to think that a Team member will be asking whether they could lose their job if they didn't make a consensus call correctly, and I sincerely hope that they won't be put in that position. Transparency is an oft-cited contributor to accountability, but we don't demand that of the Team's decisions. They don't have to 'show their work' regarding the various factors they balanced in determining consensus. Responsiveness is also cited as a contributor to accountability, especially when the subect is a buraucracy. However, in the case of the W3C, this only brings up the well-worn question of who are they being accountable to -- the broader public's needs, or the representatives of Members who are making the most noise? We have little way of knowing or judging this. One more aspect of accountability is the obligation to enter into a public dialogue -- promoting open discussion and debate. As we've explored elsewhere in this issues list, open debate at the W3C is in a sorry state; we have no community-wide discussion channel, the AC is lethargic and restricted in how it interacts, and I have to say that it's sometimes hard to get an answer out of the Team. Another signifier of accountability is evaluation -- the continuous monitoring and review of its progress and results against defined goals and objectives, with reports back into the community. The reporting I see at AC meetings doesn't fill this gap. What we do have in this process is the ability to FO a team decision -- effectively an appeal / complaint system. Again, this is a major feature of accountability systems. I'd argue that the FO council is an insufficient check against the Team's power. If it were combined with other mechanisms it might be, but alone it is too cumbersome, too secondary (not involving any stakeholders in the primary decision-making activity), and too burdensome for the objector. Also, considering how closely many of the TAG and AB work with the Team, it's not unreasonable to question whether they're naturally biased in favor of them. Again, I know that there's widespread affection and respect for the Team, and I share it. However, having an unelected and only indirectly and tenuously accountable body make important decisions 'on behalf of' the community is a serious governance issue. Parties outside the community (like regulators) are not going to have that same trust and respect. As I've said before, I think the proper way to deal with this through direct governance: setting up (or coopting) a decisionmaker that's transparent and accountable to the community. There are a lot of ways to do that, of course, but the obvious way is to give tasks to existing bodies like the TAG as appropriate. If that's too much of a change now (and I really do think we should consider doing it right from the start, no matter how much easier an incremental approach is), we should seriously look at bolstering the Team's accountability (and thus legitimacy) by addressing some of the shortcomings above. |
|
@mnot, would it help to address your concern if any W3C Decision made by the Team required documentation of the rationale in the announcement of the decision? (The PR includes that requirement for cases where a substantive change is made, but not for all such announced decisions.) That seems like a fairly common practice in charter decisions under the Director process (even if it's not been explicitly required). And it would make it a little easier/more direct to get to the Formal Objection/Appeal process; if the Team explained why it thought something was the consensus of the AC and clearly erred in their reasoning, then an appeal would be more ... appealing. |
I'm not speaking for @mnot, but he argues the key point here is ACCOUNTABILITY. That is, "subject[ing] oneself to relationships of external scrutiny which can have consequences." He lists several criteria, let's assess them:
So, @npdoty's proposal addresses one of @mnot's criteria for accountability. That a would be a step in the right direction. With the Board in place, the team has some "democratic legitimacy". We can hope a new CEO will lead the team to culture changes. For example, better responsiveness and willingness to enter public dialogue. So I support taking the step @npdoty suggests I would like to see more steps. Not just "show their work" on charters, but continuous, rigorous, open assessment of whether WGs and their Recommendations achieve the real-world outcomes promised in their charters. And I definitely agree with @mnot that giving the elected TAG and AB more of an ability to observe and question/correct the Team's chartering decisions before they go to the AC would increase legitimacy / accountability. |
At first glance, it might seem like an improvement - an obligation to explain the basis of a decision is part of accountability, as @michaelchampion points out. However, transparency without a realistic chance of consequences is a poor form of accountability. It effectively puts the Team in the position of beaurocrats who become concerned about making 'courageous' decisions -- they'll be more inclined to say 'yes', because to say 'no' to something, they'll have to list the reasons why -- and presumably relate them to established community consensus. That will invite challenges, and so the Council will become the defacto handler of anything even slightly contentious. |
+1
That built-in tilt toward "yes" decisions definitely exists today. But I understood @npdoty's proposal as asking the Team to document ALL decisions with their rationale. That implies stating the charter's goals for a better web, analysis of how creating the group could achieve those goals against counter-arguments and conflicting goals, "key performance indicators" they will be tracking to assess whether the WG meets its chartered objectives, etc . That exercise could make it easier for the team to say "great idea, but let's see how this plays out in an incubation CG" or "uhh, seemed like a reasonable idea 10 years ago. but the WG STILL hasn't come up with anything that gets real world adoption so let's not renew the charter yet again." Or even if the Team doesn't say No, the AB, TAG, AC, FO Council whoever would have better information to make their judgments. |
frivoal
added
Agenda+
|
The discussion in this issue has meandered into a variety of more or less related tangents, but the core question was about approving charters. I think there were a few potential bottlenecks:
I agree that there is Team discretion, though I think that's not inherently problematic, as discretion has been useful on occasion. (distinguishing a somewhat subdued response to a "boring" charter about maintenance of some core technology everybody depends on but isn't particularly excited about vs lack of interest in a new area that just isn't getting traction) However, I disagree that there's no recourse. Approving or Rejecting a charter as the outcome of an AC Review is a W3C decision, and those are subject to AC appeal. We could add hard rules, such as "more than 5%", but again, I think there's value in applying judgement. We could add soft rules like a 5% threshold that the Team can chose to override, but if they want to do so they'd need the Council's blessing. But that would introduce quite a bit of overhead, and I question how much value we'd get out of it. In conclusion, I propose closing this with no (further) change. (1) and (2) have been addressed, and (3) and (4) seem fine to me as is. |
|
I don't believe that (2) has been completely resolved yet, for what it's worth. A charter may receive widespread support and some Formal Objections, and the Team may not deliver its report to the Council indefinitely, leaving the Formal Objections unresolved indefinitely (whether they have any merit or not) and blocking the community from starting work. I think that challenge is better addressed through some update to the Formal Objection/Council process, or some more direct way for us to urge the Team to move forward with Formal Objection processing. I'm happy to open a separate issue if we want to close this one. |
|
Maybe my concern there is a just slightly different instance of #778. |
|
@npdoty I agree that it is possible that the Team can delay (indefinitely) the processing of FOs by the Council, by being (indefinitely) slow to form the Council. However, that's a Process violation already, since the Process has strict deadlines about how long they may take. I don't think we can solve the problem of "the process isn't being followed" by adding more rules to the Process. That seems to me to have more to do with resource allocation, tracking performance indicators, refining practices, optimizing pipelines… In short, on that point, I think this is a primarily a management question rather than a Process question. |
|
@frivoal I can certainly see how an incremental approach to Process evolution leads to that conclusion, given the path dependence we are subject to. In that sense, this issue has been addressed -- as many others in the Process have been, by progressively papering over flaws and accreting new layers of increasingly teetering structures. However, I don't know of anyone who would design an organisation with our current goals in this way -- it's an inherently flawed governance system that only makes sense when you consider the history of W3C as a fundamental constraint. Consider, for example, the failure to deal with the chartering of the PATWG. We now have a FO, and several extremely frustrated members. Is this evidence of a well-governed system? I would accept that this issue has been resolved within the artificial constraints of the Process as it currently sits. However, I would ask that the issue remain open, because it's evidence of problems that require much bigger changes to truly address -- and that this organisation needs such changes, desperately. |
|
@mnot I see where you are coming from, and yes, the current design certainly has some path-dependent aspects.
I don't consider that as a fundamental constraint. It's certainly a starting point (churn for the sake of churn isn't useful), but better ways to do things can be—and have—been adopted.
I still think that the Process isn't the only possible point of failure, and that failure doesn't necessarily therefore means we should blame (and think of changing) the Process. If/when the Process isn't being followed, maybe the problem is elsewhere. In particular, in the case you mention, the Process is indeed not being followed (as we've blown past Process deadlines by many months). If the rules aren't being followed, changing the rules isn't necessarily going to improve things: the new rules might not followed any more than the old ones. It is still a possibility that the Process isn't being followed because it's inherently hard to follow. It isn't obvious to me that that's the case. In any case, the way we now handle FOs is not the way we've done it historically. In your opening comment, it's not that particular failure mode that you were pointing at, but rather what I've called cases 3 and 4 in #651 (comment). In those cases, the way we handle it does reflect history, but I am not aware of problems in practice being caused by the Team having discretion at that stage, and I do know of upsides. |
|
The Revising W3C Process CG just discussed
The full IRC log of that discussion<fantasai> florian: I think we should close with no further action.<fantasai> ... broad version of this issue is "maybe Team has too much discretion in terms of making charters happen" <fantasai> ... narrow version is, "Team has too much discretion after AC Review because they must observe if there's enough support, and they get to determine what's enough" <fantasai> ... my response is that this discretion is good, since e.g. a maintenance WG for SVG might not get a lot of support, but Team should accept even with low threshold <fantasai> ... but for new things, if not a lot of support, probably that's a problem <fantasai> ... For the broader version of this issue, we introduced a bumch of restrictions and opportunities to FO etc. <fantasai> ... Anotehr point that came up was, Fos are not effective because they are slow; but these cases were all violations of deadlines <fantasai> ... in summary, we've removed Team discretion or provided checks for almost every concern (per Process), except the "enough" case where I think we want discretion <fantasai> florian: Finally Mark Nottingham says, "I would design this process if designing from scratch", but that's not very actionable <fantasai> ... we've addressed all the addressable things, afaict <fantasai> ... suggest to close <fantasai> fantasai: Any other opinions? <TallTed> +1 to close <fantasai> florian: I don't see the point of keeping issue open, we've made improvements in response to the concerns <fantasai> <fantasai> +1 to close; should open follow-up issues based on the current ED <fantasai> TallTed: Would be helpful if he could list the specific problems remaining, maybe in a new issue <fantasai> cwilso: Mark seems to want to keep it open because still Team discretion at play; majority of violations of spirit of charter failures is in following the Process <fantasai> florian: Yeah, so file an issue against management <fantasai> cwilso: Still some concerns about how we decide what to charter, that isn't covered here <fantasai> ... but that doesn't belong to the Process CG. That belongs somewhere in AB/TAG/Team, already some work at play there. <fantasai> florian: Can someone think of a good way to put a question to Mark to find out what the *Process CG* should do about this, i.e. why this is relevant to Process CG or agree to move it to wherever it's relevant? <fantasai> cwilso: It seems like we have clear thread in AB priorities this year for transition from CG to real work <fantasai> ... question Mark is asking here isn't about charter approval, but strategy about chartering, I think? <fantasai> florian: Opening question in the issue was about Team having discretion to decide outcome of AC Review <fantasai> ... discussion evolved since, but that's the opening comment <fantasai> florian: 2 problems left <fantasai> ... 1. Some of the time the Team doesn't follow the process (e.g. meeting deadlines). That's an issue for the Board. <fantasai> ... 2. This organization might want to think the whole way it thinks about strategy and what to charter and next new things etc. And AB already has a prioirity project about this. <fantasai> ... so part of this is already project of AB, and part of it should be handled by the Board. <fantasai> ... doesn't seem to be anything left for Process CG. <fantasai> ... Making sure the Team follows the Process seems like a Board issue; and Board should probably work with AB/management to figure out what metrics it wants to follow. But oversight of that is Board responsibility. <fantasai> fantasai: I will respond to the issue. We've addressed the issue filed as far as we can in Process, if there are further concerns they should be filed as follow-up issues in appropriate repos. <fantasai> ACTION: fantasai to respond to issue 651 |
The
director-freebranch indicates in s 4.3 that the mechanism for approving a charter will now solely be Advisory Committee Review. 5.7.1 defines the success criteria as a W3C decision, which is:Little guidelines are given to the Team, beyond that. Is this really appropriate?
First brought up in #316.
The text was updated successfully, but these errors were encountered: