In the Wikimedia wikis, right now, we succeed to a varied degree at
letting communities know about deployments that affect them. We're
definitely getting better, and the 1.20wmf1 page is an example of
release notes done well:
http://www.mediawiki.org/wiki/MediaWiki_1.20/wmf1
http://www.mediawiki.org/wiki/MediaWiki_1.20/wmf1/overview
A concise summary with translations in multiple languages, followed by
a detailed list compiled from manually collected and curated commit
summaries. Nifty. And so much work that it's unlikely to be
sustainable. Indeed with wmf2 we're already taking shortcuts:
http://www.mediawiki.org/wiki/MediaWiki_1.20/wmf2
No translations, no overview, less curation. And let's keep in mind
that this covers only the "regular two week cycle" deployment -- major
changes deployed between cycles aren't covered in either of those
summaries.
So how can we do better? I'd posit that it should be impossible to
deploy code without leaving an exposed audit trail generated from
commit messages, which can in turn be expanded by any interested
volunteer into a human-readable and translated summary.
I'd suggest exposing this information to a special page directly in
the relevant wiki, say "Special:SiteChanges". This special page would
show an automatically generated summary like so:
<example>
== Wednesday May 2, 19:03 ==
(2 hours ago)
'''[[mw:WMF deployments/345|Write or translate a deployment
summary]]'''
Deployment 345 completed. The following changes are now running on this wiki.
=== In core ===
* ca7eb5c - Removed intval for undelete reason in API - ''committed by
Petr Onderka''
* 5813680 - Few documentation/type hint updates - ''committed by Reedy''
* e22a369 - Prevent sidebar links from jumping on page load -
''committed by Trevor Parscal'
...
=== In extension FlaggedRevs ===
* ce146dc - Fixing up LSB related stuff.. Some code duplication, but
meh for the moment (yay for us using static classes for hooks)
=== In extension DynamicPageList ===
..
== Tuesday, May 1, 15:01 ==
(1 day ago)
...
</example>
I leave it up to your imagination whether the summary would be
generated from the git repo the wiki resides in (in combination with a
deployment log), or pulled from
MediaWiki.org, some combination
thereof, or some other implementation strategy. Suffice it to say that
we'd ideally want to:
* Ensure that the process of recording this information is an
automated part of deploying code updates
* Filter extensions from the Special:SiteChanges summary that are not
actually activated
* Notice when new extensions are activated that were not active in a
previous state
* Enable anyone to write deployment summaries on
MediaWiki.org
* Enable anyone to translate those summaries
* Load an existing summary in the correct language on Special:SiteChanges
In the magical database backed configuration future,
Special:SiteChanges might also be able to list out config changes, but
that seems far fetched right now
In the equally magical "notifications for everything" future, users
would be able to opt into getting notified whenever a deployment
occurs.
But keeping it at a base level of functionality, does this seem like a
feasible and desirable change? Like I said, I worry about our ability
to keep up without automating this whole process, so IMO it would be
good to incrementally start building out this functionality. Otherwise
we're constantly fighting an uphill battle to ensure information gets
disseminated in a consistent fashion. But it's possible I'm
overlooking major issues that would make this too difficult to be
worthwhile.
All best,
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge:
https://wikimediafoundation.org/wiki/Donate