تصمیم‌گیری فنی

Overview

Updates

Decisions

Forum

FAQs

فرایند تصمیم‌گیری فنی ویکی‌مدیا این اختیار را به تیم‌ها می‌دهد تا تصمیماتی را اتخاذ کنند که به تیم‌های بنیاد ویکی‌مدیا، وابستگان آن‌ها و گروه‌های داوطبان نیز اطلاع داده می‌شود.

دربارهٔ فرایند تصمیمی‌گیری

فرایند تصمیم‌گیری فنی دارای اهداف کلیدی زیر است:

• فراگیرتر فرایند به‌واسطهٔ تغییر نمایندگی توسط توسط تیم‌ها یا گروه‌ها به جای افراد
• داشتن جدول زمانی مشخص برای زمان اتخاذ تصمیم
• شفافیت در خصوص این که کدام‌یک از سهامداران در درگیر موضوع می‌شوند
• توسعهٔ یک چرخهٔ حیات شفاف برای یک تصمیم

این فرایند شامل این بخش‌های اصلی می‌شود:

• انجمن تصمیم فنی متشکل از نمایندگانی از دپارتمان‌های محصول و فنی بنیاد ویکی‌مدیا، ویکی‌مدیای آلمان و دو مشارکت‌کنندهٔ مستقل
• الگوهایی برای گزارش‌های اشکالات و سوابق تصمیم‌گیری

زمان استفاده از فرایند

فرایند تصمیم‌گیری فنی در تمام شرایطی که اثرات تصمیم اتخاذشده فراتر از تیم تصمیم‌گیرند حس می‌شوند، باید مورد استفاده قرار گیرد. این شامل تصمیماتی که تأثیر به‌سزایی بر کدها و نرم‌افزارهای به‌کارگرفته‌شده در زیرساخت‌های محصولات ویکی‌مدیا دارند نیز می‌شود.

الگوها

در فرایند تصمیم‌گیری فنی برای مستندسازی و رهنمود تصمیم‌گیری‌ها از الگوهایی استاندارد استفاده می‌شود.

• 
  الگوی گزارش اشکال
• 
  الگوی ماتریس انتساب مسئولیت (RACI)
• 
  الگوی سابقهٔ تصمیم

سوابق تصمیم‌گیری

مصنوع نهایی این فرانید کی سابقهٔ تصمیم‌گیری است. برای مطالعهٔ سوابق تصمیم‌گیری که این فرایند را تکمیل کرده‌اند، به صفحهٔ تصمیم‌گیری مراجعه کنید.

جریان فرایند

فرایند تصمیم‌گیری توالی از گام‌هایی برای کمک به تصمیم‌گیرندگان در تعریف یک مشکل، جمع‌آوری بازخوردها، پژوهش پیرامون راه حل‌ها، و مستندسازی تصمیم است.

۱. شناخت تیم تصمیم‌گیری و مالک پروژه

To start the process there needs to be a decision team and a proposal owner who will work through the process from start to finish. تیم تصمیم‌گیری و صاحب پیشنهاد گروهی هستند که تصمیم‌گیری را انجام می‌دهند. معمولاً تیم تصمیم‌گیری یکی از تیم‌های بنیاد ویکی‌مدیا، یک تیم وابسته، یا یک گروه داوطلب است. مالک پروژه عضوی از تیم تصمیم‌گیری است که مسئولیت هدایت تصمیم‌گیری در طی فرایند را برعهده دارد.

اگر یک تصمیم تأثیرات گسترده‌ای داشته باشد، تیم تصمیم‌گیری می‌تواند شامل افرادی از تیم‌های مختلف باشد. برای مثال، تصمیم برای پیاده‌سازی چارچوب Vue.js توسط یک گروه کاری با عملکرد متقابل اتخاذ شد. بسیار مهم است که کسی که در قبال تصمیم پاسخگو است، منابع و اختیارات لازم برای عمل به آن تصمیم را در اختیار داشته باشد.

۲. تعریف گزارش مشکل

برای آغاز فرایند تصمیم‌گیری، مالک پروژه باید برای گشودن یک وظیفه در تابلوی کار در فابریکاتور از الگوی گزارش اشکال استفاده کند.

هرگاه وظیفه ایجاد شد، مدیر پروژهٔ انجمن تصمیم‌گیری فنی متن گزارش اشکال را در یک سند گوگل کپی می‌کند و آن را با مالک پروژه و هیئت انجمن به اشتراک می‌گذارد تا آن را بازبینی کنند و در مورد آن نظر دهند و گفتگو کنند. اعضای هیئت انجمن یک هفته مهلت دارند تا گزارش مشکل را بازبینی کنند و به تیم تصمیم‌گیری بازخورد دهند. There will be at least one office hours with Chairs and the decision team to discussion and sign-off the final version of the Problem Statement.

Once the project owner is ready to share the revised problem statement, the Forum project manager adds a link to the Google Doc in the original Phabricator task.

Touch points

• Office hours
• Phabricator

3. Get feedback from the Decision Forum

Once the problem statement is finalized, the Technical Decision Forum Representatives will review the problem statement and provides feedback to the decision team. Forum Representatives are expected to share their feedback within one week. The feedback answers these questions:

• Is the problem statement correct?
• Is it clear how solving this problem supports Wikimedia goals (movement strategy, medium term plan, annual plan, etc.)?
• Are these the right stakeholders?
• Is the needed subject matter expertise to make a decision reflected accurately? Are the right groups outlined in the problem statement?

The Forum project manager is responsible for requesting review from Forum members and sharing Forum feedback with the project owner.

Touch points

• Office hours
• Technical Decision Forum Google Group
• Phabricator
• Google Docs
• Slack

4. Research and prototype

Once the Forum has provided feedback on the problem statement, the decision team begins researching and prototyping solutions. This phase should have a well-defined scope and time frame.

The decision team is responsible for checking in with the Forum every two weeks to share their progress. This is the time when stakeholders engage with the decision team, further models are developed, and prototyping occurs as needed.

Demonstrations do not have to be prototypes with UIs. They can be a document, pseudocode, or anything else that helps others see where the team's progress and thinking is at that time.

Touch points

• Technical Decision Forum
• Demonstrations during office hours
• Retrospectives
• Phabricator
• Progress announcements in decision making process updates

Executive review

For larger, more impactful decisions, system-level tradeoffs, or decisions that greatly impact the community, demonstration of the problem statement is done for relevant executives, typically the Chief Technology and Product Officer (CTPO) of the Wikimedia Foundation. The CTPO delegates a representative to review the problem statement and flag for executive review.

5. Make the decision

Once the decision team has engaged all the stakeholders outlined in the problem statement and (if required) reviewed with executives, the team can make the decision.

Touch points

• Technical Decision Forum
• Phabricator
• Decision announcement in in decision making process updates

6. Publish decision record

Once a decision has been made, the decision team publishes the decision record to the decisions page.

Questions and feedback

Questions and feedback are always welcome. Contact us at TDFsupport@wikimedia.org.

Background

The technical decision making process was adopted in 2020 as an evolution of the Requests for comment (RFC) process (TechCom). To learn more, visit the background page.