Talk:Technical decision making

"Technical Decision Team" definition

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.

---

There's one mention of "Technical Decision Team" in the page; is that the same as the "Decision Team"? SBMhaol (WMF) (talk) 10:55, 29 October 2020 (UTC)

Thanks it is the same thing and I changed it to "Decision Team" KChapman (WMF) (talk) 00:29, 5 November 2020 (UTC)

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

Page improvement suggestions

Hallo! I was looking at the page, and wondering about some potential clarifications...

1. In the Summary, it says "This is an evolution of the existing TechCom process". -- Is there anything that could link to, to clarify the existing process? Perhaps Wikimedia Technical Committee/Charter#Process ?
2. In the Summary, it might help to have some minimal bolding of keywords, and/or additions to the start of bulletpoints like: What When Who How (for the 4 key objectives). For ease of skimming.
3. In the Summary, it mentions "Templates" as being a key outcome, but then "Template" is only mentioned twice below. -- Could we add more details, or links to examples/napkin-sketches, into section "1 Decision Statement Overview (1 week)" ? Perhaps that just means the #Artifacts section?
4. Throughout, it would be helpful to have more internal #page-anchor links, pointing to the sections which cover new Terms in more detail. E.g. mentions of "Technical Decision Forum" elsewhere should link to the #Technical Decision Forum section (with "#" showing for clarity on target).
5. Suggestion: It currently doesn't specify where the content for each decision should be created. I suggest adding clarifications on where they should be placed/located; I.e. ideally on mediawiki-wiki (but where exactly?), or in a phab-task description, but not in a gdoc or pdf. -- That also means the current artifact templates (PDFs) need to be checked for whether they copy&paste successfully into [wiki/phab]; and if not, converted into wiki-pages.

Hope that helps. Quiddity (WMF) (talk) 21:17, 6 November 2020 (UTC)

The reference for the current RFC process should be Requests_for_comment. DKinzler (WMF) (talk) 10:23, 10 November 2020 (UTC)

Technical Decisions and Prototyping

Hi!

I was reading this document and I have a question about the prototyping stage of the process. Does this process analyze whether a previous solution to solve a problem has been attempted? I think it would be a good idea to add somewhere in the decision-making process if there have been prior attempts to solve the problem and the technical obstacles that solution faced. I believe that would better inform the decision-making process.

Finally, I think "bi-weekly" might be confusing to some people (starting by me). Does that mean twice a week, or once every two weeks? I see that the image says once every two weeks, but when I see bi-weekly, I always get confused. SCardenas (WMF) (talk) 04:43, 10 November 2020 (UTC)

I updated the language to avoid using bi-weekly. KChapman (WMF) (talk) 02:37, 17 November 2020 (UTC)

Seconding the point about analyzing previous solutions - in my experience, that always turned out to be tremendously useful when attempted.

Analyzing external solutions (e.g. how other open-source projects handle the same technical issue) is also extremely useful and rarely done. Tgr (talk) 07:30, 16 November 2020 (UTC)

I think updating the template can help with this issue of not looking at existing solutions. When I consolidate the feedback I'll include it. KChapman (WMF) (talk) 02:38, 17 November 2020 (UTC)

Ownership and Herding Cats

In the discussions we have had about this process among TechCom members, a complex of questions around actually driving decision making has stood out to me. From my experience with the RFC process, there is two kinds of issues that make it hard to drive a decision process: unclear ownership, and lack of attention.

While the proposal sets out to resolve both these issues, it's not quite clear to me how that is going to work in practice.

Regarding the first issue: If I understand correctly, the idea is that a Decision Team is identified and will be accountable for the decision to be made and acted upon. The document doesn't say however how that is done, or who would do it. It's easy enough if there already is a team that wants to do something. But quite frequently, a problem is identified by a group that is affected, but cannot resolve the problem. See for example RFC: Unify the various deletion systems - the current way MediaWiki handles deletion leads to confusion, data corruption, and performance issues. This has been known for many years, as summarized in this RFC and the ticket it links. But so far nobody stepped up to create and resource a group of people who would be responsible for coming up with a solution. How would the new process fix this issue? How would phase 0 work for this RFC?

Similar issues exist with respect to establishing and changing policies. Do I understand correctly that individual teams will have to take stewardship of the existing development policies? How do we make sure that none are left orphaned?

Regarding the second issue: If I interpret the proposal correctly, the technical forum will consist of about 30 people, which should read, investigate, and react to any communication on the forum within a week. If any of them is on vacation, busy, ill, or otherwise unavailable, the should have assigned a replacement.

From my experience with facilitating communication on complex topics, this is a sizable herd of cats to manage. Who is going to keep track of who is even on the forum at any given time? Who will make sure the relevant people have had time to look into new proposals or questions? One week is a very short time for reacting to a potentially complex question requiring investigation, reading up, asking around. And people tend to forget to say (or even realize) when they are currently unable to follow up in a timely manner.

Once we have started to actively use this process, we are likely to have a couple of decisions in flight at any given time. It seems to me that just managing membership and communication, ensuring that the process is followed and timelines are held, is going to be a full time job. Who will be doing that job? It seems clear to me that this will have to be a dedicated person. This is not really something that can be done on the side, or a duty that can be rotated. That generates too much friction, I think. DKinzler (WMF) (talk) 10:46, 10 November 2020 (UTC)

