Hi everyone,
This mail is primarily directed toward Wikimedia Foundation employees, but isn't private, so I'm directing it here.
As many of you know, we have a policy for Wikimedia Foundation engineers that states that they need to work 20% of their time on maintenance and communication tasks which immediately serve the Wikimedia developer and user community, beyond working on assigned features or longer-term work.[1] Managing how that manifests itself is the responsibility of Platform Engineering, which is why I'm the one frequently prattling on about it. :-)
Up until last week or so, this wasn't too tough an activity to coordinate. Code review was in pretty rough shape, so my frequent advice was "grab a bucket and bail" (as in, start reviewing whatever is in the queue).
As the 1.19 deployment starts up next week, coordination is both more important and harder. We're shifting our focus away from code review, and onto fixing blockers and fixmes. Even before recent times, there have been some folks at WMF who have felt a little adrift during their 20% time.
So, starting this week, we're instituting explicit 15 minute meeting times for the beginning of everyone's review 20% period, on the #wikimedia-dev Freenode channel. The schedule for these is listed below: https://www.mediawiki.org/wiki/20_percent#IRC_checkins
Those of you who noticed me drop this on your calendar last week, and wondered what this was...well, now you know.
I've tried to schedule these such that they happen as close to the beginning of everyone's shifts as possible, without having them at times that are crazy for anyone. That's going to let us coordinate on the particulars of what everyone will be working on reasonably close to the time that they'll be doing the work.
Right now, the focus of these is going to be on the 1.19 deployment, mainly around ensuring we get all of the fixmes and blockers figured out before the rollout begins. However, even after the dust settles on 1.19, I think we'll still need this level of coordination to start managing the flow of Git pull requests, making real progress on our backlog of patches in Bugzilla, and making progress on resolving the 7000 or so open bugs in Bugzilla. We have a lot of work to get done, and this 20% is going to be a key part of making it happen.
Rob