Talk:Wikimedia Technical Committee/Charter

Scope?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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? Anomie (talk) 14:09, 30 May 2017 (UTC)

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. SSastry (WMF) (talk) 16:45, 30 May 2017 (UTC)

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. Legoktm (talk) 16:54, 30 May 2017 (UTC)

ArchCom didn't have time to discuss this today, but plan to address it later. KSmith (WMF) (talk) 22:58, 31 May 2017 (UTC)

@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. Daniel Kinzler (WMDE) (talk) 18:47, 15 June 2017 (UTC)

I'd be wary of defining the scope very broadly and relying on common sense to reign it in. Common sense is notoriously unreliable. Anomie (talk) 11:21, 16 June 2017 (UTC)

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. Krinkle (talk) 18:30, 19 June 2017 (UTC)

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. Anomie (talk) 13:33, 20 June 2017 (UTC)

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. Daniel Kinzler (WMDE) (talk) 16:05, 20 June 2017 (UTC)

Being a bit more precise is my point. Right now you're saying "almost everything" and hoping people will narrow it down in practice. Anomie (talk) 16:44, 20 June 2017 (UTC)

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. KSmith (WMF) (talk) 17:36, 20 June 2017 (UTC)

@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. Daniel Kinzler (WMDE) (talk) 13:35, 19 June 2017 (UTC)

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. KSmith (WMF) (talk) 21:08, 26 June 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Intended expertise of new members?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The Technical Committee intends to expand to around ten members. Historically, all the members have been senior engineers with tenure with the movement, knowledge of MediaWiki, and general technical expertise. Given the change in scope, what is the intended expertise of the new members of the committee?

Howie Fung and Terry Chay, our former directors of product development and features engineering respectively, often talked about a "rule of three"; no major decisions should be taken without a discussion with at least one engineer, one designer, and one product manager present. The rule of three is obviously an ideal that has plenty of exceptions, but it serves as a helpful guiding principle to keep things in balance, and ensure nobody is excluded.

The highly technical nature of this committee warrants the majority of its members being senior engineers. That said, the decisions the committee makes, and the problems it approaches, will strongly influence and change our product roadmaps. I believe this warrants including non-engineers in the committee, so that no one discipline has undue influence over the direction the organisation takes. Dan Garry, Wikimedia Foundation (talk) 15:01, 30 May 2017 (UTC)

I definitely remember some IRC meetings where the conversation would have been much better if we had a PM to discuss specific issues with. Same with members of the Operations team as well. Legoktm (talk) 17:37, 30 May 2017 (UTC)

ArchCom discussed this today, and reaffirmed that this is intended to be a technical committee addressing technical issues. The committee would of course seek input from product managers and people in other disciplines, wherever it would make sense.

Members acknowledged that there are gray and overlapping areas. An analogy was made to having +2 rights: Those who have them are trusted to know what they don't know, and to refrain from misusing their rights. Similarly, the committee should know what is beyond their sphere, and to avoid setting policies that would be problematic for other disciplines or organizations.

The committee wants to focus on *how* things get built, not on *what* gets built.

I hope I captured the essence of the conversation, and I hope it helps clarify the thinking. KSmith (WMF) (talk) 22:58, 31 May 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Why is the committee non-binding?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Doesn't that defeat the point? Legoktm (talk) 16:16, 30 May 2017 (UTC)

+1 I would like to hear more about this question as well. EGalvez (WMF) (talk) 16:35, 30 May 2017 (UTC)

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. SSastry (WMF) (talk) 17:11, 30 May 2017 (UTC)

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. Legoktm (talk) 22:24, 30 May 2017 (UTC)

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. BWolff (WMF) (talk) 17:35, 30 May 2017 (UTC)

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? KSmith (WMF) (talk) 22:52, 31 May 2017 (UTC)

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. EGalvez (WMF) (talk) 22:38, 2 June 2017 (UTC)

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. Faidon Liambotis (WMF) (talk) 00:57, 14 June 2017 (UTC)

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. KSmith (WMF) (talk) 15:54, 14 June 2017 (UTC)

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. Daniel Kinzler (WMDE) (talk) 18:12, 15 June 2017 (UTC)

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:

1. A decision, approval, or disapproval, for which they expect compliance, or
2. An opinion, which they expect to be heard and understood, but not necessarily followed KSmith (WMF) (talk) 21:17, 26 June 2017 (UTC)

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. KSmith (WMF) (talk) 23:46, 12 July 2017 (UTC)

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. Krinkle (talk) 01:18, 13 July 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

What's the definition of "strategic"?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I believe I know what the definition of "strategic" encompasses, but for the sake of clarity, what was the intent of this keyword? ABaso (WMF) (talk) 16:43, 30 May 2017 (UTC)

ArchCom didn't have time to discuss this today, but plan to address it later. KSmith (WMF) (talk) 22:58, 31 May 2017 (UTC)

Anything making it significantly harder or easier to reach long term goals should be considered "strategic". Daniel Kinzler (WMDE) (talk) 18:48, 15 June 2017 (UTC)

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. KSmith (WMF) (talk) 23:37, 12 July 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Inclusion of mobile apps

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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? ABaso (WMF) (talk) 16:47, 30 May 2017 (UTC)

What do you mean by "decision rights boundary"? Are you referring to whether TechComm decisions would be binding upon the apps? Legoktm (talk) 22:25, 30 May 2017 (UTC)

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) (talk) 11:33, 2 June 2017 (UTC)

@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? KSmith (WMF) (talk) 21:11, 26 June 2017 (UTC)

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? Dan Garry, Wikimedia Foundation (talk) 14:30, 31 May 2017 (UTC)

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) (talk) 22:45, 31 May 2017 (UTC)

@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. Dan Garry, Wikimedia Foundation (talk) 09:59, 1 June 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

"T-Comm"

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

(https://people.wikimedia.org/~gwicke/bikeshed.svg)

It just sounds weird to me. I think something like "TechComm" is more in line with how we normally abbreviate our committees. I do like the name "Technical Committee" overall, especially given the prior precedent (Technical committee) Legoktm (talk) 16:58, 30 May 2017 (UTC)

+1. I had the same thought about T-Comm as a name. SSastry (WMF) (talk) 17:12, 30 May 2017 (UTC)

Pronouncing "Tech Comm" is a bit awkward. It usually either ends up as Teh-comm or Tech-a-Comm, depending on whether you run the words together or not. That was the reason for going with T-Comm, but I'm not aware of anyone feeling strong about it. [Citation: I led/facilitated the drafting of this document.] KSmith (WMF) (talk) 18:46, 30 May 2017 (UTC)

Commitee is typically shortened to Com in the Wikimediaverse (cf. ArbCom), so I'd prefer TechCom. TechCom is not hard to pronounce, in my dialect at least. :-) Dan Garry, Wikimedia Foundation (talk) 10:05, 31 May 2017 (UTC)

Yeah, I always found "Com" rather than "Comm" confusing, but if "Com" is an established norm, it would probably make sense to follow it. KSmith (WMF) (talk) 19:20, 31 May 2017 (UTC)

ArchCom discussed this today, and nobody feels strongly that T-Comm (or TechCom) is the ideal name. Apparently at other orgs, the Technical Committee is often abbreviated as "TC". So suggestions now include: TC, WTC, WMTC, and WikiTC. This remains an open topic. KSmith (WMF) (talk) 22:41, 31 May 2017 (UTC)

I would strongly recommend avoiding WMTC; this kind of abbreviation is typically used only for chapters (cf. WMDE, WMUK, etc.) and could cause significant confusion. I would weakly recommend avoiding WikiTC; wiki is a generic term for sites that allow collaborative modification of content through a browser, and this is not the technical committee for any and all kinds of wikis.

Although I still prefer TechCom, all other listed options seem sensible. Dan Garry, Wikimedia Foundation (talk) 10:07, 1 June 2017 (UTC)

Good point about the "WMxx" pattern. Aside from avoiding confusion with chapter abbreviations, it also seems more consistent with our existing short-names and abbreviations not to include "Wikimedia" in the abbreviation. E.g. As short form one would use "TC" or "Wikimedia TC". Krinkle (talk) 15:32, 19 June 2017 (UTC)

I think the main problem with TechCom is that it's hard to pronounce, especially for English speakers. In written form, I rather like it. But it's easy to confuse with ComTech (Community Tech)... Daniel Kinzler (WMDE) (talk) 10:57, 1 June 2017 (UTC)

TechCom gives you a fighting chance to reverse-engineer what it means even if you are not someone who hears it every day; T-Comm not so much. Tgr (WMF) (talk) 09:51, 2 June 2017 (UTC)

I want J.A.M. Justified Ancients of MediaWiki. Daniel Kinzler (WMDE) (talk) 18:50, 15 June 2017 (UTC)

The full name is the Wikimedia Technical Committee, and the nickname is now TechCom, rather than T-Comm. KSmith (WMF) (talk) 21:01, 26 June 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Questions about governance & decisionmaking process

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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! EGalvez (WMF) (talk) 22:18, 2 June 2017 (UTC)

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. EGalvez (WMF) (talk) 22:23, 2 June 2017 (UTC)

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. KSmith (WMF) (talk) 01:14, 3 June 2017 (UTC)

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.) KSmith (WMF) (talk) 23:52, 12 July 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Documentation, in scope or out of scope?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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. Qgil-WMF (talk) 07:32, 8 June 2017 (UTC)

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. Smalyshev (WMF) (talk) 23:25, 8 June 2017 (UTC)

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. Daniel Kinzler (WMDE) (talk) 18:40, 15 June 2017 (UTC)

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. Krinkle (talk) 16:03, 19 June 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Code Review SIG in scope?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