For long standing problems that have not been resourced someone would fill out: File:Template Decision Statement Overview.pdf My hope is that by guiding how the problem statement is defined in a template it will help align the work better to movement goals. If those that making resourcing decisions aren't convinced though it isn't going to be able to move forward though. No different than now.

How are development policy proposals currently made? Does TechCom make them or do other folks typically propose them to TechCom?

The idea of the forum is to make it easy to rotate representatives from teams off of it. They only need to confirm the problem statement and the stakeholders in a week time. The consultation will happen over a long period of time.

Yes I agree that managing this needs to be resourced by a Project or Program Manager. KChapman (WMF) (talk) 02:37, 17 November 2020 (UTC)

> How are development policy proposals currently made? Does TechCom make them or do other folks typically propose them to TechCom?

About half and half, I would say.

> The idea of the forum is to make it easy to rotate representatives from teams off of it. They only need to confirm the problem statement and the stakeholders in a week time.

My experience is that this is hard to achieve without a lot of active facilitation. DKinzler (WMF) (talk) 20:07, 9 December 2020 (UTC)

Comments and questions

I took a pass through the document and have a number of questions and comments. It seemed easier to comment in-line, so I converted it to a google doc; please ignore the imperfect formatting. I don't know if it is permitted to share docs on the Wikimedia Google space with the public, so it is restricted to WMF staff for now. Link: https://docs.google.com/document/d/10KH3zBoZ-xkR91NXFRnOtWVx8ixpULYeg66TB_kGXQ0/edit?usp=sharing The comments and questions are intended to either get clarification or discussion going about what might be points for improvement in the process. What I would want out of a new process is: to make it resourced, to make sure no one feels blocked or aggrieved after going through the process for a decision, to enable everyone to get their work done, to get good decisions made, and to really include as many people over time as possible, so that we all (if we want) gain some ability in this area, so please read my comments with that context in mind. Thanks! ArielGlenn (talk) 23:52, 13 November 2020 (UTC)

Thanks for the input. I've asked some questions in the comments. Anything I didn't comment explicitly on I didn't have a question but will consider your input when revising the proposal. KChapman (WMF) (talk) 02:28, 17 November 2020 (UTC)

GreatI I saw them and replied to a few and have some thinking and reading to do on others. ArielGlenn (talk) 23:21, 18 November 2020 (UTC)

Alignment with the Movement Strategy

The movement strategy recommendation Coordinate Across Stakeholders asks for more coordinated but also more equitable technical decisionmaking. On a high level it says "We will enhance existing and establish new organizational structures and practices that ensure comprehensive information exchange, learning, knowledge transfer, and networking opportunities with all Movement stakeholders as well as partners who share our vision. By coordinating resources and ensuring decision-making is equitable, these structures and practices will facilitate better engagement, faster reaction, and greater support across our Movement." More specifically, it says "Create a Technology Council to establish processes for introducing new functionalities onto Wikimedia platforms and tools. The aim is to improve communication between staff developers and other technical contributors to better network, coordinate innovation, provide and obtain support, and foster input on decisions and resource allocations that impact communities." While the implementation of this recommendation if probably a ways off, I think it's reasonable to expect changes to TechCom (the closest precursor we have to the proposed Technology Council today) to move us in this direction.

That recommendation doesn't really specify what "ensuring decision-making is equitable" means; there is another recommendation focused ont that issue, Ensure Equity in Decision-making (which in turn doesn't say anything specific about technology), according to which "Our Movement is composed of communities, individuals, and organizations from all over the world. By sharing accountability and responsibility as well as ensuring equitable opportunities for participation in decision-making and resource allocation, we will empower and represent all Movement stakeholders and have mechanisms to ensure all decisions that affect them are legitimate. All Movement stakeholders will have the mandate, knowledge, and resources to be present in any decision-making process that affects them, make decisions, and have meaningful input on related issues including opportunities to access resources. .... Movement structures will be adapted and created to ensure all Wikimedians can have their interests and experiences represented in decision-making." So in that light, I would expect a replacement for TechCom to err on the side of giving more opportunities for movement members who are not Wikimedia staff for participating in the actual decision-making, and include some kind of representation mechanism.

