Mailing List Archive

Reflecting on my listening tour
[also posted to wikimedia-l]


Hi everyone,

I joined the Wikimedia Foundation on August 1 of last year in a newly
created role as the Chief Product and Technology Officer (CPTO). (For the
first few weeks, some of the staff called me C3PO as they got used to the
new title :) The role was created to bring both the Product and Technology
departments back under a single accountable leader for the first time since
about 2015. Like Maryana
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Chief_Executive_Officer/Maryana%E2%80%99s_Listening_Tour>,
I decided to spend the first few months of my time at Wikimedia listening
and learning. Although I come from the open source technology field, and
have worked with volunteers and communities in prior jobs, it felt
important to start here with curiosity and openness about what’s working
well and what needs to change.

Since then, I have met one on one and in small groups with more than 360
people, who spoke with me from 38 different countries. I also attended 22
large and small convenings and events which included about 3,150 people.
This includes members of the Foundation’s product and technology teams,
other Foundation staff, editors, functionaries, affiliates, movement
organizers and open internet partners. I tried to approach every
conversation with curiosity, openness, and eagerness, letting go of any
preconceptions I may have had (intentionally embracing beginner’s mind
<https://en.wikipedia.org/wiki/Shoshin>) about the Foundation, the
Wikimedia projects, and communities worldwide that contribute to creating
and sharing free knowledge. I can confirm that I quickly found myself awash
in details, experiencing a firehose of information from all sides! My
husband and two young children have also learned a lot more about this
movement in the last six months than you might expect.

To provide myself with some structure, I asked everyone the same kind of
questions about: (1) the impact our product and technology organizations
have had on the movement and/or the world in the last five years, and what
people were most proud of; (2) the current vision and strategy and if they
will take us where we need to go; and (3) the most promising opportunities
that people see in our work, and what is needed to realize that potential.

I want to thank everyone who took the time to share with me, and I’ve
included some direct, anonymized quotes in this letter from the
conversations I had. And I want to confirm that the listening continues — I
will create more spaces in the year ahead for dedicated conversations about
some of the important topics I have highlighted below. I will also be
posting this letter to Meta.

Pulling in the same direction: More visible and shared metrics

On a page of the first notebook I had for my onboarding, I quoted a person
who said they just wanted "meaningful common goals." This was a theme
repeated over and over — a clear desire from everyone to do work together
that was linked by common purpose, and with all the volunteers that have
created all Wikimedia projects. I got to hear so many different voices, and
I heard the details from every side — what’s working, what hasn’t been
working for a long time — some of the problems we face are over ten years
old. People shared what’s missing, what’s extra, who’s fighting to be heard
and who’s feeling lost at sea.

"I think there are lots of promising opportunities to incentivise people to
pay off technical debt and make our existing stack more sustainable. Right
now there are no incentives for engineers in this regard."

"Are we really having impact?"

How can we unite behind meaningful common goals? And which metrics matter
the most? We have so much data, but we really need lodestar
<https://en.wiktionary.org/wiki/lodestar> (or some refer to this as north
star) metrics across the whole Foundation, a system for reviewing and
reflecting on what we learn from them, and then a way to connect those
metrics with the day to day work everyone is doing.

To get at that, we’re doing two main things — one is deepening our
understanding of volunteer activities and the health of the volunteer
communities. This will be through working closely with volunteers using
existing processes and sharing what we’re learning, as well as qualitative
and quantitative research workstreams, including reviewing existing
research of volunteer activities and typical work profiles. The other is
working to establish a set of Foundation-wide lodestar metrics. Shared
metrics help everyone understand how we’re measuring success across the
Foundation, and we’re sharing these publicly as part of our Annual Plan.
Over time, we plan to bring our measures of success for important
initiatives to communities for conversations and debate to help everyone
align what success might look like. Shared metrics and data will empower us
to make more effective and better decisions, along with collaboration with
those who are working on changes and those who may be directly affected by
them.

What does our open source strategy look like for today’s world?

"I strongly believe that Wikipedia will be obsolete by 2030 if we don’t fix
MediaWiki now."

What is our open source strategy?

We have to make some harder choices about what it means to be an
open-source organization, and shift the conversation to resolve historic
debates that prevent us from making important, strategic choices.

Two big areas to resolve are:

-

What is our strategy for MediaWiki support? Today there is a tug of war
about whether we should support MediaWiki for third-party users, even
though their use cases have diverged significantly from those of Wikimedia
projects. I’m planning a MediaWiki convening in late 2023 to begin tackling
this issue.
-

What is our strategy for third-party re-use of Wikimedia content? There
are a lot of nuances around rate limiting and updating the existing API
policies in line with our values around open access. How can we coordinate
more across the Foundation and technical volunteers to build greater
understanding and alignment? Wikimedia project content also has become a
cornerstone of artificial intelligence (AI) products. Wikipedias have long
used machine learning (ML) to improve content and detect vandalism. How can
we help support the use of ML and AI that is a public good? We have
started some
conversations
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/Draft/External_Trends/Community_call_notes>
about this but need to go further.


What will it take to have impact at scale?

"Before we can think about strategy, we need to answer ‘do we want to
change this culture to work with a unified strategy, or do we want to
change the strategy methodology to work with a decentralized culture? Or
some combination thereof?’"

What is our strategy for scaling that will allow us to have the most impact
with limited resources?

Today we support over 750+ distinct Wikimedia projects, with over 300 of
those including language versions of Wikipedia, Wikisource, multiple
language versions of Wiktionary, and many other free knowledge projects.

What is an efficient and responsible way to steward the limited resources
we have towards Wikipedia and/or the sister projects? And similar to the
earlier conversation about Foundation metrics – we must do this in a way
that can have an impact on our mission of bringing free knowledge to the
whole world.

Some of the big questions that came up included consolidation of projects
and the technology underpinning them where it makes sense, and from a
prompt given to me by the Commons community – how can we think even bigger,
and question elephants in the room, which in part would be to examine the
long-standing and seemingly unquestioned assumption that MediaWiki is the
best software to solve all problems we face. And if we do solve big
problems in different ways, what does that look like? What can we learn
from projects like WikiLearn, which uses free software not made by the
Foundation, as well as people and organizations outside our movement? This
is definitely a multi-year, rich problem space to explore.

Everyone’s relationship with English Wikipedia, including the Wikimedia
Foundation’s

"For various reasons, the Foundation and some parts of the communities are
stuck in an uneasy relationship where the Foundation admires but fears the
communities’ power, like a beautiful but dangerous animal – the tiger might
attack you – and the communities, not least English Wikipedia, distrust the
Foundation."

My experience so far has been that we have a very contentious relationship
with English Wikipedia. The Foundation raises most of the revenue to
support a global movement from English Wikipedia, and it’s often where
volunteers raise most of the concerns and objections to the Foundation’s
work.

