위키미디어 재단 연간 계획/2024-2025년/제품 및 기술 OKR

This page is a translated version of the page Wikimedia Foundation Annual Plan/2024-2025/Product & Technology OKRs and the translation is 88% complete.

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

Portrait of Selena

저는 지난 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개 이상 게시하는 신규 사용자의 비율이 전체적으로 #% 증가하는 것으로 나타났습니다.

참고: 이 KR은 플랫폼별로 측정됩니다.

현재의 전체 페이지 편집 경험에는 많은 신규 사용자가 건설적으로 기여하기에는 너무 많은 맥락, 인내, 시행착오가 필요합니다. 새로운 세대의 자원봉사자를 지원하기 위해 우리는 더 작고 체계적이며 작업별 편집 워크플로우의 수와 가용성을 늘릴 것입니다. (예, 편집 확인구조화된 임무).

참고: 기준선은 현재 회계연도 4분기 말까지만 설정되며, 그 이후에는 KR 목표 지표 비율도 설정됩니다.

Peter Pelberg
WE1.3

토론

4개의 조정 제품에 대한 사용자 만족도를 각각 5pp씩 높입니다. 확장된 권한을 가진 편집자는 광범위한 기존 기능, 확장 기능, 도구 및 스크립트를 활용하여 위키미디어 프로젝트에 대한 조정 작업을 수행합니다. 올해 우리는 이 공간에서 새로운 기능을 구축하기 위한 프로젝트를 수행하기보다는 이 도구를 개선하는 데 중점을 두고 싶습니다. 우리는 일년 내내 다양한 ​​제품을 다루는 것을 목표로 하고 있으며 각각에 영향을 미치는 개선을 만들고 싶습니다. 이를 통해 전반적인 콘텐츠 조정 경험을 개선할 수 있기를 바랍니다.

우리는 도구별 만족도 증가를 결정하기 위해 이 작업 흐름에서 목표로 삼을 수 있는 일반적인 중재자 도구에 대한 기준을 정의할 것입니다. 커뮤니티 위시리스트는 이 KR의 우선순위를 결정하는 데 실질적인 기여를 할 것입니다.

Sam Walton
WE2.1

토론

2분기 말까지 조직자, 기여자, 기관을 지원하여 실험을 통해 주요 주제 영역(예: 성별(여성 건강, 여성의 전기), 지리(생물 다양성))에서 양질의 콘텐츠의 보도 범위를 138개 문서로 늘립니다. 이번 KR은 기존 지식 격차를 줄이기 위한 주제 적용 범위를 개선하는 것입니다. 우리는 프로젝트의 콘텐츠 품질 향상을 목표로 하는 캠페인과 효과적인 도구를 결합하여 커뮤니티가 혜택을 누릴 수 있도록 했습니다. 올해 우리는 기존 도구를 개선하고 지식 격차를 해소하는 핵심 주제 영역의 우선순위를 정하는 새로운 방법을 실험하는 데 중점을 두고 싶습니다.

우리의 목표인 138개 문서는 기존의 품질 컨텐츠 생성 기준을 살펴봄으로써 결정될 것입니다.

Purity Waigi & Fiona Romeo
WE2.2

토론

2분기 말까지 커뮤니티 피드백 분석 평가를 통해 소규모 언어 커뮤니티의 언어 온보딩을 지원하기 위해 사회적, 기술적 두 가지 권장 사항을 구현하고 테스트합니다. 약 300개 언어로 된 위키백과 버전이 있습니다. 하지만 수백만 명의 사람들이 사용하는 언어가 더 많이 있는데, 거기에는 위키백과도 없고 위키도 전혀 없습니다. 이는 모든 인간이 모든 지식의 총합을 자유롭게 공유할 수 있다는 우리의 비전을 달성하는 데 방해가 됩니다. 위키미디어 인큐베이터는 새로운 언어 버전의 잠재적 위키미디어 프로젝트 위키를 정리하고, 작성하고, 테스트하고, 위키미디어 재단에서 호스팅할 가치가 있음을 입증할 수 있는 곳입니다. 인큐베이터는 사용자가 사전 위키 편집 지식을 갖고 있다는 가정 하에 2006년에 출시되었습니다. 이 문제는 이 과정이 우리 운동에서 가장 새롭고 경험이 가장 적은 사람들에 의해 주로 수행되어야 한다는 사실로 인해 더욱 악화됩니다. 그 이후로 위키미디어 위키 편집이 크게 향상되었지만 인큐베이터는 이러한 업데이트를 받지 못했습니다. 기술적 한계까지. 현재 위키가 인큐베이터를 졸업하는 데는 몇 주가 소요되며, 매년 약 12개의 위키만 생성되어 상당한 병목 현상을 보이고 있습니다.

기존 연구 및 자료는 인큐베이터에 새로운 언어 추가, 콘텐츠 개발 및 검토의 복잡성, 언어가 인큐베이터를 졸업할 때 위키 사이트 생성 속도 저하 등 언어 온보딩의 모든 단계에서 기술적 과제를 드러냅니다.

각 단계는 느리고 수동적이며 복잡하므로 개선이 필요합니다. 이 문제를 해결하면 새로운 언어로 위키를 더 빠르고 쉽게 만들 수 있으며 더 많은 사람이 지식을 공유할 수 있습니다. 다양한 이해관계자, 기존 연구 및 리소스에서 제안된 사회적, 기술적 권장 사항을 강조했습니다. 이 주요 결과에서는 사회적, 기술적 두 가지 권장 사항을 테스트하고 커뮤니티 피드백을 평가할 것을 제안합니다.

Satdeep Gill & Mary Munyoki
WE2.3

토론

2분기 말까지 2개의 새로운 기능이 기여자가 프로젝트 지침을 준수하는 출처 자료를 추가하도록 안내하고, 3~5명의 파트너가 언어 및 지리 격차를 해결하는 소스 자료를 기여했습니다. 전략적 콘텐츠 격차를 줄이는 데 필요한 고품질 소스 자료에 대한 접근성을 높이기 위해 우리는 다음을 수행할 것입니다:
  • 생물 다양성 유산 도서관과 파트너십을 맺으세요. AfLIA; 위키문헌 러브 매뉴스크립트 학습 네트워크도 있습니다.
  • 보다 접근하기 쉬운 재사용 지표를 통해 콘텐츠 파트너 확보 및 유지를 지원합니다.
  • 예를 들어 업로드/추가 중에 잠재적인 문제를 표시하여 기여자가 프로젝트 지침을 준수하고 콘텐츠에 대한 신뢰를 높이는 이미지와 참조를 추가하도록 안내합니다.
Fiona Romeo & Alexandra Ugolnikova
WE2.4

토론

2분기 말까지 하나 이상의 작은 언어인 위키백과에서 위키함수 호출을 활성화하여 새로운 콘텐츠를 시드하는 보다 확장 가능한 방법을 제공합니다. 지식 격차를 효과적으로 줄이려면 특히 소규모 언어 커뮤니티에서 고품질 콘텐츠의 확장 가능한 성장을 지원하는 워크플로를 개선해야 합니다. Amy Tsay
WE3.1

토론

경험 사용자의 로그아웃 독자 유지율을 5% 높이는 것을 목표로 두 가지 선별되고 접근 가능하며 커뮤니티 중심의 탐색 및 학습 경험을 대표적인 위키에 출시합니다. 이 KR은 독자들이 관심 있는 콘텐츠를 보다 쉽게 발견하고 배울 수 있는 기회를 탐색함으로써 새로운 세대가 위키백과와 지속적인 연결을 구축할 수 있도록 웹 사이트에서 새로운 세대의 독자 유지율을 높이는 데 중점을 둡니다. 여기에는 다음이 포함됩니다. 새로운 선별되고 개인화된 커뮤니티 중심 탐색 및 학습 경험의 탐색 및 개발(예: 관련 콘텐츠 피드, 주제별 콘텐츠 추천 및 제안, 커뮤니티 선별 콘텐츠 탐색 기회 등)

우리는 프로덕션 용도로 확장할 대상과 플랫폼(웹, 앱 또는 둘 다)을 결정하기 위해 일련의 브라우징 경험 실험을 통해 회계 연도를 시작할 계획입니다. 그런 다음 이러한 실험을 확장하고 프로덕션 환경에서 유지율을 높이는 데 있어 효율성을 테스트하는 데 중점을 둘 것입니다. 올해 말까지 우리의 목표는 대표적인 위키에서 최소 두 가지 경험을 시작하고 이러한 경험에 참여한 독자의 독자 보유율이 5% 증가한 것을 정확하게 측정하는 것입니다.

이 KR을 최적으로 효과적으로 달성하려면 로그아웃한 사용자를 대상으로 A/B 테스트를 수행할 수 있는 능력과 독자 유지율을 측정할 수 있는 도구가 필요합니다. 권장 사항 및 기타 큐레이션 메커니즘을 제시하는 데 필요한 새로운 API 또는 서비스가 필요할 수도 있습니다.

Olga Vasileva
WE3.2

토론

플랫폼별 연간 배너 및 이메일 호소 외 터치포인트를 통한 기부 건수 50% 증가. 우리의 목표는 기존 기부자를 인정하면서 다양한 수익원을 제공하는 것입니다. 피드백과 데이터를 바탕으로 우리는 재단이 과거에 의존했던 방식, 특히 연례 배너 호소 방식을 넘어서 기부 횟수를 늘리는 데 중점을 두고 있습니다. 우리는 보다 통합된 기부자 경험에 투자함으로써 배너 호소에 반응하지 않는 기부자와 잠재적 기부자에게 대안을 제공함으로써 우리의 활동을 지속하고 영향력을 확대할 수 있음을 보여주고 싶습니다. 50%는 벡터 2022의 결과로 웹에서 기부 버튼의 가시성이 감소하고 기부자 경험을 향상시키기 위해 위키백과 앱에서 FY 2023-2024 파일럿 프로젝트의 기부 수가 증가한 것을 기반으로 한 초기 추정치입니다(기부금 50.1% 증가). 플랫폼별로 이 측정항목을 평가하면 플랫폼의 추세를 이해하고, 플랫폼 잠재고객에 따른 행동 차이를 기반으로 향후 다양한 전술을 배포해야 하는지 이해하는 데 도움이 됩니다. Jazmin Tanner
WE3.3

토론

2024~25년 2분기 말까지 자원봉사자들은 위키백과 문서 작성 시 레거시 그래프를 새로운 그래프 확장으로 변환하기 시작할 것입니다. 2023년 4월부터 보안상의 이유로 그래프 확장 프로그램이 비활성화되어 독자는 커뮤니티 구성원이 지난 10년 동안 시간과 노력을 투자한 많은 그래프를 볼 수 없게 되었습니다.

데이터 시각화는 매력적인 백과사전적 콘텐츠를 생성하는 역할을 합니다. 따라서 회계연도 2024-25년에 우리는 위키백과 문서 페이지에서 대부분의 간단한 데이터 시각화 사용 사례를 처리할 그래프 확장을 대체하는 새로운 보안 서비스를 구축할 것입니다. 이 새로운 서비스는 향후 WMF 또는 커뮤니티 개발자가 그렇게 하기로 선택한 경우 보다 정교한 사용 사례를 지원하기 위해 확장 가능한 방식으로 구축될 것입니다.

커뮤니티 구성원이 기존 그래프를 성공적으로 변환하고 새 서비스를 사용하여 새 그래프를 게시하면 우리가 성공했다는 것을 알 수 있습니다. 프로젝트 초기 단계에서 사용할 기본 데이터 시각화 라이브러리와 지원할 그래프 유형을 결정합니다.

Christopher Ciufo
WE4.1

토론

데이터를 바탕으로 진화하는 규제 환경에 맞춰 괴롭힘 및 유해 콘텐츠에 대한 3가지 대책을 3분기 말까지 제안합니다. 사용자의 안전과 웰빙을 보장하는 것은 온라인 플랫폼의 기본 책임입니다. 많은 관할권에는 온라인 플랫폼이 괴롭힘, 사이버 폭력 및 기타 유해한 콘텐츠에 대해 조치를 취하도록 요구하는 법률 및 규정이 있습니다. 이러한 문제를 해결하지 못하면 플랫폼이 법적 책임과 규제 제재를 받을 수 있습니다.

현재 우리는 이러한 문제가 얼마나 큰지, 그 이유가 무엇인지에 대해 잘 알지 못합니다. 우리는 일화적인 증거와 수동 프로세스에 크게 의존하여 법적 위험은 물론 문제의 과소평가, 피해 확대, 평판 손상, 사용자 신뢰 저하 등 광범위한 결과에 노출됩니다.

우리는 괴롭힘 및 유해 콘텐츠의 발생률을 측정하는 강력한 문화를 구축하고 적극적으로 대응 조치를 시행해야 합니다.

Madalina Ana
WE4.2

토론

3분기 말까지 악의적인 행위자에 대한 조치의 정확성을 높이기 위해 악용 방지 워크플로에 사용할 신호를 2개 이상 개발합니다. 위키는 문서 훼손, 스팸 및 남용을 차단하기 위한 메커니즘으로 IP 차단에 크게 의존합니다. 그러나 IP 주소는 개별 행위자의 안정적인 식별자로서 점점 덜 유용하며, IP 주소를 차단하면 악의적인 행위자와 동일한 IP 주소를 공유하는 선의의 사용자에게 의도하지 않은 부정적인 영향을 미칠 수 있습니다. IP 주소의 안정성 저하와 IP 차단에 대한 과도한 의존으로 인해 악의적인 행위자를 표적으로 삼는 데 있어 정확성과 효율성이 떨어지고 선의의 사용자에 대한 부수적 피해 수준도 증가합니다. 우리는 반대 상황, 즉 부수적 피해 수준을 낮추고 악의적인 행위자를 표적으로 하는 완화의 정확성을 높이기를 원합니다.

