Talk:Technical decision making/Technical Decision-Making Process Retrospective and Consultation plan

Why "retro"?

Ironically, if the goal is to bring in as many contributors as possible, etc., use of jargon like "retro" might be a mistake. I know it's short for "retrospective", but beyond that I had never heard of this term being used in a business/management context. I looked it up, and apparently it's an Agile management term, used to refer to discussions about just-completed tasks - like a "post-mortem" but shorter-term, maybe. I'm not even sure if that concept applies here - obviously, discussions about what worked and didn't work in the past are relevant, but that's not the only thing that's relevant. Why not just call it a "discussion", or something along those lines? Yaron Koren (talk) 18:31, 31 March 2023 (UTC)

I changed the one instance of "retro" on that page to "retrospective". We could probably come up with a couple sentences explaining what "retrospective" refers to, for people who are not familiar with the term. KHarlan (WMF) (talk) 18:38, 31 March 2023 (UTC)

It would also help to reduce the use of corporate jargon and style, starting from the off-putting Title Case, which makes this look like a non-inclusive space and process. Nemo 18:21, 3 April 2023 (UTC)

Roles

There are two separate lists of roles, both naming someone with "executive ownership", but with a different description of the role and a different name. Are the two things compatible?

It's not clear to me who's responsible for digging up the reasons and objectives the current process was set up for, in order to assess whether they were achieved and whether there was an improvement compared to the status quo ante (i.e. the Requests for comment process and the ArchCom/TechCom as we knew it in 2014/2017/2020). Nemo 18:19, 3 April 2023 (UTC)

Thanks for pointing out the inconsistency, I have corrected it.

The intention of the retrospective is to understand the pain points and the areas to improve the current process. As part of that process people will be able to make suggestions that may be from previous processes. The core team is responsible for collecting the information and analyzing it. KChapman (WMF) (talk) 11:58, 4 April 2023 (UTC)

Thanks. I understand where you're coming from but I would hope for the retrospective to have sufficient resources for an assessment of at least the more recent changes. If that's not possible, the process should take into account the risk of survivorship bias, recency bias and selection bias in the information collected. Nemo 15:43, 5 April 2023 (UTC)

We will be asking for feedback on the questions that are asked in the retrospective. There will be an opportunity to suggest specific ways to get input so that we can improve how technical decisions are made regardless of what iteration of decision making the improvements come from. KChapman (WMF) (talk) 15:23, 12 April 2023 (UTC)

Timeline

So its been two weeks. While I appreciate that these things take time, and that this is also annual plan season, it'd be nice if a rough proposed timeline of when various steps in this process will happen could be posted (With the understanding of course that the timeline may very well change depending on how things go). Bawolff (talk) 00:42, 14 April 2023 (UTC)

Thanks for the note, @Bawolff. We initially had a draft timeline but decided to hold off a bit, partly because it has been and still is an intensive annual planning period, and also because we wanted to see what kind of feedback we would receive from the announcement. Finally, depending on how we define stakeholders (per your other thread), the timeline might vary. Anyway, I'll bring up this point in our group's next meeting to see if we can put some rough schedule out. KHarlan (WMF) (talk) 10:15, 18 April 2023 (UTC)

mostly, i just want to make sure i dont miss it whenever things start happening. Bawolff (talk) 10:26, 18 April 2023 (UTC)

Stakeholders

On the page there is a list of stakeholders - currently just wmf, affiliate (including wm-de, who are very different from other affiliates) and volunteer. I'm not sure if that is just a placeholder or final list, if this is stakeholders of the retro specificly or the tdf in general, but i think there could be more. I'd go with: WMF, affiliates who contribute to production code (mostly wm-de. I would not group all affiliates together), volunteers who contribute to production code, the broader wikimedia community (ordinary users, gadget writers etc), third party volunteers (e.g. people who primarily contribute to external wikis like miraheze but participate in our dev community), third party commercial interests (omitting this is odd, as the tdf had grunny and hexmode who both were from this group). Some of these groups overlap, and some are only tangentially interested in TDF (e.g. broader volunteers probably dont interact much but still may be interested in reading the rationale behind decisions and knowing what future plans are.). Bawolff (talk) 07:43, 16 April 2023 (UTC)

Thanks @Bawolff, this is a good point. We discussed in the group about how to make sure we are inclusive while still keeping the retro in the scope of the groups that are impacted, and we decided that instead of making a list of stakeholders, we will instead write a statement that guides folks whether this retrospective is relevant for them and their work around our systems. We'll add this to the main page:

Stakeholders who are most likely to find this interesting: people who do technical work that affects others in the Wikimedia environment: Contribute code to MediaWiki and our production code or who rely on production code for their code or tools. MSchottlender-WMF (talk) 18:48, 25 April 2023 (UTC)

Actively Seeking Outside Technical Help

I believe we need to actively solicit volunteers from the larger developer/sysad/SRE community early in this process-before the public consultation. Current volunteers and employees are not sufficient-we need outside voices with enough technical knowledge to understand and challenge decisions. Without these voices, the same complaints around lack of accountability are likely to resurface. BKing (WMF) (talk) 12:47, 17 May 2023 (UTC)

@BKing (WMF) thanks for your comment. I'm not sure I understand who you have in mind when you say "volunteers from the larger developer/sysad/SRE community early in this process", do you mind giving some examples?

> we need outside voices with enough technical knowledge to understand and challenge decisions

To clarify, we are not making decisions in this phase. We're gathering feedback on existing and past processes and summarizing that feedback. KHarlan (WMF) (talk) 07:23, 31 May 2023 (UTC)

@KHarlan (WMF) I'm thinking similar to what tgr mentioned here . I'd expand this even further to say that changes to our infrastructure stack (operations, config management, monitoring etc) should be within the purview of the TDM process.

Students, educators, major contributors from open source projects, engineers from for-profit tech companies, engineers from non-profits with similar missions to ours should all be a part of the process. I've only been at WMF for about 18 months, but I feel like we are missing some major opportunities to teach and learn from the community. I apologize if this is off-topic. Feel free to ping me in Slack or IRC (inflatador) if you'd like to continue the conversation. BKing (WMF) (talk) 20:58, 18 July 2023 (UTC)

I would disagree. I don't think it is neccesarily a good thing to invite extra participants who don't really have a stake in the decision. I think it would lead to design by comittee and a very bloated process. Bawolff (talk) 21:35, 18 July 2023 (UTC)

The problem statement of the TDF.

One of the main things emphasized in the TDF is everything should have a clear problem statement. However this seems to be missing from the TDF itself. At most there is a purpose statement: "The Wikimedia technical decision-making process empowers teams to make decisions that are informed by experts from Wikimedia Foundation teams, affiliates, and volunteer groups." I would submit that this is the wrong problem to solve. I think we as a group might have many problems with technical decision making. However i don't think getting experts to comment is one of them. Controversially, I would go as far to say that in many cases it might be actively unhelpful to the team trying to get something done. Bawolff (talk) 20:42, 21 July 2023 (UTC)

How other people do this sort of thing

I just read this blog post [1] about how haskell manages deciisions and thought it was interesting and thought other people who are interested in this topic might be interested in reading. Bawolff (talk) 15:55, 25 January 2024 (UTC)