Wikimedia Foundation Annual Plan/2024-2025/Product & Technology OKRs/ko

위키미디어 재단
연간 계획 2024-2025년

위키미디어 재단 연간 계획 2024-2025년

• 요약
• 역사
• 외부 동향
• 목표
  • 기반 시설
  • 형평성
  • 안전 및 무결성
  • 효과성
• 재무 모델
• 예산 세부 사항
• 협력

이것은 2024-25년 연간 계획을 위한 위키미디어 재단의 제품 및 기술 부서 초안 프로세스의 일부입니다.

이 문서는 위키미디어 재단 제품 및 기술 부서의 2024-25년 연간 계획 프로세스의 첫 번째 부분을 나타냅니다. 부서의 초안 "목표 및 주요 결과"(OKR)에 대해 설명합니다. 이는 지난해 시작된 작업 포트폴리오('버킷'이라고 함) 구조의 연속입니다.

저는 지난 11월에 위키미디어 운동이 직면한 가장 시급한 질문에 대해 여러분과 이야기를 나눴습니다. 위키백과와 모든 위키미디어 프로젝트가 여러 세대에 걸쳐 진행되도록 하려면 어떻게 해야 합니까? 시간을 내어 해당 질문을 진지하게 고려하고 제게 직접 답변해주신 모든 분들께 감사드립니다. 그리고 이제 여러분의 답변을 되돌아보는 시간을 가졌으니 제가 배운 내용을 공유하겠습니다.

첫째, 자원봉사자들이 기여하는 데에는 단 하나의 이유가 없습니다. 여러 세대의 자원봉사자를 양성하려면 사람들이 우리 프로젝트에 시간을 투자하는 다양한 이유를 더 잘 이해해야 합니다. 다음으로, 우리는 우리를 차별화시키는 요소, 즉 인터넷과 새로운 세대의 관심을 끌기 위해 경쟁하는 플랫폼에서 허위 정보와 잘못된 정보가 확산되는 상황에서 신뢰할 수 있는 콘텐츠를 제공할 수 있는 능력에 초점을 맞춰야 합니다. 여기에는 불평등, 차별 또는 편견으로 인해 발생할 수 있는 누락된 정보에 대한 적용 범위를 확대하여 인간의 모든 지식을 모아 전 세계에 전달한다는 사명을 달성하는 것이 포함됩니다. 우리의 콘텐츠는 인공 지능과 풍부한 경험으로 인해 변화하는 인터넷에서 서비스를 제공하고 그 중요성을 유지해야 합니다. 마지막으로 우리는 장기적으로 이 활동에 자금을 지원할 수 있도록 제품과 수익에 대한 공유 전략을 구축하여 우리 운동에 지속 가능한 자금을 조달할 수 있는 방법을 찾아야 합니다.

이러한 아이디어는 위키미디어 재단의 2024~2025년 연간 계획에 반영될 것입니다. 그 중 첫 번째 부분은 오늘 제품 및 기술 작업에 대한 목표 초안의 형태로 여러분과 공유하고 있습니다. 작년과 마찬가지로 우리의 전체 연간 계획은 청중과 플랫폼의 기술 요구 사항을 중심으로 이루어질 것이며 우리가 올바른 문제에 초점을 맞추고 있는지 알기 위해 여러분의 피드백을 듣고 싶습니다. 이러한 목표는 지난 몇 달 동안 대화:2024년, 메일링 리스트, 토론 페이지, 커뮤니티 이벤트를 통해 커뮤니티 회원들로부터 향후 1년 동안의 제품 및 기술 전략에 관해 들었던 아이디어를 바탕으로 구축되었습니다. 아래에서 초안 목표의 전체 목록을 볼 수 있습니다.

"목표"는 다음 회계연도에 우리가 수행할 제품 및 기술 프로젝트를 형성하는 높은 수준의 방향입니다. 이는 의도적으로 광범위하고 우리 전략의 방향을 나타내며, 중요한 것은 다가오는 해에 가능한 많은 초점 영역 중에서 우선순위를 정하기 위해 우리가 제안하는 과제가 무엇인지를 나타냅니다. 우리는 커뮤니티 구성원들이 우리의 초기 단계 사고를 형성하고 올해 예산과 측정 가능한 목표가 확정되기 전에 이를 도울 수 있도록 지금 이 정보를 공유하고 있습니다.

피드백

우리가 특히 피드백을 원하는 영역 중 하나는 "위키 경험"이라는 이름으로 그룹화된 작업입니다. "위키 경헌"은 기여자, 소비자 또는 기부자로서 사람들이 위키를 직접 사용하는 방법을 효율적으로 제공, 개선 및 혁신하는 방법에 관한 것입니다. 여기에는 핵심 기술과 기능을 지원하고 더 나은 기능과 도구, 번역 서비스 및 플랫폼 업그레이드를 통해 자원 봉사 편집자, 특히 확장된 권한을 가진 편집자의 경험을 개선할 수 있도록 하는 작업이 포함됩니다.

다음은 최근 계획 논의에 대한 몇 가지 고찰과 우리의 아이디어를 구체화하는 데 도움이 되는 몇 가지 질문입니다:

1. 위키미디어 프로젝트에 자원 봉사하는 것은 보람을 느껴야 합니다. 우리는 또한 온라인 협업 경험이 자원봉사자들이 계속해서 돌아오도록 하는 주요 요소가 되어야 한다고 생각합니다. 자원봉사자들이 편집에 대한 보람을 느끼고, 신뢰할 수 있는 콘텐츠를 구축하기 위해 더 잘 협력하려면 무엇이 필요합니까?
2. 우리 콘텐츠의 신뢰성은 위키미디어가 세계에 기여하는 독특한 기여의 일부이며, 사람들이 우리 플랫폼을 계속 찾아오고 우리 콘텐츠를 사용하게 만드는 원동력입니다. 신뢰할 수 있는 콘텐츠를 더 빠르게 성장시키는 데 도움이 되면서도 각 프로젝트에 대해 커뮤니티가 설정한 품질 가드레일 내에 있도록 무엇을 구축할 수 있습니까?
3. 위키미디어는 관련성을 유지하고 다른 대규모 온라인 플랫폼과 경쟁하기 위해 우리 콘텐츠에 대한 연결감을 느낄 수 있는 새로운 세대의 소비자가 필요합니다. 독자와 기부자가 콘텐츠를 더 쉽게 발견하고 상호 작용할 수 있도록 하려면 어떻게 해야 합니까?
4. 온라인 남용이 만연하는 시대에 우리는 커뮤니티, 플랫폼, 서비스 시스템을 보호해야 합니다. 또한 우리는 글로벌 정책 입안자들이 온라인에서 개인 정보 보호, 신원 및 정보 공유를 형성하기 위해 노력하는 규정 준수 의무에 직면해 있습니다. 학대 방지 역량을 어떻게 개선하면 이러한 문제를 해결하는 데 도움이 될까요?
5. 위키백과가 작동할 수 있게 해주는 소프트웨어 플랫폼이자 인터페이스인 미디어위키는 개방형 다국어 콘텐츠의 대규모 생성, 조정, 저장, 검색 및 소비를 제공하기 위해 향후 10년 동안 지속적인 지원이 필요합니다. 미디어위키의 지속가능성을 보장하기 위해 올해 우리는 어떤 결정과 플랫폼 개선을 할 수 있습니까?