In T129842, @Qgil-WMF suggested that a Code Review SIG (Special Interest Group) could fall within the scope of the new Technical Committee. I'm mentioning it here, because this page is my primary list of topics to raise with archcom when discussing the charter with them, and I didn't want to lose this thought. KSmith (WMF) (talk) 16:17, 8 June 2017 (UTC)

I've always thought of architecture and team/guild/division doing architecture (which I imagine T-Comm is about) as something best happening before the code gets written. Of course, the reality is often different, and the development process iterations often blur the lines, but in extremely idealized picture, that's what it seems to me. With that in mind, I'd say reviewing of specific code should be rather exception than a rule, and mostly in cases where that code is related to some larger architectural concern or involves some wide-reaching decisions (even then, ideally, the concerns should have been identified and discussed in advance, but we all know ideal doesn't always happen :). Otherwise, it should more concern with bigger picture decisions, and I think CR SIG, with more narrow code-specific focus, should be separate. Which of course does not preclude same people being of both, and two groups cooperating and communicating as needed. Smalyshev (WMF) (talk) 01:08, 10 June 2017 (UTC)

TechCom relying on the CR SIG on impementing pervasive architectural changes (e.g. there is an accepted dependency injection RfC, the platform support was created, but few things actually make use of it - how to leverage code review to change that?) or culture changes (e.g. no new code without test coverage) seem reasonable, but the current wording of the charter ("The scope does not include ... team methodologies ... and other social factors") seems to preclude it. Tgr (WMF) (talk) 12:31, 12 June 2017 (UTC)