It seems to me that this proposal is largely going in the opposite direction. ArchCom (TechCom's predecessor until 2017) was relying on the consensus of the technical contributor community as a decisionmaking method ("The Wikimedia Architecture committee strives to ensure the Wikimedia development community builds and deploy increasingly excellent software on the Wikimedia production cluster in a consensus-oriented manner"; TechCom itself was more conflicted about it but its charter still states that "Within Wikimedia, technology leadership is not vested in a single individual, but in the technical community.", This proposal, in contrast, seems to centralize all decisionmaking power in the hands of the CTO and CPO - step 4, executive review, of the "Technical Decision Making Process" is the only actual decision making step, every other one is consultative, apart from decisions made by the Decision Team, who are the initiators of the project (ie. the same people who would make a decision if we had no Technical Decision Making Process at all and everyone would just do whatever they want).

As such, this doesn't seem like a decisionmaking process to me, apart from the executive review - it is a process for ensuring the team embarking on some project have all the information they need, including stakeholder opinions and opinions from various areas of expertise, and for ensuring that the thinking of that team is well documented. I think having a better defined and better resourced process for that would be tremendously useful - but it does not play the same role that TechCom did, and while it moves us towards many of the aspirations of the movement strategy (it would certainly improve information exchange and knowledge transfer), that should not come at the expense of equity. Tgr (talk) 07:27, 16 November 2020 (UTC)

Thinking more about it, this feels a bit like the combination of two separate proposals: one for establishing a better defined process, with more explicit expectations and better resourcing, for gathering feedback and making, documenting and reviewing decisions; and one for replacing TechCom with an executive review by the CTO and the CPO. The first change seems like a straightforward improvement, the second strikes me as opposed to some of the goals - it is less inclusive and more gatekeeping-y (with a smaller and more busy group of decisionmakers, there's more risk of turning into a bottleneck). It feels also less aligned with community-based open source practices, IMO, where trust is maintained by having a group of long-time, respected contributors in a sort-of-leadership position, mediating between the community and traditional leadership (the people with authority over the resources). Tgr (talk) 11:06, 16 November 2020 (UTC)

Currently today the CTO has ultimate decision making power in the TechCom charter, so I don't see this as a change. The representation put forward is on the Decision Forum with the independent +2s.

The process is designed to iterate so as the movement strategy is implemented it is possible the process changes. KChapman (WMF) (talk) 17:48, 16 November 2020 (UTC)

Having a comittee making the decisions plus an executive with veto power vs. having an executive making the decisions (or maybe the initiator making the decisions, if the executive intervention remains more of a veto thing) seems like a pretty big change. (De we have any data on how often in recent RFCs the CTO actually exercised their ultimate decision-making authority vs. the committee deciding and the CTO accepting it?) Also, in the current TechCom charter taking community consensus into account is a baseline expectation ("In rare cases, TechCom could diverge from community consensus.") while the proposal completely discards consensus-driven decisionmaking.

The strategy calls for a community-governed Technical Council. We have a body which is a natural precursor for the Council, and while it's not really community-governed, its members are highly respected community members so its decisions are seen as having a lot of legitimacy. Disbanding that body, in the name of iterating, only to have to reestablish something similar later, doesn't seem like a good way of iterating to me.

It's also pretty unclear from the proposal why TechCom is being disbanded in first place. Having some kind of committee made from highly established community members to provide direction and resolve conflicts while drawing from open discussions is a very standard way of organizing an open-source community, and the only item in "Challenges of the TechCom RFC Process" that seems relevant is gatekeeping, and I'm super skeptical about that. First, having some kind of community governance *is* gatekeeping (all governance is), so objecting to all gatekeeping ultimately means asserting that decisions should be made along the lines of the WMF org chart, with the volunteer community having no influence over it, which again is very antithetical to the strategic direction we have chosen. Second, consider security reviews - they are a prime example of gatekeeping, but no one complains about them, presumably because the process is easy to understand, predictable, well resourced, and provides clear and actionable feedback in a timely manner. So when people complain about gatekeeping, they are actually complaining about bad gatekeeping; ie. a gatekeeper that's underresourced so passing the gate is slow and confusing. I think this proposal fixes a lot of that, but it kind of throws out the baby with the bathwater. Tgr (talk) 05:04, 17 November 2020 (UTC)

Representation of third parties

The proposal is missing any mention of third parties (users of our technology who themselves aren't part of the Wikimedia movement, for example various community platform providers running MediaWiki, or MediaWiki consultancy / development shops). This is a long-present shortcoming of our processes that I'd really like to see corrected.

Wikia/Fandom, for example, has a user and content base roughly comparable to Wikimedia, employ a significant number of MediaWiki developers and have their own MediaWiki-related technical projects. Omitting their expertise and representation from the process would be a mistake, I think. Similarly, the MediaWiki Stakeholders' Group (a user group mostly composed of people working in smallish MediaWiki shops) represents a user base that is often negatively and painfully affected by the technical decisions we make, because it is understood poorly by most Wikimedia developers. Tgr (talk) 07:42, 16 November 2020 (UTC)

In my mind they were part of the independent +2 folks. I'll do some further research if that is the case. KChapman (WMF) (talk) 02:11, 17 November 2020 (UTC)

Some of them are, and I'm sure for non-WMF/WMDE staff +2 is a somewhat valid measure of expertise and experience. But since it isn't for those two orgs, and we aren't insisting on any alternative measure, I don't think it makes sense to treat other groups differently. The extra flexibility of having more than 1-2 people to rotate into meetings would probably be appreciated. Tgr (talk) 06:07, 17 November 2020 (UTC)

Composition

With the Forum being a project management body as opposed to a decisionmaking one, this is somewhat moot (and I feel there won't be much incentive for people to participate), but were that not the case, the Composition section stands out a bit with its long list of WMF teams vs. a single "Representative from the Independent +2s". Maybe that's just a typo, and it was meant in plural; but just in case, it might be worth pointing out that about half to a third of the contribtions to MediaWiki core come from independent contributors. (See Community metrics; the dashboard is not linking-friendly. MW core used as an example here as more comprehensive statistics are harder to get.) If we want to encompass the various areas of expertise that individual contributors represent, or the various chains of trust, a single representative wouldn't necessarily work well for those either. Tgr (talk) 08:22, 16 November 2020 (UTC)

In that spirit, a suggestion: instead of two co-chairs representing WMF Technology and WMF Product, have one of them represent Technology+Product and the other one affiliates and individual contributors. (Having a volunteer co-chair might of course run into practical problems, but even having someone from the WMF Technical Engagement team as a delegate for non-WMF technical contributors seems like an improvement in terms of representation.) Tgr (talk) 08:57, 16 November 2020 (UTC)

I agree that perhaps that ought to be "representatives". This also covers the 3rd party representation qn. that @Tgr raised separately. SSastry (WMF) (talk) 23:45, 16 November 2020 (UTC)

Updated to indicate to make plural KChapman (WMF) (talk) 13:18, 2 December 2020 (UTC)

The authority to act on that decision

The section on step 0 of the process says "It is crucial that [the Decision team] have the authority to act on that decision.". In the system, participating in the process is the very thing that grants you that authority; TechCom approval means you can implement the RfC. The proposal explicitly disavows that kind of decisionmaking power; if the proposed process is not a source of authority, what else is it? WMF teams presumably have their management processes that in the end lead to the CTO/CPO, but individual contributors are also supposed to use the Technical Decision Making Process; who should authorize their work? Or does this condition simply not apply to them? Or is is a reference to community (as in, wiki-editor community) buy-in? Tgr (talk) 08:35, 16 November 2020 (UTC)

Outreach support

The proposal mentions "Project Management of process not clearly resourced" as one of the current challenges. That is certainly true; I would like to add that outreach is also not resourced (clearly or otherwise). More specifically, there is usually very little capacity left to explain to the stakeholders what is at stake - at best a message is sent out notifying them about the RfC, which is written with the engineers who will work on it as the audience, ie., often utterly incomprehensible to editors, reusers, on-wiki technical contributors, developers downstream of some API etc. To put it more plainly, I think this process needs a technical writer with a clear mandate on spending time on translating the proposal from "developer language" to "user language" (where the "users" would usually be developers themselves, but ones who use the affected API, interface, system etc. and aren't familiar with the internals), including code examples and similar easy-to-grasp documentation. Tgr (talk) 08:45, 16 November 2020 (UTC)

Involving past contributors

Something I'd like to see explicitly called out in the section about defining stakeholders is involving (or attempting to involve) past maintainers and major contributors to the code or functionality in question. Those people are not stakeholders in the strict sense, but hold valuable expertise; currently, they are sometimes ignored and the outcome is usually worse for it. Tgr (talk) 08:48, 16 November 2020 (UTC)

"Make the process more inclusive by shifting to representation by teams/groups instead of individuals"

The above is stated to be one of the key objectives of the process. I think "TechCom does not have inclusive membership" is a fair problem statement (although with this proposal replacing TechCom as a leadership/decisionmaking forum with a body focused on project management, it seems less important), but it is unclear to me how switching to team-based representation is supposed to help. Whatever the process of finding candidates is, shouldn't inclusiveness criteria be stated more explicitly? Tgr (talk) 10:30, 16 November 2020 (UTC)

Being proactive

One of the challenges the proposal lists for the current process is that "TechCom has lacked the resourcing to be proactive about decisions and all necessary stakeholders aren’t always represented". I heartily agree and would consider that maybe the biggest problem of TechCom as it is now. The proposal doesn't try to fix that, and not trying to fix everything at the same time is of course very reasonable; but it doesn't seem like there's even a path left to fixing it if the proposal gets implemented in its current form. If TechCom is replaced with an explicitly non-decisionmaker TechDecForum, who would/could be resourced in some future evolution of the process to be more proactive? The new process seems to relegate the body to a very explicitly passive role. Tgr (talk) 10:38, 16 November 2020 (UTC)

Handling of tasks about existing RFCs

A minor point: according to the proposal, "There will be a two week grace period ... for groups to claim their existing RFCs. After the two weeks the remaining RFCs will be closed". Phabricator RFC tasks represent ideas, not RFC processes (in theory the two could have separate tasks, in practice it is rarely done); those tasks are usually the result of a significant effort to understand, discuss, develop and document some idea or proposal. Tasks representing ideas should not be closed unless the idea itself is found incorrect, implausible or disadvantageous; it makes them hard to find for future discussions, and it is disrespectful to the contributors who have spent their time developing those ideas.

This is not to say that the unclaimed RFCs shouldn't be closed, and removed from the decisionmaking process; but please, find a way of doing it that doesn't require closing the Phabricator task (or split the RFC and idea into separate tasks). Tgr (talk) 11:17, 16 November 2020 (UTC)

In the context of TechCom RFCs, "closed" typically means moving the task to TechCom-RFC-CLosed, not actually closing the task. I expect that was the intention here. A future process should choose unambiguous terms for each step that don't conflict with existing Phabricator or project management terms. AntiCompositeNumber (talk) 19:23, 16 November 2020 (UTC)

Typically, yes, but sometimes valid tasks do get closed because they had an RFC tag on them, and they spent too much time in some TechCom board column or other. I just want to avoid that happening here. Tgr (talk) 03:12, 17 November 2020 (UTC)

Thanks for the clarification. I updated to indicate we would not be mass closing all the tasks. KChapman (WMF) (talk) 13:16, 2 December 2020 (UTC)

Stronger expectation to use the process

One of the challenges of the current system, as listed in the proposal, is "Often TechCom is brought in late in the process". I'd add that often TechCom is not brought into the process at all. This is especially true for high-level decisions - the kind of "vision" decisions that result in teams being created or quarterly goals being set. I think this should be called out explicitly as a current challenge, and any evolution of TechCom should happen with an eye towards fixing this. Tgr (talk) 11:25, 16 November 2020 (UTC)

Can you tell me more about how you would see this working? I'm not sure I quite understand the gap here. KChapman (WMF) (talk) 17:41, 16 November 2020 (UTC)

Simply make a rule that all technical plans (that are cross-cutting etc) require going through that process, or maybe just require all technical plans to be announced publicly and they could go into the process if challenged. Technically that is already the rule, but I don't think it has been taken seriously. (If you are asking what would need to change so that it is taken seriously, I'm not sure. That's a management and org culture issue, and I don't feel competent in either of those. Also, improving the process first before trying to guide more people into it is probably a wise idea.) Tgr (talk) 06:13, 17 November 2020 (UTC)

Google group

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.

---

A minor point: step 2 explicitly calls for a Google group as a touch point. Is there a reason for using proprietary technology with questionable relationship to the Wikimedia privacy policy, when that technology is not even considered particularly good by today's standards? (Meanwhile, the upgrade of our mailing list software from its ten-year-old version to the actively developed branch is only happening because a volunteer has chosen to invest their free time into it.) Tgr (talk) 11:42, 16 November 2020 (UTC)

+1 ·addshore· ^{talk to me!} 14:54, 26 November 2020 (UTC)

Will consider this, need to look into the feasibility of having a project manager easily manage the group. KChapman (WMF) (talk) 12:57, 2 December 2020 (UTC)

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

Being mindful of volunteer capacity limits

For a change that's aiming for better inclusion, one thing that IMO could be called out more explicitly is supporting volunteers with limited capacity. For example, one of the factors for TechCom being relatively homogenous is that all meetings happen on workdays, which can be a challenge for volunteers who have non-Wikimedia day jobs. A timeboxed prototyping phase is also something that could be challenging (although it can be managed and there is certainly value in ensuring that the process is not stalled), and the documentation also feels somewhat bureaucratic and management-lingo-heavy. Tgr (talk) 11:52, 16 November 2020 (UTC)

The same goes for smaller affiliates (as in, smaller than WMDE), and the movement strategy calls for having more of them and resourcing them to participate in technical work. So allowing for lightweight participation should be an important goal in my opinion. Tgr (talk) 12:08, 16 November 2020 (UTC)

Do you think there is a different type of representation that should happen other than the independent +2s? Is there another option that might help with capacity?

In my mind those doing the work would set the timeboxed. The only requirement would be to check-in every two weeks. If a volunteer or affiliate didn't have time to do anything in those two weeks the check-in would state that. KChapman (WMF) (talk) 17:29, 16 November 2020 (UTC)

I think other groups (e.g. WMSE, WikiHow, Hallo Welt, Wikia - possibly specific teams at Wikia, given their size) should be represented the same way as WMF teams, with a selected person that they might change periodically, or case by case to best suit their expertise. Capacity aside, that seems like the natural way of doing things. Volunteers with +2 could maybe be treated as a group of their own, so it's easier to adapt personal schedules. I don't have any ideas beyond that, other than being flexible with things like meeting methods and schedules, and minimizing mental burden (the decision templates for example seem a little heavy for someone who has experience with coding but no experience with management / planning - does the proposer have to fill those out or is that a more collaborative thing?).

Regular checkins are a good idea, it's just that having a time limit seems problematic when someone works on something in their free time and life interferes. (Maybe I'm just misunderstanding what you mean by timeboxing. I assumed there is a certain number of checkin cycles and by the end of those the work needs to be finished.) Tgr (talk) 04:10, 17 November 2020 (UTC)

Decision Type Matrix

I don't quite understand how the Decision Type Matrix fits into the rest of the proposal. I assume this is setting out who the Decision Team is going to be. But the rest of the document seems to imply that the Decision Team would be the people who will do the work, were the project to be greenlighted; and while some rows of the matrix fit in with that, some don't. To the extent TechCom being a gatekeeper was a problem, this just seems to replace it with another gatekeeper (and in the case of volunteer or affiliate projects, a much more disconnected one). As far as I can see, the proposal doesn't offer much justification for that change. Tgr (talk) 12:06, 16 November 2020 (UTC)

I bolded "Some decisions are outside the scope of this process and a new responsible party is proposed." does that help with the understanding?

Currently TechCom makes some decisions or tries to facilitate decisions that are outside of the charter. The benefit of this is folks do have somewhere to ask, the downside is things get stuck when outside of the charter. The idea here is to be more explicit in who should have the responsibility. KChapman (WMF) (talk) 17:25, 16 November 2020 (UTC)

Thanks! I took that sentence to mean something general like "there are some unspecified decisions other than the ones below which are outside the scope of the process". In hindsight I wasn't paying enough attention, but maybe something like this would be more foolproof:

Some decisions are outside the scope of this process and a new responsible party is proposed to ensure they are not lost in the transition. Below are a few examples, taken from the existing RFC process. Both the type of decision...

Now that I'm not misunderstanding it anymore, some comments on the rows of the matrix below. Tgr (talk) 05:44, 17 November 2020 (UTC)

If the tool impacts 1 other team -> If the tool impacts any other team? It means the same, it just sounded weird.

Also, I don't think the examples here illuminate this decision type. Both are massive changes affecting everyone who touches the MediaWiki frontend; surely changes like this would still go through the TechDecForum? I don't think there are any examples of RfCs about a team picking their own tooling, such issues are already not handled by TechCom.

Also, I'm not sure I fully agree with Teams should be able to pick the right tools to do their jobs. I certainly appreciate the sentiment, but the reality of WMF's current software lifecycle management is that software components live much longer than teams do, so someone else will have to live with that tooling, typically without getting the resources necessary to change them to be right for their jobs, because at that point the component is in maintenance mode. So I think putting some limits on team creativity is justified, even apart from the "coupled environment" issue that's already called out. Tgr (talk) 05:50, 17 November 2020 (UTC)

Project that touches other systems components, is a new component or service or is introducing a new capability on the production system.

Presumably this is about new components/services/capabilities which are not "strategic, cross-cutting, or hard to undo"? Again, I feel the examples here don't really help. Surely notifications infrastructure is strategic for social software? And changes to core schemas are almost always hard to undo. Tgr (talk) 05:58, 17 November 2020 (UTC)

Similarly, the "Software implementation details" examples are absolutely cross-cutting, and dropping support for some browser is both strategic and hard to undo (you can revert the changes but the users won't come back) and cross-cutting in that the benefits materialize for all front-end developers.

In general, the impression I get is that TechCom did a pretty good job excluding things that didn't need a central decisionmaking process, and while the rows of the matrix make sense in theory, the examples are quite strained. (Apart from granting +2 - moving that to TechEng is a logical move.) Tgr (talk) 06:02, 17 November 2020 (UTC)

Thanks

This is a clear and well-written document, and while I think I disagree with the proposed direction somewhat, I found it a good accounting of the current situation and its shortcomings, and a great and thought-provoking conversation starter. Thank you for all the work that went into it, and thank you for pushing for a better technical decision-making process, something that's really at the heart of our ability to function as a community and a distributed movement.

(Also, sorry for only leaving feedback at the last moment! I hope it is still useful.) Tgr (talk) 12:17, 16 November 2020 (UTC)

High-level feedback / questions

Thanks for taking up this difficult task. I imagine for most routine work, this will work fairly smoothly. So, I am going to think about a few edge cases.

1. The one-week deadline for the decision making forum seems tight in some scenarios. But, I suppose it depends on what "feedback" means here. Is there / should there be a mechanism to ask for more time?
2. I am expecting / assuming that most actors / decision teams will act in good faith on receiving critical / negative feedback from some section of stakeholders. But, how (or where in the process) are conflicts (as in technical directions that elicit potentially opposing / divergent views in the extreme) going to be resolved?
3. How are rollbacks of decisions handled where they might become necessary? Is that a fresh proposal?

Relatedly, I assume that this process is open to being refined in the future based on actual working experience with it? SSastry (WMF) (talk) 22:14, 16 November 2020 (UTC)

Thanks for the questions:

1. In that timeframe groups need to simply say if they are impacted by the decision and that they need to be consulted and the problem statement is right. Do you think it is possible for a team to know they "might" be impacted and reply in that timeframe?
2. How are things escalated now?
3. Fresh proposal

Yes, the plan is to retro and adjust as we try it. KChapman (WMF) (talk) 13:21, 2 December 2020 (UTC)

1. It is possible, but since I am talking edge cases, I am also thinking of time-off scenarios where there may not be adequate team capacity to make the call (if the team rep is say away).
2. Good qn. I don't know. Prior to TechCom, it was nebulous. With TechCom, presumably they could block approval till conflicts were resolved in whatever fashion they needed to be resolved? SSastry (WMF) (talk) 16:02, 2 December 2020 (UTC)

Logistical questions

As someone about to take a decision through the Technical Decision Making Process, I have a few clarifying questions:

• Do forum members only weigh in on decisions relevant to their team? Will there be a participant from the anti-harassment team for every decision, who only sometimes says yay or nay to the three questions?
• Step three says "Once the Decision Statement Overview is confirmed with the Technical Decision Forum...." What does that confirmation look like? Is it just that a week has passed since the phab ticket was added to the inbox? If there is disagreement on one of the three questions, does the team who brought the decision to the forum make the final call? What if the Decision Statement Overview does not include a stakeholder who may be substantially affected by the team's decision? (And who decides what "substantially affected" is?)
• Who are the CTO and CPO delegates for executive review? Who are the co-chairs?
• If a decision is flagged for executive review, and executive review finds it unacceptable, I could see the subsequent steps becoming unclear and lengthy. Is there a clear fallback when execs nix a decision? (I understand this might be difficult do to the variety of types and levels of nixing.)

Thanks for putting together this process, and for shepherding us through it. Abittaker (WMF) (talk) 19:32, 15 January 2021 (UTC)

Stakeholder analysis?

Is there a stakeholder analysis anywhere that is the basis for picking what constituencies should be represented here?

I'm asking because half a year (judging by the comments below) later, only WMF teams are actually listed.

Meanwhile, based on comments in Phabricator, the Vue.js decision was apparently trialled through this process (although it isn't listed in the on-wiki archives) and that decision has very wide ranging impacts (far beyond WMF-internal groups). In particular, as a semi-technical community member trying to cover the gaps in the core software through Gadgets and user scripts, both the status quo and the now-decided path forward holds significant challenges and opportunities (both the adoption of Vue.js and related dropping of IE11 from Grade A).

Who was to represent my concerns in this decision process? What was my channel for getting my requirements in as part of the decision and the presumably following work?

I spent several hours over the last couple of days trawling through Phabricator and mediawiki.org, and the only mentions I find of Gadgets and user scripts is as an aside when someone wants to really emphasise how important it is that Vue.js not make breaking changes without a rock-solid migration shim. I find a ton of discussion of requirements like being modern (Gadgets and user scripts still can't use ES6 syntax due to T75714 and there is no sign this will ever change), have a compilation step and use templates (both of which are not unproblematic in a Gadget/user script context), "transpilation" (buzz-word alert!) deploy and CI, all of which are at best irrelevant for most Gadgets and user scripts (and assumptions that these are the normal context can lead to choices that make it actively hostile to Gadget/user script use).

The dialog example in T155567 (simple dialog box in OOUI vs. jQuery UI) should have been a no-brainer "Wow, we really need to fix this ASAP!", and the fact that nothing happened tells me the perspective of Gadget/User script developers is not sufficiently represented in these decision processes. How is this new process intended to make sure that when picking Vue.js the requirements and pain-points of Gadget/user script developers are taken into account? How do I make sure those priorities are included in the ongoing and coming trials and migration?

Or put more succinctly: if there is someone looking out for my interests in this process I am failing to find information about it anywhere. Xover (talk) 06:39, 29 April 2021 (UTC)

Meanwhile, based on comments in Phabricator, the Vue.js decision was apparently trialled through this process (although it isn't listed in the on-wiki archives) and that decision has very wide ranging impacts (far beyond WMF-internal groups).

It wasn't. The decision to go with Vue was made in March 2020 after over half a year of discussions. The replacement of the old RfC/TechCom processes with TDMP was made in January 2021.

The bespoke mechanisms by which my colleagues researched, explored, and discussed things so as to make the Vue decision fed into the already underway work to reconsider RfCs and how they might be replaced, but they're distinct processes. Jdforrester (WMF) (talk) 16:25, 29 April 2021 (UTC)

Ping.

No community entity or individual is as yet reflected in this process. Technical Decision Forum still lists the community as "TBD". Even the Affiliates (which, I must stress, are not the same as the community) are only represented by three individual WMDE projects.

According to the front page of wikimediafoundation.org, "Collaborative projects are the core of the Wikimedia movement.—Our volunteers build tools, share photos, write articles, and are working to connect all the knowledge that exists.", but from all visible evidence these volunteers are not seen as core stakeholders whom it is critical to have represented when fundamental and far-reaching technical decisions that affect the projects are made.

The Tech Decision Forum workboard in Phabricator currently lists 10 tasks, for all of which a cursory inspection suggests at least one of the communities should be Consulted or Informed in the RACI. These should all technically be blocked on the lack of community representation, but the very lack of such representation means there's nobody in the decision loop whose responsibility it is to raise their hand and flag that issue. Xover (talk) 11:16, 6 June 2021 (UTC)

Updates?

Is there a reason why there have been no updates for a year on Technical decision making/Updates and could updates please be posted? Thanks. AKlapper (WMF) (talk) 10:13, 12 July 2022 (UTC)

I believe those "updates" were minutes of a meeting that doesn't happen any more. Nowadays Technical decision making/Decision records seems like the update channel? Jdforrester (WMF) (talk) 15:50, 12 July 2022 (UTC)

Maybe @LNguyen (WMF) knows? AKlapper (WMF) (talk) 07:30, 26 July 2022 (UTC)

@LNguyen (WMF): Do you know? AKlapper (WMF) (talk) 12:36, 14 August 2022 (UTC)

@AKlapper (WMF)@Jdforrester (WMF)

I've just added an update. There are a lot to sort through since the change over. We are also beginning a restro on the process. I'll try to give updates when there are changes. So far it has been quiet. LNguyen (WMF) (talk) 00:39, 18 August 2022 (UTC)

The "Google Docs" Bug :)

Well, interestingly this change was reverted:

https://www.mediawiki.org/w/index.php?title=Technical_decision_making&diff=prev&oldid=6388659

So here we are. We all know that Google Docs can be useful, but I'm quite sure in Wikimedia we can avoid to both adopt and promote proprietary software in general. It's easy nowadays to share a Libre online collaborative document, since we have https://cryptpad.fr/ - Collabora - OnlyOffice - EtherPads - SandStorm - etc.; - and all of these are good software.

So I'm quite sure that we can easily at least stop having Google Docs as a requirement to be involved in such technical decisions. I don't think that any clarification is needed, but, in doubt, feel free to explore reasons in m:Wikimedians for software freedom.

I think everybody will generally agree with this. We know the situation, but we cannot ask Wikimedians to all become Google customer to be part of their Wikimedia movement.

Thanks for what we can do to mitigate and fix this situation. Valerio Bozzolan (talk) 20:24, 27 February 2024 (UTC)

I think everybody will generally agree with this.

It is clear you think this is the case. However, that does not make it true. If you wish for Wikimedia management to change their policy, you should contact them and ask for this change to happen. Jdforrester (WMF) (talk) 20:26, 27 February 2024 (UTC)

Thanks. Note I was talking about avoiding Google Docs, to be not a requirement to participate in this page on Meta Technical decision making, and I was not talking about Wikimedia Foundation.

I think this was easy, and do-able, since the scope is limited.

But, by the way, I already contacted management to change the big picture. But, in 2023 the CTO clearly explained to me that it's not their priority, since Wikipedia has to invest resources to fight TikTok®, etc., and btw each team can already change tools if they want, and other interesting reasons I honestly also partially agree with (Am I wrong? User:Laurentius Board of Trustee and Mehrdad who joined the conversation).

In any case, also to change the big picture in WMF it's do-able. We are probably talking about 300 USD / month for a serious enterprise video-conference solution like BigBlueButton on a random provider; instead of relying on non-sustainable best-effort projects like m:Wikimedia Meet.

If you suggest to contact the CEO instead, well, yes, it's also do-able.

But, is it really all of this necessary, just specifically for the page Technical decision making? Probably not. Valerio Bozzolan (talk) 21:10, 27 February 2024 (UTC)

I agree that google docs is an antipattern here. The entire point of decision making is to ensure its public so that everyone is on the same page. Google docs hides decision making away, and has limited history feature so we cannot easily go back and see how things change.

That said, you cannot simply change it in an unilateral edit. This page describes the process, it doesn't define the process. An edit to this page doesn't change the process, it just makes the documentation wrong. Its the same as how you can't change who is president simply by editing w:President of the United States Bawolff (talk) 22:29, 27 February 2024 (UTC)

OK but let's do something.

A:

If the page Technical decision making should not be touched, we should probably add a banner to the top, like we usually see around. Bonus point: pointing out the workflow to change things (I guess talking in a talk page is not enough to change things here). That's do-able.

B:

I got the point. Don't worry. I will never do again similar minor edits:

https://www.mediawiki.org/w/index.php?title=Technical_decision_making&diff=prev&oldid=6388659

Premising that, no, that change was not intended to destroy this workflow. The change literally involves four (4) words. The reasons are:

- first occurrence: we can avoid a link "Google Docs" that points to Wikimedia Commons. That link is confusing for both humans and robots. We can avoid that easily. Suggestions?

- second occurrence: we can say "spreadsheet" instead of "Excel". And yes we can say "collaborative document" instead of "Google Docs" if we agree that we are not nuking the decision process. Suggestions? Valerio Bozzolan (talk) 07:40, 28 February 2024 (UTC)

You're allowed to make minor edits, i wouldn't call this minor in context.

Regardless, we are talking about a process that as far as i know, was abandoned about a year ago. Really this page should probably be marked historical more than anything else unless the situation has changed (although it probably makes sense to let the tdf retrospective play out first) Bawolff (talk) 08:34, 28 February 2024 (UTC)

Regardless, we are talking about a process that as far as i know, was abandoned about a year ago.

I'd use a different term, perhaps "paused" or "deferred".

Really this page should probably be marked historical more than anything else unless the situation has changed (although it probably makes sense to let the tdf retrospective play out first)

Indeed. Jdforrester (WMF) (talk) 18:14, 28 February 2024 (UTC)

Uh :O

Are you aware of what should people do nowadays instead, to propose technical changes?

You may think I'm completely lost, but my root problem was just... finding a place to talk about something like this without being closed as invalid (and without having to use Google Docs :D if possible):

https://phabricator.wikimedia.org/T309328

Thanks for any "Yeah look here → ...". Sorry if I landed here. Valerio Bozzolan (talk) 09:28, 28 February 2024 (UTC)

As far as i understand, you aren't being held up on the technical decision making (what this process was for) but on the political decision making. At this stage, you need to show that this is what the (non-technical) wikimedia community wants. That it is what admins and stewards want. The best place for that would probably be an RFC on meta, since this would affect how global blocking works. Bawolff (talk) 07:10, 29 February 2024 (UTC)

Oh, thanks funny.

I'm here because I was looking for "request for comments"

https://www.mediawiki.org/wiki/Requests_for_comment

That has a banner pointing here

https://www.mediawiki.org/wiki/Technical_decision_making

Instead this is my right destination :D

https://meta.wikimedia.org/wiki/Requests_for_comment Valerio Bozzolan (talk) 08:44, 29 February 2024 (UTC)