It's painfully affecting volunteers and staff that are trying to maintain
content and code, and make important improvements to all the websites, as
with the launch of Vector 2022 this year. It has made product and
engineering teams very conservative in their approach to rolling out
features, making each change take 12 or 18 months, or years!, to get
valuable features to users. And it impacts our ability to collaborate with
communities on and off English Wikipedia on big goals like knowledge equity
and the movement strategy recommendations. As Yoda noted
<https://en.wikiquote.org/wiki/Fear#L>, fear is the path to the dark side.
This is a bummer, and I’d like it to change.

So how do we break this cycle? What I’m doing now is directly engaging.
Today, for example, I participated in an office hours session to talk about
Vector 2022. Some of the product senior leadership in the recent past have
specifically avoided talking directly with people on English Wikipedia, and
this approach will no longer be applied. Engaging human to human is the
best way I know to help resolve some of the mystery, fear and anger that
are present. However, that will absolutely not fix what’s wrong here. We
need systemic solutions. Today, there’s no way to make lasting and mutually
binding agreements with volunteers, and that isn’t a sustainable way to
create and maintain infrastructure software. My hope is that, with a more
open and direct approach to engage and also through the work of the
Movement Charter Drafting Committee, we will chart out a path for more
lasting, productive collaboration.

Being more intentional, and also clear, in our technical support for
volunteers

"We lack clear governance and communication for most of our tech
components, squandering a lot of the opportunities we have for more and
better participation from long-time and new volunteers."

How can the Foundation be more intentional about our relationship with all
volunteers?

Today we have few and incomplete policies about what volunteers can do in
technical spaces. We need to chart clearer boundaries, and move more toward
rational and practical policy instead of precedent guiding our work.

Similarly, the technical spaces where the Foundation "stays out" have felt
ad hoc, which led to volunteers stepping in to do important work. The
Foundation needs to exhibit better accountability in maintaining essential
services (e.g. 2-factor authentication), and to be explicit about the
technical tasks that it is definitely leaving for volunteers to own.

Finally, we really need to embrace a product development model that’s more
collaborative and efficient. This calls into question feedback tools like
RfCs, and takes into consideration movement "technology council" proposals.
What will really make us better together? I’m really interested in finding
an answer to this question.

Three Priorities for the Coming Year

What I have identified above are complex issues that cannot be solved in a
single year. We all need to take a multi-year view, especially in order to
define the precise issues that need to be solved more carefully.

For now, you have seen the draft annual plan priorities for the
Foundation’s Product/Tech teams and they include:

- *Volunteers*: We need closer connections, with a focus on making all
time spent volunteering fulfilling and productive. I will continue to talk
directly to volunteers, on-wiki and in person. I am making a shift in our
Annual Plan to support the work and improve the experience of "editors with
extended rights" (inclusive of admins, stewards, patrollers, and moderators
of all kinds, which are also known as functionaries). The work done by this
group on mis- and dis-information and on enforcing our Universal Code of
Conduct is crucial to the functioning of all Wikimedia projects. Success
requires that we are able to have metrics to guide our progress, identify
ways of measuring the health of communities, and that we do this work hand
in hand with volunteers.
- *Maintenance*: Staff and volunteers have both identified that we have
far too many unfinished technical migrations. This means that we continue
to support both old and new tools and ways of doing our technical work.
This increases the workload of everyone, without necessarily adding
features or improving our technical systems overall. Challenges include
issues with Foundation staff and volunteer community decision making,
accountability for that decision making and the best projects to pursue,
and, on the Foundation's side, a desire to not cause upset among
volunteers. As a result, we have many abandoned or poorly maintained tools.
We must be able to choose maintenance and technical migration areas for
prioritization, and then be ok with not doing work on others in order to
complete some of these big projects. For example, we have big work to do on
our data infrastructure, which is aging and made up of more than 40
distinct and fragile systems supported by a tiny team. We also have big
work to do on MediaWiki to ensure it can support our projects for the next
20 years.
- *Decision making*: From the very start of my time with the Foundation,
a common theme that kept coming up was the confusion that internal teams
had around decision making structures and accountability. I heard stories
about teams being indefinitely stuck, unclear decisions from the past, and
an inability to make and keep a decision. I view decision making like
lifting weights: you get good at it by doing it, incrementally and
consistently, over a long period of time. To start, I am making decisions
around the structure and organization of the Product and Technology teams
within the Foundation in order to make decision owners more clear, direct
and transparent. We’re collaborating better together internally, and
raising long-standing unresolved issues between teams in order to resolve
them, one by one. As I look ahead, clarity of decision making and how we
align our work towards our three objectives will be a core part of how I
organize teams.

In addition, I believe that decision making and achieving lasting positive
results needs to be rooted in data. We will identify essential metrics to
evaluate progress and assess impact on the three objectives of our work.
This allows us to stay focused on our most important goals, make
adjustments as needed, and track our progress over time.

I am committed to promoting transparent and accountable decision making at
all levels of management and individual contributor leadership. As I wrote
earlier in this letter, I also welcome ideas on how to build well-defined
processes for engaging with communities and making decisions that endure.
These changes to how we make decisions will allow us to move more quickly,
be more responsive, and create a larger impact for our goals over time.

What’s Next

During my listening tour, some staff asked me an "elephant in the room"
question: why should they trust me? Given the number of different
executives who have come to the Foundation and left within a year or two,
skepticism about yet another new leader is high. My answer was: I believe
the problems we face, as a Foundation and volunteers striving to bring free
knowledge to the world, are complex puzzles that cannot be solved by one
person, and I’m committed to a multi-year approach to collaboratively solve
them together.


Success requires more than a product roadmap. We need deep and effective
collaboration between the Foundation and all volunteers and communities,
shared ways to learn and be successful together, and constant adaptation to
changes in the internet and world, so we can solve the big puzzles we face
together.

Trust is built over time and through consistency, so I don’t ask for trust
as I begin my work. I ask that people be open to working closely together,
learning as much as we can about the important problems we face, and that
we regularly review our work in a data-informed way.

I would like to be direct about how difficult I know some of these topics
are, even for a discussion. But it is our job to tackle the most difficult
questions, especially where inaction due to fear has led to stagnation and
demotivation amongst both our staff and communities. This is not going to
be a quick turnaround. None of these issues will be a quick or easy fix.
Building and improving systems will be a lot of work, and will take a lot
of patience. But the payoff for solving each of these puzzles will be that
we’re able to engage more fully, and maybe even more joyfully, in our work.

My listening tour was an invaluable opportunity to get candid information
about what exactly is working, what isn’t, and what ideas everyone has for
creating something great together. We have a lot of work ahead of us, but
I’m encouraged by the energy and enthusiasm and I know we’ll be able to
tackle this together.