I thought "The scope does not include ... team methodologies ... and other social factors" is more about things like "do we use scrum or kanban" or "how often standup meetings should happen" and such. Something like implementing DI would be IMHO definitely in scope, and I would see T-Comm as the body to develop some kind of guidelines (see the sister topic on docs - that's the kind of docs T-Comm should be doing) of how to properly implement DI and then SIG would rely on these to review specific code. Same for tests - T-Comm writes (and implements the process needed to gather consensus, as required) the guidelines for what we require test-wise, what is tested, what is not, what we accept, what we "accept for now but with FIXME", what we reject, etc. - and SIG would apply these on specific code. Of course, in both cases T-Comm would solicit feedback from people in SIG and take it into account. Smalyshev (WMF) (talk) 19:12, 12 June 2017 (UTC)

I don't think the charter precludes the committee from promoting the use of DI, making suggestions on how to improve the code review process prevent "bad" code from being merged, or run hackathon sessions to promote DI. The charter just says that the committee doesn't have any final authority on the code review process, or team processes, or the code of conduct.

The committee would have the authority to set architecture policy to the effect that all new code must use DI, and code that introduces global state must not be merged. If that policy went ignored, it would be the CTO's job to take steps to enforce the policy. Daniel Kinzler (WMDE) (talk) 18:38, 15 June 2017 (UTC)

The committee seemed to feel that managing a SIG would not fall within its scope. It would happily work with a group that had overlapping interests, such as code review or technical documentation. I'll post back on the phab task as well. KSmith (WMF) (talk) 22:42, 29 June 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Wikimedia vs. MediaWiki community

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The Wikimedia technical community and the MediaWiki community have a large overlap but are still not quite the same. Wikimedia uses various tools not related to MediaWiki (ORES, RESTBase, puppet etc), which are rarely used by other users of MediaWiki (and little effort goes into making that kind of usage easy). On the other hand, MediaWiki-based websites not hosted by some Wikimedia group are categorically outside the Wikimedia mission (at least according to the current interpretation), even if they do some or all of open, collaborative, free-content, educational. Many widely-used and architecturally complex MediaWiki extensions/libraries, and even some parts of core, are irrelevant to all Wikimedia-hosted sites but highly relevant to most third parties.

The old ArchCom seemed to position itself as a governing body of the MediaWiki community (for some very limited value of "governing"). The new charter clearly claims authority over the non-MediaWiki part of Wikimedia (and it's a very reasonable thing to do); it's less clear what happens with the non-Wikimedia parts of MediaWiki. Do those fall under "non-production technologies" (and so outside of scope)?

De facto that seems to not be the case as we just had an ArchCom RfC about the Postgres DB connector in MediaWiki. It's not very clear what's in and what's out, though. Should (or must?) someone rewriting the installer ask TechCom? How about someone doing major changes in Semantic MediaWiki? Tgr (WMF) (talk) 12:48, 12 June 2017 (UTC)

Our Puppet tree definitely counts as software in my book, but I doubt the intention was for the Technical Committee to include it in its scope. I think this is excepted from the wording that says "that serves Wikimedia users". Your other examples, ORES and RESTBase are good ones, though; I think the intention is to include them in the scope? You're definitely raising some good points in general :) Faidon Liambotis (WMF) (talk) 00:40, 14 June 2017 (UTC)

It's quite hard to draw a hard line, so let me just give my personal interpretation for the examples given.

• ORES, RESTBase: definitely in scope! For ORES, we have little expertize though.
• puppet: I'd say yes - not the nitty gritty, but if we discuss whether we want to replace puppet with something else, T-Comm should be involved. I consider puppet part of our production environment, btw.
• Rewriting the installer (which is not used by Wikimedia): in scope, because it's part of MediaWiki core; but only relevant if the changes are strategic, cross-cutting, or hard to undo. E.g. changing the parser to dynamically download extensions and run composer would count as a big enough change to warrant T-Comm involvement. An UI overhaul wouldn't. Internal refactoring may or may not want an RFC.
• Postgres DB connector: in scope, because it's maintained as part of core. Dropping it would be a strategic decision, so also in scope.
• Semantic MediaWiki: that does not affect any software maintained by WMF, nor any site run by WMF, so I would consider it out of scope. Though if SMW maintainers filed an RFC with the committee, I think we should still run it through the process. I just don't think the committee can make binding decisions about SMW. Daniel Kinzler (WMDE) (talk) 18:32, 15 June 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Reactive vs. proactive

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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. Tgr (WMF) (talk) 13:00, 12 June 2017 (UTC)

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! KSmith (WMF) (talk) 16:50, 12 June 2017 (UTC)

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. Faidon Liambotis (WMF) (talk) 00:43, 14 June 2017 (UTC)

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"? Daniel Kinzler (WMDE) (talk) 18:22, 15 June 2017 (UTC)

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.) Krinkle (talk) 18:00, 19 June 2017 (UTC)

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. KSmith (WMF) (talk) 23:40, 12 July 2017 (UTC)

The committee also felt that a "roadmap" would be the domain of a product manager. KSmith (WMF) (talk) 23:41, 12 July 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

System vs. software architecture, "software"

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

One of the reasons ArchComm has always felt a little out-of-scope and honestly, a little boring :) for us opsens is that it has traditionally focused on very esoteric software architecture decisions (e.g. dependency injection), and less so on the broader system/platform architecture of our software stack and its application in production.