토론

–– Selena Deckelmann

초안 목표

현재 게시된 내용은 가장 높은 계획 수준인 "목표"입니다.

다음 단계인 각 최종 목표에 대한 "핵심 결과'(KR) 초안이 아래에 제공됩니다.

각 KR의 기본 "가설'은 관련 프로젝트/팀의 위키 페이지에 연중 내내 업데이트되어 교훈을 얻음에 따라 연중 내내 업데이트됩니다.

위키 경험 (Wiki Experiences, WE) 초안 목표
목표	목표 영역	목표	목표 배경	소유자
WE1 토론	기여자 경험	경험이 풍부한 기여자와 새로운 기여자가 모두 온라인으로 함께 모여 더욱 쉽고 좌절감 없이 신뢰할 수 있는 백과사전을 구축합니다.	앞으로 위키백과가 활기를 띠기 위해서는 여러 세대의 자원봉사자를 양성하고 사람들이 원하는 일에 기여할 수 있는 일을 해야 합니다. 다양한 세대의 자원봉사자에게는 다양한 투자가 필요합니다. 경험이 많은 기여자는 강력한 워크플로를 간소화하고 수정해야 하며, 새로운 기여자는 자신에게 적합한 새로운 편집 방법이 필요합니다. 그리고 이러한 세대 전반에 걸쳐 '모든' 기여자는 가장 영향력 있는 작업을 수행하기 위해 서로 연결하고 협력할 수 있어야 합니다. 이 목표를 통해 우리는 숙련된 기여자를 위한 중요한 작업 흐름을 개선하고, 신규 이민자를 위한 건설적인 기여에 대한 장벽을 낮추고, 자원봉사자가 공통 관심사를 중심으로 서로 찾고 소통할 수 있는 방식에 투자할 것입니다.	Marshall Miller
WE2 토론	백과사전 내용	커뮤니티는 보다 쉽게 액세스하고, 적응하고, 개선할 수 있는 도구와 지원 시스템을 통해 지식 격차를 효과적으로 해소할 수 있도록 지원되어 신뢰할 수 있는 백과사전 콘텐츠의 성장을 보장합니다.	주로 위키백과에 있는 백과사전 콘텐츠는 지속적인 참여와 혁신을 통해 증가하고 개선될 수 있습니다. 기여자가 자신의 필요에 따라 사용할 수 있는 도구 및 리소스(기술적 및 비기술적)를 보다 쉽게 검색하고 신뢰할 수 있게 만들 수 있습니다. 이러한 도구는 짧은 주기로 달성할 수 있는 기능 개선을 통해 WMF에서 더 잘 지원되어야 합니다. AI 지원 콘텐츠 생성 및 사용자 행동 변화와 관련된 최근 추세를 고려하여 콘텐츠 생성 및 재사용의 규모 확장을 지원할 수 있는 실질적인 변화(예: 위키함수)에 대한 기반도 탐색할 것입니다. 콘텐츠 격차를 식별하는 메커니즘은 발견하고 계획하기가 더 쉬워야 합니다. 자매 프로젝트, 위키백과 라이브러리와 같은 프로젝트 및 캠페인의 콘텐츠를 포함하여 백과사전 콘텐츠의 성장을 지원하는 리소스는 기여 워크플로와 더 잘 통합될 수 있습니다. 동시에, 성장에 사용되는 방법에는 증가하는 위협에 대한 보호책이 있어야 하며, 이를 통해 위키미디어 프로젝트 전체에서 인식되는 백과사전 콘텐츠의 기본 원칙을 지키면서 프로세스에 대한 지속적인 신뢰를 보장할 수 있습니다. 청중: 편집자, 번역자	Runa Bhattacharjee
WE3 토론	소비자 경험(읽기 및 미디어)	새로운 세대의 소비자는 백과사전적 콘텐츠를 발견하고, 참여하고, 지속적인 연결을 구축하기 위해 선호하는 목적지를 찾기 위해 위키백과에 옵니다.	목표: 기존 및 새로운 세대의 소비자와 기부자를 유지합니다. 콘텐츠를 더욱 쉽게 발견하고 상호 작용할 수 있도록 하여 기존 소비자와 새로운 세대의 소비자와의 관련성을 높입니다. 플랫폼 전반에 걸쳐 작업하여 우리의 경험과 기존 콘텐츠를 조정함으로써 백과사전적인 콘텐츠를 새로운 세대의 소비자와 기부자가 탐색하고 선별할 수 있습니다.	Olga Vasileva
WE4 토론	신뢰 및 안전	진화하는 규제 환경을 준수하면서 다양한 종류의 규모 및 지시적 남용으로부터 커뮤니티, 플랫폼, 서비스 시스템을 보호할 수 있도록 인프라, 도구 및 프로세스를 개선합니다.	우리의 학대 방지 역량 중 일부 측면에는 업그레이드가 필요합니다. IP 기반 남용 완화의 효율성이 떨어지고 여러 관리 도구에 효율성 개선이 필요하며 다양한 신호 및 완화 메커니즘(보안 문자, 차단 등)을 사용하여 규모가 큰 남용에 대처하는 데 도움이 되는 통합 전략을 마련해야 합니다. 공연에서. 올해 우리는 이 분야의 가장 큰 문제에 대한 진전을 시작할 것입니다. 또한, 학대 방지에 대한 이러한 투자는 지역사회 건강에 대한 이해 및 개선에 대한 투자와 균형을 이루어야 하며, 그 중 여러 측면은 다양한 규제 요건에 포함되어 있습니다.	Suman Cherukuwada
WE5 토론	지식플랫폼Ⅰ(플랫폼 진화)	위키백과의 핵심 요구 사항을 더 잘 충족할 수 있도록 미디어위키 플랫폼과 인터페이스를 발전시킵니다.	미디어위키는 개방형 다국어 콘텐츠를 대규모로 생성, 조정, 저장, 검색 및 소비할 수 있도록 구축되었습니다. 지식 플랫폼의 두 번째 해에 우리는 시스템을 살펴보고 Wikipedia를 시작으로 향후 10년 동안 위키미디어 프로젝트의 핵심 요구 사항을 효과적으로 지원하기 위해 플랫폼 개선을 위한 작업을 시작할 것입니다. 여기에는 지식 생산 플랫폼을 정의하기 위한 지속적인 작업, 플랫폼의 지속 가능성 강화, 기능 개발을 명확하고 간소화하기 위한 확장/후크 시스템에 대한 집중, 지식 공유 및 사람들이 미디어위키에 기여할 수 있도록 하는 데 지속적으로 투자하는 것이 포함됩니다.	Birgit Müller
WE6 토론	지식 플랫폼 II(개발자 서비스)	기술 직원과 자원 봉사 개발자는 위키미디어 프로젝트를 효과적으로 지원하는 데 필요한 도구를 갖추고 있습니다.	우리는 위키미디어 제품의 개발, 테스트 및 배포 작업 흐름을 개선(및 확장)하기 위해 시작된 작업을 계속하고 도구 개발자를 위한 서비스를 포함하도록 정의를 확장할 것입니다. 또한 우리는 개발자/엔지니어링 워크플로 및 대상 분야에서 자주 묻는 질문에 답변하는 능력을 향상하고 정보에 입각한 의사 결정을 내릴 수 있도록 관련 데이터에 액세스할 수 있도록 하는 것을 목표로 합니다. 이 작업의 일부는 현재 생태계에 문제가 되는 관행(또는 그러한 관행의 부족)을 살펴보는 것입니다.	Birgit Müller

