Community Tech/Team Processes

This page is intended for Community Tech team members to share information about internal processes and norms. This document serves to catalog information, expectations, cadences, and good practices for:

Community Wishlist Survey
Phabricator
Releases
Meetings
Communication

For developer-specific processes, please visit Community_Tech/Development

Although everyone on CommTech should feel empowered to edit and make comments/suggestions on this doc, James McLeod is the primary owner and is accountable for keeping it updated as we refine our processes together.

Main CommTech Workboard: https://phabricator.wikimedia.org/project/board/1274

List of Sprint Milestones: https://phabricator.wikimedia.org/project/subprojects/1274

Community Wishlist SurveyEdit

How do we implement wishes?Edit

To make sure we implement wishes in a balanced way we thought of a way to share responsibilities. One dev in the team can we a "wish lead" for one of the wishes while others are the "wish devs".

What does it mean to be a wish lead?Edit

Wish Devs inform the Wish Lead on updates of their implementation

Does NOT mean

To be responsible for the whole project
To make technical decisions on your own
To work in isolation or to feel like you have to do most of it
To have all the answers
Writing tickets on their own, but rather collectively

What it means

To work closely with the team and steward technical direction by facilitating conversations around research and technical planning
To work closely with PM, TPM and EM pruning phabricator tickets, and creating a balanced timeline, but make sure that tickets are being written collaboration
To identify tasks that are blocking the team and make sure they are being prioritized by the PM
To kick-start and open up the floor for healthy discussions about what's working and what's not working for the project

Wishlist Survey Overview

Wishlist Survey Process & Prioritization Scoring Rubric

Roles & ResponsibilitiesEdit

People and roles within our teamEdit

People	Roles
Karolin Siebert	Engineering Manager
Dayllan Maza	Lead Engineer/Tech Lead
Natalia Rodriguez	Product Manager
Sandister Tei	Community Relations Specialist
Leon Ziemba	Engineer
Harumi Monroy	Engineer
Sam Wilson	Engineer
Sammy Tarling	Engineer
Dom Walden	QA Engineer
Nicolas Ayoub	UX Designer
James McLeod	Technical Program Manager

Specific tasks and responsibilities per roleEdit