There are obviously counterexamples (the SOA RFC and the Thumbnail RFC from 2013 come to mind) but this context-switching between vastly different abstraction layers of our stack and level of detail have made the committee a bit impossible to follow or join. It has also resulted in at least the appearance being that ArchComm was not really interested in that sort of level of detail and thus a lot of the broader architectural work happening outside the committee -- and, frankly, in my opinion, with most committee members even unaware of the changes in that space.

Is that something that you have thought about and if so, what is your opinion on this? (This won't be a surprise either, I've discussed this with a number of you already before) Faidon Liambotis (WMF) (talk) 00:50, 14 June 2017 (UTC)

We have indeed thought about this, and the intended solution is "recruit more people with a wider range of expertise". Adding an ops person to the committee is high on the wish list - after all, the committee used to have an ops member.

We are currently in the process of considering new members to invite. Daniel Kinzler (WMDE) (talk) 18:15, 15 June 2017 (UTC)

@Faidon Liambotis (WMF): I agree system architecture is in-scope. See also Talk:Wikimedia Technical Committee/Charter#c-Krinkle-2017-06-19T18:00:00.000Z-Tgr_(WMF)-2017-06-12T13:00:00.000Z. With regards to following/joining, I hope this is addressed by improving communication.

Such RFCs would already be tagged with #Operations (and any more specific tags). They'd also be in the status update on Wikitech-l. And in general, I don't think it would make sense to discuss such RFC without input from opsen (regardless of whether or not we'd succeed in recruiting operations members to the committee). For example, by pinging relevant members from the conversation on Phabricator, informally over IRC, inviting to a hangout meeting when the committee discusses the RFC, and by announcing and inviting you to the public IRC meeting when a meeting about the task has been scheduled.

What kind of communication would you prefer for hearing about such proposals? We could also announce them as part of SoS. Krinkle (talk) 18:12, 19 June 2017 (UTC)

You're raising a semi-related issue that I've had with past ArchComm decisions and that I have mentioned before but one that it's probably worth surfacing again: "silent approval".

I recall at least one ArchComm decision that was made in the absence of all the affected teams (like us), with the assumption being made that since we weren't present in the IRC meeting, we were OK with the proposal. Granted, the last occurence of this I can recall is years ago and it may just have been an isolated incident, but perhaps it's worth calling it explicitly: if a team is affected, ArchComm needs to actively seek involved parties' input, and don't make any decisions unless the affected parties have been involved, rather than just go ahead unless someone objects. The incident I recall was before "last calls" and emails to wikitech-l were instituted, so this may have helped already quite a bit and may not be a problem in practice nowadays, which is why I hesitated to make it yet another topic in this conversation before.

As for ways to communicate with ops, or any other affected team for that matter… your ideas make sense to me. I'm not too worried about figuring that part out, as long as the intention is there :) Faidon Liambotis (WMF) (talk) 13:59, 20 June 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Last Call for Comments

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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. Daniel Kinzler (WMDE) (talk) 12:49, 20 July 2017 (UTC)

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. ↠Pine (✉) 17:37, 20 July 2017 (UTC)

He's pretty late to the party... Daniel Kinzler (WMDE) (talk) 18:32, 20 July 2017 (UTC)

It is late, but we do plan to respond. KSmith (WMF) (talk) 22:10, 21 July 2017 (UTC)

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. Daniel Kinzler (WMDE) (talk) 19:27, 23 July 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

"TechCom will work closely with teams within the foundation to ensure alignment between the architectural vision and product development."

Only with teams within the foundation? ·addshore· ^{talk to me!} 14:01, 20 December 2018 (UTC)

"Strategic" needs clarification

I think the term "Strategic" as used in the charter needs some clarification. In the context of the context what does "Strategic" actually mean? ·addshore· ^{talk to me!} 10:16, 21 December 2018 (UTC)

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? ·addshore· ^{talk to me!} 10:18, 21 December 2018 (UTC)