Core Platform Team/tr

Bu ekip, Wikimedia Taşımacılık projelerini destekleyen Platform için birincil sorumluluğa sahiptir. Platform, MediaWiki ve hizmetlerimizi, API'lerimizi ve araçlarımızı sağlayan Wikimedia hizmet altyapısından oluşur. Ekip ayrıca, çeşitli bağlamlarda bilgiyi barındırmak ve paylaşmak için 3. taraflarca kullanılacak bir FLOSS ürünü olarak MediaWiki'yi destekler. Bu ekip, Temmuz 2018'de MediaWiki Platform ekibi ve Hizmetler ekibini birleştirerek oluşturuldu.

Core Platform Leading the maintenance and improvement of the MediaWiki platform and Wikimedia service infrastructure Group: Platform Engineering Start: 2018-07-01 End: 2020-07-01 Team members: Clara Andrew-Wani, Kate Chapman, Cindy Cicalese, Will Doran, Eric Evans, Daniel Kinzler, Holger Knust, Mandy Mooney, Alex Paskulin,Petr Pchelko, Bill Pirkle, Tim Starling, Hugh Nowlan, Nikki Nikkhoui, Naïké Nembetwa Nzali, Mat Nadrofsky, Gabriele Modena Backlog: #Platform_Engineering Lead: Corey Floyd ← MediaWiki Platform team & Wikimedia Services

Mission

We shepherd Wikimedia’s essential software and infrastructure technologies enabling our users and developers to unlock free knowledge.

Our values and how we model them in our work

Knowledge sharing

1. We continually learn and hone our skills to apply the best solutions to challenges
2. When learning something new, we aim to share it with both within and outside the team and encourage others to do the same
3. We proactively share our knowledge, collaboratively work on solutions, and provide mentoring whenever we can
4. We prefer to aid others in achieving their goals, rather than solving problems for them. This both empowers them and makes our team and organization stronger
5. We actively and frequently talk to our teammates about their work and challenges over simply asking them if they need help.

Clear and respectful communication

1. We ensure all voices are heard in discussions by asking the opinions of others who have not spoken up.
2. We give detailed code reviews and try to communicate the “why” as well as the “what”.
3. When we offer criticisms, we also offer help and assistance getting to a solution.
4. We volunteer our thoughts and perspectives while considering and respecting the thoughts and perspectives of others
5. When we offer criticisms, we are careful to re-evaluate our own assumptions and are open to changing our minds.

Quality work

1. We strike a balance between constraints and long-term implications of our work
2. We follow the architecture principles whenever possible and be sure to communicate our rationale to others when we don’t
3. We focus on projects that deliver clear and measurable impacts
4. We use experiments to figure out new paths while minimizing risks in order to overcome challenges
5. We use our own products for our work whenever possible in order to better understand and improve our software.
6. We do not hold ourselves to perfection, but we do establish good metrics of success that allow us space to experiment while minimizing risks
7. We keep the codebase clean and hold others accountable to do the same in order to minimize tech debt.

Effective and Inclusive Collaboration

1. We take time to get input from team members on decisions that affect them.
2. We always try to finish what we are working on before starting something new.
3. We try to solve problems ourselves first because we value the time of our teammates, but we don’t wait too long before asking someone else because we also value our own time.
4. We make an effort to promptly respond to messages so to not block other team members.
5. We keep our code reviews focused on facilitating merging, minimizing feedback that are not required for the code’s goal and provide actionable comments
6. We collaboratively support other teams’ goals by proactively asking them for their needs and requirements and providing them timely responses and concrete decisions and feedback.
7. We keep our priorities clear and work on what is most important.
8. We give people the space, opportunity and trust to grow, even if it means the most skilled person isn’t working on a task.

Goals

• To lead the maintenance and improvement of the MediaWiki platform.
• To assist and encourage feature development on top of MediaWiki by providing developers with a clean and elegant core.
• To provide value for end users by undertaking feature development work which is primarily architectural in nature.
• To create and publish a MediaWiki roadmap to assist planning of internal and external users.
• To establish guidelines and standards for the MediaWiki core code.
• To automate monitoring, metric reporting and logging for Wikimedia services.
• To keep the majority of services simple and stateless by offering general multi-datacenter storage and change propagation solutions.
• To make our infrastructure more flexible, robust and efficient by gradually migrating from a monolithic architecture to micro-services.

