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
As part of the pre flight steps the mobile team generates a list of gerrit changes that have gone into the deployment branch. We then throw it on a wiki page so that its much easier to trace back what changed. Our current list is here
http://www.mediawiki.org/wiki/Extension:MobileFrontend/Deployments
Formatting aside its become really useful to know exactly what's going out without having to hound each developer about their changes.
This combined with Special:SiteChanges would be great in the glorious future.
--tomasz
On Wed, May 2, 2012 at 8:04 PM, Erik Moeller erik@wikimedia.org wrote:
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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2012/5/3 Erik Moeller erik@wikimedia.org:
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:
Yes, yes, please. :D This would be a big step forward.
Strainu
This combined with Special:SiteChanges would be great in the glorious
future.
+1. It would indeed be a good step in the right direction.
Alolita
On Thu, May 3, 2012 at 8:18 AM, Strainu strainu10@gmail.com wrote:
2012/5/3 Erik Moeller erik@wikimedia.org:
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:
Yes, yes, please. :D This would be a big step forward.
Strainu
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, May 3, 2012 at 12:04 AM, Erik Moeller erik@wikimedia.org wrote:
I'd suggest exposing this information to a special page directly in the relevant wiki, say "Special:SiteChanges".
+1
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
On Portuguese Wikibooks we kept a history of configuration changes which affected our project: https://pt.wikibooks.org/wiki/Wikilivros:Hist%C3%B3rico_de_configura%C3%A7%C... If we could have some consistent way to tag bugzilla tickets which are related to a given wiki (is it possible to add new fields for project/lang?), then a table like that could be generated by a script eliminating the need to do manual updates. Such a script would likely use bugzilla API as in https://en.wikipedia.org/wiki/MediaWiki:Gadget-BugStatusUpdate.js (which works on pages where https://en.wikipedia.org/wiki/Template:Tracked is used).
Best regards, Helder
wikitech-l@lists.wikimedia.org