Editing team/team norms

This page is intended to document the Editing Team's norms and ceremonies. Team ceremonies for Editing is defined as a series of acts and processes performed regularly with the intention of creating an environment that promotes iterative improvement, innovation and productivity.

On this team, process is not intended to become performative, rather it is intended to provide the needed structure to:

• Improve Iteratively; Learn and Adjust  
  • Experiment
  • Fail Fast
  • Reflect
• Collaborate
• Share Knowledge, Wins & Lessons
  • With Each Other
  • Our Communities
  • The Foundation
• Set and Meet Goals
  • Adding Value/Priorities > Scope  
  • Wikimedia Foundation Annual Plan
  • Short and Long Term

Team ceremonies can be altered if it is collectively determined after trial they are not effective as is. Plans and goals are set as a baseline and something to strive towards. Plans and goals if not met should not result in condemnation or negative tones. Not meeting plans and goals should be viewed as an opportunity to learn what needs to be adjusted, rather it is process, priorities, scope or expectations.

Standup:

Standups occur currently on Tuesday and Thursday and last thirty minutes each. Standups are an opportunity to share progress on work, raise tasks that could potentially impact others, or to escalate blockers that impede team productivity. We sometimes have space for discussing a topic at hand. Otherwise, further discussion are left for our "Needs Discussion" meeting or a follow up meeting. The first person to start standup is voluntary and will then choose who goes next. After each report, the team member will call on whoever hasn’t spoken until everyone has had an opportunity to speak or time has run out.

Board Triage Meetings

Official Board Triage Meetings are bi-weekly meetings where members of the team go through the To Triage column of our boards (VisualEditor, DiscussionTools, EditCheck) to determine:

• If a task should be prioritized
• The urgency in which a task should be prioritize
• If the task is within scope for our team

Based on the team's decision of prioritization and scope, we will leave a comment with our decision and move it into the proper column.

Tickets are placed into the "Product Feedback Required" column from "To Triage" if our Product Manager is not present during Triage and there needs to be further product discussion.

Engineers will prioritize urgent tasks coming up on a daily basis and will work on them. Those tasks will also be triaged at the same time.

Sprints:

Our team sprints are two working weeks and begin with Planning Meetings and end with Retrospectives. Once a sprint starts it is not advised that a Product Manager requests changes to what is being produced. It is the job of the Technical Program Manager to work with the team to adjust and re-prioritize tasks as necessary within the sprint to meet the criteria set during planning. At the end of each sprint, the entire team should discuss what was accomplished as it compares to the criteria agreed upon with the Product Manager and make necessary process adjustments.

Planning Meetings:

Planning & Deep Dive Meetings are bi-weekly meetings attended by the team at the start of a sprint. During the planning meeting, the team identifies and prioritizes tasks that are to be completed for the two-week sprint. Tasks that will be worked on in the current sprint are to be represented on the Current Sprint board. Topics that needs further strategizing are also explored during this meetings. With excess time the team will schedule Demos to share prototypes and demonstrate what was build during the last sprint.

"Needs Discussion" Meetings:

The team is refining tasks or upcoming work together weekly. You might call this a sort of Backlog refinement meeting. It gives us the opportunity to discuss topics that matter to us to deliver on our current work.

Retrospective Meetings:

Retrospective Meetings (retros) are bi-weekly meetings attended by the team at the end of each sprint. During Retrospectives, the team revisits action items from the last retrospective and reflects on the two-week sprint by collectively answering the following:

• Did we meet our acceptance criteria?
• What have we accomplished?
• What worked?
• What could we improve next time?
• What was confusing?

Action items will be captured during the meeting and due dates and action owners will be assigned.

Google Calendar:

New members of the team will be added to the Editing team calendar. If a team member will be out of the office for four or more hours during a working day, they are to share it on the team calendar at the earliest indicator that they may be out. This practice will help the team manage expectations when estimating what work can get accomplished during planning. Team ceremonies will also be represented on the Google Calendar.

Gerrit:

The Editing team uses Gerrit, a code collaboration tool, for peer code review.  

Phabricator:

Phabricator is the organization’s task/issue tracking tool that houses the Editing team’s user stories, tasks, progress and prioritization of work.

• our Kanban board
• our backlogs for VisualEditor, DiscussionTools, EditCheck