신호 및 데이터 서비스 (SDS) 초안 목표
목표	목표 영역	목표	목표 배경	소유자
SDS1 토론	필수 지표	위키미디어 사명과 운동을 지원하는 방법에 대한 우리의 결정은 높은 수준의 지표와 통찰력을 바탕으로 이루어집니다.	효과적이고 효율적으로 기술을 구축하고, 자원봉사자를 지원하고, 지식에 대한 접근을 보호하고 발전시키는 정책을 옹호하려면 위키미디어 생태계를 이해하고 성공이 어떤 것인지에 맞춰야 합니다. 이는 신뢰할 수 있고 이해하기 쉬우며 적시에 이용 가능한 공통 측정항목 세트를 추적하는 것을 의미합니다. 이는 또한 측정 이면의 이유와 방법을 이해하는 데 도움이 되는 연구와 통찰력을 표면화하는 것을 의미합니다.	Kate Zimmerman
SDS2 토론	실험 플랫폼	제품 관리자는 제품 기능의 영향을 빠르고 쉽고 자신 있게 평가할 수 있습니다.	제품 기능 개발에 대한 데이터 기반 의사 결정을 활성화하고 가속화하려면 제품 관리자는 기능을 정의하고, 사용자의 처리 대상을 선택하고, 영향 측정을 확인할 수 있는 실험 플랫폼이 필요합니다. 학습 일정을 단축하면 실험이 가속화되고 궁극적으로는 혁신이 가속화되므로 출시부터 분석까지의 시간을 단축하는 것이 중요합니다. 수동 작업과 측정에 대한 맞춤형 접근 방식은 속도에 대한 장벽으로 확인되었습니다. 이상적인 시나리오는 제품 관리자가 엔지니어와 분석가의 수동 개입을 거의 또는 전혀 없이 실험 시작부터 발견까지 진행할 수 있다는 것입니다.	Tajh Taylor

미래의 청중 (FA) 초안 목표
목표	목표 영역	목표	목표 배경	소유자
FA1 토론	가설 테스트	온라인에서 지식이 공유되고 소비되는 방식에 대한 이해를 높이는 실험에서 얻은 통찰력을 바탕으로 위키미디어 재단이 추구할 전략적 투자에 대한 권장 사항을 제공하여 우리 운동이 변화하는 인터넷에서 새로운 청중에게 서비스를 제공하는 데 도움을 줍니다.	기술 및 온라인 사용자 행동의 지속적인 변화(예: 소셜 앱을 통해 정보를 얻는 것에 대한 선호도 증가, 짧은 비디오 에듀테인먼트의 인기, 생성 AI의 부상)로 인해 위키미디어 운동은 독자와 기여자를 유치하고 유지하는 데 어려움을 겪고 있습니다. 이러한 변화는 또한 새로운 방식으로 정보를 생성하고 전달함으로써 새로운 청중에게 서비스를 제공할 수 있는 기회를 가져옵니다. 그러나 하나의 운동으로서 우리는 과제를 극복하거나 새로운 기회를 포착하기 위해 추구할 수 있는 다양한 잠재적 전략의 이점과 장단점에 대한 명확한 데이터 기반 그림을 갖고 있지 않습니다. 예를 들어, 우리는 ... 우리 플랫폼의 챗봇이나 소셜 비디오와 같은 대규모 새로운 기능에 투자하시겠습니까? 인기 있는 제3자 플랫폼에 기여하기 위해 위키미디어의 지식과 경로를 가져오시겠습니까? 다른 것? 위키미디어가 다세대 프로젝트가 되도록 하기 위해 우리는 위키미디어 재단과 위키미디어 운동이 미래의 청중을 유치하고 유지하기 위해 추구하는 유망한 전략을 더 잘 이해하고 권장하기 위한 가설을 테스트할 것입니다.	Maryana Pinchuk

