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]
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 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 |
|
| Lead Engineer/Tech Lead |
|
| Product Manager |
|
| Community Relations Specialist |
|
| UX Designer |
|
| Quality Assurance Engineer |
|
| Engineer |
|
| Technical Program 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).
| 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).
| Column header | What kinds of tasks live here? | Who moves tasks into this column? |
|---|---|---|
| Ready for development |
|
|
| 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 | 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