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 Survey[edit]

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 & Responsibilities[edit]

People and roles within our team[edit]

People	Roles
Jack Wheeler	Lead Community Tech Manager (PM)
Karolin Siebert	Engineering Manager
Dayllan Maza	Lead Engineer/Tech Lead
Sandister Tei	Movement Communications Specialist
MusikAnimal	Engineer
Harumi Monroy	Engineer
Sam Wilson	Engineer
Sammy Tarling	Engineer
Dom Walden	QA Engineer
Joydeep Sengupta	Principal UX Designer

Specific tasks and responsibilities per role[edit]

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 Shapes team mission and values Identifies open questions and decisions of the team
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 Plan timing for releases and deployments 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

DACI[edit]

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

Phabricator[edit]

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

Releases[edit]

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 Norms == (Still Editing)

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.

Experiment: we will try various ways of working to see what works best

Key Meeting: “CommTech Go.”

This meeting should be our “how we work” hub. It should serve as a place to discuss stalled tickets, project meetings (kickoffs, design review, eng review). CommTech Go replaces our standup. We won’t do RTL, but instead do that in our Async Standups. Help each other get “unstuck” and move things forward. This is a mix of product planning, engineering discussion, or design meetings. Could be focused on a specific project or task. Dedicated team time to discuss issues. If we have nothing to talk about, we could give people the time back, play games, or just hang.

Other Meetings

Async - Sprint planning doc Everyone should provide an update on their priorities, what’s outstanding, and accomplishments Track work and discuss blockers

“Demos”

Async - #commtech-demos

Share a “demo” of your accomplishments. This could be a screen recording, a link to a document (with context) or other shareout. Celebrate progress, increase visibility, and learning

Sprint kickoff

Async #community-tech

Share sprint’s priorities and objectives. Create a “time capsule” for the team’s identified priorities for the sprint

💹 Team leads planning 💻

Attendees: Jack Wheeler, Karolin Siebert, Joydeep Sengupta, Dayllan Maza. Go over the current roadmap, identify priorities, and adjust as needed.

Assign people to priorities to facilitate estimation and planning To help team keep focus on current and upcoming work. Weekly on Mondays

Sprint Prep

Async - Jack Wheeler A video recording (~3-5 minutes) of voiceover for the upcoming Sprint’s priorities. Ensure the team is focused and working on the most pertinent issues. Align on sprint goals, plan tasks, address risks, and boost communication

Async - Sprint planning doc

Update team on your priorities, outline progress, identify blockers or issues to discuss Keep team informed of progress and things that may need attention

🤕 Sprint planning and estimation 🔢

Synchronous AM and PM session Team/individuals break down objectives into tasks and estimate work Ensure that we’re discussing product trade offs/priorities, and so we can accomplish something in the 2-week interval

Retro Synchronous AM and PM session Reflect on the sprint and team health Demos from last sprint

Team operations

We run in “sprints,” or more specifically “Scrumban.” Each Sprint will have 2-3 priorities that are achievable within a 2-week period, or map to a broader milestone. Goal is not to release every two weeks, but complete a discrete unit of work. Individuals will be tasked against each priority. We will measure how much “walk-on” work we take on.” Every two weeks we update a “planning doc” which outlines sprint goals and objectives.

We will manage this process on a “Scrumban” board. It will look and behave like a Kanban board, however we will only roll new tickets onto the board, or close tickets during our Sprint Planning meetings.

This is similar to what Language does.

Example Planning meeting template:

Feb 26, 2024-Mar 8, 2024

Last sprint review: 👏 Wins

Community update: Edit Recovery is deployed on enwiki, frwiki and mediawikiwiki :) (Help page) 💡Learnings 🛑 Road-bumps and blockers 📈 # of # planned tasks completed 🐢 # of walk-on work 🎯Goals and priorities Ideally no more than 3 priorities per sprint. Edit recovery Goal: Person community update Person ship the feature Multiblocks - Goal: Person task Person task Codemirror Goal: Person task Person task

Up next Focus areas for design and product - directional (1-2 sprints out)

Person Design on FOTW intake form Person Start scoping architectural impact of FOTW intake site / dashboard On the horizon 2-3 focus areas from: 23/24 - Community Tech - Roadmap

Sprints FAQ

What is the change that is being proposed?