제품 및 엔지니어링 지원 (PES) 초안 목표
목표	목표 영역	목표	목표 배경	소유자
PES1 토론	운영 효율성	재단의 업무를 더 빠르고, 저렴하고, 영향력 있게 만드세요.	직원들은 우리의 운영을 더 빠르고, 저렴하고, 더 영향력 있게 만들기 위해 정규 업무에서 많은 일을 합니다. 이 목표는 a) 더 빠르고, 더 저렴하거나, 더 영향력 있는 방향으로 상당한 이익을 얻을 수 있는 구체적인 이니셔티브를 강조합니다. b) 재단에서 공동의 노력을 기울이고 공식 및 비공식 관행을 변경합니다. 본질적으로, 이 목표에 포함된 KR은 당사 제품 및 기술과 관련된 업무의 운영 효율성을 위해 올해 우리가 이룰 수 있는 가장 어렵고 최선의 개선입니다.	Amanda Bittaker

초안 주요 결과

각 최종 목표에 대한 "핵심 결과'(한국어) 초안은 여기에 있습니다. 이는 위의 각 목표에 해당합니다.

각 KR의 기본 가설'은 교훈을 얻음으로써 일년 내내 관련 프로젝트나 팀의 위키 페이지에 업데이트됩니다.

위키 경험(WE) 초안 주요 결과 [ 초안 목표 ]
핵심 결과 단축명	핵심 결과 텍스트	핵심 결과 맥락	소유자
WE1.1 토론	공통 관심사를 가진 기여자가 서로 연결하고 함께 기여할 수 있도록 돕는 하나의 워크플로를 개발하거나 개선합니다.	우리는 위키의 커뮤니티 공간과 상호 작용이 기여자로서 사람들을 더 행복하고 생산적으로 만든다고 생각합니다. 또한 커뮤니티 공간은 신규 이민자를 모집 및 멘토링하고 기여 모범 사례를 모델링하며 지식 격차를 해소하는 데 도움이 됩니다. 그러나 위키에서 인간 관계를 지원하는 기존 리소스, 도구 및 공간은 수준이 낮으며 오늘날 대다수 편집자의 과제와 요구를 충족하지 못합니다. 한편, 캠페인 팀의 작업을 통해 많은 주최자가 커뮤니티 작업에 도움이 되는 구조화된 워크플로를 갖춘 새로운 도구를 채택하고 실험하고 싶어한다는 사실이 입증되었습니다. 이러한 이유로 우리는 위키 기여자들 사이에 소속감을 장려하고 증진하는 데 중점을 두고 싶습니다.	Ilana Fried
WE1.2 토론	건설적인 활성화: 모바일 장치의 기본 네임스페이스에 건설적인 편집을 1개 이상 게시하는 신규 사용자의 비율이 전년 대비 #% 증가했습니다.	현재의 전체 페이지 편집 경험에는 많은 신규 사용자가 건설적으로 기여하기에는 너무 많은 맥락, 인내, 시행착오가 필요합니다. 새로운 세대의 자원봉사자를 지원하기 위해 우리는 더 작고 체계적이며 작업별 편집 워크플로우의 수와 가용성을 늘릴 것입니다. (예, 편집 확인 및 구조화된 임무). 참고: 기준선은 현재 회계연도 4분기 말까지만 설정되며, 그 이후에는 KR 목표 지표 비율도 설정됩니다.	Peter Pelberg
WE1.3 토론	4개의 조정 제품에 대한 사용자 만족도를 X% 높입니다.	확장된 권한을 가진 편집자는 광범위한 기존 기능, 확장 기능, 도구 및 스크립트를 활용하여 위키미디어 프로젝트에 대한 조정 작업을 수행합니다. 올해 우리는 이 공간에서 새로운 기능을 구축하기 위한 프로젝트를 수행하기보다는 이 도구를 개선하는 데 중점을 두고 싶습니다. 우리는 일년 내내 다양한 제품을 다루는 것을 목표로 하고 있으며 각각에 영향을 미치는 개선을 만들고 싶습니다. 이를 통해 전반적인 콘텐츠 조정 경험을 개선할 수 있기를 바랍니다. 우리는 이 작업 흐름에서 목표로 삼을 수 있는 몇 가지 일반적인 중재자 도구에 대한 기준을 측정하여 X%를 정의할 것입니다. 커뮤니티 위시리스트는 이 작업의 우선순위를 결정하는 데 상당한 기여를 할 것입니다.	Sam Walton
WE2.1 토론	By the end of Q2, support organizers, contributors, and institutions with specific tools, insights, & organizing approaches that increase the coverage of quality content in key topic areas [TBD] by X%.	This KR is about improving topic coverage towards reducing existing knowledge gaps. We’ve established that communities benefit from effective tools paired with campaigns targeted at increasing the quality of content in our projects. This year we want to focus on improving existing tools and experimenting with new ways of prioritizing key topic areas that address knowledge gaps. Our target X% increase in coverage will be determined by looking at existing baselines of quality content creation. Also, the topic areas we’ll be focusing on with communities and institutions will be determined by next quarter.	Purity Waigi & Fiona Romeo
WE2.2 토론	By the end of Q2, implement and test two recommendations, both social and technical, to support languages onboarding for small language communities, with an evaluation to analyze community feedback.	There are editions of Wikipedia in about 300 languages. And yet, there are many more languages that are spoken by millions of people, in which there is no Wikipedia and no Wiki at all. This is a blocker to fulfilling our vision: that every single human being can freely share in the sum of all knowledge. The Wikimedia Incubator, is where potential Wikimedia project wikis in new-language versions can be arranged, written, tested and proven worthy of being hosted by the Wikimedia Foundation. The Incubator was launched in 2006 with the assumption that its users would have prior wiki editing knowledge. This problem is exacerbated by the fact that this process is supposed to be mostly performed by people who are the newest and the least experienced in our movement.While editing on Wikimedia wikis has significantly improved since then, the Incubator hasn't received these updates due to technical limitations. Currently, it takes several weeks for a wiki to graduate from the Incubator and only around 12 wikis are created each year, showing a significant bottleneck. Existing research and materials reveal technical challenges in every phase of language onboarding: adding new languages to the Incubator, complexities in developing and reviewing content, and slow process in creating a wiki site when a language graduates from Incubator. Each phase is slow, manual, and complex, indicating the need for improvement. Addressing this problem will allow creating wikis in new languages more quickly and easily, and allow more humans to share knowledge. Various stakeholders, existing research and resources have highlighted proposed recommendations both social and technical. This key result proposes testing two recommendations both social and technical and evaluating the community feedback.	Satdeep Gill & Mary Munyoki
WE2.3 토론	By the end of Q2, 2 new features guide contributors to add source materials that comply with project guidelines, and 3-5 partners have contributed source material that addresses language and geography gaps.	To grow access to the quality source material that’s needed to close strategic content gaps, we will: Partner with the Biodiversity Heritage Library; AfLIA; and the Wikisource Loves Manuscripts learning network. Support the acquisition and retention of content partners through more accessible reuse metrics. Guide contributors to add images and references that comply with project guidelines and increase trust in content, for example, by flagging potential issues during their upload/addition.	Fiona Romeo & Alexandra Ugolnikova
WE2.4 토론	By the end of Q2, enable Wikifunctions calls on at least one smaller language Wikipedia to provide a more scalable way to seed new content.	To reduce our knowledge gaps effectively, we need to improve workflows that support scalable growth in quality content, especially in smaller language communities.	Amy Tsay
WE3.1 토론	Release two curated, accessible, and community-driven browsing and learning experiences to representative wikis, with the goal of increasing the logged-out reader retention of experience users by 5%.	This KR focuses on increasing the retention of a new generation of readers on our website, allowing a new generation to build a lasting connection with Wikipedia, by exploring opportunities for readers to more easily discover and learn from content they are interested in. This will include explorations and the development of new curated, personalized, and community-driven browsing and learning experiences (for example, feeds of relevant content, topical content recommendations and suggestions, community-curated content exploration opportunities, etc). We plan on beginning the fiscal year by experimenting with a series of experiments of browsing experiences to determine which we would like to scale for production use, and on which platform (web, apps, or both). We will then focus on scaling these experiments and testing their efficacy in increasing retention in production environments. Our goal by the end of the year is to launch at least two experiences on representative wikis and to accurately measure a 5% increase in reader retention for readers engaged in these experiences. To be optimally effective at achieving this KR, we will require the ability to A/B test with logged-out users, as well as instrumentation capable of measuring reader retention. We might also need new APIs or services necessary to present recommendations and other curation mechanisms.	Olga Vasileva
WE3.2 토론	50% increase in the number of donations via touch points outside of the annual banner and email appeals per platform.	Our goal is to provide a diversity of revenue sources while recognizing our existing donors. Based on feedback and data, our focus is on increasing the number of donations beyond the methods the Foundation has relied upon in the past, specifically the annual banner appeals. We want to show that by investing in more integrated donor experiences, we can sustain our work and expand our impact by providing an alternative to donors and potential donors that are unresponsive to banner appeals. 50% is an initial estimate based on the decreased visibility of the donate button on Web as a result of Vector 2022, and the increase in the number of donations from FY 2023-2024's pilot project on the Wikipedia apps to enhance donor experiences (50.1% increase in donations). Evaluating this metric by platform will help us understand trends in platforms and if different tactics should be deployed in the future based on a difference in behavior based on platform audience.	Jazmin Tanner
WE4.1 토론	Provide a proposal of 3 countermeasures to harassment and harmful content informed by data and in accordance with the evolving regulatory environment by Q3.	Ensuring user safety and well-being is a fundamental responsibility of online platforms. Many jurisdictions have laws and regulations that require online platforms to take action against harassment, cyberbullying and other harmful content. Failing to address these may expose platforms to legal liability and regulatory sanctions. Right now we do not have a very good idea about how big these problems are or the reasons behind them. We rely heavily on anecdotal evidence and manual processes which leave us exposed both to legal risks as well other far-reaching consequences: underestimation of the problem, escalation of harm, reputational damage and erosion of user trust. We need to build a strong culture of measuring the incidence of harassment & harmful content and proactively implement countermeasures.	Madalina Ana
WE4.2 토론	Develop at least two signals for use in anti-abuse workflows to improve the precision of actions on bad actors by Q3.	The wikis rely heavily on IP blocking as a mechanism for blocking vandalism, spam and abuse. But IP addresses are increasingly less useful as stable identifiers of an individual actor, and blocking IP addresses has unintended negative effects on good faith users who happen to share the same IP address as bad actors. The combination of the decreasing stability of IP addresses and our heavy reliance on IP blocking result in less precision and effectiveness in targeting bad actors, in combination with increasing levels of collateral damage for good faith users. We want to see the opposite situation: decreased levels of collateral damage and increased precision in mitigations targeting bad actors. To better support the anti-abuse work of functionaries and to provide building blocks for reuse in existing (e.g. CheckUser, Special:Block) and new tools, in this KR we propose to explore ways to reliably associate an individual with their actions (sockpuppetting mitigation), and combine existing signals (e.g. IP addresses, account history, request attributes) to allow for more precise targeting of actions on bad actors.	Kosta Harlan
WE4.3 토론	Reduce the effectiveness of a large-scale distributed attack by 50% as measured by the time it takes us to adapt our measures and the traffic volume we can sustain in a simulation.	The evolution of the landscape of the internet, including the rise of large-scale botnets and more frequent attacks have made our traditional methods of limiting large-scale abuse obsolete. Such attacks can make our sites unavailable by flooding our infrastructure with requests, or overwhelm the ability of our community to combat large-scale vandalism. This also puts an unreasonable strain on our high privilege editors and our technical community. We urgently need to improve our ability to automatically detect, withstand, and mitigate or stop such attacks. In order to measure our improvements, we can't rely solely on frequency/intensity of actual attacks, as we would be dependent on external actions and it would be hard to get a clear quantitative picture of our progress. By setting up multiple simulated attacks of varying nature/complexity/duration to be run safely against our infrastructure, and running them every quarter, we will be able to both test our new countermeasures while not under attack, and to report objectively on our improvements.	Giuseppe Lavagetto
WE5.1 토론	By Q3, complete at least 5 interventions that are intended to increase the sustainability of the platform.	The MediaWiki platform sustainability is an evergreen effort important for our ability to scale, increase or avoid degradation of developer satisfaction, and grow our technical community. This is hard to measure and depends on technical and social factors. However, we carry tacit knowledge about specific areas of improvements that are strategic for sustainability. The planned interventions may help increase the sustainability and maintainability of the platform or avoid its degradation. We plan to evaluate the impact of this work in Q4 with recommendations for sustainability goals moving forward. Examples of sustainability interventions are: simplify complex code domains that are core to MediaWiki but just a handful of people know how it works; increase the usage of code analysis tooling to inform quality of our codebase; streamline processes like packaging and releases.	Mateus Santos
WE5.2 토론	Identify by Q2 and complete by Q4 one or more interventions to evolve the MediaWiki ecosystem’s programming interfaces to empower decoupled, simpler and more sustainable feature development.	The main goal of KR 5.2 is to improve and clarify the interaction between MediaWiki's core platform and its extensions, skins, and other parts. Our intent is to provide functional improvements to MediaWiki’s architecture that enable practical modularity and maintainability, for which it is easier to develop extensions, and to empower the requirements from the wider MediaWiki product vision. This work also aims to inform what should exist (or not) within core, extensions, or the interfaces between them. The year will be divided into two phases: a 5-month research and experimentation phase that will inform the second phase where specific interventions are implemented.	[TBD]
WE5.3 토론	By the end of Q2, complete one data gathering initiative and one performance improvement experiment to inform followup product and platform interventions to leverage capabilities unlocked by MediaWiki’s modeling of a page as a composition of structured fragments.	The primary goal here is to empower developers and product managers to leverage new MediaWiki platform capabilities to meet current and future needs of encyclopedic content by making possible new product offerings that are currently difficult to implement as well as improve performance and resiliency of the platform. Specifically, at a MediaWiki platform level, we want to shift the processing model of MediaWiki from treating a page as a monolithic unit to treating a page as a composition of structured content units. Parsoid-based read views, Wikidata integration, and Wikifunctions integration into wikis are all implicit moves towards that. As part of this KR, we want to more intentionally experiment with and gather data to inform future interventions based on these new capabilities to ensure we can achieve the intended infrastructure and product impacts.	[TBD]
WE6.1 토론	Resolve 5 questions to enable efficiency and informed decisions on developer and engineering workflows and services and make relevant data accessible by the end of Q4.	“It’s complicated” is a frequent response to questions like “which repositories are deployed to Wikimedia production”. In this KR we will explore some of our “evergreens” in the field of engineering productivity and experience - recurring questions that seem easy but are hard to answer, questions that we can answer, but the data is not accessible and require custom queries by subject matter experts, or questions that are cumbersome to get a response on for process gap or other reasons. We will define what “resolve” means for each of the questions: For some this may just mean to make existing, accurate data accessible. Other questions will require more research and engineering time to address them. The overarching goal of this work is to reduce the time, workarounds and effort it takes to gain insights in key aspects of the developer experience and enable us to make improvements to engineering and developer workflows and services.	[TBD]
WE6.2 토론	By Q4, enhance an existing project and perform at least two experiments aimed at providing maintainable, targeted environments moving us towards safe, semi-continuous delivery.	Developers and users depend on the Wikimedia Beta Cluster (beta) to catch bugs before they affect users in production. Over time, the uses of beta have grown and come into conflict—the uses are too diverse to fit in a single environment. We will enhance one existing alternative environment and perform experiments aimed at replacing a single high-priority testing need currently fulfilled by beta with a maintainable alternative environment that better serves each use case's needs.	Tyler Cipriani
WE6.3 토론	By Q2, introduce a sustainability scoring system for the Toolforge platform across a variety of technical and social factors. By Q4, improve one of its key technical factors by 50%.	Toolforge, the key platform for Wikimedia’s volunteer-built tools, plays a crucial role from editing to anti-vandalism. Our goal is to enhance Toolforge usability, lower the barriers to contribution, improve community practices, and promote adherence to established policies. To this effect, we will introduce a scoring system by Q2 to evaluate the Toolforge platform sustainability, focusing on technical and social aspects. Using this system as a guide, we aim to improve one of the key technical factors by 50%.	Slavina Stefanova

