Doesn't that defeat the point?
Topic on Talk:Wikimedia Technical Committee/Charter
+1 I would like to hear more about this question as well.
I think making every decision of the committee binding is both a lot of responsibility and power. How does accountability work in this scenario? I think in the long run, i think a scaled approach might be useful, i.e. some decisions should be considered recommendations and others might be considered binding. There are also other considerations to work out about how this authority intersects with the existing product verticals and authority vested in there ... i.e. what kind of project and product (annual / quarterly / whatever cadence) planning needs guidance / input from this committee.
I am mixing scope and authority here, but, I think making everything binding has some bearing on scope and accountability.
I agree with the scaled approach, but I trust the committee itself to make the decision on whether they want their opinion to be taken as a recommendation or a binding ruling, meaning they need the power to say a decision is binding.
As I see it, the main check on the TechComm's power would be that of resourcing. If a project is greenlit and no one works on it because all the PMs think it's a bad idea, or Ops vetos giving it server resources then it doesn't matter right? (e.g. Hierator, approved by ArchCom, vetoed by ops). The inverse is also possible where ArchCom makes a recommendation a project goes in but the PM/team decides to go a different way (e.g. Gather, the end result here speaks for itself). My anecdotal recollection/experience is that projects that received ArchComm's blessing have been reasonably successful, provided there was/is adequate resourcing provided.
I had a similar reaction of surprise to this wording. At first I was wondering if that's a change from arch-com, whose decisions I would normally consider binding, but on reflection I think its actually a larger departure from the arch-com model. In arch-com, the committee in theory isn't really making decisions but interpreting consensus, much like a 'crat would do on a wiki. Now the committee would be making actual decisions potentially independent of consensus. Perhaps this makes sense, but I would love to see an expanded rationale for why the committee should operate in this fashion.
ArchCom discussed this today, and agree with some of the questions and concerns raised here. There is a tension between non-binding ("why bother?") and binding ("it's a power grab!").
The outcome of the conversation was to propose changing the wording to something along the lines of what Legoktm suggested. Specifically: "The committee may issue non-binding recommendations, but can also issue binding decisionsā. As examples, a recommendation about how a specific technical problem might be solved could be non-binding, but a deprecation policy might be binding.
Does that sound better?
These are different types of decisions that the committee might make under the overall decision-making process. So I would make that clear if there are different types of decisions the committee might make, and then offer a few examples.
The authority of making binding decisions is not that useful unless you accompany it with a requirement for certain matters to be discussed in the committee. Otherwise, experience shows that people will just ignore the committee and avoid discussing controversial matters with it, just because they can be potentially told to go a different way than the one they originally envisioned.
In other words, I think either could work: an advisory body, that can opine in a non-binding manner on any matter when asked, or a decision-making body, which absolutely has to be involved in certain important decisions. We already know from experience that ArchComm's in-between model where it's binding, but only if/when asked, does not really work.
My sense is that intentionally not bringing a relevant topic to the committee before acting would be viewed as an offense comparable to going against a binding decision. And of course anyone who was aware it was happening, and didn't alert the committee, would be part of the problem.
But I'll raise this for discussion with the committee.
I think this should be handled like consultations of the security team: if you have something security relevant, ask them. If they say no, don't do it. If you do it anyway, or you didn't ask and things go wrong, it's your fault. It should be the same for asking T-Com about architecture and such. And of course the line is always somewhat blurry. It's blurry for security too - you never really know what's security relevant, until it's exploited.
In some (many?) cases, the committee may just give an opinionto consider, instead of a hard approve/oppose. On matters out of the committee's scope, the committee can still offer opinions - e.g. on the code review process.
Should the charter be updated to specifically say something like this?
The committee might take one of two approaches on any given topic, and will be clear which was taken:
- A decision, approval, or disapproval, for which they expect compliance, or
- An opinion, which they expect to be heard and understood, but not necessarily followed
The committee concluded that its decisions won't be "binding", in the strict sense of the word, because they could be overridden by the CTO. Instead, the charter now describes an escalation path if someone disagrees with a committee decision. Note that the committee also expects to issue "opinions" or "recommendations", which would carry less of an obligation. An analogy would be how existing standards bodies use "must" vs. "should" language.
In this thread I see agreement that the committee should have the power to make decisions and policies that cannot be overridden unless by first consulting TechCom and/or the CTO.
In discussing this during the TechCom meeting today, however, some of the member were uncomfortable with the phrasing of "binding decisions" because this word implies there cannot be any appeal - whereas our intent is merely to require there be an appeal, through an escalation path (bluntly put: "follow the policy or escalate accordingly").
With the latest edit (Revision 2511554, Revision 2512165), the draft no longer mentions "binding", nor "non-binding". Instead, it documents an escalation path.
We decided not to make any distinction in the charter between opinions (that may be overridden without escalation), and policies/decisions (that require escalation). Instead, if a specific policy isn't meant to require escalation, then we should say so within that policy.