Next time you’ll hear from me is August to share the outcomes of community
discussions related to annual planning
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024>,
and where I think we’re going to have impact in the coming year. In the
meantime, I want to share a few questions that I’ll be returning to
regularly: Are there examples of big issues that we've tackled well as a
movement? Where would you suggest I draw inspiration? What's worked well?
These are the complex issues that will guide my priorities over the coming
years. What elephants am I missing?

As I shared when I joined
<https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/XO27SCB2UKZ6H6YRKFZLBR4URFW2VPGW/>,
I came to work for the Wikimedia Foundation because free access to
knowledge is the most important thing I can be doing right now. Our work
empowers the people who have knowledge to share. By involving youth, women,
and underrepresented identities to contribute their unique knowledge, we
will continue our journey to share the sum of all human knowledge. And this
kind of mission cannot be accomplished by any one person alone; we are
called to – and I feel strongly committed to – collaborate and truly be in
this mission together.

-selena
Re: Reflecting on my listening tour [ In reply to ]
Thank you for this email. I appreciate your effort to tackle difficult
problems head on and in recognizing our problems are socio-technical, not
just technical. This email is probably one of the most reassuring things I
have read from someone in WMF management in a very long time. There were
some parts I wanted to give my 2 cents on.

> "I think there are lots of promising opportunities to incentivise people
to pay off technical debt and make our existing stack more sustainable.
Right now there are no incentives for engineers in this regard."

Interesting. Personally to me, it can sometimes feel like we never stop
talking about technical debt. While I think paying off technical debt is
important, at times I feel like we've swung in the opposite direction where
we are essentially rewriting things for the sake of rewriting things.

> "I strongly believe that Wikipedia will be obsolete by 2030 if we don’t
fix MediaWiki now."

A bold statement. And I appreciate that these headers are meant to trigger
thoughts and not be a firm arguments. However, I would certainly be curious
though as to the "why" of that statement, in your view.

> What is our strategy for MediaWiki support? Today there is a tug of war
about whether we should support MediaWiki for third-party users, even
though their use cases have diverged significantly from those of Wikimedia
projects. I’m planning a MediaWiki convening in late 2023 to begin tackling
this issue.

I would disagree that third party use cases have diverged at all from
Wikimedia projects, let alone significantly. (Speaking generally. Of course
the wide internet includes people doing crazy things). Perhaps this is not
the time to discuss this, but I would certainly be curious to know what
people in WMF think the third party use case is that doesn't match with
Wikimedia's.

> What will it take to have impact at scale?

Aren't we already at scale? (With perhaps the exception of WDQS, which does
have significant scaling issues on the horizion). Our exponential growth
phase is long over and we have largely come out on the other side. Unless
you mean scaling our social decision making structures, in which case I
would agree that we have failed to scale that effectively in the past.

> how can we think even bigger, and question elephants in the room, which
in part would be to examine the long-standing and seemingly unquestioned
assumption that MediaWiki is the best software to solve all problems we face

I disagree that it is unquestioned. People have talked about this in the
past. However usually it goes nowhere because (imho) the people who in the
past have brought it up often don't fully understand how MediaWiki's is
actually used and suggested solutions that don't really fit our needs. So
perhaps you're right that it hasn't been seriously brought up. However,
replacing software is much like rewriting it. There's a lot of hidden
gotchas.

>Some of the product senior leadership in the recent past have specifically
avoided talking directly with people on English Wikipedia, and this
approach will no longer be applied. Engaging human to human is the best way
I know to help resolve some of the mystery, fear and anger that are present.

This is excellent. The hiding behind an anonoymous corporate fascade is a
major contibuting factor to so many problems (not all of them of course).

> However, that will absolutely not fix what’s wrong here. We need systemic
solutions. Today, there’s no way to make lasting and mutually binding
agreements with volunteers, and that isn’t a sustainable way to create and
maintain infrastructure software.

There can't be any agreement without consent, and there can't be any
consent when WMF ignores answers when they are inconvinent. Good luck with
this, it will be hard. Fixing the relationship with the community is
probably the most effective thing you could hope to accomplish. I think its
possible, but we got to the place we are now over many years and decades of
broken trust, which will take time to rebuild.

I think an underappreciated factor here, is there are cultural differences
between WMF staff and communities. How they talk. How they solve disputes.
What motivates them. What sounds inauthentic. What statements sound
insulting. etc. Some problems really do just start as miscommunication
between people of different cultural backgrounds failing to communicate.
Its been a long time since I worked at the foundation, so perhaps things
have changed, but from what i remember, there was very little to prepare
staff that don't have a community background how to "fit in" to the
community. After all, how could you trust someone to redesign Wikipedia who
doesn't even seem to know the basics of how Wikipedia works? Even simple
things like failing to sign a talk page post rapidly signals that the
person is an outsider who knows nothing of what it is like to edit the
site. Anyways, one thing I'd like to see is more cultural (for lack of a
better word) training to new staff so they know how to behave on a wiki.

> "We lack clear governance and communication for most of our tech
components, squandering a lot of the opportunities we have for more and
better participation from long-time and new volunteers."

Agree 1000%.

> Similarly, the technical spaces where the Foundation "stays out" have
felt ad hoc, which led to volunteers stepping in to do important work. The
Foundation needs to exhibit better accountability in maintaining essential
services (e.g. 2-factor authentication), and to be explicit about the
technical tasks that it is definitely leaving for volunteers to own.


Indeed. I feel that in the past this may even have lead to resentment. A
feeling that WMF staff end up working on vanity projects, while leaving the
important job of making sure the site works to volunteers. Things have
improved on that front in recent years.


However, i would add its not just volunteers. I can't speak to the current
state, but in the past there was a sense that a lot of critical work was
done by WMF staff in a volunteer/off the record capacity, basically when
their managers weren't looking. This sort of system is exploitative and
unfair to those stuck with the unappreciated but critical work.


As I said, i believe the situation now isn't as bad as in the past, and I
look forward to it improving even further. However I hope it doesn't come
at the cost of volunteers being able to take leadership roles in our code
base.


> Finally, we really need to embrace a product development model that’s
more collaborative and efficient. This calls into question feedback tools
like RfCs, and takes into consideration movement "technology council"
proposals. What will really make us better together? I’m really interested
in finding an answer to this question.


Well, the bar is pretty low on that front ;)


> During my listening tour, some staff asked me an "elephant in the room"
question: why should they trust me? Given the number of different
executives who have come to the Foundation and left within a year or two,
skepticism about yet another new leader is high. My answer was: I believe
the problems we face, as a Foundation and volunteers striving to bring free
knowledge to the world, are complex puzzles that cannot be solved by one
person, and I’m committed to a multi-year approach to collaboratively solve
them together.


