Mailing List Archive

Technical Decision Making Retro
*Fixing my list addressing errors...*

TLDR: The Foundation will be conducting a retrospective on the Technical
Decision Making Process.

To the entire Wiki technical community,

For quite some time now, we have experienced issues with the Technical
Decision Making Process (TDMP). Volunteer contributors and staff have asked
if we are still operating the Technical Decision Forum (TDF, the member
body that participates in the TDMP). Communication about it from the
Foundation has been inconsistent, and interest from the volunteer community
in joining has been low. Some of our most senior engineers on Foundation
staff have expressed that the process is flawed, doesn’t create room for
discussion about the technical issues surrounding a decision, and doesn’t
ensure participation by all stakeholders who may be affected by the
decision. Suffice it to say, the current state of affairs leaves many
participants wanting more.

We must also remind ourselves of the purpose of a decision making process.
The decisions are not meant to be random or isolated. They should be
aligned to our technical strategy, and we should be able to look at the
decisions we have made and understand how they advance our progress against
that strategy. If the process is working as it should, the decisions that
are produced should represent settled wisdom, and not need to be revisited
too quickly. The goals for a well-run process include:

-

A straightforward, widely understood decision making process, that
-

Facilitates impactful technical decisions to be made in a timely manner,
-

Incorporates input from staff and volunteers in our technical community,
with
-

Decisions that align with accountability for decision outcomes, and
-

Clear communication and transparent operations throughout the process.

On examination of the contributing factors that have led us to this point,
the factor that stands out to me is the need for clear accountability:
accountability for the TDMP itself and accountability for each of the
decisions we make. Technical decision making, beyond a certain magnitude,
is a core organizational process for any engineering organization. It is
therefore important for us to examine and improve this process from time to
time to ensure organizational effectiveness. Not unrelated, regular
retrospectives are a routine agile software engineering practice to enact
continuous improvement. To keep our decision making process effective and
efficient, we need to conduct regular retros. Overall accountability for
maintaining an effective decision making process should rest with a person
who is sufficiently able to marshal resources and address problems at a
large scale – here at the Foundation, that resides in the executive level.

The Foundation will be conducting a retro on the TDMP over the next couple
of months. Because we don’t yet have a habit of doing retros on this
process, and because there is a wide range of stakeholders we seek to hear
from, the process will be a bit more structured than an ordinary retro, and
will take more time. As we do more of these, we should get better at them.
The feedback gathered through the retro will be used to make changes to
improve the TDMP.

Foundation staff will follow up with more information about the kickoff of
the retro and what steps will follow. I am looking forward to wide
participation in this retro.


Here are the links to the relevant wiki page and Phab ticket:

- Wiki page
<https://www.mediawiki.org/wiki/Technical_decision_making/Technical_Decision-Making_Process_Retrospective_and_Consultation_plan>
- Phabricator ticket <https://phabricator.wikimedia.org/T333235>

Thank you! And apologies for all the crossposting.

Tajh Taylor (he/him/his)

VP, Data Science & Engineering

Wikimedia Foundation <https://wikimediafoundation.org/>
Re: Technical Decision Making Retro [ In reply to ]
Hi Tajh,

On 3/30/23 09:18, Tajh Taylor wrote:
> For quite some time now, we have experienced issues with the Technical
> Decision Making Process (TDMP). Volunteer contributors and staff have
> asked if we are still operating the Technical Decision Forum (TDF, the
> member body that participates in the TDMP). Communication about it from
> the Foundation has been inconsistent, and interest from the volunteer
> community in joining has been low. Some of our most senior engineers on
> Foundation staff have expressed that the process is flawed, doesn’t
> create room for discussion about the technical issues surrounding a
> decision, and doesn’t ensure participation by all stakeholders who may
> be affected by the decision. Suffice it to say, the current state of
> affairs leaves many participants wanting more.

I'm glad to see this stated in the open, I think your summary is a
decent starting point of why the TDF never worked. I do think a retro or
post-mortem of the TDF from this perspective is needed.

From the talk page:
> The intention of the retrospective is to understand the pain points
and the areas to improve the current process.

What from the TDF is worth salvaging to the point that it makes sense to
iterate on top of? More importantly, what is the value in putting in
this work when we already have a pending Movement Strategy
recommendation to establish a Technology Council[1]? Surely that's a
better base to start from?

As much as I respect the people listed on the "Core team", I'm pretty
concerned that they're all WMF staff, given that we're talking about
performing a retro on a body that explicitly excluded volunteers for
most of its lifetime and as you said, weren't interested in joining once
that option was given to them.

[1]
<https://meta.wikimedia.org/wiki/Movement_Strategy/Initiatives/Technology_Council>

Thanks,
-- Kunal / Legoktm
_______________________________________________
Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Re: Technical Decision Making Retro [ In reply to ]
Hi Kunal,

