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;
 * Organize the content in highlights and short news;
 * 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 you are using Etherpad, comment out the whole wiki page and add a link to the etherpad.

Immediately before publication

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

Date

 * 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).

Porting the report to WordPress
where blogfix.py is:
 * Open the printable version of the wiki page;
 * Copy the relevant HTML for the content you want to publish (i.e. leave all the sidebar navigation and other stuff);
 * Remove the table of content (everything between  and  at the beginning);
 * Pass it through the python cleanup script:
 * 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.
 * Send a heads-up to wikitech-l containing a link to the report;
 * Tweet & dent about the report (and push to the !wikimedia group on identi.ca);
 * 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;
 * 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.