Wikimedia Engineering/Report

Style guidelines

 * Use a matter-of-fact tone, to be consistent with the rest of the document.
 * Use the simple past consistently; avoid too much projection in the future. We're reporting on what you did, not what you are or will be doing.
 * The report is long and includes a lot of different materials; be succinct.
 * Give credit where appropriate. "We" is vague; instead, name your team members and their accomplishments. It's clearer for the audience, and more gratifying for your team.
 * Avoid buzzwords and peacock words (see the English Wikipedia's full list of words to watch)

Over the month

 * When personnel changes are made, add them to the draft report page, along with a link to the public announcement.

Second-to-last week of the month

 * Update the list of projects based on projects listed as "Current" on the team hubs (Wikimedia Features engineering, Wikimedia Mobile engineering, Wikimedia Platform Engineering and Wikimedia Language engineering);
 * Send an e-mail to engineering@ and contractors you know about (i.e. Wikidata people, Offline people, Wikia people) asking for status updates, and give a deadline.

Last week of the month

 * Clean up and copyedit the draft;
 * Check all links;
 * Add an introduction summarizing the main accomplishments, by listing what was featured on the Wikimedia tech blog.
 * Check that "Priority activities" have status updates. As of February 2013, those activities (and people to nag if statuses are missing) are: VisualEditor & Parsoid (James Forrester), Editor Engagement (Fabrice Florin & Terry Chay), Editor engagement experiments (Steven Walling), and Mobile (Tomasz Finc & Maryana Pinchuk)

Fill out the Metrics box

 * For committer stats for the last 30 days, follow instructions in this wikitech-l post.
 * Or,   with the username and date changed.  The   means 'exclude patches that have not been touched in the last 40 days', which casts too wide a net, but then filtering for   restricts it to whatever month it was 27 days ago according to your local machine. (so it expands to something like  ) Then subtract 1 to account for L10n-bot.
 * A bugzilla query (update the date parameters) provides the shell requests stats.
 * Ryan Lane provides the Labs stats.

Immediately before publication

 * Check one last time the Job openings on the WMF website to make sure they're all listed, and expired openings have been removed;
 * Read the whole post carefully one last time, paying attention to grammar, spelling & typography;
 * Check all links one last time.

Plain English summary
Plain English summaries are mostly written for inclusion into the monthly Foundation reports, which include activities from all Foundation departments, including engineering. They focus on "Priority activities" and mention in passing other accomplishments, especially if they were featured on the Tech blog.


 * Create one section for each Priority activity: VisualEditor (including Parsoid), Editor engagement (including experiments), and Mobile. It's also fine to include noteworthy work in other areas, possibly in a fourth section.
 * Rewrite the monthly statuses for these areas by removing jargon and being extremely thorough in explaining technical terms;
 * Only keep the most relevant and useful links; remove links to user pages.
 * Tweak links so they work from meta (e.g. add the  prefix for pages hosted on mediawiki.org).
 * Add the summary to the etherpad containing the draft of the WMF monthly report; If necessary, ask Tilman for the link to the etherpad.
 * Make the page translatable.

Publication

 * Check the Communications calendar to avoid any major conflict with another announcement;
 * Aim for the middle of the week, as this gives the Signpost editors enough time to incorporate our items in their weekly issue (traditionally published on Mondays).
 * Port the report to WordPress, using the Python script at m:Wikimedia Blog/Converting wiki pages to blog posts. Then:
 * Remove the TOC
 * Remove the status edit links (the spans starting with ). A newer version of the script does this automatically.
 * Remove the upcoming events.
 * Add the colored frames around each subdepartment's section to make them more distinguishable visually. (They can be found in previous reports in WordPress.)
 * Using the more feature in the WordPress editor, add a break (e.g.) after the "Major news" intro
 * Add the footer (update the link):

After publication

 * Update the [ latest report] and [ latest summary] redirects.
 * Send a heads-up to wikitech-l and wikimediaannounce-l containing a link to the report, and the text of the report in the email's body;
 * Do the same with the report's summary to wikitech-ambassadors;
 * Leave a note on the Signpost's Newsroom page, in the Technology section;
 * Add the report to the Reports and Wikimedia Foundation reports pages on meta, in the Technology section;
 * Add the report to the Foundation wiki's main page: foundation:Template:Reports-en;
 * Review comments as they arrive, and if necessary ping the appropriate people to respond.

Set up the next report

 * Create a page for the next report, using the previous report as template. Update the date for status transclusion, and comment out previous statuses if they weren't transcluded.