Signals & Data Services (SDS) Draft Key Results [ 초안 목표 ]
핵심 결과 단축명	핵심 결과 텍스트	핵심 결과 맥락	소유자
SDS1.1 토론	Leaders of 2 programs or KR driven initiatives have produced widely shared documentation explaining the logical link between their team’s work and impact on one or more core Foundation metrics.	Our core organizational metrics serve as the basis for assessing the Foundation's progress toward its goals. As we allocate resources to programs and design key result (KR) oriented workstreams, these high-level metrics should guide how we link these investments to the Foundation's overarching goals as defined in the annual plan. The work in this key result acknowledges that the Foundation as a whole is at an early stage in its ability to quantitively link the impacts of all planned interventions to high-level, or core metrics. In pursuit of that eventual goal, this KR aims to develop the process by which we share the logical and theoretical links between our initiatives and our high-level metrics. In practice, this means partnering with initiative owners throughout the Foundation to understand how the output of their work at a project level is linked to and impacts our core metrics at a Foundation level. Impact mapping frameworks and exercises like ‘Theory of Change mapping’ and causal graph construction will be employed to ensure consistency and rigor in documenting the potential impact of work. To execute on this key result, we will also need to develop supporting materials that help initiative owners understand organizational metrics and understand how to construct theories of change associated with their work.	Omari Sefu
SDS1.2 토론	Answer 2 strategic open research questions by December 2024 in order to provide recommendations or inform FY26 annual planning.	There are many open research questions in the Wikimedia ecosystem, and answering some of those questions is strategic for WMF or the affiliates. The answers to these questions can inform future product or technology development or can support decision-making/advocacy in the policy space. While some of these questions can be answered by utilizing purely research or research engineering expertise, given the socio-technical nature of the WM projects arriving at trustworthy insights often requires cross-team collaboration for data collection, context building, user interaction, careful design of experiments, and more. Through this KR we aim to prioritize some of our resources towards answering one or more of such questions. The work in this KR includes prioritizing a list of strategic open questions, as well as doing experimental work to find an answer for X number (currently estimated 2) of them. The ideal type of questions we tackle in this KR are questions that once answered can have an unlocking effect by enabling multiple other teams or groups to do (better? informed) product, technology, or policy work. We intend the work in this KR to be complementary to the following KRs: PES1.3. where the focus is on experimenting with on-platform product or feature ideas based on existing products. FA1.1. where the focus is on experimentation about future audiences by utilizing AI/ML technologies.	Leila Zia
SDS1.3 토론	Achieve at least a 50% reduction in the average time required for data stakeholders to understand and trace data flows for 3 core and essential metrics	Required for Data Governance standards. Tracing back the transformation and source of datasets is difficult and requires knowledge of different repos and systems. We should make it easy to understand how data flows around our systems so that data stakeholders can work in a more self service way. This work will support workflows where data is transformed and used for analytics, features, API’s and data quality jobs. There will be a follow up KR around documenting metrics.	Luke Bowmaker
SDS2.1 토론	By the end of Q2, we can support 1 product team to evaluate a feature or product via basic A/B testing that reduces their time to user interaction data by 50%.	We think using shared tools will increase product teams' confidence in data-driven decision making, improve efficiency and productivity, and enhance product strategy and innovation. We will look at adopting team's individual time to user interaction data baselines and improve it by 50%. We will also investigate how we can contextualize these gains in the fuller context of all product teams. We expect to learn how we can improve the experience and identify and prioritize capability enhancements based on feedback from the adopting team and results of SDS2.2.	Virginia Poundstone
SDS2.2 토론	By end of Q2, we will have 2 essential metrics for analyzing experiments (A/B tests) to support testing product/feature hypotheses related to FY24-25 KRs.	When a product manager (or designer) has a hypothesis that a product/feature will address a problem/need for the users or the organization, an experiment is how they test that hypothesis and learn about the potential impact of their idea on a metric. The results of the experiment inform the product manager and help them make a decision about what action to take next (abandon this idea and try a different hypothesis, continue development if the experiment was performed early in the development lifecycle, or release the product/feature to more users). Product managers must be able make such a decision with confidence, supported by evidence they trust and understand. A major hurdle to this is that product teams currently formulate their hypotheses with custom project-specific metrics which require dedicated analyst support to define, measure, analyze, and report on them. Switching to a set of essential metrics for formulating all testable product/feature hypothesis statements would make it: easier and faster to design, deploy, and analyze experiments to test those hypotheses easier to communicate results and learnings from experiments to decision makers (product managers) and other audiences (e.g. senior leadership, others in the organization, communities) We think that a set of essential metrics which are widely understood and consistently used – and informed/influenced by industry standard metrics – would also improve organizational data literacy and promote a culture of review, experimentation, and learning. We are focusing on essential metrics that (1) are needed for best measurement and evaluation of success/impact of products/features related to 2 Wiki Experiences KRs – WE3.1 and WE1.2 – and (2) reflect or map to industry-standard metrics used in web analytics.	Mikhail Popov