I think you're off to a really good start :)


> Trust is built over time and through consistency, so I don’t ask for
trust as I begin my work. I ask that people be open to working closely
together, learning as much as we can about the important problems we face,
and that we regularly review our work in a data-informed way.


Agree 100%


One thing I'll note about data. Sometimes there can be mistrust when the
team proposing something also gathers the data to support the decision.
There's been instances in the past where it has been felt that data was
gathered or presented in misleading ways to support a narrative. Of course,
even with the best of intentions, we all have unconcious biases as well
that can affect data collection. I don't have a solution for this, but
something to keep in mind in the context of community relations.


I look forward to seeing the results of all the things you said.


Thanks,

Brian



On Thu,Apr 13, 2023 at 4:55?PM Selena Deckelmann <sdeckelmann@wikimedia.org>
wrote:

> [also posted to wikimedia-l]
>
>
> Hi everyone,
>
> I joined the Wikimedia Foundation on August 1 of last year in a newly
> created role as the Chief Product and Technology Officer (CPTO). (For the
> first few weeks, some of the staff called me C3PO as they got used to the
> new title :) The role was created to bring both the Product and Technology
> departments back under a single accountable leader for the first time since
> about 2015. Like Maryana
> <https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Chief_Executive_Officer/Maryana%E2%80%99s_Listening_Tour>,
> I decided to spend the first few months of my time at Wikimedia listening
> and learning. Although I come from the open source technology field, and
> have worked with volunteers and communities in prior jobs, it felt
> important to start here with curiosity and openness about what’s working
> well and what needs to change.
>
> Since then, I have met one on one and in small groups with more than 360
> people, who spoke with me from 38 different countries. I also attended 22
> large and small convenings and events which included about 3,150 people.
> This includes members of the Foundation’s product and technology teams,
> other Foundation staff, editors, functionaries, affiliates, movement
> organizers and open internet partners. I tried to approach every
> conversation with curiosity, openness, and eagerness, letting go of any
> preconceptions I may have had (intentionally embracing beginner’s mind
> <https://en.wikipedia.org/wiki/Shoshin>) about the Foundation, the
> Wikimedia projects, and communities worldwide that contribute to creating
> and sharing free knowledge. I can confirm that I quickly found myself awash
> in details, experiencing a firehose of information from all sides! My
> husband and two young children have also learned a lot more about this
> movement in the last six months than you might expect.
>
> To provide myself with some structure, I asked everyone the same kind of
> questions about: (1) the impact our product and technology organizations
> have had on the movement and/or the world in the last five years, and what
> people were most proud of; (2) the current vision and strategy and if they
> will take us where we need to go; and (3) the most promising opportunities
> that people see in our work, and what is needed to realize that potential.
>
> I want to thank everyone who took the time to share with me, and I’ve
> included some direct, anonymized quotes in this letter from the
> conversations I had. And I want to confirm that the listening continues — I
> will create more spaces in the year ahead for dedicated conversations about
> some of the important topics I have highlighted below. I will also be
> posting this letter to Meta.
>
> Pulling in the same direction: More visible and shared metrics
>
> On a page of the first notebook I had for my onboarding, I quoted a person
> who said they just wanted "meaningful common goals." This was a theme
> repeated over and over — a clear desire from everyone to do work together
> that was linked by common purpose, and with all the volunteers that have
> created all Wikimedia projects. I got to hear so many different voices, and
> I heard the details from every side — what’s working, what hasn’t been
> working for a long time — some of the problems we face are over ten years
> old. People shared what’s missing, what’s extra, who’s fighting to be heard
> and who’s feeling lost at sea.
>
> "I think there are lots of promising opportunities to incentivise people
> to pay off technical debt and make our existing stack more sustainable.
> Right now there are no incentives for engineers in this regard."
>
> "Are we really having impact?"
>
> How can we unite behind meaningful common goals? And which metrics matter
> the most? We have so much data, but we really need lodestar
> <https://en.wiktionary.org/wiki/lodestar> (or some refer to this as north
> star) metrics across the whole Foundation, a system for reviewing and
> reflecting on what we learn from them, and then a way to connect those
> metrics with the day to day work everyone is doing.
>
> To get at that, we’re doing two main things — one is deepening our
> understanding of volunteer activities and the health of the volunteer
> communities. This will be through working closely with volunteers using
> existing processes and sharing what we’re learning, as well as qualitative
> and quantitative research workstreams, including reviewing existing
> research of volunteer activities and typical work profiles. The other is
> working to establish a set of Foundation-wide lodestar metrics. Shared
> metrics help everyone understand how we’re measuring success across the
> Foundation, and we’re sharing these publicly as part of our Annual Plan.
> Over time, we plan to bring our measures of success for important
> initiatives to communities for conversations and debate to help everyone
> align what success might look like. Shared metrics and data will empower us
> to make more effective and better decisions, along with collaboration with
> those who are working on changes and those who may be directly affected by
> them.
>
> What does our open source strategy look like for today’s world?
>
> "I strongly believe that Wikipedia will be obsolete by 2030 if we don’t
> fix MediaWiki now."
>
> What is our open source strategy?
>
> We have to make some harder choices about what it means to be an
> open-source organization, and shift the conversation to resolve historic
> debates that prevent us from making important, strategic choices.
>
> Two big areas to resolve are:
>
> -
>
> What is our strategy for MediaWiki support? Today there is a tug of
> war about whether we should support MediaWiki for third-party users, even
> though their use cases have diverged significantly from those of Wikimedia
> projects. I’m planning a MediaWiki convening in late 2023 to begin tackling
> this issue.
> -
>
> What is our strategy for third-party re-use of Wikimedia content?
> There are a lot of nuances around rate limiting and updating the existing
> API policies in line with our values around open access. How can we
> coordinate more across the Foundation and technical volunteers to build
> greater understanding and alignment? Wikimedia project content also has
> become a cornerstone of artificial intelligence (AI) products. Wikipedias
> have long used machine learning (ML) to improve content and detect
> vandalism. How can we help support the use of ML and AI that is a public
> good? We have started some conversations
> <https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/Draft/External_Trends/Community_call_notes>
> about this but need to go further.
>
>
> What will it take to have impact at scale?
>
> "Before we can think about strategy, we need to answer ‘do we want to
> change this culture to work with a unified strategy, or do we want to
> change the strategy methodology to work with a decentralized culture? Or
> some combination thereof?’"
>
> What is our strategy for scaling that will allow us to have the most
> impact with limited resources?
>
> Today we support over 750+ distinct Wikimedia projects, with over 300 of
> those including language versions of Wikipedia, Wikisource, multiple
> language versions of Wiktionary, and many other free knowledge projects.
>
> What is an efficient and responsible way to steward the limited resources
> we have towards Wikipedia and/or the sister projects? And similar to the
> earlier conversation about Foundation metrics – we must do this in a way
> that can have an impact on our mission of bringing free knowledge to the
> whole world.
>
> Some of the big questions that came up included consolidation of projects
> and the technology underpinning them where it makes sense, and from a
> prompt given to me by the Commons community – how can we think even bigger,
> and question elephants in the room, which in part would be to examine the
> long-standing and seemingly unquestioned assumption that MediaWiki is the
> best software to solve all problems we face. And if we do solve big
> problems in different ways, what does that look like? What can we learn
> from projects like WikiLearn, which uses free software not made by the
> Foundation, as well as people and organizations outside our movement? This
> is definitely a multi-year, rich problem space to explore.
>
> Everyone’s relationship with English Wikipedia, including the Wikimedia
> Foundation’s
>
> "For various reasons, the Foundation and some parts of the communities are
> stuck in an uneasy relationship where the Foundation admires but fears the
> communities’ power, like a beautiful but dangerous animal – the tiger might
> attack you – and the communities, not least English Wikipedia, distrust the
> Foundation."
>
> My experience so far has been that we have a very contentious relationship
> with English Wikipedia. The Foundation raises most of the revenue to
> support a global movement from English Wikipedia, and it’s often where
> volunteers raise most of the concerns and objections to the Foundation’s
> work.
>
> It's painfully affecting volunteers and staff that are trying to maintain
> content and code, and make important improvements to all the websites, as
> with the launch of Vector 2022 this year. It has made product and
> engineering teams very conservative in their approach to rolling out
> features, making each change take 12 or 18 months, or years!, to get
> valuable features to users. And it impacts our ability to collaborate with
> communities on and off English Wikipedia on big goals like knowledge equity
> and the movement strategy recommendations. As Yoda noted
> <https://en.wikiquote.org/wiki/Fear#L>, fear is the path to the dark
> side. This is a bummer, and I’d like it to change.
>
> So how do we break this cycle? What I’m doing now is directly engaging.
> Today, for example, I participated in an office hours session to talk about
> Vector 2022. Some of the product senior leadership in the recent past have
> specifically avoided talking directly with people on English Wikipedia, and
> this approach will no longer be applied. Engaging human to human is the
> best way I know to help resolve some of the mystery, fear and anger that
> are present. However, that will absolutely not fix what’s wrong here. We
> need systemic solutions. Today, there’s no way to make lasting and mutually
> binding agreements with volunteers, and that isn’t a sustainable way to
> create and maintain infrastructure software. My hope is that, with a more
> open and direct approach to engage and also through the work of the
> Movement Charter Drafting Committee, we will chart out a path for more
> lasting, productive collaboration.
>
> Being more intentional, and also clear, in our technical support for
> volunteers
>
> "We lack clear governance and communication for most of our tech
> components, squandering a lot of the opportunities we have for more and
> better participation from long-time and new volunteers."
>
> How can the Foundation be more intentional about our relationship with all
> volunteers?
>
> Today we have few and incomplete policies about what volunteers can do in
> technical spaces. We need to chart clearer boundaries, and move more toward
> rational and practical policy instead of precedent guiding our work.
>
> Similarly, the technical spaces where the Foundation "stays out" have felt
> ad hoc, which led to volunteers stepping in to do important work. The
> Foundation needs to exhibit better accountability in maintaining essential
> services (e.g. 2-factor authentication), and to be explicit about the
> technical tasks that it is definitely leaving for volunteers to own.
>
> Finally, we really need to embrace a product development model that’s more
> collaborative and efficient. This calls into question feedback tools like
> RfCs, and takes into consideration movement "technology council" proposals.
> What will really make us better together? I’m really interested in finding
> an answer to this question.
>
> Three Priorities for the Coming Year
>
> What I have identified above are complex issues that cannot be solved in a
> single year. We all need to take a multi-year view, especially in order to
> define the precise issues that need to be solved more carefully.
>
> For now, you have seen the draft annual plan priorities for the
> Foundation’s Product/Tech teams and they include:
>
> - *Volunteers*: We need closer connections, with a focus on making all
> time spent volunteering fulfilling and productive. I will continue to talk
> directly to volunteers, on-wiki and in person. I am making a shift in our
> Annual Plan to support the work and improve the experience of "editors with
> extended rights" (inclusive of admins, stewards, patrollers, and moderators
> of all kinds, which are also known as functionaries). The work done by this
> group on mis- and dis-information and on enforcing our Universal Code of
> Conduct is crucial to the functioning of all Wikimedia projects. Success
> requires that we are able to have metrics to guide our progress, identify
> ways of measuring the health of communities, and that we do this work hand
> in hand with volunteers.
> - *Maintenance*: Staff and volunteers have both identified that we
> have far too many unfinished technical migrations. This means that we
> continue to support both old and new tools and ways of doing our technical
> work. This increases the workload of everyone, without necessarily adding
> features or improving our technical systems overall. Challenges include
> issues with Foundation staff and volunteer community decision making,
> accountability for that decision making and the best projects to pursue,
> and, on the Foundation's side, a desire to not cause upset among
> volunteers. As a result, we have many abandoned or poorly maintained tools.
> We must be able to choose maintenance and technical migration areas for
> prioritization, and then be ok with not doing work on others in order to
> complete some of these big projects. For example, we have big work to do on
> our data infrastructure, which is aging and made up of more than 40
> distinct and fragile systems supported by a tiny team. We also have big
> work to do on MediaWiki to ensure it can support our projects for the next
> 20 years.
> - *Decision making*: From the very start of my time with the
> Foundation, a common theme that kept coming up was the confusion that
> internal teams had around decision making structures and accountability. I
> heard stories about teams being indefinitely stuck, unclear decisions from
> the past, and an inability to make and keep a decision. I view decision
> making like lifting weights: you get good at it by doing it, incrementally
> and consistently, over a long period of time. To start, I am making
> decisions around the structure and organization of the Product and
> Technology teams within the Foundation in order to make decision owners
> more clear, direct and transparent. We’re collaborating better together
> internally, and raising long-standing unresolved issues between teams in
> order to resolve them, one by one. As I look ahead, clarity of decision
> making and how we align our work towards our three objectives will be a
> core part of how I organize teams.
>
> In addition, I believe that decision making and achieving lasting positive
> results needs to be rooted in data. We will identify essential metrics to
> evaluate progress and assess impact on the three objectives of our work.
> This allows us to stay focused on our most important goals, make
> adjustments as needed, and track our progress over time.
>
> I am committed to promoting transparent and accountable decision making at
> all levels of management and individual contributor leadership. As I wrote
> earlier in this letter, I also welcome ideas on how to build well-defined
> processes for engaging with communities and making decisions that endure.
> These changes to how we make decisions will allow us to move more quickly,
> be more responsive, and create a larger impact for our goals over time.
>
> What’s Next
>
> During my listening tour, some staff asked me an "elephant in the room"
> question: why should they trust me? Given the number of different
> executives who have come to the Foundation and left within a year or two,
> skepticism about yet another new leader is high. My answer was: I believe
> the problems we face, as a Foundation and volunteers striving to bring free
> knowledge to the world, are complex puzzles that cannot be solved by one
> person, and I’m committed to a multi-year approach to collaboratively solve
> them together.
>
>
> Success requires more than a product roadmap. We need deep and effective
> collaboration between the Foundation and all volunteers and communities,
> shared ways to learn and be successful together, and constant adaptation to
> changes in the internet and world, so we can solve the big puzzles we face
> together.
>
> Trust is built over time and through consistency, so I don’t ask for trust
> as I begin my work. I ask that people be open to working closely together,
> learning as much as we can about the important problems we face, and that
> we regularly review our work in a data-informed way.
>
> I would like to be direct about how difficult I know some of these topics
> are, even for a discussion. But it is our job to tackle the most difficult
> questions, especially where inaction due to fear has led to stagnation and
> demotivation amongst both our staff and communities. This is not going to
> be a quick turnaround. None of these issues will be a quick or easy fix.
> Building and improving systems will be a lot of work, and will take a lot
> of patience. But the payoff for solving each of these puzzles will be that
> we’re able to engage more fully, and maybe even more joyfully, in our work.
>
> My listening tour was an invaluable opportunity to get candid information
> about what exactly is working, what isn’t, and what ideas everyone has for
> creating something great together. We have a lot of work ahead of us, but
> I’m encouraged by the energy and enthusiasm and I know we’ll be able to
> tackle this together.
>
> Next time you’ll hear from me is August to share the outcomes of community
> discussions related to annual planning
> <https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024>,
> and where I think we’re going to have impact in the coming year. In the
> meantime, I want to share a few questions that I’ll be returning to
> regularly: Are there examples of big issues that we've tackled well as a
> movement? Where would you suggest I draw inspiration? What's worked well?
> These are the complex issues that will guide my priorities over the coming
> years. What elephants am I missing?
>
> As I shared when I joined
> <https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/XO27SCB2UKZ6H6YRKFZLBR4URFW2VPGW/>,
> I came to work for the Wikimedia Foundation because free access to
> knowledge is the most important thing I can be doing right now. Our work
> empowers the people who have knowledge to share. By involving youth, women,
> and underrepresented identities to contribute their unique knowledge, we
> will continue our journey to share the sum of all human knowledge. And this
> kind of mission cannot be accomplished by any one person alone; we are
> called to – and I feel strongly committed to – collaborate and truly be in
> this mission together.
>
> -selena
> _______________________________________________
> 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: Reflecting on my listening tour [ In reply to ]
On Thu, 2023-04-13 at 20:06 -0700, bawolff wrote:
> > "I think there are lots of promising opportunities to incentivise
> > people to pay off technical debt and make our existing stack more
> > sustainable. Right now there are no incentives for engineers in
> > this regard."
>
> Interesting. Personally to me, it can sometimes feel like we never
> stop talking about technical debt. While I think paying off technical
> debt is important, at times I feel like we've swung in the opposite
> direction where we are essentially rewriting things for the sake of
> rewriting things.

