Readers/Software Engineer onboarding

This page documents the standard team onboarding of new hires in the Wikimedia Product Engineering unit dubbed "OMNI Engineering" (known colloquially as "Readers Engineering").

When onboarding new personnel, copy this to a Google Doc a couple business days before the new hire starts, then on the new hire's start day +mention the appropriate individuals in the "Team member onboarding support" section via the Google Docs comment feature.

OMNI Onboarding
Welcome 👋. There's a lot of information here, so it's broken down into three waves to help with pacing. Take your time as you're going through it all. If you have any questions, don't hesitate to reach out to any of your colleagues, we're here to help. Your onboarding buddy will help guide you along the way, too.

First wave

 * Set up Slack, and join any team channel(s) that may be applicable (and some general-interest ones if you like).
 * Set up IRC. Attach an IRC cloak. If you don't already have an IRC client, consider using IRCCloud, a web-based client popular among Foundation staff.
 * Become a MediaWiki hacker and verify access to Gerrit using your Wikitech LDAP account.
 * Get access to our GitHub Organization at https://github.com/wikimedia. Confirm which username you’d like added to the Wikimedia organization
 * Create a Wikitech LDAP account. Commonly, the username you use is your internet handle (i.e., not a (WMF) username), but you will want to use your @wikimedia.org email address.
 * Verify that you can log into Phabricator with your Wikitech LDAP account. If you run into any issues, refer to this help document. See generally Phabricator for more documentation and tips.
 * Ask a teammate for links to pertinent Phabricator boards.
 * Read the guide for new hires, including the guide for new engineering staff.
 * Review our guide to the various Wikimedia wikis.
 * Verify access to OfficeWiki (separate account), and Wikipedia / MediaWiki.org (same account via your (WMF) Single User Login account).
 * Write up an introduction email for yourself written in the first or third person, and send it to your manager for review, so your manager can share on the internal Product wide mailing list and share on the Slack announcement channel for new hire activity.
 * Arrange for a staff photo, and then add yourself to the org chart on OfficeWiki.
 * Sit back and enjoy reading some code. Then ask a colleague to pair program on your first simple patch.

Second wave

 * Request access to the group ldap/wmf, adding your manager to the access request task for approval. This group gives you more code review approval rights in the system as well as access to myriad different tools and services


 * Read about the Movement Strategy.
 * Read the Medium Term Plan.
 * Read the WMF annual plan for FY 2019-2020 (July 2019 - June 2020)
 * Review the latest Tuning Session from Product on OfficeWiki (if one happened recently but isn't available yet ask a colleague for a link).
 * Subscribe to the following lists on https://lists.wikimedia.org/ with your Wikimedia email address.
 * wikitech-l - Default list for tech discussions on Wikimedia and MediaWiki software.
 * mediawiki-api and mediawiki-api-announce - Lists about internet facing APIs.
 * analytics - List about analytics.
 * ops - tech ops mailing list covering matters of deployment.
 * cloud-announce - Wikimedia Cloud Services (WCS) announcements, useful as you’re bound to use access to WCS or will need to be aware of service maintenance.
 * mobile-l - This is a low traffic list now, but is for mobile-related topics, often associated with OMNI.
 * Read Debugging Teams: Better Productivity through Collaboration (Brian W. Fitzpatrick and Ben Collins-Sussman)
 * Start on making 50 edits on a broad range of user agents, form factors, network conditions, etc. - MediaWiki.org and OfficeWiki are simplest for your work account. Remember, if you make personal edits on project wikis with any non-work username those are your personal edits. Some help: Help:Wiki markup, Help:Wikitext examples
 * View the data training modules.
 * Be aware of component responsibilities.

Web team specific items
Web team onboarding

Product Infrastructure team specific items
Product Infrastructure team onboarding

Required for some
Verify with your manager which of these apply to you:


 * Request access to one of the data access groups. Consult your manager to figure out the appropriate group(s) and add them to the access request task for approval. This will allow you to access analytics data. Ensure that you have also read the data access guidelines.
 * Apply for beta cluster event logging access for debugging analytics data submission.
 * Request access to OTRS, our system for customer support requests, first by "signing" L45, and then by emailing [mailto:otrs-admins@lists.wikimedia.org otrs-admins@lists.wikimedia.org].
 * If you will be doing deployment related work (typically, for web engineering and content services), request "deployment access and operational logs access" when following the steps for shell access.

Third wave (recommended)

 * Set meetings with product managers and product owners: Web (Olga V), iOS (Josh M), Android (Charlotte G), Structured Data (Ramsey I), Parsing (Subbu S), Product Infrastructure.
 * Set one time meetings with all OMNI engineering engineers and managers to say hi - one every other day is a good tempo.
 * Scan the English Wikipedia Village Pumps and Commons Village Pump and other equivalents if you know other languages.
 * Review recent quarterly tuning session decks for Product.

If you like

 * In Gmail, enable Settings > General (tab) > Undo Send and change the timeout to 30 seconds and press Save Change.
 * Read some blog posts, like Why it took a long time to build that tiny link preview on Wikipedia.
 * Watch this video of Joel Spolsky at Wikimedia
 * Read The Wikipedia Revolution

Calendar
Mark your working hours and blocked off parts of the day in Google Calendar.

Out of office

 * 1) Verify the dates you'll be out with your team and your manager.
 * 2) Request time off in the HRIS.
 * 3) Make an out of office event on your personal calendar that spans the time you'll be out as Busy. Ensure "Automatically decline new and existing meetings" is checked (alternatively, decline manually with a reason).
 * 4) Make an event on your team calendar indicating you'll be out. Ensure "All-day" is checked and have it span all days you'll be out.
 * 5) Set your Gmail vacation responder with a message that indicates that you're out of office, when you'll return, and contact information of your delegate(s) for urgent issues regarding your work. Ensure that "Only send a response to people in Wikimedia Foundation" is checked.

Team member onboarding support

 * Technical Program Manager:
 * With admin, add to relevant calendar invites: Standup, Weekly meetings, etc.
 * Add to relevant team page on MediaWiki.org
 * Explain team development cycle, project management tools, Phabricator workflow, and meeting scheduling (checking individual calendars and room availability, etc.)
 * Product Manager:
 * Introduce to team members who haven't met new software engineer
 * Product overview
 * Testing overview - in house and Specialists Guild
 * Wikimedia project overview - what are our projects and who uses them
 * Director:
 * Discuss career development and open lines of communication, first six months, privacy/security principles and techniques, email/chat clients/calendar productivity tips
 * Manager:
 * Notify team members with actions to review actions here
 * Ask Engineering Admin to add to product-all, plus the following calendars: "WMF Engineering", and if in San Francisco "WMF Fun & Learning".
 * Confirm with hire that the hire can access the "WMF Staff Calendar", as access is customarily granted behind the scenes as part of the general onboarding process
 * Setup on team internal and role specific list(s)
 * Design:
 * UX / Design overview
 * Design research overview
 * Tech Lead or Onboarding Buddy:
 * Explore Gerrit workflow. Review Gerrit tutorial. Install git-review, unless you like raw git commands.
 * Suggest appropriate Gerrit review group(s).
 * Explore GitHub workflow.
 * Review internet facing APIs
 * Guide through setup of Vagrant and Docker
 * Explain MobileFrontend (Web tech lead should explain)
 * Explain RESTBase services for apps (Mobile Content Service / Page Content Service engineering point of contact)