직원의 남용 방지 작업을 더 잘 지원하고 기존 도구(예: 검사관, 특수:차단)와 새 도구에서 재사용할 수 있는 구성 요소를 제공하기 위해, 이번 KR에서는 개인을 자신의 행동(대중계정 완화)과 안정적으로 연결하고 기존 신호(예: IP 주소, 계정 기록, 요청 속성)를 결합하여 악의적인 행위자에 대한 행동을 보다 정확하게 타겟팅할 수 있는 방법을 모색할 것을 제안합니다.

Kosta Harlan
WE4.3

토론

측정값을 조정하는 데 걸리는 시간과 시뮬레이션에서 유지할 수 있는 트래픽 양을 기준으로 측정했을 때 대규모 분산 공격의 효과를 50% 줄입니다. 대규모 봇넷의 등장과 빈번한 공격 등 인터넷 환경의 발전으로 인해 대규모 남용을 제한하는 전통적인 방법이 더 이상 쓸모 없게 되었습니다. 이러한 공격으로 인해 인프라에 요청이 넘쳐 사이트를 사용할 수 없게 되거나 대규모 문서 훼손 행위에 맞서 싸우는 커뮤니티의 능력이 압도될 수 있습니다. 이는 또한 우리의 고위 편집자 및 기술 커뮤니티에 불합리한 부담을 줍니다.

우리는 그러한 공격을 자동으로 감지하고, 방어하고, 완화하거나 중지하는 능력을 시급히 개선해야 합니다. 개선 사항을 측정하기 위해 실제 공격의 빈도/강도에만 의존할 수는 없습니다. 왜냐하면 외부 조치에 의존하고 진행 상황에 대한 명확한 정량적 그림을 얻는 것이 어렵기 때문입니다.

다양한 특성/복잡성/기간의 여러 시뮬레이션 공격을 설정하여 인프라에 대해 안전하게 실행하고 매 분기마다 실행함으로써 공격을 받지 않는 동안 새로운 대응책을 테스트하고 개선 사항을 객관적으로 보고할 수 있습니다.

Giuseppe Lavagetto
WE4.4

토론

모든 위키의 100%에 임시 계정을 시작하세요. 임시 계정은 다양한 표면에서 우리 플랫폼의 IP 노출과 관련된 다양한 규제 요구 사항을 준수하기 위한 솔루션입니다. 이 작업에는 추가 계정 유형의 존재에 대처하기 위해 많은 제품, 데이터 파이프라인, 기능 도구 및 다양한 자원 봉사 워크플로를 업데이트하는 작업이 포함됩니다. Madalina Ana
WE5.1

토론

3분기 말까지 플랫폼의 지속 가능성을 높이기 위한 최소 5가지 개입을 완료하세요. 미디어위키 플랫폼 지속 가능성은 개발자 만족도 저하를 확장, 증가 또는 방지하고 기술 커뮤니티를 성장시키는 능력에 중요한 지속적인 노력입니다. 이는 측정하기 어렵고 기술적, 사회적 요인에 따라 달라집니다. 그러나 우리는 지속 가능성을 위한 전략적 개선의 특정 영역에 대한 암묵적 지식을 보유하고 있습니다. 계획된 개입은 플랫폼의 지속 가능성과 유지 관리 가능성을 높이거나 성능 저하를 방지하는 데 도움이 될 수 있습니다. 우리는 앞으로 지속 가능성 목표에 대한 권장 사항을 통해 4분기에 이 작업의 영향을 평가할 계획입니다. 지속 가능성 개입의 예는 다음과 같습니다: 미디어위키의 핵심이지만 소수의 사람들만이 그것이 어떻게 작동하는지 알고 있는 복잡한 코드 도메인을 단순화합니다. 코드베이스의 품질을 알리기 위해 코드 분석 도구의 사용을 늘립니다. 패키징 및 릴리스와 같은 프로세스를 간소화합니다. Mateus Santos
WE5.2

토론

분리되고 단순하며 지속 가능한 기능 개발을 지원하기 위해 미디어위키 생태계의 프로그래밍 인터페이스를 발전시키기 위한 하나 이상의 개입을 2분기 말까지 식별하고 4분기 말까지 완료합니다. KR 5.2의 주요 목표는 미디어위키의 핵심 플랫폼과 확장 기능, 스킨 및 기타 부분 간의 상호 작용을 개선하고 명확하게 하는 것입니다. 우리의 의도는 실용적인 모듈성과 유지 관리성을 가능하게 하는 미디어위키 아키텍처의 기능적 개선을 제공하여 확장을 더 쉽게 개발하고 더 넓은 미디어위키 제품 비전의 요구 사항을 강화하는 것입니다. 이 작업은 또한 코어, 확장 또는 이들 사이의 인터페이스 내에 무엇이 존재해야 하는지(또는 존재하지 않아야 하는지)를 알려주는 것을 목표로 합니다. 올해는 두 단계로 나누어질 것입니다. 5개월 간의 연구 및 실험 단계는 구체적인 개입이 구현되는 두 번째 단계를 알려줄 것입니다. [TBD]
WE5.3

토론

2분기 말까지 하나의 데이터 수집 이니셔티브와 하나의 성능 개선 실험을 완료하여 후속 제품 및 플랫폼 개입을 알리고 미디어위키의 페이지 모델링을 통해 구조화된 조각의 구성으로 잠금 해제된 기능을 활용합니다. 여기서 주요 목표는 개발자와 제품 관리자가 새로운 미디어위키 플랫폼 기능을 활용하여 현재 구현하기 어려운 새로운 제품 제공을 가능하게 하고 플랫폼의 성능과 탄력성을 향상시킴으로써 백과사전 콘텐츠의 현재와 미래의 요구를 충족할 수 있도록 하는 것입니다.

특히 미디어위키 플랫폼 수준에서 우리는 미디어위키의 처리 모델을 페이지를 단일 단위로 처리하는 것에서 페이지를 구조화된 콘텐츠 단위의 구성으로 처리하는 것으로 전환하려고 합니다. Parsoid 기반 읽기 보기, 위키데이터 통합, 위키에 위키함수 통합은 모두 이를 향한 암묵적인 움직임입니다. 이번 KR의 일환으로 우리는 의도한 인프라 및 제품 영향을 달성할 수 있도록 이러한 새로운 기능을 기반으로 향후 개입을 알리기 위해 데이터를 보다 의도적으로 실험하고 수집하고자 합니다.

[TBD]
WE5.4

토론

2분기 말까지 PHP 업그레이드와 동기화되는 새로운 MW 릴리스 프로세스를 통해 1.43 LTS 릴리스를 실행하세요. 미디어위키 소프트웨어 플랫폼은 안전하고 지속 가능한 상태를 유지하기 위해 다음 PHP 버전에 대한 정기적인 업데이트에 의존합니다. 이는 우리 프로세스의 문제점이자 인프라 현대화에 중요합니다. 동시에 우리는 정기적으로 미디어위키 소프트웨어의 새 버전을 출시합니다. translatewiki.net은 위키미디어 프로젝트 및 기타 많은 오픈 소스 프로젝트의 소프트웨어 메시지를 번역하는 데 사용되는 플랫폼에 의존합니다.

장기 지원 버전(LTS)이 될 다음 릴리스 이전에 미디어위키 제품 전략에 맞춰 기술 문서화 및 PHP 업그레이드와의 동기화를 포함하여 미디어위키 출시 프로세스를 개선할 수 있는 기회가 있습니다. 이 작업은 미디어위키 플랫폼(5.1 참조)의 지속 가능성에 대한 전략적 투자의 일부이며 개발자 경험과 인프라 관리를 개선하는 것을 목표로 합니다.

Mateus Santos
WE6.1

토론

5가지 질문을 해결하여 개발자와 엔지니어링 워크플로 및 서비스에 대한 효율성과 정보에 입각한 결정을 내리고 4분기 말까지 관련 데이터에 액세스할 수 있도록 하세요. "복잡하다"는 "위키미디어 프로덕션에 어떤 저장소가 배포되는지"와 같은 질문에 자주 대답됩니다. 이번 KR에서는 엔지니어링 생산성 및 경험 분야의 "항상 최신 버전" 중 일부를 탐색합니다. 쉬워 보이지만 답변하기 어려운 반복 질문, 답변할 수 있지만 데이터에 액세스할 수 없고 주제별 사용자 정의 쿼리가 필요한 질문 등을 살펴보겠습니다. 문제 전문가, 프로세스 격차 또는 기타 이유로 답변을 얻기 어려운 질문. 우리는 각 질문에 대해 "해결"이 무엇을 의미하는지 정의할 것입니다. 일부의 경우 이는 단지 기존의 정확한 데이터에 액세스할 수 있도록 하는 것을 의미할 수도 있습니다. 다른 질문을 해결하려면 더 많은 연구와 엔지니어링 시간이 필요합니다. 이 작업의 가장 중요한 목표는 개발자 경험의 주요 측면에 대한 통찰력을 얻고 엔지니어링 및 개발자 워크플로와 서비스를 개선하는 데 소요되는 시간, 해결 방법 및 노력을 줄이는 것입니다. [TBD]
WE6.2

토론

4분기 말까지 기존 프로젝트를 강화하고 유지 관리 가능하고 대상이 지정된 환경을 제공하여 안전하고 반연속적인 제공을 목표로 하는 최소 두 가지 실험을 수행합니다. 개발자와 사용자는 위키미디어 베타 클러스터(베타)를 사용하여 버그가 프로덕션 환경에서 사용자에게 영향을 미치기 전에 버그를 잡아냅니다. 시간이 지남에 따라 베타 사용이 증가하고 충돌이 발생했습니다. 사용이 너무 다양하여 단일 환경에 적합하지 않습니다. 우리는 하나의 기존 대체 환경을 개선하고 현재 베타로 충족되는 단일 우선 순위 테스트 요구 사항을 각 사용 사례의 요구 사항을 더 잘 충족하는 유지 관리 가능한 대체 환경으로 대체하는 것을 목표로 하는 실험을 수행할 것입니다. Tyler Cipriani
WE6.3

토론

2분기 말까지 다양한 기술적, 사회적 요인에 걸쳐 툴포지 플랫폼을 위한 지속 가능성 채점 시스템을 도입합니다. 4분기 말까지 핵심 기술 요소 중 하나를 50% 개선합니다. 위키미디어의 자원 봉사 도구의 핵심 플랫폼인 툴포지는 편집부터 반달리즘 방지까지 중요한 역할을 합니다. 우리의 목표는 툴포지 유용성을 향상시키고, 기여 장벽을 낮추며, 커뮤니티 관행을 개선하고, 확립된 정책 준수를 촉진하는 것입니다. 이를 위해 우리는 기술적, 사회적 측면에 초점을 맞춰 툴포지 플랫폼의 지속 가능성을 평가하는 점수 시스템을 2분기 말까지 도입할 예정입니다. 이 시스템을 가이드로 사용하여 핵심 기술 요소 중 하나를 50% 개선하는 것을 목표로 합니다. Slavina Stefanova

신호 및 데이터 서비스(SDS) 주요 결과

[ 목표 ]

핵심 결과 단축명 핵심 결과 텍스트 핵심 결과 맥락 소유자
SDS1.1

토론

3분기 말까지 2개의 프로그램 또는 KR 주도 이니셔티브가 하나 이상의 핵심 지표에 대한 작업의 직접적인 영향을 평가했습니다. 우리의 핵심 조직 지표는 재단의 목표 달성 과정을 평가하는 핵심 도구 역할을 합니다. 우리가 프로그램에 자원을 할당하고 핵심 결과(KR) 중심 작업 흐름을 설계할 때 이러한 높은 수준의 측정 기준은 이러한 투자를 연간 계획에 정의된 재단의 중요한 목표와 연결하는 방법을 안내해야 합니다.

이 주요 결과에 대한 작업은 재단 전체가 계획된 모든 개입의 영향을 상위 수준 또는 핵심 지표에 정량적으로 연결하는 능력이 초기 단계에 있음을 인정합니다. 이러한 최종 목표를 추구하기 위해 이 KR은 우리의 이니셔티브와 상위 수준 지표 간의 논리적, 이론적 연결을 공유하는 프로세스를 개발하는 것을 목표로 합니다. 실제로 이는 재단 전체의 이니셔티브 소유자와 협력하여 프로젝트 수준에서 작업 결과가 재단 수준의 핵심 지표와 어떻게 연결되고 영향을 미치는지 이해하는 것을 의미합니다.

현재 재단은 프로그램이나 제품 중심 이니셔티브를 실행하고 이러한 활동이 핵심 재단 수준 지표에 미치는 영향을 분석할 수 있다는 목표의 초기 단계에 있습니다. 이 목표를 추구하기 위해 본 KR은 다음을 수행하는 것을 목표로 합니다. 최소 두 가지 후보 프로그램 또는 제품 중심 이니셔티브를 식별하고, 핵심 지표 영향을 평가하기 위한 평가 전략을 설계하고, 이 평가 전략을 실행합니다. 두 가지 이니셔티브로 시작하면 작업의 영향을 핵심 지표의 관찰 가능한 변화에 귀속시킬 수 있는 분석 수행의 과제를 빠르게 이해하는 데 도움이 됩니다. 이번 KR에서 배운 내용은 이 측정 전략을 더 넓은 범위와 양의 재단 이니셔티브에 적용하기 위한 더 넓은 전략을 알려줄 것입니다.

Omari Sefu
SDS1.2

토론