Work for this quarter

• Image Recommendation - Bill, Clara, Nikki and Gabriele
• Expedition - Daniel, Petr and Cindy
• Clinic Duty - Ariel, Holger + 10% for Tim and 15% for Bill
• Purple Team: MW on K8's - Tim + 5% for Bill
• Matrixed to Product Infrastructure for maps - Hugh
• Matrixed to Architecture - Eric
• Matrixed to SDAW - Cindy (2 hrs per week for 1 to 2 months)

Roadmap

An updated list of projects we're working on is visible in Phabricator on the Platform Engineering Roadmap.

PET Work Processes

Our pipeline

Stewardship Acceptance Criteria Form

Code Stewards are ultimately responsible for the development policies, support, and overall health of the code in question. Despite this responsibility, Code Stewards are not expected to do all the work themselves, instead they should engage with staff and volunteer technical contributors in the collaborative effort. Click here to complete our form

Defining a vocabulary

In order to have the common vocabulary when discussing our work, we have adopted the Agile framework developed by Atlassian. When planning our work, we use the words ”Initiatives”, “Epics”, “User Stories”, and “Tasks” from their framework to describe size and type of work we plan and perform on the team. In this system, we breakdown the MTP Key Deliverables into our Initiatives. In this way we keep a direct link between our internal team system and how work is tracked within the organization

Platform Engineering Team Initiatives

The Platform Engineering Team work process involves a number of stages that derive from the PET Roadmap, which maps at a high level the layout of all initiatives that the PET is responsible to complete or support. Initiatives are drawn from the PET Roadmap and entered into PET Initiative Planning. The Director, Senior Project Manager, Product Managers, Engineering Managers and Technical Leads are responsible for the work of developing the initial outline to a full proposal decomposed into Epics and Tasks ready to be scheduled and implement by Engineers.

All PET Initiatives are published and updated through out planning and implementation on our wiki.

The PET is composed of 2 functional teams specialising in Distributed System and Storage, and Features, Data and Content. Within PET we break down into 3 core teams, 2 teams focused on product work and 1 Clinic Duty Team. Our work process is agile based using 2 week sprints. The content of the sprints is determined in pre-sprint planning. Product teams are formed based on the functional requirements of the projects to be undertaken while the Clinic Duty team is rotated on a sprint by sprint basis.

Supporting WMF Teams

For work that is inbound to the PET from WMF teams or external volunteers, our goal is to participate early in projects where we are a dependency or have a supporting role in order to ensure that we can integrate this work into our ongoing planning and provide others with consistent, predictable timelines for when work can be accomplished.

For Unbreak Now, reactive work and external code reviews, the Clinic Duty Team is designed to provide ongoing triaging and handling of inbound tasks as well as working on code health, maintenance and improvements.

 Note: Tasks that are Unbreak Now(UBN) or reactive should be tagged with #platform-engineering, they will then be picked up by our triage process and scheduled

Inbound work is managed by our Task Triage process, which evaluates the task and routes it appropriately depending priority and content.

Matrixing

To provide targeted support for other teams, deepen cross collaboration, as well as knowledge sharing the Platform Engineering team is set up to matrix Engineers for fixed timeboxes. This work is most effective early in a project life cycle ideally at or before project design.

The process for requesting this type of support is via our intake process.

Design Documents

Platform Design Doc Template

Individual Goals

Members of our team set goals each quarter in order to support other team members and their own professional development.

Goals

Metrics

Clinic Duty Stats

Workboards

• #platform-engineering
  • This board contains our Inbox and a set of columns identifying the Initiatives we are working on and the prioritized tasks of work to complete each
• #platform-team-workboards
  • This board contains the PET Icebox and each of our sub team work boards
    • #sf-contract, our contractor workboard
    • #cpt-clinic, our Clinic Duty Team workboard
    • #cpt-prod-green, Product Team
    • #cpt-prod-arch-review, Architecture Team

Contact the team

Contact the team:

• wikitech-l mailing list
• #wikimedia-services IRC channel
• #mediawiki-core IRC channel

Past Programs

The Platform Team is currently supporting the following programs:

• TEC1: Reliability, Performance, and Maintenance
• TEC2: Modern Event Platform
• TEC13: Code Health
• CDP2: Platform Evolution (see also: Platform Evolution)
• CDP4: Structured Data Program