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/ Product Manager
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]

What do our boards look like?[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?
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
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
New & TBD Tickets	Newly-created tasks in which CommTech is tagged	Anyone! This is the default column for any tasks tagged with Community-Tech.
Needs Discussion	Tasks that need to be refined and/or estimated at an upcoming Estimation meeting.	Product Manager, Tech Lead, Engineering Manager
Maintenance Backlog	As a team, we maintain some projects that have been build fulfilling wishes in the past, these maintenance tasks come in constantly but receive only limited attention as we are focussing on wish fulfilment.	Product Manager, Tech Lead, Engineering Manager
CommTech Backlog	This is the backlog for features that we are currently working on that have reserved time/capacity on our roadmap	Product Manager, Tech Lead, Engineering Manager
Epics	Parent tasks tagged as Epic, which likely carry over multiple sprints.	Product Manager, Tech Lead, Engineering Manager, UX Designer, Engineer, QA Engineer, TPgM
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 for development	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	Product Manager Engineering Manger
Goals and epics	High level tasks/sprint goals	Product Managers/Tech Leads/Engineering Manager
In Development	Tasks that are being worked on	Anybody
Review/Feedback	Completed tasks that need to be reviewed before testing	Anybody
QA	Tasks that have been developed and are undergoing testing	Anybody
Done	Tasks that have been completed	QA testers

How do we structure work in Phabricator?[edit]

In the context of our team, which is Full Stack and very distributed, it would make sense if each epic has multiple user stories and one user story is one ticket, as this would allow us to add detailed acceptance criteria per story. Engineers can split out tasks further into tasks i.e. UI and backend implementation, this happens during planning meetings.

Workflow[edit]

Product Manager and Designer plan out features and create Epics that give a broader picture of what other tasks fit into and specfiy the purpose of the work.
To be able to split out work into more manageable chunks, PM and Engineers and EM divide work into Stories during Planning meetings. This can only be done together, as it's a cross-functional effort and the crucial conversations in Planning meetings, help narrow down requirements realistically. Key notes about agreements in the meeting are put down as notes in the Phab tickets.
If tasks are still more than 1/2 week - 1 week large Engineers and EM can create even smaller tasks, before working on them. This gives us a greater sense of progress and prevents huge merge requests.
Work work work.

So if you're working on a ticket, that is maybe not marked as anything and has tons of user stories. It's a good moment to start thinking about how long does this work take if it's more than a week or half a week, Then it's a good moment to split it out into a story and same goes for tickets that have lots of user stories that solve lots of user problems

	Epic	Story	Task
What	A high-level goal that outlines what and why we’re building it. Often framed as a Sprint Goal	A user story to satisfy the goals of the epic. This is where acceptance criteria and details live	How we build the user story
Who	PM + Design	PM + Engineering	Engineering
Phab tag	Epic	Story
Duration (eng time)	1-2 sprints	½ week - 1 week	1-3 days
Example size	Wish index page	Sort wishes in the table	Add codex component for sorting
Phab template	Link to template	Link to template	N/A

Anatomy of an Epic[edit]

Template	Example
What + Why Explanation of the epic, what it intends to do, and why it’s important	Users frequently don't know what template to insert on a page. The current UX forces users to remember the name of a template and type it in; the only affordance is a search box. In this epic, we want to add metadata about templates and help users see the most transcluded templates in their wiki, and show how often a template is transcluded when a user searches for templates.
Details Details about the user experience that are relevant for the feature. Typically a bulleted list of user stories	As a contributor, I should be able to see the most transcluded templates in my wiki, so that I can quickly see and use the most popular templates As a contributor, when I search for a template, I should see transclusion data so that I have more confidence in the template I am using. As a contributor, when the template selector loads, I should see a list of the most transcluded templates in my wiki, scoped to the content namespace
Goals Metrics to watch and how this impacts the product	Improve the rate of articles with templates Increase the number of editors adding a template
Research findings / data Links to research or data that is an outcome of spikes and research preparing the work.	When starting research for implementation we surface finding that change our course of action, that might be interesting going forward.
Designs Links or screenshot of design.	Provide visual context for an accordion and what goes into each tab
Out of scope Any user stories or experiences that are out of scope.	Creating a community configuration for suggested templates Changing search terms or search algorithm Changing the UX once a user has selected a template.
Related Conversations: (Optional) To make sure one as all information in documents or Slack channels related to this one.	Sometimes getting on the same stage of knowledge is tricky, therefore listing sources of infomation can be beneficial, that could be doc or Phab tasks
Contact person/team: (Optional) For example wish lead of a project.	For wishes we assign a project manager that owns the work and is the point of contact.

Anatomy of a Story[edit]


Template	Example
User story A specific goal and outcome for an end user. There should be only one, otherwise you want to split out the ticket.	As an admin I want to plan a future block and gain and overview of the existing blocks.
Acceptance criteria Checklist of different specifications and UI elements	add a view of current blocks and a history if blocks
Details for QA Example suggestions for test cases or instructions for approaching testing	Test who this feature is visible to
Designs Links or screenshot of design	Show a table and visualise all of its sorting functionalities

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

Meeting Norms

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 a meeting event in Google Calendar within 1-2 days ahead of its scheduled time (including meetings outside your normal working hours).

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

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

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

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

Weekly Meetings Flow[edit]

Ritual	How	Who	What	When
Sprint close	Async on Sprint planning doc CommTech Sprint Planning and Standup	Commtech	Everyone should provide an update on their priorities, what’s outstanding, and accomplishments
"Demos"	Async on Slack #commtech-demos	All	“demo” of your accomplishments. This could be a screen recording, a link to a document
Sprint Kickoff	Async on Slack #community-tech	Jack Wheeler	Share sprint’s priorities and objectives.
CommTech Team Leads Planning	Synchronous Meeting	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	Weekly on Mondays 2pm UTC
Sprint Prep	Async - #community-tech	Jack Wheeler	A video recording (~3-5 minutes)for the upcoming Sprint’s priorities.
Async 🧍	Async - Sprint planning doc	All	Update team on your priorities, outline progress, identify blockers or issues to discuss	Tuesdays, Thursdays, Friday
CommTech	Synchronous AM and PM session	All - as needed	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.	Weekly AM:- Tuesdays 12:15pm UTC PM- Thursdays 5pm UTC
🤕 Sprint planning and estimation 🔢	Synchronous AM and PM session	All attend one session	Team/individuals break down objectives into tasks and estimate work	Weekly on Wednesdays AM: 10:30am UTC PM: 6:00pm UTC
Retro	Synchronous AM and PM session	All attend one session	Reflect on the sprint and team health	Fortnightly

Team operations[edit]

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

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

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

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