Product Analytics/Team norms

Expectations for work & off hours

Team core work hours: Monday–Thursday, 09:00-11:00 San Francisco time (note that this varies with daylight saving time)
- Team members should be available for scheduled meetings during these hours
- Team members should be able to respond to questions within that time frame, though not necessarily immediately (given that people may be involved in meetings, heads down work, etc)
- If you are not available during these hours, mark it on your calendar
Time off should be time off! Block time off on your calendar, set email vacation messages, and redirect questions to the team email address.
Make sure to advertise when you’re working and when you're not: block off vacation days and non-work hours on your calendar, set a vacation auto-responder.
Keep the Office wiki contact list up to date with ways to reach you when you are not working.
- Only use these methods to contact people if the issue absolutely cannot wait or be handled by someone else (this should happen very, very rarely).
Offsites & Virtual Convenings
- Our Team's: Give ample notice to Product Managers and other collaborators that you will be attending your team's offsite and will not be available for 1:1's and team meetings. If you are on chore wheel duty refer to this page.
- Other Team's: If you are attending another team's offsite, you are not expected to attend our team's meetings for those days. Even if you are attending it remotely, the assumption is that during those days you are 100% at that convening.
Event participation
- For events such as Wikimania, Wikimedia Hackathons, and other Wikimedia-affiliated events that often start on a weekday and end on a weekend our team policy is that if you participate on a weekend you can float the 1-2 weekend days you attend.
- Please let your manager know ahead of time and check with them whether the event qualifies.

Sick Leave

If you're feeling unwell and need to take time off to rest/recover:

let the team know in the team's private Slack channel
set an Out Of Office (OOO) in your Calendar so that you automatically decline all meetings while you're OOO

The time-off request in Namely can be made when you return to work.

Meetings

Be present: avoid doing other things during meetings (unless you're presenting or taking notes, of course).
Text messages are the same as talking. Feel free to send them, but be aware they're just as interrupting as saying the same thing out loud.
If you can, stay unmuted during meetings so the conversation feels more natural. This may take some work to achieve (for example, buying a good headset to minimize background noise).
Be aware of how much you're talking: if you're talking a lot, consider leaving more space for others. If you're only talking a little, consider whether you have something to say.
Don't be afraid to eat a snack during a meeting (just mute yourself while you do!). Similarly, if you need a quick bathroom break, it's fine to step away briefly.
The person who requests a meeting should put it on the calendar.

Communication

Make it so you don’t get notifications about work communications (emails or chats) when you’re not working. That way, you can really recharge during your off hours and people don’t have to worry whether you’re working before sending a ping.
By default, we don’t expect emails or chats to be “urgent”; we understand people may be unavailable during heads down work or in meetings. If a message or question is urgent, preface it with [URGENT]
In chats, try not to send multiple messages when you can use one. For example, when asking a question, put the question in the same message as your greeting.
Unless you actively want something to be private, use main channels (email or Slack) for discussion and questions so the rest of the team can benefit and help.

Triaging tasks

Our future work can be found on the main #product-analytics board on Phabricator. Its columns are:

Triage: This column is the default column that tasks tagged for our team go into. These tasks need their priority to be determined (using priority levels described below) and need to be moved to one of the other columns or into our Kanban (if it will be worked on in the next two weeks).
Epics: This column collects tasks which track large bodies of work that are broken down into many smaller tasks.
Current Quarter: This column collects tasks which we plan and expect to work on in the current quarter.
Upcoming Quarter: This column collects tasks which we plan and expect to work on in the next quarter.
Blocked: This column collects tasks which we own and whose start is blocked by an unmet dependency.
Backlog: This column collects tasks which we hope to get to eventually or which is planned for quarters beyond the upcoming quarter.
Tracking: This column collects work which we need to be aware of and keep tabs on.
Icebox: This column collects work that is lower priority than anything in the backlog and which we (for whatever reason) do not feel comfortable declining or untagging ourselves from.

Priority levels

Unbreak Now!: Fixing a crisis in progress that is jeopardizing core Wikimedia functions.
- Examples: Resolving an imminent threat to private data. Providing data to address a community crisis.
High: Urgent or time sensitive work that is an essential part of accomplishing major Wikimedia goals.
- Examples: Providing analysis for organizational goals in time for a Tuning Session or Annual Report. Resolving a data bug that affects key metrics.
Medium: Work that is important or useful for major Wikimedia goals.
- Examples: Identifying key goals and metrics for a major feature. A/B test of a new feature.
Low: Work that's tangentially useful to major goals, or useful to minor ones.
Lowest: Work that has some value, but is not related to current goals.

Working on tasks

Our Kanban board in Phabricator has the following columns:

Next 2 weeks: This column collects tasks which have been triaged and which we plan to start work on in the two weeks following their triage.
Needs Investigation: This column collects tasks which we have not started actively working on or have made a conclusive decision about (e.g. whether to decline the task or whether it should be planned for current quarter or moved into the backlog) because we have some open questions about the scope or purpose of the task.
Doing: This column collects tasks which we are actively working on.
Blocked: This column collects tasks whose progress is blocked by an unment dependency which emerged after starting work on the task.
Needs Review: This column collects work that requires review from fellow members of the Product Analytics team. For example: reports/analyses that need to be peer-reviewed before sharing with the intended stakeholder or queries which need reviewed before committing to using the queried data in an analysis.Tasks in Next 2 weeks come from the main board's Needs Triage and Current Quarter columns. Once a task is started it enters the Doing column. When we are done with a task:

Tag the stakeholder and let them know to either:
1. Re-open the task if they disagree about the acceptance criteria being met
2. Create new task if they have follow-up questions / additional requests
Resolve the task ourselves

Collaboration

Some of these are copied from the Technical Engagement team norms.

Mentor and share knowledge: Demonstrate and share lines of code, ad hoc commands, and general understanding. Don’t be afraid to ask a question, even if you think it’s basic.
Feedback is valuable! Offer specific & actionable praise, constructive criticism, or alternative solutions.
Apologize for and acknowledge behavior we seek to avoid when it has happened: A team of humans will experience being tired, frustrated, and overwhelmed. Mutual respect is the only currency we have to navigate these challenges long-term. Demonstrating that respect means acknowledging its value.
Forgiveness is a conscious, intentional, and deliberate decision to release feelings of resentment. Take a breath. Take a walk.
Practice healthy debate. Avoid petty controversies, but don’t shy away from raising problems if exposing them is helpful. Think twice before criticizing if you don’t have a different proposal to suggest, and always make sure to clearly acknowledge the necessary work that has been done.

Request Follow-up Kit

Outlined below are good practices & questions to consider when refining incoming requests.

What is the deliverable? Is it a report, an answer in Phab…?
How will QA be handled?
If the request involves a list of questions/metrics, work with the requester to rank them in order of importance, highlighting the ones that are required versus "nice to have"/optional. This helps us break down the work clearly, enabling us to focus on highest priority tasks first. It might mean the request is split into multiple Phabricator tasks.

Define acceptance criteria, definition of done, expectations, & scope. As much as our work is iterative, we do our best to plan by beginning with the end in mind. For example:
- What do you envision the outcome of this request to be? (e.g., a list of numbers, a question to be answered, a decision to be made).
- Requests that result in software/data/ETL management (e.g. notebook, dashboard, or dataset that’s been built to enable a request); recurrent jobs, “productionizing.”
How we handle follow-up requests for more data (especially for teams where there is no explicit relationship/assignment):
- We start with an assumption that a request is ad hoc/one-time. If the task is a recurring one, that means a larger request that will need more scoping.
- Future-proofing adds overhead, which should be explicitly considered in the task scope.