Thank you for the feedback. To address your question about the relationship
between this work and the Movement Strategy recommendation to establish a
Technology Council, I will say that I do not believe they are addressing
the same set of needs, but I can see how the work of each body will be
related. What is proposed as the purpose for the Technology Council is "to
oversee the process of *developing new technical features*" (emphasis
theirs). Though the words in the recommendation do not describe it this
way, I see this as a product development and management function. My
perspective on the purpose of the TDMP is somewhat different: in the
pursuit of ongoing product development or operations support, we need to
make decisions in an engineering capacity, and those decisions have
consequences for system architecture, operational outcomes, and paths of
software development. It isn't a way to make product decisions, and it
does have to reflect and consider the operational responsibilities that
reside with Foundation staff. That said, I can see a possible scenario
where many of the same volunteers are interested in both functions, though
I do not think that will be true of all volunteers, and it is likely not
the case that Foundation staff participants would be the same in both
cases, as our roles are more sharply defined. I will be watching to see how
the Movement Strategy recommendation is moved forward, to continue to
verify that my understanding remains accurate, and to see what impact that
may have on our work.

On the matter of the "Core team", I have given the task of planning and
running the retro to staff members whose work I can direct. The retro has
been planned from the beginning to be inclusive of as wide a range of
volunteer voices and perspectives as we can manage within the scope of the
work. In this way, it is not really different from any other operational
process that the Foundation runs, where volunteer voices may be included
but volunteers don't have the responsibility of managing the processes. The
retro itself is not a governance process, and it won't involve making
decisions of consequence. It is an information gathering process, to build
a broad and comprehensive perspective on the TDMP. Reflection on the
information we have gathered should inform decisions we can make,
particular decisions to change or adjust the TDMP itself, but those
decisions are not themselves part of the retro.

I'm looking forward to your participation in the retro activities!

Tajh Taylor (he/him/his)

VP, Data Science & Engineering

Wikimedia Foundation <https://wikimediafoundation.org/>



On Thu, Apr 13, 2023 at 2:56?AM Kunal Mehta <legoktm@debian.org> wrote:

> Hi Tajh,
>
> On 3/30/23 09:18, Tajh Taylor wrote:
> > For quite some time now, we have experienced issues with the Technical
> > Decision Making Process (TDMP). Volunteer contributors and staff have
> > asked if we are still operating the Technical Decision Forum (TDF, the
> > member body that participates in the TDMP). Communication about it from
> > the Foundation has been inconsistent, and interest from the volunteer
> > community in joining has been low. Some of our most senior engineers on
> > Foundation staff have expressed that the process is flawed, doesn’t
> > create room for discussion about the technical issues surrounding a
> > decision, and doesn’t ensure participation by all stakeholders who may
> > be affected by the decision. Suffice it to say, the current state of
> > affairs leaves many participants wanting more.
>
> I'm glad to see this stated in the open, I think your summary is a
> decent starting point of why the TDF never worked. I do think a retro or
> post-mortem of the TDF from this perspective is needed.
>
> From the talk page:
> > The intention of the retrospective is to understand the pain points
> and the areas to improve the current process.
>
> What from the TDF is worth salvaging to the point that it makes sense to
> iterate on top of? More importantly, what is the value in putting in
> this work when we already have a pending Movement Strategy
> recommendation to establish a Technology Council[1]? Surely that's a
> better base to start from?
>
> As much as I respect the people listed on the "Core team", I'm pretty
> concerned that they're all WMF staff, given that we're talking about
> performing a retro on a body that explicitly excluded volunteers for
> most of its lifetime and as you said, weren't interested in joining once
> that option was given to them.
>
> [1]
> <
> https://meta.wikimedia.org/wiki/Movement_Strategy/Initiatives/Technology_Council
> >
>
> Thanks,
> -- Kunal / Legoktm
> _______________________________________________
> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
> To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
> https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
Re: Technical Decision Making Retro [ In reply to ]
Hi,

> The retro itself is not a governance process, and it won't involve making
decisions of consequence.

This seems kind of at odds what is written on wiki. To quote the opening
paragraph of
https://www.mediawiki.org/wiki/Technical_decision_making/Technical_Decision-Making_Process_Retrospective_and_Consultation_plan
: "The general goal of this process is to revise the Wikimedia Technical
decision-making process...The process will run in two phases: consultation,
and design and implementation."

The on wiki page seems to imply the primary output of this process will be
to decide what needs to be changed, and make those changes. Doesn't get
much more consequential than that.

I think this is something that should be clarified at the get-go to align
expectations. I think its really important to know what the expected
outputs are when designing a process like this.

--
Brian

On Friday, April 14, 2023, Tajh Taylor <ttaylor@wikimedia.org> wrote:

> Hi Kunal,
>
> Thank you for the feedback. To address your question about the
> relationship between this work and the Movement Strategy recommendation to
> establish a Technology Council, I will say that I do not believe they are
> addressing the same set of needs, but I can see how the work of each body
> will be related. What is proposed as the purpose for the Technology
> Council is "to oversee the process of *developing new technical features*"
> (emphasis theirs). Though the words in the recommendation do not describe
> it this way, I see this as a product development and management function.
> My perspective on the purpose of the TDMP is somewhat different: in the
> pursuit of ongoing product development or operations support, we need to
> make decisions in an engineering capacity, and those decisions have
> consequences for system architecture, operational outcomes, and paths of
> software development. It isn't a way to make product decisions, and it
> does have to reflect and consider the operational responsibilities that
> reside with Foundation staff. That said, I can see a possible scenario
> where many of the same volunteers are interested in both functions, though
> I do not think that will be true of all volunteers, and it is likely not
> the case that Foundation staff participants would be the same in both
> cases, as our roles are more sharply defined. I will be watching to see how
> the Movement Strategy recommendation is moved forward, to continue to
> verify that my understanding remains accurate, and to see what impact that
> may have on our work.
>
> On the matter of the "Core team", I have given the task of planning and
> running the retro to staff members whose work I can direct. The retro has
> been planned from the beginning to be inclusive of as wide a range of
> volunteer voices and perspectives as we can manage within the scope of the
> work. In this way, it is not really different from any other operational
> process that the Foundation runs, where volunteer voices may be included
> but volunteers don't have the responsibility of managing the processes. The
> retro itself is not a governance process, and it won't involve making
> decisions of consequence. It is an information gathering process, to build
> a broad and comprehensive perspective on the TDMP. Reflection on the
> information we have gathered should inform decisions we can make,
> particular decisions to change or adjust the TDMP itself, but those
> decisions are not themselves part of the retro.
>
> I'm looking forward to your participation in the retro activities!
>
> Tajh Taylor (he/him/his)
>
> VP, Data Science & Engineering
>
> Wikimedia Foundation <https://wikimediafoundation.org/>
>
>
>
> On Thu, Apr 13, 2023 at 2:56?AM Kunal Mehta <legoktm@debian.org> wrote:
>
>> Hi Tajh,
>>
>> On 3/30/23 09:18, Tajh Taylor wrote:
>> > For quite some time now, we have experienced issues with the Technical
>> > Decision Making Process (TDMP). Volunteer contributors and staff have
>> > asked if we are still operating the Technical Decision Forum (TDF, the
>> > member body that participates in the TDMP). Communication about it from
>> > the Foundation has been inconsistent, and interest from the volunteer
>> > community in joining has been low. Some of our most senior engineers on
>> > Foundation staff have expressed that the process is flawed, doesn’t
>> > create room for discussion about the technical issues surrounding a
>> > decision, and doesn’t ensure participation by all stakeholders who may
>> > be affected by the decision. Suffice it to say, the current state of
>> > affairs leaves many participants wanting more.
>>
>> I'm glad to see this stated in the open, I think your summary is a
>> decent starting point of why the TDF never worked. I do think a retro or
>> post-mortem of the TDF from this perspective is needed.
>>
>> From the talk page:
>> > The intention of the retrospective is to understand the pain points
>> and the areas to improve the current process.
>>
>> What from the TDF is worth salvaging to the point that it makes sense to
>> iterate on top of? More importantly, what is the value in putting in
>> this work when we already have a pending Movement Strategy
>> recommendation to establish a Technology Council[1]? Surely that's a
>> better base to start from?
>>
>> As much as I respect the people listed on the "Core team", I'm pretty
>> concerned that they're all WMF staff, given that we're talking about
>> performing a retro on a body that explicitly excluded volunteers for
>> most of its lifetime and as you said, weren't interested in joining once
>> that option was given to them.
>>
>> [1]
>> <https://meta.wikimedia.org/wiki/Movement_Strategy/
>> Initiatives/Technology_Council>
>>
>> Thanks,
>> -- Kunal / Legoktm
>> _______________________________________________
>> Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org
>> To unsubscribe send an email to wikitech-l-leave@lists.wikimedia.org
>> https://lists.wikimedia.org/postorius/lists/wikitech-l.
>> lists.wikimedia.org/
>
>
Re: Technical Decision Making Retro [ In reply to ]
Hi Brian,

I'm not sure I see the misalignment. Let me rephrase here and see if we can
reach better wording.

The intent of the first phase is to gather information, summarize the
findings and make recommendations. How to act on those recommendations and
implement the changes would happen as part of the second phase.

On Fri, Apr 14, 2023 at 3:29?PM Brian Wolff <bawolff@gmail.com> wrote:

>
> The on wiki page seems to imply the primary output of this process will be
> to decide what needs to be changed, and make those changes. Doesn't get
> much more consequential than that.
>

Based on your summary here I see the current phase is determining what
needs to be changed and the second phase to make those changes.

The group running the process of the retro will be sharing at each step and
asking for feedback. The idea is to manage the information gathering
process with staff-time and shape each step with input from the broader
technical community.

-Kate

--
Kate Chapman (she/her/hers)
Director of Engineering Enablement
Wikimedia Foundation
kchapman@wikimedia.org