Talk:Technical decision making/Flow

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.

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.

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.

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

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?

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)

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.

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.

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.

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

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.

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?

Maybe @LNguyen (WMF) knows?

@LNguyen (WMF): Do you know?

@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.

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.

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.

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.

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.

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.

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.

> 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.

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?

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.

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?

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.

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.)

I agree that perhaps that ought to be "representatives". This also covers the 3rd party representation qn. that @Tgr raised separately.

Updated to indicate to make plural

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).

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.

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.

Thanks for the clarification. I updated to indicate we would not be mass closing all the tasks.

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.)

+1

Will consider this, need to look into the feasibility of having a project manager easily manage the group.

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!

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.

GreatI I saw them and replied to a few and have some thinking and reading to do on others.