"Technical debt" spontaneously brings the following items to my little
mind. They should not be about rewriting but rather "maintenance":

* librsvg for SVG rendering is a five year old version:
https://phabricator.wikimedia.org/T193352 /
https://phabricator.wikimedia.org/T265549
* Graph extension on old Vega version 2.6.3: see subtasks of
https://phabricator.wikimedia.org/T292341
* Scribunto extension on old Lua version 5.1 (last 5.1.x release was
in 2012): https://phabricator.wikimedia.org/T178146
* 3D extension on a five year old three.js library in
https://phabricator.wikimedia.org/T277930#7636129
* Removing the OpenStackManager extension from wikitech.wm.org:
https://phabricator.wikimedia.org/T161553
* Removing WVUI from MediaWiki
core: https://phabricator.wikimedia.org/T310244
* Replacing jsduck with JSDoc3 across all Wikimedia code bases:
https://phabricator.wikimedia.org/T138401
* Undeploy VipsScaler from Wikimedia wikis:
https://phabricator.wikimedia.org/T290759
* https://phabricator.wikimedia.org/T151393 (a non-public task)

This is not a complete list. Plus there are also separate "waiting for
someone to make a decision" and "improving communicating & documenting
already-made decisions" categories which would be different lists.

Of course there might be valid reasons not to look into some of this
technical debt (other higher priorities, high risk, complexity, etc).

