I think the term "Strategic" as used in the charter needs some clarification. In the context of the context what does "Strategic" actually mean?
Talk:Wikimedia Technical Committee/Charter
Infact "Cross-cutting" is also pretty vague and can be interpreted in many different ways within the Wikimedia world, what does it actually mean here?
Only with teams within the foundation?
As per the Architecture Committee Meeting on July 20th, the charter is entering the Last Call period.
If no new and pertinent concerns are raised and remain unaddressed by July 26, the charter will be enacted as the new basis of the committee's operation and authority.
For the on-wiki record, User:MZMcBride has objected here: https://lists.wikimedia.org/pipermail/wikitech-l/2017-July/088509.html. I'm not familiar enough with ArchCom to feel comfortable joining in the objection, but I think that there should be a carefully considered response to it.
He's pretty late to the party...
It is late, but we do plan to respond.
Of course we respond - what would be the point of a Last Call period otherwise? But he's raising fundamental concerns after weeks of bikeshedding over phrases. Took me a bit to shift gear ;) But you can find my response on wikitech-l now, see https://lists.wikimedia.org/pipermail/wikitech-l/2017-July/088514.html.
Doesn't that defeat the point?
+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.
In my role in the Community Engagement department, I've had the opportunity to observe various committees and how they work. From what I've observed, when "we" (the Foundation) alter the processes we use to make decisions, the expectations from communities we serve might stay the same, which results in misunderstandings. So this is where I'm coming from in my comments. I very much appreciate the opportunity to be able to weigh in on this discussion.
RFC process - According to Requests for comment page, in the RFC process "The developer community strives to achieve consensus." What does "consensus" mean for these discussions? It is unclear if the "consensus" needs to be reached by the committee or by the commenters. What does it look like if "consensus" is not reached? What happens if someone has a complaint on a decision? I believe RfC's work differently on Wikipedia and other projects, which typically end up in a Support/Oppose vote from commenters and are not necessarily done through consensus. I am wondering if or how RfC's are different/the same as they are done on other projects, and whether the name "RfC" is appropriate or not (I'm really not sure). This is similar to how the word "consultation" can mean different things to different people.
Membership - as a committee whose role is to support decision-making that affects an extremely wide audience (e.g. every single user), am I correct in noticing that most are staff of WMDE or WMF? What is the term length for members? How are new members added or removed? I also observe that most of the current committee members are part of the Technology Department, who report directly or indirectly to the CTO of the Foundation. I'm also wondering if or how committees that are entirely made up of staff might be renamed so its clear they are entirely made up of staff. A committee that includes staff as voters and that serves such a public function feels to me like a very different model from other committees (FDC, AffCom, ArbCom, etc.). These other committees have staff, but they are non-voting.
Hope you find this helpful. Thanks!
One thought about the RFC process is to call it the "MediaWiki RFC process" or the "Technical RFC process" to distinguish it from other processes.
Thanks for raising these questions. I'll take them to the committee for discussion.
As for membership, I believe you are correct that all current members are either WMF or WMDE staff. And currently there is a strong concentration in the Technology department.
Moving forward, the committee explicitly wants membership to be open to non-staff, and would prefer broader coverage within and beyond the organization--not because there are actual ties between departments or teams and the committee, but because people in other parts of the org, or outside it, are likely to have skills and knowledge that existing members don't.
Under the existing model, membership does not have explicit terms. The committee itself has complete discretion for adding or removing members. This charter proposal does not change either of those.
I believe the RFC process here works as it does with standards bodies: That input is solicited from anyone interested, but in the end, the decision is made by the committee.
Documentation outside the charter should clearly describe the RFC process in more detail. (It may already do so, but the committee will be reviewing and updating its process documentation as needed.)
The current wording at "Types of issues within scope" makes it sound like everyone has to get this committee's sign-off on a huge variety of changes, including potentially things like adding a new public or protected method to a class (since that's part of the "public interface" exposed to extensions). Is that really intended?
I imagine that this kind of consultation and sign off would be required only on "major changes" (subject to judgement of people concerned) vs. every small change that affects a public interface.
I think the intention is that if reviewers are concerned with a change/commit/bug they can bring it up to the committee as it is within their scope, but they aren't going to try and review every bug/commit. I agree that this could/should be written better.
ArchCom didn't have time to discuss this today, but plan to address it later.
@Anomie I indeed expect a large variety of changes to be in scope, but not a very large number. I don't think we'll want to be asked to sign off on every new public method on any class. I'd hope that developers have a good idea of when such an addition might be hard to undo, or strategy, or cross-cutting.
Of course, such an assessment may turn out to be wrong. There is no way around that.
I see the scope definition not as a hard test that can be applied to any change. It will often be a matter of subjective assessment and common sense.
I'd be wary of defining the scope very broadly and relying on common sense to reign it in. Common sense is notoriously unreliable.
I agree that "Common sense" would be too vague, especially when applied to just "anyone" who uploads a patch. We cannot (and should not) expect contributors to have the awareness of this guideline, and the expertise to apply it.
However, I think it is more than fair to demand this level of understanding from the group of people in charge of maintaining and reviewing the code. In other words: Those with CR+2 permissions. If someone with CR+2 permission on a repository does not know when a change requires more input or input from others, their access was likely granted too soon. As much as I dislike the thought of raising a barrier, we cannot afford distrust on Code Review. I'd rather have other reviewers (incl. myself) spend more time rapid-merging changes +1'ed by various specific people, then to have to go through post-merge because we can't trust their abilities. And besides, this is already an established policy: Gerrit/+2.
In reviewing the charter document just now, I see that the "Scope" section already describes the relationship to "Developers with +2 rights".
T-Comm members cannot monitor every possible repository commit or Phabricator task, so they must rely on the cooperation of others. Developers with +2 rights in any repo deployed at Wikimedia or included in MediaWiki tarballs, as well as managers or others who work with those technical projects, should watch for relevant issues.
@Anomie: Does that satisfy your concern? It essentially answers the question "Does every change require sign-off from ArchCom?" by saying: No, but every change does require sign-off from a reviewer.
That still doesn't tell me, as a reviewer, whether "common sense" is that any particular change should be reviewed by the committee or not. I'll wind up making my own judgments as to when to ignore the overbroad requirements stated here, as will other people, and our judgments will probably differ in some cases.
People with +2 rights are trusted to come to a sane conclusion when making up your own mind.
What's the alternative? An exhaustive list of precise criteria that can be evaluated objectively without judgement based on personal experience? I don't believe that's even possible.
We can try to be a bit more precise, sure; but subjective judgement from experience will always be a factor.
Being a bit more precise is my point. Right now you're saying "almost everything" and hoping people will narrow it down in practice.
Would it help to include an example or two that would not warrant involving the TC? If we could find a couple edge cases, and explain how one might decide which side they fall on, that could be helpful. On the other hand, that might not belong in the charter...but on the third hand, I'm not sure where else it would go.
@Anomie how do you suggest to limit the scope?
Scope creep is a thing, but it's usually countered by the fact that resources are limited. The committee isn't going to want a say in every detail, simply because it couldn't possibly handle the work load.
We removed the example (artifacts or public APIs) from the "Hard to undo" bullet. Hopefully this puts the emphasis back on "hard to undo", where it belongs, and avoids implying that every public API change would have to go before the committee.
Eventually, we envision creating documentation outside the charter, which would give more precise guidance, with examples, as to what changes would rise the level of deserving committee review.
@Anomie: Does that address your concerns? It remains a judgment call, but at least now we're (hopefully) not giving misleading guidance.
I noticed that "official mobile apps" were listed under T-Comm scope. I'm glad to see the inclusion of this as a potential scope area, although I was curious about the decision rights boundary around it. Would someone with familiarity please comment?
What do you mean by "decision rights boundary"? Are you referring to whether TechComm decisions would be binding upon the apps?
Not so much about decisions being binding (there's a general matter about binding versus non-binding that you called out rightly, addressed below), but rather the scope - which apps, and which parts of them. I think Kevin's readout in this topic notes that cross-cutting or strategic questions are the main thing of interest.
@ABaso (WMF): I just realized that I didn't specifically address your question about scope. You are correct that the committee is interested in strategic, cross-cutting, and hard-to-undo changes. Do you think the charter is clear enough on this point?
In addition to Adam's question, I'd like to see an enumeration of what the "official apps" are. There are several apps published by the Wikimedia Foundation account on Google Play that are not developed by staff, but are nevertheless official. Is the thinking that these would be included?
ArchCom discussed this today, and the consensus of those present was that the definition of "official" would be anything published under the WMF account, regardless of who did the development work.
That is not to say that the committee would want to micromanage the apps. Just that they would consider cross-cutting or strategic questions related to such apps to fall within their scope. The apps would be expected to comply with committee decisions and policies.
Does that make sense?
@KSmith (WMF) Yes, it does. These apps are official from the user's perspective since they are published by the Foundation [1], so covering them in this manner makes sense. I would expect that the volunteer developers would welcome helpful and constructive input from the TechCom where relevant. :-)
[1]: I mean "published" in the sense that the author of the app is stated as "Wikimedia Foundation" in Google Play. All credit for the app, of course, goes to the volunteer developers.
The charter as currently written seems very reactive: people who have a plan on how to evolve the technology landscape write an RfC, and TechCom approves/rejects/amends, but has no role of initiating and driving changes on its own. While the lack of resourcing power understandably limits options in this regard, and a more limited role might result in healthier power dynamics as well, it still seems like a missed opportunity to put the ten most adept and respected members of the technical community in the same room, and then not use them for anything other than reviewing submissions. Wouldn't it be a natural role for ArchCom to (in cooperation with those who would provide the resources) manage some kind of roadmap/technical strategy? We have recently recognized the problems that stem from MediaWiki not having a roadmap, but that's very much true for the wider technology stack as well.
The charter allows RFCs to be initiated by committee members, so it doesn't rule out being proactive. Various members have expressed a desire to be more proactive, and to work more closely with WMF managers who own the budgets. I guess the question is whether being proactive should be described more specifically in this document.
I'll raise this with the committee, along with other new topics on this page. Thanks!
This is one of the issues that trouble me the most as well. I've often raised that, including at the ArchComm meeting I joined back in December. RFCs initiated by commitee members don't really count IMHO, as anyone can initiate RFCs, so presumably this wouldn't be done with a T-Comm hat.
I'll echo @Tgr (WMF) in that we need for an architectural roadmap/technical strategy and that's something I would definitely expect the T-Comm to lead, as a group, not just opine on.
I think RFCs initiated by committee members do count, as anyone can submit roadmap/technical strategy RFCs, and the RFC process is suitable for policies and strategy discussions, I believe.
I think the important point is that T-Comm should see it is one of it's key tasks to set policy (backed by strategy). So committee members (or the committee as a whole) should be expected to propose such RFCs, or initiate other deliberation processes as appropriate for setting policy.
What kind of wording would be helpful to make this point more clear? At the moment, we have "...make decisions and set policies regarding high-level technical issues" and later "Anyone (including committee members) can propose a new policy or guideline through the RFC process". Perhaps that can be made stronger, e.g. "the committee will propose new policies or guidelines via the RFC process"?
I understand the difference between "reactive" and "proactive", however I also believe that one of the outcomes of this charter should be to eliminate this difference. Meaning, that there couldn't be either. I'll address them from different perspectives.
Problems
In the past, major changes, and changes that affect multiple products/features, could sometimes happen without an RFC. There was no CTO and no enforcement. At the same time, it feels wrong if ArchCom would (proactively?) interfere with internal team practices. E.g. Whether resolving tech debt in a product or feature is a priority shouldn't be our call. On the other hand, if it starts to affect the code's overall stability, security, performance, or causes problems with other areas (cross-cutting), it becomes our concern - in so far that the product would have essentially diverged from its previously reviewed architecture.
This has always felt like a paradox to me. I hope requiring ArchCom involvement going forward (as enforced by CTO) will prevent this.
Product backend
The feature roadmap of end-user products is not in our scope, however their technical requirements are. As such, I don't think there will be a strong need for us to proactively propose specific major changes to individual products. I do believe we should be proactive, but not by going into individual products - rather, by sharing and justifying our intentions through general guideline documents that set the overall direction.
On a small scale, this would be proactively adopted by developers (enforced by project maintainers through Code-Review, perhaps with ArchCom as last resort).
On a larger scale, requiring ArchCom involvement would naturally apply it for any new proposals. Even proposals that don't seem to immediately relate to overall direction (e.g. new feature) may still require changes in order for the end-result to still be a stable, consistent, and performant production environment.
By applying the direction only through proposals, we keep ourselves on-track to serving the needs of Product, and naturally avoid scope overlap with product management by only proposing major changes when there is a specific need. For example, if RESTBase hadn't existed yet, perhaps ArchCom would've blocked Page Previews (Popups) as it didn't perform to acceptable standards without it. How it goes from there depends on available resourcing, product prioritisation, and coordination between the various Product (Audiences) and Technology teams.
Infrastructure
Long-term planning that doesn't directly impact or enable something tangible. While possible, it's unlikely an existing RFC would exist where it'd be appropiate to block on such change. For example: Kubernetes for scaling of production apps, Using Thumbor for image thumbnails, etc.
Are these in ArchCom scope? Undoubtedly, Yes. And when such change comes up, it should use the RFC process.
But could ArchCom members (proactively) create an RFC for such things? How does that deal with the resourcing problem?
Usually with RFCs, the resourcing is on the author. If it doesn't happen in the end, no harm is done. The notable exception is RFCs for establishing guidelines and overall direction. Often, such RFCs apply retroactively and require involvement from many teams to go through existing code over time. I suppose the same could be done for infrastructure direction. I think it would be natural for such infrastructure direction RFCs to not be too specific, but overall I think it makes sense for ArchCom to be involved in this area, even proactively. (More about this point at Topic: System vs. software architecture.)
The committee added a sentence to the purpose saying that they also work at the level of vision or high-level direction. That opens the doors for working more proactively.
The committee also felt that a "roadmap" would be the domain of a product manager.
I believe I know what the definition of "strategic" encompasses, but for the sake of clarity, what was the intent of this keyword?
ArchCom didn't have time to discuss this today, but plan to address it later.
Anything making it significantly harder or easier to reach long term goals should be considered "strategic".
The committee decided not to define "strategic" in the charter. Presumably if this becomes a problem, they can either amend the charter, or publish external clarifying documents as needed.
Reading the charter it is unclear whether documentation is within scope or out of scope in this new charter. "Documentation" is admittedly vague. Let's say (improvements welcome):
- Documentation in source code. Expectations, requirements, quality criteria...
- Technical documentation describing the software within scope. Architecture, extension pages...
- Technical documentation describing how to contribute to the software within scope.
I think doc standards in the code would be in scope, though code docs themselves probably not. Architecture docs regarding decisions taken by the committee should be - in fact, it would be nice if every RFC that proposes some architectural change would be combined with the document describing the resulting design, which can be used both by implementers and other developers.
I think guidelines and policies for documentation in the source code, and mid-level documentation (hopefully) maintained in the code repo, are definitely in scope. Installation instructions and such probably too. Documentation for user-facing features - not so much.
Community processes, and documentation of such - not authority, though the committee will probably have opinions and suggestions.
I agree with the others here. In scope seems primarily documentation as written and intended for developers and site-admins that contribute to, or use, the software as customer of MediaWiki. For those it would be appropiate for ArchCom to consider introducing new standards or guidelines.
Documentation for other purposes or about other topics, including those in the form of wiki pages, not in our scope.
However, any technical requirements for such documentation, would be in-scope again. For example if a new domain name, service, or software feature is desired. We should review the proposed implementation there, purely from a technical perspective.