Future Audiences (FA) Draft Key Result [ 초안 목표 ]
핵심 결과 단축명	핵심 결과 텍스트	핵심 결과 맥락	소유자
FA1.1 토론	As result of Future Audiences experimental insights and recommendations, by the end of Q3 at least one objective or key result owned by a non-Future Audiences team is present in the draft for the following year's annual plan.	Since 2020, the Wikimedia Foundation has been tracking external trends that may impact our ability to serve future generations of knowledge-consumers and knowledge-contributors and remain a thriving free knowledge movement for generations to come. Future Audiences, a small R&D team, will: Perform rapid, time-bound experiments (aiming for at least 3 experiments per fiscal year) to explore ways to address these trends Based on insights from experimentation, make recommendations for new non-experimental investments that WMF should pursue – i.e. new products or programs that need to be taken on by a full team or teams – during our regular annual planning period.This key result will be met if at least one objective or key result that is owned by a team outside of Future Audiences and is driven by a Future Audiences recommendation appears in the draft annual plan for the following fiscal year.	Maryana Pinchuk

Product and Engineering Support (PES) Draft Key Results [ 초안 목표 ]
핵심 결과 단축명	핵심 결과 텍스트	핵심 결과 맥락	소유자
PES1.1 토론	Culture of Review: Incrementally improve scores for P+T staff sentiment related to our delivery, alignment, direction, and team health in a quarterly survey.	A culture of review is a product development culture based on shorter cycles of iteration, learning, and adaptation. This means that our organization may set yearly goals, but what we do to achieve these goals will change and adapt over the course of the year as we learn. There are two components to building a culture of review: processes and behaviors. This KR focuses on the latter. Behavior changes can grow and strengthen our culture of review. This involves changes in individual habits and routines as we move towards more iterative product development. This KR will be based on self-reported changes in individual behaviors, and measuring resulting changes, if any, in staff sentiment.	Amy Tsay
PES1.2 토론	By the end of Q2, the new Wishlist better connects movement ideas and requests to Foundation P+T activities: items from the Wishlist backlog are addressed via a 2024-5 KR, the Foundation has completed 10 smaller Wishes, and the Foundation has partnered with volunteers to identify 3+ areas of opportunity for the 2025-26 FY.	The Community Wishlist represents a narrow slice of the movement; approximately 1k people participate, most of whom are contributors or admins. People often bypass the Wishlist by writing feature requests and bug reports via Phabricator, where it’s hard to discern requests from WMF or the community. For participants, the Wishlist is a costly time investment with minimal payoff. They still engage with the Wishlist because they feel it is the only vehicle to call attention to impactful bugs and feature improvements, or signal a need for broader, strategic opportunities. Wishes are often written as solutions, vs problems. The solutions may seem sensible on paper, but don’t necessarily consider the technical complexity or movement strategy implications. The scope and breadth of wishes sometimes exceeds the scope and capacity of Community Tech or a single team, perpetuating the frustration, leading to RFCs and calls to dismantle the Wishlist. Whereas community members prefer to use the Wishlist for project ideas, teams at the Foundation look at the Wishlist and other intake processes for prioritization, in part because wishes are ill-timed for Annual Planning and are hard to incorporate into roadmaps / OKRs. The Future Wishlist should be a bridge between the community and the Foundation, where communities provide input in a structured way, so that we are able to take action and in turn make volunteers happy. We’re creating a new intake process for any logged in volunteer to submit a wish, 365 days a year. Wishes can report or highlight a bug, request an improvement, or ideate on a new feature. Anyone can comment on, workshop, or support a Wish to influence prioritization. The Foundation won’t categorize wishes as “too big” or “too small.” Wishes that thematically map to a larger problem area can influence annual planning and team roadmaps, offering strategic directions and opportunities. Wishes will be visible to the Movement in a dashboard that categorizes wishes by project, product/problem area, and wish type. The Foundation will respond to wishes in a timely manner, and partner with the Community to categorize and prioritize wishes. We will partner with Wikimedians to identify and prioritize three areas of improvement, incorporated in the Foundation’s 2025-26 Annual Plan, which should improve the adoption rate and fulfillment of impactful wishes. We will flag well-scoped wishes for the volunteer developer community and Foundation teams, leading to more team and developer engagement and more wishes fulfilled, leading to community satisfaction. Addressing more wishes improves contributor happiness, efficacy, and retention, which should generate more quality edits, higher quality content, and more readers.	Jack Wheeler
PES1.3 토론	Run and conclude two experiments from existing exploratory products/features that provides us with data/insights into how we grow Wikipedia as a knowledge destination for our current consumer and volunteer audiences in Q1 and Q2. Complete and share learnings and recommendations for potential adoption for future OKR work in the Wiki Experiences bucket by the end of Q3.	This work is a counterpart to the Future Audiences objective, but focuses instead on uncovering opportunities to increase and deepen engagement of our existing audiences (of Wikipedia consumers and contributors) through more nimbly testing more on-platform product ideas. It lives in PES1 as it is an energiser and multiplier - channelling the time individuals and teams have already devoted to hacking/experimenting on side projects to bring more promising features into focus. Instead of these side projects languishing (not a good use of our limited resources), this KR provides a path for some of these ideas to potentially make it into larger APP setting through proven experiments, thus more efficiently using staff time and motivating their creativity and productivity. By shepherding more of these smaller, shorter projects into play, we also diversify our spread of ‘bets’ for more learnings and trials of ideas that may transform Wikipedia in line with the changing needs and expectations of our current audiences. This will make our work more impactful and faster as it helps the foundation to align on the correct goal in less time.	Rita Ho
PES1.4 토론	Learn how to: set, monitor, and make decisions on SLOs. Pick at least one new thing to define SLOs for as we release it. Collaborate with the respective team(s) (typically: product, development teams, SRE) to define that SLO. Reflect and document guidelines for what releases should have SLOs in the future and how to set them.	FUTURE KR: Set up process and rudimentary tools for setting and monitoring SLOs for new releases. Report on a quarterly basis, and use it to make decisions on when to (and not to) prioritize work to fix something. Share report with the community. WHY: We don’t know when we need to prioritize work to fix something. And we have a lot of code. As this footprint continues to grow, there are more situations where we may need to decide between addressing issues or focus on innovation, and more uncertainty around when we should. Also, not clear to staff and community what our level of support/commitment on reliability and performance is for all the different features and functionality they interact with. If we define a expected level of service, we can know when we should allocate resources to it or not.	Mark Bergsma