We want to work out of “Scrumban” instead of a Kanban approach. We propose kicking this off Monday, Apr 1, 2024, and trying this experiment through Jun 3, 2024

What are sprints?

A series of time-boxed iterations used to break a complex software development process into smaller achievable targets. For each Sprint, we’ll outline 2-3 goals that we aim to achieve as a team, with specific individuals assigned to each goal or task.

What’s a Scrumban board

A kanban board that we operate like a “sprint” board. We will only add tickets to the kanban board every 2 weeks, and we will measure progress on a 2-week basis.

Why are we proposing this?

People on our team feel that they’re working in isolation, and have less visibility of other engineers’ projects, as well as the team roadmap It feels like we currently pick off the Kanban board at random, which sometimes hinders our ability to focus or ship as quickly as we’d like. We aren’t committing to any work Deadlines seem to be non-existent

How would we flag if a different model would work better for us?

If the new process is getting in the way of progress If we feel like we’re not flexible enough to prioritize correctly for our levels of uncertainty at the time We will take notes along the way about how things are going and discuss regularly in retro

How will we ensure we are focusing on the right things? We will more rigorously define and stick to our roadmap We will not pull tickets into the sprint without having defined or estimated tickets ahead of sprint planning

How will we ensure a reasonable workload for the team? Use estimation to limit the amount of tasks per sprint

How do we manage Phabricator?

We will have a “backlog” board of groomed tickets and epics Our priorities will be set at the “epic” level, each ticket should wrap into an Epic We will move tickets onto our “Scrumban” board when we kick off a new Sprint

How long is a sprint? 2 weeks

How do we end a sprint? We’ll document how much progress we made against our goals We’ll leave any leftover tickets in their columns, and remove tickets as necessary Break down tasks that seem too big We have a retro to discuss how things went We have a demo of the work we’ve completed

How will this change team meetings? Tickets going onto our Scrumban board should be estimated Backlog should only contain estimated and prioritized tickets (for next sprints) Estimation and analysis are for the upcoming sprint

💹 Team leads planning 💻 🤕 Triage and estimation 🔢 Async 🧍

Async 🧍 Week 2 Sprint prep (for next Sprint)

Team moves tickets into “backlog” and triages “up next” Async 🧍 🤕 Triage and estimation 🔢 Async 🧍

Retro ⏪ Close sprint, tidy up async

Meetings

Sprint 🚀 Demos from last sprint Articulate sprint goals Review incomplete work from the last sprint, discuss and potentially remove that work Estimate any remaining tickets left over from the estimation meeting Descope the sprint if too much work has been taken on

Async 🧍 Share current progress, show demos a-sync, surface questions and blockers. Framed through team/individual priorities

🤕 Triage and estimation 🔢 Go through new tickets and estimate as needed

💹 Team leads planning 💻 Review roadmap, outline goals for upcoming Sprints, epics, get tickets written as needed

🍱 Sprint Prep 🧑‍🍳 Review upcoming Sprint, create and estimate as needed Discuss longterm roadmap as team

Retro ⏪ Retro

How and when should we prioritize tasks? Anyone who creates a ticket can offer a provisional priority, but the PM sets the final priority on a ticket. Anyone who creates a ticket can also estimate the tickets

How and when should we estimate tasks? As a team, we discuss tasks in weekly estimation meetings and validate initial assumptions

How/when do we incorporate feedback from the communities? Factors that can affect priority for community tasks/questions Which community and what is their relationship to the WMF Which project Did we break something Is it a bug or is it a feature request Who opened the ticket and how controversial are they? Are they a part of our target audience? Are they a pilot/partner wiki on a project? Other factors we need to take into consideration What are the differences from a WMF UBN/High priority ticket?

How will we estimate? Fibonacci

Open questions How do we deal with interrupt work? Types of interrupt work Technical work that bubbles up Requests from other teams Community patches - requests for code review (we should respond to volunteers, maybe have a priority system based on time/risk/etc) Regressions (we can push back on almost all the other kinds but probably not these) What is our prioritization criteria for interrupt work we pull in? Affects more than 5% of logged out users or 10% of logged-in users Is urgent for another team/the department itself Large visual regressions

What is our definition of “done”? Clear QA and are in Signoff What about the train? Task is in QA in Production? Should we try to avoid L tasks? (they take longer, often carry over) Split them up earlier Agree on approach sooner If it’s larger than a week’s work, a sign to break it up

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.

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.