Role what we expect you to do	Responsibility tasks that allow you to fill your role
Engineering Manager	Manages team budget, resourcing, and hiring Leads onboarding of new engineers Promotes culture of trust and transparency Adjust team processes if required Coordinates with Product leadership to remove blockers Facilitates 1:1 conversations to proactively address issues such as overwork Encourages cross-team and internal collaboration Ensure everyone feels heard and valued
Lead Engineer/Tech Lead	Ensures team adherence to common standards Serves as the technical authority for the team by being the final decision-maker on all major technical design issues Code review to ensure team’s code hygiene (refactoring, test cases, etc) Helps onboard new engineers Assists QA in test automation Leads Engineering meetings Ensures that developers' ideas are captured and clarified Escalates significant technical issues (outside or within team) for resolution Ensures that dev issues are communicated promptly/regularly to PM/TPgM Helps with planning/tracking Represents the dev team in meetings that facilitate planning/tracking when the rest of the team is not present Determines initial high-level estimates for stories when necessary for planning/tracking
Product Manager	Responsible for the product or service being delivered by the team by providing vision for the product or service being developed Serves as the single point of escalation for contending priorities among stakeholders Manages, creates, and updates the product roadmap Maintains and prioritizes the product backlog Determines priority of tasks Determines what features the team should work on in order to achieve our user, community, and Foundation goals; this is done in collaboration with the team Makes final decision about whether or not work done on stories is complete ('acceptance') NOTE: bugs and technical/non-user-facing stories are treated differently from user-facing work: If a bug is resolved in Phabricator, it is automatically considered "signed off" For tech tasks, whoever merges the task has indicated that they sign off on it Makes final decisions about trade-offs when desired functionality, or scope, exceeds the capacity of the team Makes themselves available to team members as questions arise Defines the target constituent for iterations, releases, and the overall product Ensures that our products serve the intended need and provide a coherent user experience
Community Relations Specialist	Participates in the strategizing/planning process providing community perspectives and risk assessments through the lens of DEI/equity Designs and/or develops communication plans for activities targeting Wikimedia communities. Drafts and posts information targeting Wikimedia communities, and/or reviews messages authored by the PM. Writes and/or organizes documentation targeting Wikimedia communities.
UX Designer	Defines how users will interact with the product Proposes designs to define how users will interact with the functionality of the product (including designs of UX in general, and the product's interface in particular) Provides design expertise and guidance to engineers and QA during code writing and testing Ensures that the product is not only useful, but usable as well Assists in crafting the vision and narrative that informs user stories, particularly in the delivery of development-ready design assets and/or prototypes Leads usability testing and logs associated findings & recommendations Gathers real-world data to assess needs/requirements of users
Quality Assurance Engineer	Oversees the quality of the product Produces test cases/scenarios Manually tests when not automated/automatable Maintains regression test suite Integrates testing Undertakes exploratory testing Assists Product Owner with the acceptance criteria definition Responsible for training and otherwise working with engineers in best-practices for assuring code and product quality
Engineer	Turns requirements into working software Writes code to satisfy acceptance criteria Helps with technical analysis Helps with detailed design Helps with architecture Helps with testing Helps code review teammates’ work/code Takes part in estimation of stories Works with QA Engineers to automate story test scenarios Resolves issues and fixes prioritized bugs Decides own standards, technology and architecture Presents work to QA prior to final testing Stands behind the architectural decisions/patterns/best practices the team has agreed to
Technical Program Manager	Tracks evolving team capacity Facilitates team in story delivery & visibility of work in Phabricator Facilitates meetings Owns & maintains team calendar Optimizes & documents processes Coordinates project workstreams & external dependencies Surfaces & escalates risks/issues Reports on progress to stakeholders as necessary Plans and coordinates team off-sites with the input from the budget owner and Product Manager

DACIEdit

indicates who Drives, Approves, Consults, and is Informed for CommTech decisions

	Product Manager	Technical Program Manager	Engineering Manager	Technical Lead	Quality Assurance Engineer	UX Designer	Engineers	Community Relations Specialist	Director of Product Management	Other
Product prioritization
Set product strategy	Approver	Informed	Consulted	Consulted	Consulted	Consulted	Consulted	Consulted	Approver
Set roadmap + goals	Driver	Consulted	Consulted	Consulted	Consulted	Consulted	Consulted	Consulted	Approver	Consulted
Prioritize feature development	Driver	Consulted	Consulted	Driver	Consulted	Consulted	Consulted	Consulted	Informed
Prioritize bug fixes	Approver	Consulted	Consulted	Consulted	Driver	Consulted	Consulted	Informed	Informed
Define user research needs + strategies	Approver	Informed	Consulted	Consulted	Informed	Driver	Consulted	Consulted	Informed

Meetings/Ceremonies
Manage Process Improvements and team norms/artifacts	Approver	Driver	Consulted	Consulted	Consulted	Consulted	Consulted	Consulted
Plan Offsites (attendees, budget, travel)	Consulted	Driver	Approver	Consulted	Consulted	Consulted	Consulted	Consulted	Informed	Consulted
Plan Offsite Content	Approver	Driver	Consulted	Consulted	Consulted	Consulted	Consulted	Consulted	Informed

Collaboration & Communication
Organise collab events and sessions	Approver	Approver	Driver	Consulted	Consulted	Informed	Consulted	Informed	Informed
Plan sync and async comms and alignment	Approver	Approver	Driver	Consulted	Consulted	Informed	Consulted	Informed	Informed
Have weekly conversations with Engineers	Informed	Informed	Driver	Informed	Informed	Informed	Approver	Informed	Informed

Operations
Engineering Resource Recruitment and Allocation	Approver	Informed	Driver	Consulted	Informed	Informed	Informed	Informed
Coordinate Team Dependencies	Consulted	Approver	Driver	Consulted	Consulted	Consulted	Consulted	Consulted	Informed
Professional Development for Engineers	Informed	Informed	Driver	Consulted	Consulted	Consulted	Consulted	Consulted	Informed
Onboard new team members	Approver	Approver	Driver	Consulted	Consulted	Consulted	Consulted	Consulted	Informed

Technical
Determine Technical Approach	Informed	Informed	Approver	Driver	Consulted	Consulted	Consulted	Informed	Informed
Maintain testing infrastructure	Informed	Informed	Approver	Consulted	Driver	Consulted	Consulted	Consulted
Team Tool Creation and Management	Consulted	Informed	Approver	Consulted	Consulted	Consulted	Driver	Informed

Reporting/Documentation
Keep Community Informed	Approver	Consulted	Consulted	Consulted	Consulted	Consulted	Consulted	Driver	Informed
Keep public team and project pages up to date	Approver	Driver	Consulted	Consulted	Consulted	Consulted	Consulted	Consulted	Informed

PhabricatorEdit

Phabricator (often affectionately referred to as Phab) is Wikimedia Foundation’s primary task management and bug tracking system.
- New to Phab? Visit this page on MediaWiki to learn more.
- A distinct piece of work within Phabricator (e.g., https://phabricator.wikimedia.org/T283897) is referred to as a task or a ticket.
  - An epic is also a type of task within Phabricator. Epics are typically used to house groups of tasks (as sub-tasks).

Main CommTech Workboard

Phabricator Columns on Main CommTech Workboard
Column header	What kinds of tasks live here?	Who moves tasks into this column?
New & TBD Tickets	Newly-created tasks in which CommTech is tagged	Anyone! This is the default column for any tasks tagged with Community-Tech.
Freezer	Tasks that we won’t be able to work on now (i.e., not in Unbreak Now!, not within the scope of a prioritized wish), and we don’t anticipate working on in the future. This column should be used sparingly, as an alternative to declining the task or untagging CommTech.	Product Manager, Tech Lead, Engineering Manager, Engineer, TPgM
Engineering Backlog	Tasks that we won’t be able to work on now (i.e., not in Unbreak Now!, not within the scope of a prioritized wish), but would like to refine/work on in the future.	Product Manager, Tech Lead, Engineering Manager, Engineer, TPgM
Epics	Parent tasks tagged as Epic, which likely carry over multiple sprints.	Product Manager, Tech Lead, Engineering Manager, UX Designer, Engineer, QA Engineer, TPgM
Following	Tasks that CommTech won’t work on directly, but want to keep an eye on.	Product Manager, Tech Lead, Engineering Manager, UX Designer, Engineer, QA Engineer, TPgM
To Be Estimated/Discussed	Tasks that need to be refined and/or estimated at an upcoming Estimation meeting.	Product Manager, Tech Lead, Engineering Manager
Estimated	Tasks that have been discussed, estimated with a point value, and are ready to be prioritized within a present or future sprint.	Product Manager, Tech Lead, Engineering Manager, TPgM
CommTech-Sprint-x (where x is a numbered sprint)	Milestone column! Tasks that are actively being worked on, or prioritized for the immediate future. Opens a separate kanban board for active & future sprints.	Product Manager, Tech Lead, Engineering Manager, UX Designer, Engineer, QA Engineer, TPgM

CommTech Sprint Kanban boards
- Each sprint board represents a 2-week timespan (we also keep a log of CommTech sprints, outside of Phab, here).

Phabricator Columns on CommTech Sprint Kanban Boards
Column header	What kinds of tasks live here?	Who moves tasks into this column?
Ready	Our highest priority tasks that should be worked on next Design tasks, engineering tasks that are the result of design tasks, engineering tasks or bugs that do not require design Tasks that have a clear description, user story, & acceptance criteria Placeholder tasks representing urgent items that need action in parallel with ticket writing	Example
In Development	Example	Example
Review/Feedback	Example	Example
QA	Example	Example
Product Sign-off	Example	Example
Done	Example	Example

ReleasesEdit

We use a simple release plan checklist template outlining tasks, roles, and responsibilities for releasing wishes into the world. Open items to be figured out & documented: Release - need to align on what makes a change visible to end users Train https://wikitech.wikimedia.org/wiki/Deployments/Train_vs_backport Backport-config Beta cluster Anything pertinent from https://wikitech.wikimedia.org/wiki/How_to_deploy_code or https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team

Meeting NormsEdit

We have a highly distributed team across multiple time zones, so we are careful about when & why we hold synchronous meetings.

Please RSVP (yes/no) to meeting events in Google Calendar within 1-2 days ahead of its scheduled time.

Meetings:Edit

RTL (Right-to-Left): Right-to-left review of our active Sprint board to ensure visibility of all our work, surface blockers & areas where clarity is needed, and generally see how everyone's doing at alternating times to accommodate different time zones

Collab Sessions: This is a time slot reserved for collaborative programming sessions. Engineers may add non-urgent tickets to the Etherpad to work on together. Otherwise, it's always fine to come with whatever you are currently working on and share your struggles. It will be great for others to get insights into a different codebase or way to work at alternating times to accommodate different time zones

Unmeeting: Chit-chat time! Non-work related, totally optional, informal.

Engineering + Design: A meeting for the team, specifically engineers and designer, to discuss current design work, brainstorm ideas around UX/UI, explore technical feasibility and find optimal design/engineering solutions at alternating times to accommodate different time zones

Retrospective: Here we go over what went well, what could have gone better, and give shoutouts/kudos to people who helped us out over the last 2 weeks at alternating times to accommodate different time zones

Estimation: In this meeting we go over tickets that have been added to To Be Estimated/Discussed on Phabricator, as well as tickets that need to be re-pointed or pointed retroactively. We estimate in the order of highest priority.

Sprint Planning: In this meeting we prioritize work for the upcoming sprint, ensure tickets are well defined, and set a goal for the sprint.

Triage: Here we assign priority levels to newly-created tasks in New & TBD Tickets column, align on next actions, and move tasks to the appropriate column or sprint.

15-minute Wish Check-ins: In these deliberately short meetings, we align on status, blockers, dependencies, and needs for specific wishes.