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.
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
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
  1. 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.
  2. 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.
  3. 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.
  4. 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
  1. Which community and what is their relationship to the WMF
  2. Which project
  3. Did we break something
  4. Is it a bug or is it a feature request
  5. Who opened the ticket and how controversial are they?
  6. Are they a part of our target audience?
  7. Are they a pilot/partner wiki on a project?
  8. Other factors we need to take into consideration
  9. 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