권장 사항을 제공하거나 회계연도 26년 연간 계획을 알리기 위해 2024년 12월까지 2가지 전략적 공개 연구 질문에 답변하세요. 위키미디어 생태계에는 공개된 연구 질문이 많이 있으며 이러한 질문 중 일부에 대답하는 것은 WMF 또는 계열사에게 전략적입니다. 이러한 질문에 대한 답변은 향후 제품이나 기술 개발에 대한 정보를 제공하거나 정책 공간에서 의사 결정/옹호를 지원할 수 있습니다. 이러한 질문 중 일부는 순전히 연구 또는 연구 엔지니어링 전문 지식을 활용하여 답할 수 있지만 신뢰할 수 있는 통찰력에 도달하는 WM 프로젝트의 사회 기술적 특성을 고려할 때 종종 데이터 수집, 컨텍스트 구축, 사용자 상호 작용, 신중한 디자인을 위한 팀 간 협업이 필요합니다. 실험 등. 이 KR을 통해 우리는 이러한 질문 중 하나 이상에 답하는 데 일부 리소스의 우선순위를 지정하는 것을 목표로 합니다.

이 KR의 작업에는 전략적 미해결 질문 목록의 우선순위를 지정하는 것뿐만 아니라 그 중 X개(현재 약 2개)에 대한 답을 찾기 위한 실험 작업도 포함됩니다. 이 KR에서 우리가 다루는 이상적인 유형의 질문은 일단 답변되면 여러 다른 팀이나 그룹이 (더 나은 정보를 바탕으로) 제품, 기술 또는 정책 작업을 수행할 수 있도록 하여 잠금 해제 효과를 가질 수 있는 질문입니다. 우리는 이 KR의 작업이 다음 KR을 보완할 계획입니다.

  • PES1.3. 플랫폼 내 제품을 실험하거나 기존 제품을 기반으로 한 기능 아이디어를 실험하는 데 중점을 두고 있습니다.
  • FA1.1. AI/ML 기술을 활용하여 미래 청중에 대한 실험에 중점을 둡니다.
Leila Zia
SDS1.3

토론

데이터 이해관계자가 3가지 핵심 및 필수 지표에 대한 데이터 흐름을 이해하고 추적하는 데 필요한 평균 시간을 최소 50% 단축합니다. 데이터 거버넌스 표준에 필요합니다.

데이터세트의 변환과 소스를 역추적하는 것은 어려우며 다양한 저장소와 시스템에 대한 지식이 필요합니다. 데이터 이해관계자가 보다 셀프 서비스 방식으로 작업할 수 있도록 시스템에서 데이터가 어떻게 흐르는지 쉽게 이해할 수 있도록 해야 합니다.

이 작업은 분석, 기능, API 및 데이터 품질 작업을 위해 데이터가 변환되고 사용되는 워크플로를 지원합니다. 측정항목 문서화에 대한 후속 KR이 있을 예정입니다.

Luke Bowmaker
SDS2.1

토론

2분기 말까지 우리는 1개의 제품 팀이 사용자 상호 작용 데이터에 소요되는 시간을 50% 단축하는 기본 A/B 테스트를 통해 기능이나 제품을 평가하도록 지원할 수 있습니다. 우리는 공유 도구를 사용하면 제품 팀의 데이터 기반 의사 결정이 향상되고, 효율성과 생산성이 향상되며, 제품 전략과 혁신이 강화될 것이라고 생각합니다.

로그인한 사용자를 위한 UX 및 기술 시스템을 구축하면 SDS 2.3의 타당성 작업이 진행되는 동안 로그아웃된 사용자에 대한 A/B 테스트를 지원한다는 장기적인 목표를 향해 나아갈 수 있습니다. 우리는 팀의 개별 사용자 상호 작용 시간 데이터 기준을 채택하고 이를 50% 개선할 것입니다. 또한 모든 제품 팀의 전체 맥락에서 이러한 이점을 맥락화할 수 있는 방법을 조사할 것입니다.

우리는 채택 팀의 피드백과 SDS 2.2의 결과를 기반으로 경험을 개선하고 기능 향상을 식별하고 우선 순위를 지정할 수 있는 방법을 배울 것으로 기대합니다.

Virginia Poundstone
SDS2.2

토론

2분기 말까지 우리는 회계연도 24-25년 KR과 관련된 제품/기능 가설 테스트를 지원하기 위해 실험(A/B 테스트) 분석을 위한 3가지 필수 측정항목을 갖게 될 것입니다. 제품 관리자(또는 디자이너)가 제품/기능이 사용자 또는 조직의 문제/요구 사항을 해결할 것이라는 가설을 가지고 있는 경우, 실험은 해당 가설을 테스트하고 자신의 아이디어가 지표에 미치는 잠재적 영향에 대해 알아보는 방법입니다. 실험 결과는 제품 관리자에게 알리고 다음에 취할 조치를 결정하는 데 도움이 됩니다(이 아이디어를 버리고 다른 가설을 시도하고, 실험이 개발 수명주기 초기에 수행된 경우 개발을 계속하거나, 더 많은 사용자에게 제품/기능을 출시하세요). 제품 관리자는 자신이 신뢰하고 이해하는 증거를 바탕으로 확신을 가지고 그러한 결정을 내릴 수 있어야 합니다.

이에 대한 주요 장애물은 현재 제품 팀이 정의, 측정, 분석 및 보고를 위해 전담 분석가 지원이 필요한 맞춤형 프로젝트별 측정항목을 사용하여 가설을 공식화한다는 것입니다. 테스트 가능한 모든 제품/기능 가설 진술을 공식화하기 위해 일련의 필수 측정항목으로 전환하면 다음과 같은 결과가 발생합니다.

  • 이러한 가설을 테스트하기 위한 실험을 더 쉽고 빠르게 설계, 배포 및 분석할 수 있습니다.
  • 실험의 결과와 학습 내용을 의사 결정자(제품 관리자) 및 기타 청중(예: 고위 경영진, 조직 내 다른 사람, 커뮤니티)에게 더 쉽게 전달할 수 있습니다.

우리는 널리 이해되고 지속적으로 사용되며 업계 표준 지표에 의해 정보를 얻거나 영향을 받는 일련의 필수 지표가 조직의 데이터 활용 능력을 향상시키고 검토, 실험 및 학습 문화를 촉진할 것이라고 생각합니다. 우리는 (1) 2가지 위키 경험 KR(WE3.1 및 WE1.2)과 관련된 제품/기능의 성공/영향을 가장 잘 측정하고 평가하는 데 필요한 필수 지표에 초점을 맞추고 있습니다. (2) 업계에 반영하거나 매핑합니다. 웹 분석에 사용되는 표준 측정항목입니다.

Mikhail Popov
SDS2.3

토론

익명의 독자를 통해 제품 기능의 A/B 테스트를 가능하게 하는 고유한 에이전트 추적 메커니즘을 CDN에 배포합니다. 이러한 추적 메커니즘이 없으면 익명의 독자를 대상으로 제품 기능에 대한 A/B 테스트를 구현하는 것은 합리적이지 않습니다.

이는 기본적으로 다른 사람들이 측정 가능한 것을 구축할 수 있는 새로운 기술적 역량을 창출하기 위한 이정표 기반 결과입니다. 핵심 우선순위 사용 사례는 익명의 독자를 대상으로 한 기능의 A/B 테스트이지만 이 작업은 또한 WE4.x(요청 위험 등급 및 대규모 공격 완화용)에서 나중에 후속 가설을 생성할 수 있는 다른 중요한 미래 기능도 가능하게 하며 다음과 같은 고유 장치 수에 대한 측정/연구를 수행합니다. 리소스와 우선순위가 허용됩니다.

Brandon Black

향후 잠재고객(FA) 주요 결과

[ 목표 ]

핵심 결과 단축명 핵심 결과 텍스트 핵심 결과 맥락 소유자
FA1.1

토론

미래 잠재고객 실험 통찰력 및 권장 사항의 결과로, 3분기 말까지 미래 잠재고객 팀이 아닌 팀이 소유한 하나 이상의 목표 또는 핵심 결과가 다음 연도 연간 계획 초안에 포함됩니다. 2020년부터 위키미디어 재단은 미래 세대의 지식 소비자 및 지식 기여자에게 서비스를 제공하고 다음 세대를 위해 번성하는 무료 지식 운동을 유지하는 능력에 영향을 미칠 수 있는 외부 동향을 추적해 왔습니다. 소규모 R&D 팀인 미래의 잠재고객은 다음을 수행합니다:
  • 이러한 추세를 해결하는 방법을 모색하기 위해 신속하고 시간 제한이 있는 실험(회계연도당 최소 3번의 실험 목표)을 수행합니다.
  • 실험에서 얻은 통찰력을 바탕으로 WMF가 추구해야 하는 새로운 비실험적 투자(예: 전체 팀이 수행해야 하는 새로운 제품 또는 프로그램)에 대한 권장 사항을 정기 연간 계획 기간 동안 제시합니다. 이 주요 결과는 충족될 것입니다. 미래의 잠재 고객 외부의 팀이 소유하고 미래의 잠재 고객 권고 사항에 따라 추진되는 하나 이상의 목표 또는 주요 결과가 다음 회계 연도의 연간 계획 초안에 나타나는 경우.
Maryana Pinchuk

제품 및 엔지니어링 지원(PES) 주요 결과

[ 목표 ]

핵심 결과 단축명 핵심 결과 텍스트 핵심 결과 맥락 소유자
PES1.1

토론

검토 문화: 분기별 설문조사를 통해 전달, 조정, 방향 및 팀 상태와 관련된 P+T 직원 감정 점수를 점진적으로 향상합니다. 검토 문화는 더 짧은 반복, 학습 및 적응 주기를 기반으로 하는 제품 개발 문화입니다. 이는 우리 조직이 연간 목표를 설정할 수 있지만 이러한 목표를 달성하기 위해 수행하는 작업은 학습하면서 일년 내내 변경되고 적응될 것임을 의미합니다. 검토 문화를 구축하는 데에는 프로세스와 행동이라는 두 가지 구성 요소가 있습니다. 본 KR은 후자에 초점을 맞추고 있습니다. 행동 변화는 우리의 검토 문화를 성장시키고 강화할 수 있습니다. 여기에는 보다 반복적인 제품 개발을 향해 나아가면서 개인의 습관과 일상의 변화가 포함됩니다. 이 KR은 개인 행동의 자체 보고된 변화를 기반으로 하며, 결과적인 변화가 있는 경우 직원 정서의 변화를 측정합니다. Amy Tsay
PES1.2

토론

2분기 말까지 새로운 위시리스트는 운동 아이디어와 요청을 재단 P+T 활동에 더 잘 연결합니다. 위시리스트 백로그의 항목은 2024-5년 KR을 통해 처리되고 재단은 10개의 작은 소원을 완료했으며 재단은 다음과 파트너십을 맺었습니다. 2025-26년 회계연도에 3개 이상의 기회 영역을 식별하기 위한 자원 봉사자입니다. 커뮤니티 위시리스트는 운동의 좁은 부분을 나타냅니다. 약 1,000명이 참여하며, 대부분은 기여자 또는 관리자입니다. 사람들은 종종 파브리케이터를 통해 기능 요청 및 버그 보고서를 작성하여 위시리스트를 우회하는데, 여기서는 WMF나 커뮤니티의 요청을 식별하기 어렵습니다. 참가자에게 위시리스트는 최소한의 보상으로 값비싼 시간 투자입니다. 그들은 위시리스트가 영향력 있는 버그와 기능 개선에 대한 관심을 불러일으키거나 더 광범위하고 전략적인 기회에 대한 필요성을 알리는 유일한 수단이라고 생각하기 때문에 여전히 위시리스트에 참여합니다. 소망은 종종 문제와 해결책으로 쓰여집니다. 솔루션은 서류상으로는 타당해 보일 수 있지만 기술적 복잡성이나 이동 전략에 미치는 영향을 반드시 고려하지는 않습니다.

희망사항의 범위와 폭이 때때로 커뮤니티 테크나 단일 팀의 범위와 역량을 초과하여 불만이 지속되어 RFC 및 위시리스트 해체 요청으로 이어집니다. 커뮤니티 구성원은 프로젝트 아이디어를 위해 위시리스트를 사용하는 것을 선호하는 반면, 재단의 팀은 우선순위를 위해 위시리스트 및 기타 접수 프로세스를 살펴봅니다. 그 이유 중 하나는 희망 사항이 연간 계획에 적합하지 않고 로드맵/OKR에 통합하기 어렵기 때문입니다.

미래 위시리스트는 커뮤니티와 재단 사이의 가교 역할을 하여 커뮤니티가 구조화된 방식으로 의견을 제공함으로써 우리가 조치를 취하고 결과적으로 자원봉사자들을 행복하게 만들 수 있어야 합니다. 우리는 로그인한 모든 자원봉사자가 1년 365일 소원을 제출할 수 있는 새로운 접수 프로세스를 만들고 있습니다. Wish는 버그를 보고하거나 강조하거나, 개선을 요청하거나, 새로운 기능에 대한 아이디어를 내는 데 사용할 수 있습니다. 누구든지 Wish에 댓글을 달거나, 워크숍을 진행하거나, 지원할 수 있어 우선순위에 영향을 미칠 수 있습니다. 재단은 소원을 '너무 크다', '너무 작다'로 분류하지 않습니다.

더 큰 문제 영역에 주제별로 매핑하면 연간 계획과 팀 로드맵에 영향을 주어 전략적 방향과 기회를 제공할 수 있습니다. 희망사항은 프로젝트, 제품/문제 영역, 희망사항 유형별로 분류된 대시보드에서 운동에 표시됩니다. 재단은 적시에 희망사항에 응답하고, 커뮤니티와 협력하여 희망사항을 분류하고 우선순위를 정합니다. 우리는 위키미디어인들과 협력하여 재단의 2025-26년 연간 계획에 포함된 세 가지 개선 영역을 식별하고 우선순위를 정할 것입니다. 이는 채택률과 영향력 있는 소망의 성취를 향상시켜야 합니다. 우리는 자원 봉사 개발자 커뮤니티와 재단 팀에 대한 폭넓은 소망을 표시하여 더 많은 팀과 개발자 참여를 유도하고 더 많은 소망을 성취하여 커뮤니티 만족도를 높일 것입니다. 더 많은 희망 사항을 해결하면 기여자의 만족도, 효율성 및 유지율이 향상되어 더 많은 편집 품질, 더 높은 품질의 콘텐츠 및 더 많은 독자가 생성됩니다.

