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 _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l