Explanation of buckets

Wiki Experiences

Diversity (40786) – The Noun Project

The purpose of this bucket is to efficiently deliver, improve and innovate on wiki experiences that enable the distribution of free knowledge world-wide. This bucket aligns with movement strategy recommendations #2 (Improve User Experience) and #3 (Provide for Safety and Inclusion). Our audiences include all collaborators on our websites, as well as the readers and other consumers of free knowledge. We support a top-10 global website, and many other important free culture resources. These systems have performance and uptime requirements on-par with the biggest tech companies in the world. We provide user interfaces to wikis, translation, developer APIs (and more!) and supporting applications and infrastructure that all form a robust platform for volunteers to collaborate to produce free knowledge world-wide. Our objectives for this bucket should enable us to improve our core technology and capabilities, ensure we continuously improve the experience of volunteer editors and moderators of our projects, improve the experience of all technical contributors working to improve or enhance the wiki experiences, and ensure a great experience for readers and consumers of free knowledge worldwide. We will do this through product and technology work, as well as through research and marketing. We expect to have at most five objectives for this bucket.

Knowledge is constructed by people! And as a result our annual plan will focus on the content as well as the people who contribute to the content and those who access and read it.

Our aim is to produce an operating plan based on existing strategy, mainly our hypotheses about the contributor, consumer and content "flywheel". The primary shift I’m asking for is an emphasis on the content portion of the flywheel, and exploration of what our moderators and functionaries might need from us now, with the aim of identifying community health metrics in the future.