Jack Wheeler
PES1.3

토론

1분기와 2분기에 위키백과를 현재 소비자 및 자원 봉사 대상 청중을 위한 지식 목적지로 성장시키는 방법에 대한 데이터/통찰력을 제공하는 기존 탐색 제품/기능에서 두 가지 실험을 실행하고 결론을 내립니다. 3분기 말까지 위키 경험 버킷에서 향후 OKR 작업에 대한 잠재적 채택을 위한 학습 및 권고 사항을 완료하고 공유하세요. 이 작업은 미래의 잠재 고객 목표에 상응하는 것이지만, 대신 더 많은 플랫폼 내 제품 아이디어를 보다 민첩하게 테스트함으로써 기존 청중(위키백과 소비자 및 기여자)의 참여를 늘리고 심화할 수 있는 기회를 찾는 데 중점을 둡니다.

이는 개인과 팀이 "이미" 사이드 프로젝트에 대한 해킹/실험에 투자한 시간을 더 유망한 기능에 집중시키기 위해 에너지를 공급하고 승수로서 PES1에 존재합니다. 이러한 사이드 프로젝트가 시들해지는 대신(제한된 자원을 제대로 활용하지 못함), 이 KR은 입증된 실험을 통해 이러한 아이디어 중 일부를 잠재적으로 더 큰 APP 설정으로 만들 수 있는 경로를 제공하여 직원 시간을 보다 효율적으로 사용하고 창의력과 동기를 부여합니다. 생산력.

더 작고 짧은 프로젝트를 더 많이 진행함으로써 우리는 현재 청중의 변화하는 요구와 기대에 맞춰 위키백과를 변화시킬 수 있는 아이디어에 대한 더 많은 학습과 시도를 위해 '베팅'의 확산을 다양화합니다. 이를 통해 재단이 더 짧은 시간에 올바른 목표를 달성하는 데 도움이 되므로 우리 작업이 더욱 효과적이고 빨라질 것입니다.

Rita Ho
PES1.4

토론

SLO 설정, 모니터링, 결정 방법을 알아보세요. 출시할 때 SLO를 정의할 새로운 항목을 하나 이상 선택하세요. 해당 팀(일반적으로 제품, 개발팀, SRE)과 협력하여 해당 SLO를 정의합니다. 향후 SLO를 적용해야 하는 릴리스와 이를 설정하는 방법에 대한 지침을 반영하고 문서화합니다. 미래 KR:

새 릴리스의 SLO를 설정하고 모니터링하기 위한 프로세스 및 기본 도구를 설정합니다. 분기별로 보고하고 이를 사용하여 문제를 해결하기 위해 작업의 우선 순위를 정할 시기와 하지 않을 시기를 결정합니다. 보고서를 커뮤니티와 공유하세요.

왜:

우리는 무언가를 고치기 위해 언제 작업의 우선순위를 정해야 할지 모릅니다. 그리고 우리에게는 많은 코드가 있습니다. 이러한 발자국이 계속 증가함에 따라 문제 해결과 혁신에 집중해야 하는 상황 사이에서 결정해야 할 상황이 더 많아지고, 언제 해야 하는지에 대한 불확실성도 커집니다. 또한 직원과 커뮤니티가 상호 작용하는 모든 다양한 기능에 대한 안정성과 성능에 대한 지원/약속 수준이 무엇인지 명확하지 않습니다. 예상되는 서비스 수준을 정의하면 해당 서비스에 리소스를 할당해야 하는지 여부를 알 수 있습니다.

Mark Bergsma

가설

아래 가설은 위의 관련 주요 결과를 해결하기 위해 각 분기에 수행하는 구체적인 작업입니다.

각 가설은 주요 결과를 달성하는 데 도움이 될 것이라고 믿는 실험 또는 실험의 단계입니다. 팀은 가설을 세우고 이를 테스트한 후 결과를 반복하거나 완전히 다른 새로운 가설을 개발합니다. 가설은 팀의 시간에 대한 베팅으로 생각할 수 있습니다. 팀은 몇 주 정도의 작은 베팅 또는 몇 달의 큰 베팅을 하지만 위험 조정 보상은 팀이 투자한 시간에 비례해야 합니다. 우리의 가설 민첩하고 빠르게 적응해야 합니다. 우리는 분기 중 언제든지 가설을 철회, 조정 또는 시작할 수 있습니다.

가설의 최신 상태를 확인하거나 팀과 가설에 대해 논의하려면 아래 프로젝트 페이지 링크를 클릭하세요.

1분기

WMF 연간 계획의 (1분기)는 7월부터 9월까지입니다.

위키 경험 (WE) 가설

[ WE 주요 결과 ]

토론

가설 단축명 1분기 텍스트 세부사항 및 토론
WE1.1.1 이벤트 목록을 위키프로젝트를 포함하는 커뮤니티 목록으로 확장하면 제품 개발을 위해 위키프로젝트에 참여하는 방법에 대한 초기 학습 내용을 수집할 수 있습니다.
WE1.1.2 커뮤니티 목록에 포함될 3개의 별도 위키백과에서 최소 15개의 위키프로젝트를 식별하면 위키프로젝트를 포함하는 커뮤니티 목록의 MVP를 구축하는 데 필요한 주요 특성을 캠페인 제품에 조언할 수 있습니다.
WE1.1.3 리프트윙을 통해 제공되는 주제를 최대한 활용하는 방법에 대해 20명의 이벤트 주최자와 20명의 위키프로젝트 주최자에게 문의하면 이벤트와 위키프로젝트 간의 주제 연결을 개선할 주제 모델 개정의 우선순위를 지정할 수 있습니다.
WE1.2.1 편집 확인 API의 첫 번째 버전을 구축하고 이를 사용하여 새로운 검사를 도입하면 다른 팀과 함께 속도와 용이성을 평가할 수 있으며 자원봉사자는 API를 사용하여 새로운 검사 및 제안된 편집을 만들 수 있습니다.
WE1.2.2 UI 구성 요소와 시각적 아티팩트 라이브러리를 구축하면 편집 확인의 사용자 경험이 구조화된 작업 패턴을 수용하도록 확장될 수 있습니다.
WE1.2.3 시각 편집기 내/인접한 신규 사용자에게 구조화된 작업을 소개하는 두 개 이상의 디자인 프로토타입에 대해 사용자 테스트를 수행하면 어떤 디자인이 새로운 편집자에게 가장 적합한지 빠르게 알 수 있습니다. 또한 엔지니어가 기술적 타당성을 평가하고 각 접근 방식에 대한 노력을 예측할 수 있도록 해줍니다. mw:Growth/Constructive activation experimentation
WE1.2.4 "공작" 행동 감지에 대해 LLM을 교육하면 이 정책 위반을 최소 >70%의 정밀도와 >50%의 재현율로 감지할 수 있는지 여부를 알 수 있으며 궁극적으로 해당 LLM이 새로운 편집 확인 및/또는 제안된 편집을 수행할 만큼 효과적인지 결정합니다.
WE1.2.5 iOS 앱의 프로덕션 버전에서 대체 텍스트 제안 편집 프로토타입을 사용하여 A/B/C 테스트를 수행하면 이미지에 대체 텍스트를 추가하는 것이 신규 사용자가 성공할 수 있는 작업인지, 그리고 궁극적으로 웹 및/또는 앱에서 제안된 편집으로 구현할 만큼 영향력이 있는지 결정합니다. mw:Wikimedia Apps/iOS Suggested edits project/Alt Text Experiment
WE1.3.1 자동중재자의 동작을 추가로 사용자 정의하고 1분기에 파일럿 프로젝트 피드백을 기반으로 변경하면 더 많은 중재자가 기능 세트와 안정성에 만족하고 위키미디어 프로젝트에서 이를 사용하도록 선택하여 제품 채택이 늘어날 것입니다. mw:Automoderator
WE1.3.2 희망사항의 하위 집합을 중재자 관련 초점 영역으로 해석하고 1~2분기에 커뮤니티 의견을 위해 이러한 초점 영역을 공유할 수 있다면, 그러면 우리가 선택한 초점 영역이 3분기에 출시될 때 중재자 만족도가 향상될 것이라는 높은 수준의 확신을 갖게 될 것입니다.
WE2.1.1 위키백과 문서에 대한 국가 수준 추론 모델을 구축하면 >70%의 정밀도와 >50%의 재현율로 특정 지역에 대한 문서 목록을 필터링할 수 있습니다. m:Research:Language-Agnostic Topic Classification/Countries
WE2.1.2 사용자가 선택한 주제 영역을 기반으로 번역 제안을 제공하는 개념 증명을 구축하면 번역가가 자신의 관심 영역에서 더 많은 번역 기회를 찾고 일반 번역에 비해 더 많이 기여할 수 있는지 여부를 성공적으로 테스트할 수 있게 됩니다. 현재 사용 가능한 제안이 있습니다. mw: Translation suggestions: Topic-based & Community-defined lists
WE2.1.3 목록 작성을 서비스로 제공하는 경우, (1) 관련 위키의 관련 주제에 대한 표준 품질 적용 범위의 변경 및 (2) 위키의 주제 영역 적용 범위에 대한 주최자 만족도에 대한 간략한 설문 조사를 통해 측정된 대로 최소 5개 커뮤니티가 해당 주제 영역에서 보다 목표화된 기여를 할 수 있도록 할 것입니다.
WE2.1.4 위키프로젝트 및 기타 목록 작성 이니셔티브에서 가져온 번역 작업을 추가하는 개념 증명을 개발하고 이를 CX 모바일 워크플로우 내에서 제안으로 제시한다면 더 많은 편집자가 주제 격차에 초점을 맞춘 문서를 발견하고 번역할 것입니다. 편집자가 주제 목록을 기반으로 번역 제안을 선택할 수 있는 옵션을 도입함으로써 이 접근 방식이 프로젝트의 콘텐츠 적용 범위를 늘리는지 테스트할 것입니다. mw: Translation suggestions: Topic-based & Community-defined lists
WE2.2.1 유네스코 및 민족학과의 데이터 공유 계약을 확보하여 위키미디어의 언어 현황 데이터를 확장한다면 적어도 한 파트너는 자체 데이터 제품 및 커뮤니케이션에서 위키미디어의 언어 포함 진행 상황을 나타내기로 결정할 것입니다. 파트너 기관에 유용할 뿐만 아니라 확장된 데이터 세트는 의사 결정을 위한 중요한 상황 정보를 제공하고 개입 영역을 식별하는 데 필요한 정보를 커뮤니티에 제공합니다.
WE2.2.2 지난 2년 동안 위키미디어인들이 수행한 언어 문서화 활동을 매핑하면 새로운 언어 온보딩에 대한 커뮤니티 경험을 위한 데이터 기반 기준선을 개발할 것입니다.
WE2.2.3 인큐베이터 유무에 관계없이 5개의 새로운 언어에 대한 프로덕션 위키 액세스를 제공하면 영어 위키백과에서 사용할 수 있는 것과 같은 최신 기능(콘텐츠 번역 및 위키데이터 지원, 고급 편집 및 검색 결과 포함)을 갖춘 본격적인 위키에 액세스할 수 있는지 여부를 알게 됩니다. 빠른 편집을 도와줍니다. 궁극적으로 이는 이 접근 방식이 새로운 언어 또는 기존 언어에 대한 언어 온보딩에 실행 가능한 방향이 될 수 있는지 여부를 알려주고 추가 조사를 정당화합니다. mw:Future of Language Incubation
WE2.3.1 공용의 미디어 업로드 흐름을 두 가지 추가로 개선하고 이를 커뮤니티와 공유하면 피드백은 긍정적일 것이며 업로드 후 30일 이내에 삭제 요청 비율로 측정했을 때 업로더가 덜 나쁜 업로드(저작권을 중심으로)를 하는 데 도움이 될 것입니다. 여기에는 공용의 업로드 마법사의 릴리스 권한 단계에 대한 추가 UX 개선을 위한 디자인 정의와 업로드 흐름에서 로고 감지 MVP 출시가 포함됩니다.

phab:T347298 phab:T349641