Cheers,
andre

--
Andre Klapper (he/him) | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/
_______________________________________________
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: Reflecting on my listening tour [ In reply to ]
Hello Selena,

from my point of view it is important to build trust between the Wikimedia Foundation and the community. It is great that you mentioned in your email that there are problems regarding trust into the Wikimedia Foundation of parts of the community at the moment. I have difficulties understanding where the money raised through small donations is spent for and I often dont trust the Wikimedia Foundation that the money is spent in an effective way. So I think I belong the group of people with a at least lower trust level regarding the Wikimedia Foundation as in general. At the annual plan discussions there is the possibility to share thoughts about the priorities. I wish a current org chart to get an overview about who is working for the Wikimedia Foundation or in another Wikimedia organization on tech related topics. If such an org chart actually exists please share a link. There are a lot of challenges and I wish you success in your task and I hope it will be possible to fix some the issues to ensure a secure operation of the Infrastructure of the Wikimedia projects for the next years.

Hogü-456
_______________________________________________
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: Reflecting on my listening tour [ In reply to ]
Hi Hogü-456,

I just wanted to jump in with a link to
https://www.mediawiki.org/wiki/Wikimedia_Product - a page that we recently
updated to list out the Wikimedia Foundation product teams, highlight their
areas of work, and link to venues where you can have input on those
projects. We're endeavouring to keep it more up to date than it has been in
the past. I appreciate that's not a full org chart but I thought it might
be helpful on the Product side of things.

Best,
Sam

On Fri, 14 Apr 2023 at 20:04, <tim.herb@gmx.de> wrote:

> Hello Selena,
>
> from my point of view it is important to build trust between the Wikimedia
> Foundation and the community. It is great that you mentioned in your email
> that there are problems regarding trust into the Wikimedia Foundation of
> parts of the community at the moment. I have difficulties understanding
> where the money raised through small donations is spent for and I often
> dont trust the Wikimedia Foundation that the money is spent in an effective
> way. So I think I belong the group of people with a at least lower trust
> level regarding the Wikimedia Foundation as in general. At the annual plan
> discussions there is the possibility to share thoughts about the
> priorities. I wish a current org chart to get an overview about who is
> working for the Wikimedia Foundation or in another Wikimedia organization
> on tech related topics. If such an org chart actually exists please share a
> link. There are a lot of challenges and I wish you success in your task and
> I hope it will be possible to fix some the issues to ensure a secure
> operation of the Infrastructure of the Wikimedia projects for the next
> years.
>
> Hogü-456
> _______________________________________________
> 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/



--
Sam Walton
Senior Product Manager, Moderator Tools

swalton@wikimedia.org
Re: Reflecting on my listening tour [ In reply to ]
This is not really about Selena's email but it's so nerdy I still want to
talk about what tech debt is and what it isn't.

The word tech debt at the beginning meant a very specific thing: When an
engineer takes a shortcut to deliver a feature faster. Daniel has a pretty
good essay on tech debt: https://www.mediawiki.org/wiki/The_Tech_Debt_Trap

But the term slowly became so overused that engineers used it to refer to
any invisible work they couldn't tie into a feature. At this point, people
refer to tech debt as the general maintenance practically. And that led to
non-tech people to slowly disregard maintenance work because everything is
tech debt now.

What tech debt is not (this is not a MECE list):

- Keep the lights on: OS upgrades, security updates, hw maintenance,
incidents, ...
- Bitrot: The code stays the same but the underlying technology changes,
the usage pattern changes, requirements changes, etc.
- Over-engineering: This is way more common than you think. Building an
overly complex palace that no one can maintain anymore because no one
understands it and everyone is afraid to remove anything. This is sorta the
opposite of tech debt, people spent more resources than they should and
it's still hurting us.
- Plain bad engineering: People make mistakes, typos are easily fixable
while architectural mistakes are not, sometimes we know it because of
hindsight, sometimes it was obvious from the beginning.
- Limiting architecture: Many architectural decisions come in the form
of trade-offs, a classic example is performance vs. security. If someone
wants something and it's not possible due to architectural limitations, it
doesn't necessarily mean a bad thing. We sacrificed something in favor of
the other.
- Code hygiene: Improvements on readability and maintainability of the
code.
- Scale/Performance/Security considerations: I have seen that people see
a prototype and want it in Wikipedia right now. I understand it but any
solution on such a large scale comes with all sorts of edge cases and
hidden costs. People bash MediaWiki for being too complex and messy but
anything you build at the scale of Wikipedia is going to be complex and
messy. If a solution takes years, sometimes that's the only option.

What I want to say is that while we do have a tech debt problem in
Wikimedia, we also have a lot of bitrot problems too, or any other "slowing
down development" kind of problem. Some cases it's fixable, in some cases
it is not. What is needed is more resources on maintenance which is
happening and is making me extremely happy. Whether we call that paying
back tech debt or not.


Am Fr., 14. Apr. 2023 um 23:44 Uhr schrieb Brian Wolff <bawolff@gmail.com>:

> Perhaps i am hyperfocused on technical debt in the sense of improving the
> abstractions used in mediawiki. The phrasing around sustainability
> especially leads me in that direction. However, technical debt is certainly
> a broad concept and can mean a lot of things.
>
> The common thread in the examples you cited seem to be things that have
> fallen through the ownership cracks. I'm not sure its the case that
> engineers aren't incentivized to fix these, so much as there are no natural
> engineers to be incentivized due to team structure (scribunto is an
> exception but i would disagree with that task's inclusion for reasons that
> get off topic). On the other hand, perhaps a different incentivization
> structure would encourage people to branch out more.
>
> I think it is especially telling that 3 (or 4 even) of these tasks are
> multimedia related, given that wmf hasn't had a multimedia team in a very
> long time [SDC does not count], and definitely not one focused on the
> backend. There are quite a few multimedia related areas in desperate need
> of love (it is 2023 and video uploads are limited to 4gb with the flakiest
> upload process known to man).
>
>
> It was also pointed out to me on irc, that many critical workflows in the
> community depend on toolforge tools that have very limited volunteer
> maintainership. A sort of https://xkcd.com/2347/ situation. Just because
> they're not "production" we often pretend they don't exist. Regardless of
> how we label them, in the end it doesn't make a difference to the end user,
> and the fragility of that ecosystem is a form of technical debt that is
> often overlooked.
>
>
> So i guess it all depends on what is meant by "technical debt"
> --
> Brian
>
> On Friday, April 14, 2023, Andre Klapper <aklapper@wikimedia.org> wrote:
>
>> On Thu, 2023-04-13 at 20:06 -0700, bawolff wrote:
>> > > "I think there are lots of promising opportunities to incentivise
>> > > people to pay off technical debt and make our existing stack more
>> > > sustainable. Right now there are no incentives for engineers in
>> > > this regard."
>> >
>> > Interesting. Personally to me, it can sometimes feel like we never
>> > stop talking about technical debt. While I think paying off technical
>> > debt is important, at times I feel like we've swung in the opposite
>> > direction where we are essentially rewriting things for the sake of
>> > rewriting things.
>>
>> "Technical debt" spontaneously brings the following items to my little
>> mind. They should not be about rewriting but rather "maintenance":
>>
>> * librsvg for SVG rendering is a five year old version:
>> https://phabricator.wikimedia.org/T193352 /
>> https://phabricator.wikimedia.org/T265549
>> * Graph extension on old Vega version 2.6.3: see subtasks of
>> https://phabricator.wikimedia.org/T292341
>> * Scribunto extension on old Lua version 5.1 (last 5.1.x release was
>> in 2012): https://phabricator.wikimedia.org/T178146
>> * 3D extension on a five year old three.js library in
>> https://phabricator.wikimedia.org/T277930#7636129
>> * Removing the OpenStackManager extension from wikitech.wm.org:
>> https://phabricator.wikimedia.org/T161553
>> * Removing WVUI from MediaWiki
>> core: https://phabricator.wikimedia.org/T310244
>> * Replacing jsduck with JSDoc3 across all Wikimedia code bases:
>> https://phabricator.wikimedia.org/T138401
>> * Undeploy VipsScaler from Wikimedia wikis:
>> https://phabricator.wikimedia.org/T290759
>> * https://phabricator.wikimedia.org/T151393 (a non-public task)
>>
>> This is not a complete list. Plus there are also separate "waiting for
>> someone to make a decision" and "improving communicating & documenting
>> already-made decisions" categories which would be different lists.
>>
>> Of course there might be valid reasons not to look into some of this
>> technical debt (other higher priorities, high risk, complexity, etc).
>>
>> Cheers,
>> andre
>>
>> --
>> Andre Klapper (he/him) | Bugwrangler / Developer Advocate
>> https://blogs.gnome.org/aklapper/
>> _______________________________________________
>> 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/
>
> _______________________________________________
> 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/



