Wikimedia Engineering/Report

Style

 * 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

 * Discuss with EPMs regularly (possibly during their daily status meeting) to be kept in the loop about what's happening in engineering.
 * When a new project is started, create a new stub project page using the page template, and ask the EPM to add details.
 * Make sure the project pages are kept up-to-date;
 * Maintain the "Events" and "Personnel" sections:
 * When a new engineering staff is announced, add them to the draft report page. You might also want to add them to the Wikimedia Foundation contractors list on meta, since it's not maintained by HR;
 * Follow the job openings template.

Last week of the month

 * Send a breakdown of missing information and FIXMEs to the EPMs;
 * Clean up and copyedit the draft;
 * Check all links;
 * Add an introduction summarizing the main accomplishments;
 * Nag the EPMs repeatedly until they add the missing pieces;
 * Organize the monthly report review session with all the EPMs. When using Etherpad, comment out the whole wiki page and add a link to the etherpad.

Fill out the Metrics box

 * Ohloh provides committer stats for the last 30 days.
 * The Code review stats tool used to provide the number of commits reviewed over the time period ("newly reviewed") and yet unreviewed commits ("new"). For now we need to query gerrit.
 * A bugzilla query provides the shell requests stats.
 * Sumana provides the number of new committers. They can also be approximated by counting the number of new accounts on labsconsole.
 * Ryan Lane provides the Labs stats.

Immediately before publication

 * Check one last time the Job openings on the Jobvite 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.

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
 * Add the footer (check the edit history of the wiki page for the actual list):

After publication
It's usually better to advertise the link to the blog post, rather than the wiki page, since people can easily comment on the blog post.
 * Update the [ Wikimedia engineering report/latest] redirect.
 * Send a heads-up to wikitech-l containing a link to the report;
 * Leave a note on the Signpost's Newsroom page, in the Technology section;
 * Add the report to the Reports and 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.

Monthly Foundation reports
The monthly Foundation reports include activities from all Foundation departments, including engineering.
 * Select key activities from the engineering report.
 * Be bold in summarizing the status updates, and in grouping similar activities.
 * Remove the project descriptions.
 * 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 Dana for the link to the etherpad.

Set up the next report

 * Create a page for the next report, using the previous report as template. Comment out the previous statuses.