WE2.4.1 미디어위키 콘텐츠에 포함된 위키함수 호출의 프로토타입을 구축하면 미디어위키의 비동기 콘텐츠 처리 파이프라인을 사용하고 2분기에 성능 타당성을 테스트할 준비가 됩니다. phab:T261472
WE2.4.2 위키백과 위키에서 초기 위키함수 사용 사례의 디자인 프로토타입을 생성하면 2분기에 성능 타당성이 검증되면 통합을 구축하고 테스트할 준비가 됩니다(가설 1 참조). phab:T363391
WE2.4.3 위키함수 사용자가 위키데이터 사전 편찬 데이터에 액세스할 수 있게 하면 불규칙 형식을 처리할 수 있는 기능을 포함하여 문장 구문을 생성하는 자연어 기능을 생성하기 시작할 것입니다. 이러한 기능에 대한 월 평균 생성률이 31인 경우 해당 기능을 사용할 수 있게 된 후 실험이 성공한 것입니다. phab:T282926
WE3.1.1 큐레이팅되고 개인화되었으며 커뮤니티 중심의 검색 및 학습 경험을 구축하는 데 초점을 맞춘 세 가지 개념 증명을 설계하고 정성적으로 평가하면 독자 유지율이 높아질 가능성을 추정할 수 있습니다(실험 1: 검색 및 문서 컨텍스트에서 추천 콘텐츠 제공, 실험 2: 문서 내용을 요약하고 단순화하기, 실험 3: 위키에서 멀티태스킹을 더 쉽게 만들기.
WE3.1.3 당사의 인프라(예: 리프트윙)를 통해 호스팅 및 제공될 수 있는 콘텐츠 단순화 또는 요약과 같은 콘텐츠 리믹스를 위한 모델을 개발한다면 새로운 콘텐츠 검색 기능을 통해 독자 유지율을 높이는 데 초점을 맞춘 작업의 기술적 방향을 수립할 것입니다.
WE3.1.4 검색 API에 대한 가설 WE3.1.1 및 WE3.1.2의 예상 성능 영향을 분석하면 성능 및 확장성 문제가 사용자에게 부정적인 영향을 미치기 전에 범위를 지정하고 해결할 수 있습니다.
WE3.1.5 사용자의 관심을 기반으로 개인화된 콘텐츠를 추천하고 더 나은 결과를 표시하기 위해 안드로이드 앱의 검색 필드를 강화한다면, 검색 결과의 노출수와 클릭률(CTR)이 증가하는지 관찰하여 사용자 참여가 향상되는지 알아볼 것입니다. 30일간의 A/B 테스트에서 실험군은 대조군에 비해 5% 증가했습니다. 이러한 개선으로 인해 로그아웃한 사용자의 유지율이 1% 증가할 수 있습니다.
WE3.2.1 관심 있는 문서를 옹호하는 기부자를 나타내는 배지 개념을 보여주는 클릭 가능한 디자인 프로토타입을 만들면 앱에서 모금을 위한 이 방법의 생산 버전에 대한 커뮤니티의 승인이 있는지 알 수 있습니다. Fundraising Experiment in the iOS App
WE3.2.2 웹 모바일 및 데스크톱 환경의 로그아웃 환경에서 기부에 대한 진입점의 중요성을 높이면 기부 링크의 클릭률이 전년 대비 30% 증가합니다. phab:T368765
WE3.2.3 iOS 앱의 "기부" 버튼을 기본 탐색 화면에서 한 번만 클릭하면 눈에 띄게 만들면 검색 가능성이 배너가 아닌 기부에 대한 장벽인지 알 수 있습니다.
WE3.3.1 데이터 시각화 라이브러리를 선택하고 7월 말까지 새로운 서버 렌더링 그래프 서비스의 초기 버전을 얻을 수 있다면, 우리는 위키마니아의 자원봉사자들로부터 레거시 그래프를 대체하는 데 사용할 솔루션을 개발하고 있는지 알아볼 수 있습니다.
WE4.1.1 사용자가 사건 보고 시스템을 통해 토론 중에 잠재적인 괴롭힘 및 유해 콘텐츠를 신고할 수 있는 방법을 구현한다면, 우리는 보고되는 사건의 수와 유형에 대한 데이터를 수집할 수 있으므로 상황과 우리가 취해야 할 조치를 더 잘 이해할 수 있습니다.
WE4.2.1 고유한 장치 식별 모델에 대한 위키미디어 고유의 ​​방법을 탐색하고 정의하면 나중에 악용 방지 작업 흐름에서 구현할 수 있는 수집 및 저장 메커니즘을 정의하여 악의적인 행위자를 더욱 표적화하여 차단할 수 있습니다. phab:T368388
WE4.2.9 차단될 IP와 관련된 평판에 대한 상황 정보를 제공하면 관리자가 차단의 잠재적인 부수적 피해 효과에 대해 더 많은 통찰력을 갖게 되므로 부수적 피해 IP 및 IP 범위 차단이 줄어들 것입니다. 특수:차단을 계측하고 추가 정보가 있을 때와 그렇지 않을 때 동작이 어떻게 변하는지 관찰하여 이를 측정할 수 있습니다. WE4.2.9 Talk page
WE4.2.2 악용 방지 워크플로에 사용할 사용자 계정 평판 점수를 계산하는 알고리즘을 정의하면 플랫폼에서 악의적인 행위자를 표적으로 삼는 관리자를 위한 추가 신호로 이 점수를 사용하는 엔지니어링 노력의 기반을 마련하게 됩니다. 점수 계산 알고리즘이 X% 정밀도로 기존 계정 분류에 매핑되면 가설이 성공했다는 것을 알 수 있습니다. 영구적으로 차단된 계정의 X%에는 "낮은" 점수가 적용되어야 합니다. WE4.2.2 Talk page
WE4.2.3 이전 공격에 사용된 것과 유사한 공개적으로 사용 가능한 기술을 사용하여 평가 프레임워크를 구축한다면 공격 차단 시 현재 CAPTCHA의 효율성에 대해 자세히 알아보고, 주어진 시간과 재정적 비용에 대해 달성 가능한 공격률 측면에서 측정 가능한 개선을 제공하는 CAPTCHA 대체품을 권장할 수 있습니다.
WE4.3.1 알려진 공격 중에 웹 요청 로그에 일부 기계 학습 및 데이터 분석 도구를 적용하면 우리는 80% 이상의 정밀도로 악의적인 트래픽을 보내는 악의적인 IP 주소를 식별할 수 있으며, 그런 다음 에지에서 속도 제한을 적용하여 사용자의 안정성을 향상시킬 수 있습니다. phab:T368389
WE4.3.2 지속적인 공격자의 알려진 IP 주소가 인프라에 배치할 수 있는 로드를 제한하면 영향을 미치는 캐시 버스팅 공격 수가 20% 감소하여 사용자의 안정성이 향상됩니다.
WE4.3.3 'Liberica' 로드 밸런서의 개념 증명을 배포하면 TCP SYN 플러드 처리 용량이 33% 향상되는 것으로 측정됩니다.
WE4.3.4 유용성을 개선하고 'requestctl' 도구에 대한 일부 교육 연습도 수행하면 SRE는 도구 사용에 대한 더 높은 신뢰도를 보고할 것입니다. phab:T369480
WE4.4.1 임시 계정 배포 주기를 2회 이상 실행하면 이것이 성공적으로 작동하는지 확인할 수 있습니다.
WE5.1.1 1분기까지 모든 위키여행에 파소이드 읽기 뷰를 성공적으로 출시하면 파소이드 읽기 뷰를 모든 위키백과에 확장하는 데 대한 확신이 높아질 것입니다. 신뢰 프레임워크 보고서를 사용하여 자세한 평가를 통해 이 출시의 성공을 측정할 것이며, 특히 시각적 Diff 보고서와 성능 및 사용성과 관련된 지표에 중점을 둘 것입니다. 또한 잠재적인 차단 요소 목록의 감소를 평가하여 광범위한 배포 전에 중요한 문제가 해결되도록 할 것입니다.
WE5.1.2 사용하지 않는 Graphite 측정지표를 비활성화하고 db 접두사가 붙은 데이터 팩토리를 사용하여 측정지표를 마이그레이션하고 1분기에 다른 팀과 커뮤니티에 대한 홍보 활동을 강화하면 3분기에 Graphite를 읽기 전용으로 전환한다는 목표를 달성할 수 있을 것이며, 마이그레이션 진행률이 30% 증가할 것입니다.
WE5.1.3 REST API에 대한 버전 관리 기능을 갖춘 표준 URL 구조를 구현하면 Q1까지 Parsoid 엔드포인트 및 유사 서비스에 대한 서비스 마이그레이션과 테스트를 활성화할 수 있습니다. phab:T344944
WE5.1.4 브라우저의 추적 방지 조치가 CentralAuth 자동 로그인에 미치는 영향을 완화하고 보다 탄력적인 인증 인프라(SUL3)로 전환하기 위한 나머지 작업을 완료하면, 2분기에 제품 위키에 출시할 준비가 됩니다.
WE5.1.5 소나 클라우드의 적용 범위를 늘려 주요 미디어위키 코어 repo를 포함하면 미디어위키 코드베이스의 유지 관리성을 개선할 수 있습니다. 이 가설은 선택된 repo를 테스트 그룹과 대조군으로 나누어 측정합니다. 그런 다음 이러한 그룹을 분기별로 비교하여 개발자에게 커밋 수준 피드백의 영향을 측정합니다.
WE5.2.1 미디어위키 코어의 동작에 영향을 미치는 후크와 확장 레지스트리 속성의 유형을 분류하면, 가장 큰 영향을 미치는 부분에 대한 추가 연구와 개입에 집중할 수 있습니다. [1]
WE5.2.2 MW 코어와 Echo에서 알림을 위한 새로운 아키텍처를 탐색한다면, 모듈성을 제공하는 새로운 방법과 확장 기능이 코어와 상호 작용하는 새로운 방법을 발견하게 될 것입니다. [2]
WE5.3.1 파서와 캐시 코드를 사용하여 템플릿 구조와 세부적인 타이밍 데이터를 수집하면 향후 위키텍스트 파싱 플랫폼이 발전하면서 실현 가능한 예상 성능 향상을 정량화할 수 있습니다. T371713
WE5.3.2 템플릿 편집의 경우, 편집된 템플릿에 따라 달라지는 페이지의 HTML을 재사용하고 페이지를 처음부터 처리하지 않고도 Parsoid 알고리즘을 구현하여 1.5배 이상의 처리 속도 향상을 입증할 수 있다면, 템플릿 편집 시 효율적인 페이지 업데이트를 위한 잠재적인 증분적 파싱 솔루션을 확보할 수 있을 것입니다. T363421
WE5.4.1 미디어위키 엔지니어링 그룹이 릴리스 프로세스 책임성을 성공적으로 수행하고 제품 전략에 맞춰 2분기 말까지 커뮤니케이션 프로세스를 개선하면 계획되지 않은 작업이나 자원 봉사에 의존하는 현재 프로세스를 제거하고 릴리스 프로세스에 대한 커뮤니티 만족도를 개선할 것입니다. 1.43 LTS 릴리스에 대한 커뮤니티 피드백과 릴리스 프로세스에 필요한 계획되지 않은 직원 및 자원 봉사 시간을 크게 줄임으로써 측정합니다.
WE5.4.2 미디어위키 릴리스 프로세스와 연계하여 PHP를 보다 정기적으로 업그레이드하는 프로세스를 연구하고 구축한다면 1.43 릴리스 전에 PHP 8.1 업그레이드가 성공했던 사례를 관찰하여 CI 시스템의 복잡성과 런타임을 줄이는 동시에 속도와 보안을 향상시킬 수 있습니다.
WE6.1.1 권한 부여 프레임워크의 초기 구현을 설계하고 완료하면 모든 LDAP 액세스 요청의 승인을 효과적으로 관리하는 시스템을 구축하게 됩니다.
WE6.1.2 사용 가능한 문서 지표를 조사하면 미디어위키 코어 문서를 테스트 사례로 사용하여 위키미디어 기술 문서의 상태를 측정하는 지표를 확립할 수 있습니다. mw:Wikimedia Technical Documentation Team/Doc metrics
WE6.1.3 다양한 팀이 기술적 결정을 내리는 방식에 대한 통찰력을 수집하면 조직 전체에서 유사한 관행을 활성화하고 확장할 수 있는 모범 사례와 통찰력을 얻을 수 있습니다.
WE6.2.1 우리가 미디어위키, 확장 기능, 스킨, 위키미디어 구성의 버전별 빌드를 하루에 한 번 이상 게시한다면 새로운 제약 조건을 발견하고 빌드를 수행하는 데 필요한 실제 시간의 기준을 확립할 수 있습니다. mw:Wikimedia Release Engineering Team/Group -1
WE6.2.2 기존 공유 미디어위키 개발 및 테스트 환경(Apache 가상 서버에서 쿠버네테스까지)의 백엔드 인프라를 대체하면 격리된 환경에서 미디어위키 코어, 확장 기능 및 스킨을 개발하는 기존 기능 외에도 미디어위키 서비스를 활성화하여 사용을 확장할 수 있습니다. 미디어위키, 하나 이상의 확장 기능 및 하나 이상의 서비스를 포함하는 하나의 환경을 개발합니다. wikitech:Catalyst
WE6.2.3 배포자에게 더 많은 정보를 제공하고 배포에 필요한 권한의 양을 줄이는 새로운 배포 UI를 만들면 배포가 더 쉬워지고 고유 배포자 수와 전체 배포에서 백포트된 패치 수의 백분율로 측정했을 때 더 많은 사용자에게 배포가 가능해집니다. Wikimedia Release Engineering Team/SpiderPig
WE6.2.4 쿠버네테스에서 투표위키, 위키기술및 공용을 미디어위키로 마이그레이션하면 일관성의 이점을 얻을 수 있으며 더 이상 두 개의 다른 인프라 플랫폼을 병렬로 유지할 필요가 없으므로 사용자 정의 작성 도구의 양을 줄이고 배포를 더 쉽고 배포자에게 덜 힘들게 만들 수 있습니다. 이는 총 배포 시간이 감소하고 배포 차단기가 감소하는 것으로 측정됩니다. 작업 T292707
WE6.2.5 미디어위키에서 멀티버전 라우팅을 옮기면 단일 버전의 미디어위키 컨테이너를 제공할 수 있으며, 배포 도구로 측정했을 때 컨테이너 크기를 크게 줄여 배포 속도를 높일 수 있습니다. SingleVersion MW: Routing options
WE6.3.1 플랫폼의 지속 가능하지 않은 측면에 대해 툴포지 관리자와 상의하면 측정할 수 있는 잠재적인 범주 목록을 수집할 수 있습니다.
WE6.3.2 배포에 필요한 단계 수를 측정하는 "표준" 도구를 만들면 배포 프로세스에서 최대 개선 효과를 평가할 수 있습니다.
WE6.3.3 사용성 테스트, 사용자 인터뷰, 경쟁 분석을 수행하여 툴포지의 기존 워크플로와 사용 사례를 탐색하면 개선을 위한 핵심 영역을 파악할 수 있습니다. 이 연구를 통해 사용자 만족도와 효율성에 가장 큰 영향을 미치는 개선 사항을 우선 순위로 지정하여 향후 사용자 인터페이스 디자인을 위한 토대를 마련할 수 있습니다.
신호 및 데이터 서비스(SDS) 가설

[ SDS 주요 결과 ]

토론

가설 단축명 1분기 텍스트 세부사항 및 토론
SDS 1.1.1 이니셔티브 소유자와 협력하여 그들의 작업이 핵심 재단 지표에 미치는 영향을 평가하면 재단의 팀이 핵심 재단 지표에 안정적으로 영향을 미칠 수 있는 반복 가능한 메커니즘을 식별하고 사회화할 수 있습니다.
SDS1.2.2 공식적인 조정 및 관리 역할을 맡은 장기 커뮤니티 구성원의 모집, 유지 및 감소 패턴을 연구하고 이러한 현상에 영향을 미치는 요인(추세 뒤에 숨은 '이유')을 이해한다면 범위, 성격, 그리고 프로젝트 전반에 걸친 현상의 가변성. 이를 통해 편집자를 위한 강력한 다세대 프레임워크 생성을 목표로 하는 더 나은 개입 및 지원 기회를 식별할 수 있습니다. phab:T368791
SDS1.2.1 독자와 기여자를 위한 위키미디어 서비스의 AI 사용에 관해 제품 및 기능 엔지니어링 관리자로부터 사용 사례를 수집하면, 제품 기능에 통합하기 위해 기존 AI 모델을 테스트하고 평가해야 하는지 판단할 수 있으며, 그렇다면 테스트할 후보 모델 목록을 생성할 수 있습니다. phab:T369281

Meta Page

SDS1.3.1 모든 데이터 세트와 파이프라인 구성을 데이터 플랫폼에서 데이터허브로 전송하는 프로세스를 정의하면 계보 문서를 자동으로 가져오는 도구를 구축할 수 있습니다.
SDS 1.3.2 이벤트 플랫폼을 사용하여 채워지고 미디어위키 위키텍스트 기록을 나타내는 중간 테이블을 생성하기 위해 잘 문서화되고 이해되는 프로세스를 구현하고 데이터의 신뢰성과 품질을 모니터링한다면 이 테이블을 생성하는 데 프로세스의 어떤 추가 부분이 필요한지 알게 될 것입니다. 데이터 플랫폼 엔지니어링 팀이 준비하고 폭넓게 지원합니다.
SDS2.1.2 현재 sdlc의 데이터 제품을 조사하면 제품 전달에 긍정적인 영향을 미치기 위해 QTE 지식을 적용할 수 있는 변곡점을 결정할 수 있을 것입니다.
SDS2.1.3 성장 팀이 측정지표 플랫폼에서 홈페이지 모듈을 계측하여 측정지표 플랫폼에 대해 알게 되면 1분기에 측정 계획의 개요를 설명하고 2분기 말까지 새로운 측정지표 플랫폼에서 A/B 테스트를 완료할 준비가 됩니다.
SDS2.1.4 실험 프로세스의 파일럿 사용자를 대상으로 프로토타입에 대한 사용성 테스트를 수행하면 제품 관리자와 기타 이해관계자가 실험을 독립적으로 설정하고 분석하는 데 직면하는 주요 문제점을 식별하고 우선순위를 지정할 수 있습니다. 이러한 이해는 도구를 개선하고 효율성과 영향력을 향상시키는 결과를 가져올 것입니다.
SDS2.1.5 측정지표 플랫폼을 사용하여 인스트루먼테이션을 구축하는 사용자의 경험을 안내하는 문서 시스템을 설계하면 이러한 사용자는 극단적인 경우를 제외하고 데이터 제품 팀의 직접적인 지원 없이 독립적으로 인스트루먼테이션을 생성할 수 있습니다. phab:T329506
SDS2.2.1 실험 분석(A/B 테스트)에 적용할 수 있는 로그아웃 모바일 앱 독자 유지율에 대한 지표를 정의하면 모바일 앱에서 로그아웃한 독자의 유지율을 측정하기 위한 계측 계획에 대한 지침을 제공하고 엔지니어링을 활성화할 수 있습니다. 팀은 로그아웃한 독자를 대상으로 실험 전략을 개발합니다.
SDS2.2.2 전환율을 측정하고 분석하기 위한 표준 접근 방식을 정의하면 실험 및 기준에 사용할 잘 정의된 측정항목 모음을 설정하고 실험/프로젝트 간의 비교를 활성화하여 이를 통해 학습을 늘리는 데 도움이 됩니다.
SDS2.2.3 당사 제품/기능의 클릭률(CTR)을 측정하고 분석하는 표준 방법을 정의하면, 이는 개선을 위해 CTR을 목표로 하는 실험을 설계하고, 클릭 추적 도구를 표준화하고, 실험 플랫폼 사용자가 CTR을 목표 측정항목으로 사용할 수 있도록 하는 데 도움이 될 것입니다.
SDS2.3.1 로그아웃한 사용자에 대해 제안된 고유 쿠키에 대한 법적 검토를 수행하면 커뮤니티 상담에 알리거나 기술 구현 자체에 영향을 미치는 개인 정보 보호 정책이나 기타 법적 문제가 있는지 확인할 수 있습니다.
잠재적 청중 (FA) 가설

[ FA 주요 결과 ]

토론

가설 단축명 1분기 텍스트 세부사항 및 토론
FA1.1.1 AI 기반의 "Add a Fact" 실험을 통해 오프사이트 기여를 매우 적은 노력으로 수행한다면, 위키백과 콘텐츠가 주로 플랫폼 외부에서 소비되는 미래에 플랫폼 외부 사용자가 지식 저장소를 성장/유지하는 데 도움을 줄 수 있는지 여부를 알 수 있습니다. m:Future Audiences/Experiment:Add a Fact
Product and Engineering Support (PES) Hypotheses

[ PES 주요 결과 ]

토론

가설 단축명 1분기 텍스트 세부사항 및 토론
PES1.1.1 P&T 리더십 팀이 보다 반복적인 소프트웨어 개발 문화로 팀을 이끄는 방법에 대해 정기적으로 동기화하고 현재 개발 관행에 대한 기준 측정치와 제품 출시를 위해 협력하는 방법에 대한 직원 감정을 수집한다면, 우리는 변화 관리를 위한 기회 영역을 발견할 것입니다. 나타나는 주제를 통해 우리는 다음 분기에 우리 팀을 위한 목표 지침이나 프로그램을 구축할 수 있을 것입니다.
PES1.2.2 중재자 도구 팀이 커뮤니티 위시리스트를 조사하고 1분기에 2개 이상의 중점 영역을 개발하면 커뮤니티로부터 피드백을 요청하고 커뮤니티와 WMF가 해결하고자 하는 문제를 식별할 수 있습니다.
PES1.2.3 템플릿 선택 및 삽입과 관련된 3~5가지 희망사항을 묶어서 1분기에 개선된 기능을 출시한다면, 커뮤니티기술은 학습을 통해 재단이 2025-26년 연간 계획에 더 많은 "중점 영역"을 통합할 수 있는 사례 연구를 개발할 수 있습니다.
PES1.3.1 우리가 1년 동안 청중의 커뮤니티와 위키백과 사용에 대한 통찰력을 제공한다면 위키백과와의 더 큰 연결을 자극하여 사회적 공유, 위키백과에서 상호 작용하는 데 소요되는 시간 또는 기부의 형태로 더 많은 참여를 장려할 것입니다. 성공 여부는 위키 참여를 높일 수 있는 기회로서 "위키백과 통찰력"에 대한 권장 사항을 하나 이상 제공하는 실험 프로젝트를 완료하여 측정됩니다. mw: New Engagement Experiments#PES1.3.1_Wikipedia_user_insights
PES1.3.2 광범위한 지식 영역의 연결을 강조하는 일상적인 사용을 위한 위키백과 기반 게임을 만든다면, 이는 소비자가 위키백과를 정기적으로 방문하도록 장려하고 적극적인 학습을 촉진하여 위키백과 콘텐츠와의 상호 작용을 더 오랫동안 증가시킬 것입니다. 성공 여부는 위키 참여를 높일 수 있는 기회로서 학습의 게임화에 대한 권장 사항을 하나 이상 제공하는 실험 프로젝트를 완료하여 측정됩니다. mw: New Engagement Experiments#PES_1.3.2:_Wikipedia_games
PES1.3.3 향후 실험을 배양하기 위해 위키미디어 해킹 이벤트에서 새로운 프로세스/트랙을 개발하면 향후 연간 계획 프로젝트를 위한 파이프라인이 되는 이러한 이벤트의 영향과 가치가 증가하는 동시에 자원 봉사자와 엔지니어링/설계 직원 간의 더 큰 연결을 촉진하여 전략적 계획에 더 많이 참여하게 됩니다. 성공 여부는 재단 지원 이벤트에서 시작되거나 OKR로 발전하는 최소 하나의 PES1.3 프로젝트로 측정됩니다. mw: New Engagement Experiments#PES_1.3.3:_Incubator_space
PES1.4.1 편집팀에서 편집 확인 기능을 출시하면서 SLO 초안을 작성하면 사용자 대상 SLO를 함께 정의하고 추적하는 방법을 배우고 이해하며 향후 프로세스를 반복하게 됩니다.
PES1.4.2 OOUI를 "유지 관리 모드"로 전환하기 위한 SLA를 정의하고 게시하면 위키미디어 프로젝트 전체에서 OOUI를 사용하는 새 코드의 성장은 1분기에도 X% 이내로 유지될 것입니다.
PES1.4.3 1분기에 알려진 소유 서비스에 대해 제안된 서비스 카탈로그를 사용하여 소유권을 매핑하면 연말까지 SLO 문화를 해결하는 데 도움이 되므로 서비스 카탈로그에서 상당한 격차를 식별할 수 있습니다.

2분기

WMF 연간 계획의 (2분기)는 10월부터 12월까지를 포함합니다.

위키 경험 (WE) 가설

[ WE 주요 결과 ]

토론

가설 단축명 2분기 텍스트 세부사항 및 토론
WE1.1.1 이벤트 목록을 위키프로젝트를 포함하는 커뮤니티 목록으로 확장하면 제품 개발을 위해 위키프로젝트에 참여하는 방법에 대한 초기 학습을 얻을 수 있습니다. Campaigns/Foundation Product Team/Event list
WE1.1.2 위키 내 협업에 초점을 맞춘 컨설팅을 최소 1회 시작하고, 이러한 협업에 참여한 사람 20명 이상으로부터 피드백을 수집하면, 새롭거나 개선된 연결 방식을 개발하는 데 필요한 주요 특징에 관해 캠페인 제품에 조언할 수 있을 것입니다. Campaigns/WikiProjects
WE1.1.3 리프트윙을 통해 제공되는 주제를 최대한 활용하는 방법에 대해 20명의 이벤트 주최자와 20명의 위키프로젝트 주최자에게 문의하면 이벤트와 위키프로젝트 간의 주제 연결을 개선할 주제 모델 개정의 우선순위를 지정할 수 있습니다.
WE1.1.4 2분기에 캠페인행사를 커뮤니티 구성에 통합하면 3분기에 최소 5개 이상의 위키가 확장 기능을 활성화할 수 있는 토대를 마련할 수 있고, 이를 통해 도구 사용량이 늘어날 것입니다.
WE1.2.2 UI 구성 요소와 시각적 아티팩트 라이브러리를 구축하면 편집 확인의 사용자 경험을 확장하여 구조화된 작업 패턴을 수용할 수 있습니다.
WE1.2.5 iOS 앱의 프로덕션 버전에서 대체 텍스트 제안 편집 프로토타입을 사용하여 A/B/C 테스트를 수행하면 이미지에 대체 텍스트를 추가하는 작업이 초보자도 성공적으로 수행할 수 있는지 알아낼 수 있으며, 궁극적으로 웹 및/또는 앱에서 제안 편집으로 구현하기에 충분히 효과적인지 여부를 결정할 수 있습니다.
WE1.2.6 새로운 계정 소유자에게 위키백과 문서의 "링크 추가" 구조화된 작업을 소개하면 기준선에 비해 모바일에서 건설적으로 활성화하는 새로운 계정 소유자의 비율이 10% 증가할 것으로 예상됩니다.
WE1.3.1 자동중재자의 동작을 추가로 사용자 정의하고 1분기에 파일럿 프로젝트 피드백을 기반으로 변경하면 더 많은 중재자가 기능 세트와 안정성에 만족하고 위키미디어 프로젝트에서 이를 사용하도록 선택하여 제품 채택이 늘어날 것입니다. mw:Moderator_Tools/Automoderator
WE1.3.3 2분기에 Nuke 확장 프로그램의 사용자 경험과 기능을 개선한다면, 분기 말까지 제품에 대한 관리자 만족도가 5pp 증가할 것입니다. mw:Extension:Nuke/2024_Moderator_Tools_project
WE2.1.3 목록 작성을 서비스로 제공하면 최소 5개 커뮤니티가 (1) 관련 위키에서 관련 주제에 대한 표준 품질 범위 변경 및 (2) 위키에서 주제 영역 범위에 대한 조직자 만족도에 대한 간략한 설문 조사를 통해 측정한 대로 주제 영역에서 더욱 집중적인 기여를 할 수 있습니다.
WE2.1.4 위키프로젝트 및 기타 목록 구축 이니셔티브에서 얻은 번역 작업을 추가하는 개념 증명을 개발하고 CX 모바일 워크플로 내에서 제안으로 제시한다면 더 많은 편집자가 주제 간 격차에 초점을 맞춘 문서를 발견하고 번역할 수 있을 것입니다.

편집자가 주제별 목록을 기반으로 번역 제안을 선택할 수 있는 옵션을 도입하여, 이 접근 방식이 프로젝트의 콘텐츠 범위가 늘어나는지 테스트해보겠습니다.

WE2.1.5 If we expose topic-based translation suggestions more broadly and analyze its initial impact, we will learn which aspects of the translation funnel to act on in order to obtain more quality translations.
WE2.2.4 인큐베이터 유무에 관계없이 5개의 새로운 언어에 대한 프로덕션 위키 액세스를 제공하면 영어 위키백과에서 사용할 수 있는 것과 같은 최신 기능(콘텐츠 번역 및 위키데이터 지원, 고급 편집 및 검색 결과 포함)을 갖춘 본격적인 위키에 액세스할 수 있는지 여부를 알게 됩니다. 빠른 편집을 도와줍니다. 궁극적으로 이는 이 접근 방식이 새로운 언어 또는 기존 언어에 대한 언어 온보딩에 실행 가능한 방향이 될 수 있는지 여부를 알려주고 추가 조사를 정당화합니다.
WE2.2.5 addwiki.php를 코어로 옮기고 위키미디어에 맞게 커스터마이징하면 위키 제작 시스템의 코드 품질이 향상되어 테스트가 가능하고 견고해질 수 있으며, 새로운 위키 제작자가 사용하기 쉬워지고, 따라서 위키 제작 프로세스가 간소화되는 데 큰 진전이 있을 것입니다. phab:T352113
WE2.3.2 공용에서 미디어 업로드 흐름을 두 가지 더 개선하고 이를 커뮤니티와 공유하면 피드백이 긍정적일 것이고 업로더가 업로드 후 30일 이내에 삭제 요청 비율을 측정하여 나쁜 업로드(저작권에 초점을 맞춤)를 줄이는 데 도움이 될 것입니다. 여기에는 공용의 업로드 마법사에서 릴리스 권한 단계에 대한 추가 UX 개선 사항과 외부 소스의 자동 감지가 포함됩니다.
WE2.3.3 BHL-위키미디어 작업 그룹이 출판물에 묘사된 남아메리카 및/또는 아프리카 종에 대한 공용 분류와 설명적 가이드라인을 만들면 3,000개의 이미지가 생물다양성 커뮤니티에 더 쉽게 접근 가능해질 것입니다.

(BHL = 생물다양성 헤리티지 라이브러리)

WE2.4.1 미디어위키 콘텐츠에 내장된 위키함수 호출의 프로토타입을 빌드하고 안정성을 위해 로컬에서 테스트하면 미디어위키의 비동기 콘텐츠 처리 파이프라인을 사용하고 2분기에 성능 타당성을 테스트할 준비가 됩니다. phab:T261472
WE2.4.2 위키백과 위키에서 초기 위키함수 사용 사례에 대한 디자인 프로토타입을 만들면 가설 1에서 언급한 대로 Q2에서 성능 가능성이 검증되면 통합을 빌드하고 테스트할 준비가 됩니다. phab:T363391
WE2.4.3 위키함수 사용자가 위키데이터 사전 데이터에 액세스할 수 있게 하면, 불규칙한 형태를 처리할 수 있는 문장 구문을 포함하여 문장 구문을 생성하는 자연어 함수를 만들기 시작할 것입니다. 이러한 함수에 대한 월 평균 생성률이 31인 경우, 해당 기능이 사용 가능해진 후, 실험이 성공적이라는 것을 알게 될 것입니다. phab:T282926
WE3.1.3 콘텐츠 단순화나 요약 등의 콘텐츠 리믹스를 위한 모델을 개발해 인프라(예: 리프트윙)를 통해 호스팅하고 제공하면 새로운 콘텐츠 검색 기능을 통해 독자 유지율을 높이는 데 중점을 둔 작업의 기술적 방향을 확립할 수 있습니다. Research
WE3.1.5 안드로이드 앱의 검색 필드를 개선하여 사용자의 관심사에 따라 개인화된 콘텐츠를 추천하고 더 나은 결과를 표시하면, 30일 A/B 테스트에서 실험 그룹과 대조군을 비교했을 때 검색 결과의 노출 및 클릭률(CTR)이 5% 증가하는지 관찰하여 사용자 참여가 향상되는지 알아볼 수 있습니다. 이러한 개선은 잠재적으로 로그아웃한 사용자의 유지율을 1% 증가시킬 수 있습니다. Recommended Content in Search
WE3.1.6 안드로이드 앱에 개인화된 래빗홀 기능을 도입하고 사용자가 관심 있는 주제 및 섹션 유형에 따라 요약된 버전의 기사를 추천하면, 30일 기간 동안 실험에 노출된 사용자 중 10%가 며칠 동안 해당 기능을 사용할 만큼 기능이 끈끈한지, 그리고 해당 기능에 노출되지 않은 사용자보다 페이지뷰율이 더 높은지 알아낼 수 있습니다.
WE3.1.7 웹 독자에게 문서 요약을 제시하는 데 초점을 맞춘 정성적 실험을 실행하면 클릭률과 사용 패턴을 대리하여 문서 요약이 독자 유지율을 높일 수 있는 잠재력이 있는지 여부를 확인할 수 있습니다.
WE3.1.8 문서 수준의 추천을 추가로 제공하는 기능을 하나 만든다면 기존 추천 옵션보다 클릭률이 10% 증가하고, 새로운 기능과 적극적으로 상호 작용하는 사용자의 외부 추천이 크게 늘어날 것입니다.
WE3.2.2 데스크톱 웹 경험의 로그아웃 환경에서 기부에 대한 진입점의 중요성을 높이면 기부 링크의 클릭률이 전년 대비 30% 증가합니다. mw:Readers/2024_Reader_and_Donor_Experiences
WE3.2.3 iOS 앱의 "기부" 버튼을 기본 탐색 화면에서 한 번만 클릭하면 눈에 띄게 만들면 검색 가능성이 배너가 아닌 기부에 대한 장벽인지 알 수 있습니다. mw:Readers/2024_Reader_and_Donor_Experiences
WE3.2.4 앱에 로그인한 사용자의 기여 페이지를 업데이트하여 앱 기여자에게는 활성 배지를, 앱에서 기부하지 않기로 결정한 사람에게는 기부하라는 메시지와 함께 비활성 상태를 표시하면, 이러한 인식이 현재 기여자에게 가치가 있는지, 잠재 기여자의 기여 행동을 장려하는지 여부를 파악할 수 있으며, 이를 통해 기여자 배지 개념을 확장하거나 폐기할 가치가 있는지 여부를 알 수 있습니다.
WE3.2.5 위키백과 앱에서 위키백과 검토 실험을 만들어 사용자들이 독서, 편집, 기부 습관에 대한 개인화된 데이터를 보고 공유할 수 있게 하면, 이 기능을 사용한 결과 iOS에서 시청자의 2%가 기부하고, 5%가 공유를 클릭하고, 65%의 사용자가 이 기능을 중립적이거나 만족스럽다고 평가하는 결과를 얻을 수 있을 것입니다. Personalized Wikipedia Year in Review
WE3.2.6 가치 있는 기부 넛지를 구축하고 사용자가 기존 기능(저장된 독서 목록)을 반복적으로 사용한 후나 앱 전체 탐색 개선 사항을 출시한 후에 테스트하면 시청자의 최소 1%가 기부하면 이것이 모금의 효과적인 방법인지 알 수 있을 것입니다.
WE3.2.7 모바일 사이트에서 로그아웃한 상태에서 기부에 대한 진입점의 눈에 띄는 부분을 높이면 기부 링크의 클릭률이 전년 대비 30% 증가합니다.
WE3.3.2 차트 MVP를 개발하여 프로덕션 테스트 위키에서 처음부터 끝까지 작동하게 하면, 12월에 코드가 동결되기 전에 최소 두 개의 위키백과와 공용이 시범 운영에 동의할 것입니다.
WE3.4.1 기술적 역량, 보안 및 개인 정보 보호를 유지하면서 구현에 한 달이 걸리는 소규모 캐시 사이트 배포를 통해 웹사이트 성능을 개선하는 역량 모델을 개발합니다.
WE4.1.1 토론 중에 발생하는 괴롭힘이나 유해한 콘텐츠의 잠재적 사례를 사고 보고 시스템을 통해 사용자가 보고할 수 있는 방법을 구현한다면, 보고된 사고의 수와 유형에 대한 데이터를 수집할 수 있고, 이를 통해 상황을 더 잘 이해하고 취해야 할 조치를 더 잘 파악할 수 있습니다.
WE4.2.1 고유한 장치 식별 모델에 대한 위키미디어 특유의 방법을 탐색하고 정의하면, 나중에 악용 방지 워크플로에 구현하여 나쁜 행위자를 더욱 집중적으로 차단할 수 있는 수집 및 저장 메커니즘을 정의할 수 있습니다.
WE4.2.9 차단될 IP와 관련된 평판에 대한 상황 정보를 제공하면 관리자가 차단의 잠재적인 부수적 피해 효과에 대해 더 많은 통찰력을 갖게 되므로 부수적 피해 IP 및 IP 범위 차단이 줄어들 것입니다. 특수:차단을 계측하고 추가 정보가 있을 때와 그렇지 않을 때 동작이 어떻게 변하는지 관찰하여 이를 측정할 수 있습니다.
WE4.2.2 우리가 남용 방지 워크플로에서 사용할 사용자 계정 평판 점수를 계산하는 알고리즘을 정의한다면, 우리는 이 점수를 우리 플랫폼에서 악의적인 행위자를 타겟팅하는 관리자를 위한 추가 신호로 사용하는 엔지니어링 노력의 토대를 마련할 것입니다. 우리는 알고리즘이 기존 계정의 범주에 X%의 정밀도로 매핑되는 경우 가설이 성공적임을 알게 될 것입니다. 예를 들어, "낮은" 점수는 영구적으로 차단된 계정의 X%에 적용되어야 합니다.
WE4.2.3 이전 공격에 사용된 것과 유사한 공개적으로 이용 가능한 기술을 사용하여 평가 프레임워크를 구축하면 공격 차단에 있어 현재 CAPTCHA의 효율성에 대해 더 많이 알 수 있으며, 주어진 시간과 재정적 비용으로 공격률 측면에서 측정 가능한 개선을 가져오는 CAPTCHA 대체 방안을 추천할 수 있습니다.
WE4.3.1 알려진 공격 중에 웹 요청 로그에 일부 기계 학습 및 데이터 분석 도구를 적용하면 우리는 80% 이상의 정밀도로 악의적인 트래픽을 보내는 악의적인 IP 주소를 식별할 수 있으며, 그런 다음 에지에서 속도 제한을 적용하여 사용자의 안정성을 향상시킬 수 있습니다.
WE4.3.2 지속적인 공격자의 알려진 IP 주소가 인프라에 배치할 수 있는 로드를 제한하면 영향을 미치는 캐시 버스팅 공격 수가 20% 감소하여 사용자의 안정성이 향상됩니다.
WE4.3.3 'Liberica' 로드 밸런서의 개념 증명을 배포하면 TCP SYN 플러드 처리 용량이 33% 향상되는 것으로 측정됩니다.
WE5.1.1 If we successfully roll out Parsoid Read Views to all Wikivoyages by Q1, this will boost our confidence in extending Parsoid Read Views to all Wikipedias. We will measure the success of this rollout through detailed evaluations using the Confidence Framework reports, with a particular focus on Visual Diff reports and the metrics related to performance and usability. Additionally, we will assess the reduction in the list of potential blockers, ensuring that critical issues are addressed prior to wider deployment.
WE5.1.3 If we reroute the endpoints currently exposed under rest_v1/page/html and rest_v1/page/title paths to comparable MW content endpoints, then we can unblock RESTbase sunsetting without disrupting clients in Q1.
WE5.1.4 If we complete the remaining work to mitigate the impact of browsers' anti-tracking measures on CentralAuth autologin and move to a more resilient authentication infrastructure (SUL3), we will be ready to roll out to production wikis in Q2.
WE5.1.5 If we increase the number of relevant SonarCloud rules enabled for key MediaWiki Core repositories and refine the quality of feedback provided to developers, we will optimize the developer experience and enable them to improve the maintainability of the MediaWiki codebase in the future. This will be measured by tracking developer satisfaction levels and whether test group developers feel the tool is becoming more useful and effective in their workflow. Feedback will be gathered through surveys and direct input from developers to evaluate the perceived impact on their confidence in the tool and the overall development experience.
WE5.1.7 If we represent all content module endpoint responses (10 in total) in our MediaWiki REST API OpenAPI spec definitions, we will be able to implement programmatic validation to guarantee that our generated documentation matches the actual responses returned in code.
WE5.1.8 If we introduce support for endpoint description translation (ie: does not include actual object definitions or payloads) into our generated MediaWiki REST API OpenAPI specs, we can lay the foundation to support Wikimedia’s expected internationalization standards.
WE5.2.3 If we conduct an experiment to reimplement at least [1-3] existing Core and Extension features using a new Domain Event and Listener platform component pattern as an alternative to traditional hooks, we will be able to confirm our assumption of this intervention enabling simpler implementation with more consistent feature behavior.
WE5.3.3 If we instrument both parsers to collect availability of prior parses and timing of template expansions, and to classify updates and dependencies, we can prioritize work on selective updates (Hypothesis 5.3.2) informed by the quantification of the expected performance benefits.
WE5.3.4 If we can increase the capability of our prototype selective update implementation in Parsoid using the learnings from the 5.3.1 hypothesis, we can leverage more opportunities to increase the performance benefit from selective update.
WE5.4.1 If the MediaWiki engineering group is successful with release process accountability and enhances its communication process by the end of Q2 in alignment with the product strategy, we will eliminate the current process that relies on unplanned or volunteer work and improve community satisfaction with the release process. Measured by community feedback on the 1.43 LTS release coupled with a significant reduction in unplanned staff and volunteer hours needed for release processes.
WE5.4.2 If we research and build a process to more regularly upgrade PHP in conjunction with our MediaWiki release process we will increase speed and security while reducing the complexity and runtime of our CI systems, by observing the success of PHP 8.1 upgrade before 1.43 release.
WE6.1.1 If we design and complete the initial implementation of an authorization framework, we’ll establish a system to effectively manage the approval of all LDAP access requests.
WE6.1.3 If we collect insights on how different teams are making technical decisions we are able to gather good practices and insights that can enable and scale similar practices across the organization.
WE6.1.4 If we research solutions for indexing the code of all projects hosted in WMF’s code repositories, we will be able to pick a solution that allows our users to quickly discover where the code is located whenever dealing with incident response or troubleshooting.
WE6.1.5 If we test a subset of draft metrics on an experimental group of technical documentation collections, we will be able to make an informed decision about which metrics to implement for MediaWiki documentation.
WE6.2.1 If we publish a versioned build of MediaWiki, extensions, skins, and Wikimedia configuration at least once per day we will uncover new constraints and establish a baseline of wallclock time needed to perform a build.
WE6.2.2 If we replace the backend infrastructure of our existing shared MediaWiki development and testing environments (from apache virtual servers to kubernetes), it will enable us to extend its uses by enabling MediaWiki services in addition to the existing ability to develop MediaWiki core, extensions, and skins in an isolated environment. We will develop one environment that includes MediaWiki, one or more Extensions, and one or more Services.
WE6.2.3 If we create a new deployment UI that provides more information to the deployer and reduce the amount of privilege needed to do deployment, it will make deployment easier and open deployments to more users as measured by the number of unique deployers and number of patches backported as a percentage of our overall deployments.
WE6.2.4 If we migrate votewiki, wikitech and commons to MediaWiki on Kubernetes we reap the benefits of consistency and no longer need to maintain 2 different infrastructure platforms in parallel, allowing to reduce the amount of custom written tooling, making deployments easier and less toilous for deployers. This will be measured by a decrease in total deployment times and a reduction in deployment blockers.
WE6.2.5 If we move MultiVersion routing out of MediaWiki, we 'll be able to ship single version MediaWiki containers, largely cutting down the size of containers allowing for faster deployments, as measured by the deployment tool.
WE6.3.4 By building an "orchestrator" toolforge component (components-api) we will be able to automate most manually-triggered deployments and reduce the steps to 1 for those. phab:T375199
WE6.3.5 By assessing the relative importance of each sustainability category and its associated metrics, we can create a normalized scoring system. This system, when implemented and recorded, will provide a baseline for measuring and comparing Toolforge’s sustainability progress over time.
WE6.3.6 If we conduct discovery, such as target user interviews and competitive analysis, to identify existing Toolforge pain points and improvement opportunities, we will be able to recommend a prioritized list of features for the future Toolforge UI.
Signals & Data Services (SDS) Hypotheses

[ SDS Key Results ]

토론

가설 단축명 1분기 텍스트 세부사항 및 토론
SDS 1.1.1 If we partner with an initiative owner and evaluate the impact of their work on Core Foundation metrics, we can identify and socialize a repeatable mechanism by which teams at the Foundation can reliably impact Core Foundation metrics.
SDS1.2.1.B TBA
SDS1.2.2 If we study the recruitment, retention, and attrition patterns among long-tenure community members in official moderation and administration roles, and understand the factors affecting these phenomena (the ‘why’ behind the trends), we will better understand the extent, nature, and variability of the phenomenon across projects. This will in turn enable us to identify opportunities for better interventions and support aimed at producing a robust multi-generational framework for editors. Research:Wikipedia Administrator Recruitment, Retention, and Attrition
SDS1.3.1 If we define the process to transfer all data sets and pipeline configurations from the Data Platform to DataHub we can build tooling to get lineage documentation automatically.
SDS1.3.2 If we implement a well documented and understood process to produce an intermediary table representing MediaWiki Wikitext History, populated using the event platform, and monitor the reliability and quality of the data we will learn what additional parts of the process are needed to make this table production ready and widely supported by the Data Platform Engineering team.
SDS2.1.1 If we create an integration test environment for the proposed 3rd party experimentation solution, we can collaborate practically with Data SRE, SRE, QTE, and Product Analytics to evaluate the solution’s viability within WMF infrastructure in order to make a confident build/install/buy recommendation. mw:Data_Platform_Engineering/Data_Products/work_focus
SDS2.1.3 If the Growth team learns about the Metrics Platform by instrumenting a Homepage Module on the Metrics Platform, then we will be prepared to outline a measurement plan in Q1 and complete an A/B test on the new Metrics platform by the end of Q2.
SDS2.1.4 If we conduct usability testing on our prototype among pilot users of our experimentation process, we can identify and prioritize the primary pain points faced by product managers and other stakeholders in setting up and analyzing experiments independently. This understanding will lead to the refinement of our tools, enhancing their efficiency and impact.
SDS2.1.5 If we design a documentation system that guides the experience of users building instrumentation using the Metrics Platform, we will enable those users to independently create instrumentation without direct support from Data Products teams, except in edge cases. 작업 T329506
SDS2.1.7 If we provide a function for user enrollment and a mechanism to capture and store CTR events to a monotable in a pre-declared event stream we can ship MPIC Alpha in order to launch an basic split A/B test on logged in users.
SDS2.2.2 If we define a standard approach for measuring and analyzing conversion rates, it will help us establish a collection of well-defined metrics to be used for experimentation and baselines, and start enabling comparisons between experiments/projects to increase learning from these.
SDS2.3.1 If we conduct a legal review of proposed unique cookies for logged out users, we can determine whether there are any privacy policy or other legal issues which inform the community consultation and/or affect the technical implementation itself.
Future Audiences (FA) Hypotheses

[ FA Key Results ]

토론

가설 단축명 1분기 텍스트 세부사항 및 토론
FA1.1.1 If we make off-site contribution very low effort with an AI-powered “Add a Fact” experiment, we can learn whether off-platform users could help grow/sustain the knowledge store in a possible future where Wikipedia content is mainly consumed off-platform. Experiment:Add a Fact
Product and Engineering Support (PES) Hypotheses

[ PES Key Results ]

토론

가설 단축명 1분기 텍스트 세부사항 및 토론
PES1.2.4 If we research the Task Prioritization focus area in the Community Wishlist in early Q2, we will be able to identify and prioritize work that will improve moderator satisfaction, which we can begin implementing in Q3.
PES1.2.5 If we are able to publish and receive community feedback on 6+ focus areas in Q2, then we will have confidence in presenting at least 3+ focus areas for incorporation in the 2025-26 annual plan.
PES1.2.6 By introducing favouriting templates, we will improve the number of templates added via the template dialog by 10%.
PES1.3.4 If we create an experience that provides insights to Wikipedia Audiences about their community over the year, it will stimulate greater connection with Wikipedia – encouraging engagement in the form of social sharing, time spent interacting on Wikipedia, or donation.
PES1.4.1 If we draft an SLO with the Editing team releasing Edit Check functionality, we will begin to learn and understand how to define and track user-facing SLOs together, and iterate on the process in the future.
PES1.4.2 If we define and publish SLAs for putting OOUI into “maintenance mode”, growth of new code using OOUI across Wikimedia projects will stay within X% in Q1.
PES1.4.3 If we map ownership using the proposed service catalog for known owned services in Q1, we will be able to identify significant gaps in service catalog as it helps in solving the SLO culture by the end of the year.
TBA If we finalize and publish the Edit Check SLO draft, practice incorporating it in regular workflows and decisions, and draft a Citoid SLO, we’ll continue learning how to define and track user-facing and cross-team SLOs together.
TBA By creating a system that spawns and controls thousands of virtual workers in a cloud environment, we will be able to simulate Distributed Denial of Service (DDoS) attacks and effectively measure the system's ability to withstand, mitigate, and respond to such attacks.


버킷 설명

위키 경험

 
Diversity (40786) – The Noun Project

이 버킷의 목적은 전 세계에 무료 지식을 배포할 수 있는 위키 경험을 효율적으로 제공, 개선 및 혁신하는 것입니다. 이 버킷은 운동 전략 권장 사항 #2(사용자 경험 개선) 및 #3(안전 및 포용성 제공)에 부합합니다. 우리의 청중에는 우리 웹사이트의 모든 협력자뿐만 아니라 독자와 기타 무료 지식 소비자도 포함됩니다. 우리는 상위 10개 글로벌 웹사이트와 기타 중요한 무료 문화 리소스를 지원합니다. 이러한 시스템은 세계 최대 기술 기업과 동등한 성능 및 가동 시간 요구 사항을 갖추고 있습니다. 우리는 자원봉사자들이 협력하여 전 세계적으로 무료 지식을 생산할 수 있는 강력한 플랫폼을 형성하는 위키, 번역, 개발자 API(및 기타!) 및 지원 애플리케이션과 인프라에 대한 사용자 인터페이스를 제공합니다. 이 버킷에 대한 우리의 목표는 우리의 핵심 기술과 역량을 향상시키고, 프로젝트의 자원 편집자와 조정자의 경험을 지속적으로 개선하고, 위키 경험을 개선하거나 향상시키기 위해 노력하는 모든 기술 기여자의 경험을 향상시키고, 전 세계 자유 지식의 독자와 소비자를 위한 훌륭한 경험입니다. 우리는 제품과 기술 작업뿐만 아니라 연구와 마케팅을 통해 이를 수행할 것입니다. 이 버킷에는 최대 5개의 목표가 있을 것으로 예상됩니다.

지식은 사람이 만듭니다! 결과적으로 우리의 연간 계획은 콘텐츠뿐만 아니라 콘텐츠에 기여하는 사람, 콘텐츠에 접근하고 읽는 사람에도 초점을 맞출 것입니다.

우리의 목표는 기존 전략, 주로 기여자, 소비자 및 콘텐츠 "플라이휠"에 대한 가설을 기반으로 운영 계획을 수립하는 것입니다. 제가 요청하는 주요 변화는 플라이휠의 콘텐츠 부분에 중점을 두고 향후 커뮤니티 건강 지표를 식별하기 위한 목표로 중재자와 임원이 현재 우리에게 필요로 할 수 있는 것이 무엇인지 탐색하는 것입니다.

신호 및 데이터 서비스

 
Arrythmia noun 246518

의사 결정의 형평성 보장(권고 사항 #4), 사용자 경험 개선(권고 사항 #2), 평가, 반복 및 적응(권고 사항 #10)을 위한 운동 전략 권고 사항을 충족하려면 위키미디어 운동 전체의 의사 결정자는 신뢰할 수 있고 관련성이 높은 정보에 접근할 수 있어야 합니다. 그리고 자신의 업무와 커뮤니티의 업무가 미치는 영향(실현 및 잠재력 모두)을 평가하여 더 나은 전략적 결정을 내리는 데 도움이 되는 시기적절한 데이터, 모델, 통찰력 및 도구를 제공합니다.

신호 및 데이터 서비스 버킷에서 우리는 위키미디어 재단 직원, 위키미디어 가맹단체 및 사용자 그룹, 콘텐츠를 재사용하는 개발자, 위키미디어 연구자 등 네 가지 주요 대상을 식별했으며 이러한 대상의 데이터 및 통찰력 요구 사항에 우선 순위를 지정하고 해결합니다. 우리의 작업은 격차 정의, 지표 개발, 지표 계산을 위한 파이프라인 구축, 데이터 개발, 의사 결정자가 데이터 및 통찰력과 보다 효과적이고 즐겁게 상호 작용하는 데 도움이 되는 탐색 경험 및 경로 신호 개발 등 다양한 활동에 걸쳐 있을 것입니다.

미래의 잠재 고객

 

이 버킷의 목적은 자유 지식 생태계의 필수 인프라로서 전 세계 모든 사람에게 진정으로 다가가기 위한 노력의 일환으로 기존 소비자 및 기여자 대상을 넘어 확장하기 위한 전략을 탐색하는 것입니다. 이 버킷은 운동 전략 권고 사항 #9(자유 지식의 혁신)에 부합합니다. 점점 더 많은 사람들이 문서가 포함된 전통적인 웹사이트 제공 방식과 다른 경험과 형태로 정보를 소비하고 있습니다. 사람들은 음성 도우미를 사용하고, 비디오와 함께 시간을 보내고, AI에 참여하고 있습니다. 이 버킷에서 우리는 자유 지식 생태계의 잠재적인 장기 미래와 우리가 어떻게 필수 인프라가 될 것인지에 대한 가설을 제안하고 테스트할 것입니다. 우리는 연구, 파트너십, 마케팅뿐만 아니라 제품 및 기술 작업을 통해 이를 수행할 것입니다. 유망한 미래 상태를 식별하면 이 버킷에서 얻은 학습 내용은 연속 연간 계획의 버킷 #1 및 #2를 통해 영향을 미치고 확장되어 미래의 지식 추구자에게 서비스를 제공하기 위해 제품 및 기술 제공이 필요한 방향으로 나아갈 것입니다. 이 버킷에 대한 우리의 목표는 자유 지식의 미래에 대한 비전에 초점을 맞추면서 실험하고 탐구하도록 유도해야 합니다.

하위 버킷

 
Noun project 3067

우리는 또한 기본 운영을 지원하기 위해 재단에 존재해야 하는 중요한 기능 영역으로 구성된 두 개의 다른 "하위 버킷"을 갖고 있으며, 그 중 일부는 모든 소프트웨어 조직과 공통적으로 갖고 있습니다. 이러한 "하위 버킷"에는 자체 최고 수준 목표가 없지만 다른 그룹의 최고 수준 목표에 대한 의견이 있고 지원됩니다. 그것은:

  1. 인프라 기반. 이 버킷에는 데이터 센터, 컴퓨팅 및 스토리지 플랫폼, 이를 운영하는 서비스, 공개 사이트 및 서비스 운영을 가능하게 하는 도구 및 프로세스를 유지하고 발전시키는 팀이 포함됩니다.
  2. 제품 및 엔지니어링 지원. 이 버킷에는 다른 팀의 생산성과 운영을 개선하는 서비스를 다른 팀에 제공하는 "규모에 맞게" 운영되는 팀이 포함됩니다.