--
Amir (he/him)
Re: Reflecting on my listening tour [ In reply to ]
Despite agreeing wholeheartedly that technical debt, product debt,
ownership, and maintenance are persistent problems, here's a story about
when this *didn't* happen, which maybe we can learn from.

Disclaimer: this is from my memory of 2014! Warning, potential inaccuracy
and rose-tinted glasses!

We had a global login system (single user login, or SUL) but it was in a
bit of disarray. There were many local accounts disconnected from global
ones because they were made before the global login system, many username
conflicts that went unaddressed. Users were given some tools to resolve
these conflicts, but not enough to actually finalise the whole thing. We
all agreed it needed solving. We all new the end state we wanted. But,
there were multiple technical and product solutions to get there, and no
actual concerted effort to do it. Many of the username conflicts were
between long-time community members, so we were sure to get some dedicated
volutneers angry no matter how we did it. So it sat in limbo, annoying
everyone, and never happening. Sound familiar?

Around then, WMF leadership introduced a new prioritisation framework: "top
5 priorities". This was a ranked list of projects that were considered to
be more important than others for that quarter. It was intended as a first
attempt to combat the "if everything's important, nothing's important"
syndrome. You can't argue with a ranked list! And, number one on the list
for the first quarter, not something new and shiny, but an old one: the SUL
finalisation <https://www.mediawiki.org/wiki/SUL_finalisation>! Sort it all
out, once and for all.

Erik Möller (the then VP of Product and Engineering, de facto CPO and CTO
really, reflecting on it) asked me to be the product manager. I was very
inexperienced as a PM but had been an editor for eight years, so I
understood the problem well. Still, I wondered how we were possibly going
to achieve anything, the project had been "in progress" for years with
almost no progress. Erik asked me what I needed to make it happen. I got
some advice, and said I need a systems designer, a systems architect, an
engineer that knows the community well, and a community liaison. Erik went
and had the hard conversations with the people that currently needed said
people ("It's top priority this quarter, the other stuff has to wait.") and
went and got those people. We figured it all out, and we did it, once and
for all (timeline reduced, it did still take multiple quarters, but we knew
that going in). Everyone now has a fully global account!

Now, times were simpler back then. This exact technique wouldn't work now,
for multiple reasons. But, I wonder what we can learn from this as an
organisation. What would it take to repeat this achievement?

Dan

P.S. Some of that team I worked with are still on this list. Hello! Thank
you for the growth as a PM that I got out of that project, and for beating
my inexperienced head around a bit until it got more experienced.
Re: Reflecting on my listening tour [ In reply to ]
Hi Dan,

Thank you so much for sharing this story.

Similarly, I once was colleagues with a group of people working on process
isolation (
https://en.m.wikipedia.org/wiki/Process_isolation) for Firefox. They had
sort of hit a wall where the memory usage was going to be far more that we
thought users could tolerate, and fixing the memory problems would take
quite a few more engineers than anyone thought we could spare. Then,
Spectre/Meltdown (
https://meltdownattack.com/) happened. It so happened that we were together
at an all company meeting, so a group of us got together in a room and
talked about what we needed. The group left the room understanding that
this work was critically important, that we needed a dedicated team, and we
ended up forming a larger team to ship the work with the support (although
not unanimous!) of managers and staff. A lot more to the story before and
after, but that was the beginning of phase where Firefox ended up actually
shipping process isolation.

What I learned is that it’s possible for critically important change to
happen that might be stuck if we all have a very good reason to move it
forward (like a very scary security problem!).

The challenge in prioritization I see for WMF is that we need to find these
good reasons, prioritize and do work in small enough chunks that we are
able to evaluate progress and adjust course where needed. It’s common to
slip into analysis paralysis, or believe that it’s too hard to set short
term milestones that deliver significant value to someone.

Finding ways to move forward together this way is what I see as the path.
It has part of the urgency in your story or mine (Meltdown vulns
fortunately aren’t happening every quarter!), but balanced with some kind
of repeatable process.

-selena


On Mon, Apr 17, 2023 at 3:18 PM Dan Garry (Deskana) <djgwiki@gmail.com>
wrote:

> Despite agreeing wholeheartedly that technical debt, product debt,
> ownership, and maintenance are persistent problems, here's a story about
> when this *didn't* happen, which maybe we can learn from.
>
> Disclaimer: this is from my memory of 2014! Warning, potential inaccuracy
> and rose-tinted glasses!
>
> We had a global login system (single user login, or SUL) but it was in a
> bit of disarray. There were many local accounts disconnected from global
> ones because they were made before the global login system, many username
> conflicts that went unaddressed. Users were given some tools to resolve
> these conflicts, but not enough to actually finalise the whole thing. We
> all agreed it needed solving. We all new the end state we wanted. But,
> there were multiple technical and product solutions to get there, and no
> actual concerted effort to do it. Many of the username conflicts were
> between long-time community members, so we were sure to get some dedicated
> volutneers angry no matter how we did it. So it sat in limbo, annoying
> everyone, and never happening. Sound familiar?
>
> Around then, WMF leadership introduced a new prioritisation framework:
> "top 5 priorities". This was a ranked list of projects that were considered
> to be more important than others for that quarter. It was intended as a
> first attempt to combat the "if everything's important, nothing's
> important" syndrome. You can't argue with a ranked list! And, number one on
> the list for the first quarter, not something new and shiny, but an old
> one: the SUL finalisation
> <https://www.mediawiki.org/wiki/SUL_finalisation>! Sort it all out, once
> and for all.
>
> Erik Möller (the then VP of Product and Engineering, de facto CPO and CTO
> really, reflecting on it) asked me to be the product manager. I was very
> inexperienced as a PM but had been an editor for eight years, so I
> understood the problem well. Still, I wondered how we were possibly going
> to achieve anything, the project had been "in progress" for years with
> almost no progress. Erik asked me what I needed to make it happen. I got
> some advice, and said I need a systems designer, a systems architect, an
> engineer that knows the community well, and a community liaison. Erik went
> and had the hard conversations with the people that currently needed said
> people ("It's top priority this quarter, the other stuff has to wait.") and
> went and got those people. We figured it all out, and we did it, once and
> for all (timeline reduced, it did still take multiple quarters, but we knew
> that going in). Everyone now has a fully global account!
>
> Now, times were simpler back then. This exact technique wouldn't work now,
> for multiple reasons. But, I wonder what we can learn from this as an
> organisation. What would it take to repeat this achievement?
>
> Dan
>
> P.S. Some of that team I worked with are still on this list. Hello! Thank
> you for the growth as a PM that I got out of that project, and for beating
> my inexperienced head around a bit until it got more experienced.
> _______________________________________________
> 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/