Signals and Data Services

Arrythmia noun 246518

In order to meet the Movement Strategy Recommendations for Ensuring Equity in Decision Making (Recommendation #4), Improving User Experience (Recommendation #2), and Evaluating, Iterating and Adapting (Recommendation #10), decision makers from across the Wikimedia Movement must have access to reliable, relevant, and timely data, models, insights, and tools that can help them assess the impact (both realized and potential) of their work and the work of their communities, enabling them to make better strategic decisions.

In the Signals & Data Services bucket, we have identified four primary audiences: Wikimedia Foundation staff, Wikimedia affiliates and user groups, developers who reuse our content, and Wikimedia researchers, and we prioritize and address the data and insights needs of these audiences. Our work will span a range of activities: defining gaps, developing metrics, building pipelines for computing metrics, and developing data and signals exploration experiences and pathways that help decision makers interact more effectively and joyfully with the data and insights.

Future Audiences

The purpose of this bucket is to explore strategies for expanding beyond our existing audiences of consumers and contributors, in an effort to truly reach everyone in the world as the essential infrastructure of the ecosystem of free knowledge. This bucket aligns with Movement Strategy Recommendation #9 (Innovate in Free Knowledge). More and more, people are consuming information in experiences and forms that diverge from our traditional offering of a website with articles – people are using voice assistants, spending time with video, engaging with AI, and more. In this bucket, we will propose and test hypotheses around potential long-term futures for the free knowledge ecosystem and how we will be its essential infrastructure. We will do this through product and technology work, as well as through research, partnerships, and marketing. As we identify promising future states, learnings from this bucket will influence and be expanded through Buckets #1 and #2 in successive annual plans, nudging our product and technology offerings toward where they need to be to serve knowledge-seekers of the future. Our objectives for this bucket should drive us to experiment and explore as we bring a vision for the future of free knowledge into focus.

Sub-buckets

Noun project 3067

We also have two other “sub-buckets” which consist of areas of critical functions, which must exist at the Foundation to support our basic operations, and some of which we have in common with any software organization. These “sub-buckets” won’t have top level objectives of their own, but will have input on and will support the top level objectives of the other groups. They are:

1. Infrastructure Foundations. This bucket covers the teams which sustain and evolve our datacenters, our compute and storage platforms, the services to operate them, the tools and processes that enable the operation of our public facing sites and services.
2. Product and Engineering Support. This bucket includes teams which operate “at scale” providing services to other teams that improve the productivity and operations of other teams.