Thanks Greg for the overview. 0–4 is fine, but there a couple premises I
question, which trigger a couple considerations/conjectures which may be
of use.
First, let's not call the wmfXX subpages "release notes". They just are
lists of commits. As you noted, they are also created – by design – too
late for them to have any substantial content before the commits are
deployed, not to speak of being read. Sometimes we (we = whoever
happens) managed to get some more information and Wikimedia-specific
warnings on them, just because they are the WMF-only pages and there
wasn't any other place: but that's not what they're designed for.
Moreover, after this there's still nobody tasked with more targeted and
actual communication of their content. It's an error in perspective to
think that those pages naturally have or will have the information and
role you attribute them.
Second, "There are a lot of changes and I'm unfamiliar with
about 100% of them": this is true for all MediaWiki developers and users
and it's why release notes exist in the first place. :) If you rely on a
hour of asking and poking, 1) you're likely to miss something (example:
the only person who knows the real implications of commit Y is sleeping
in another timezone) hence nobody will rely on this system, 2) you don't
share this information with third party users.
Approaching my conclusion: perhaps you need to focus on ensuring that
relevant information is added to the RELEASE-NOTES-* files at the time
of commit, or before deployment if the system fails and they were not
before. This is a shared effort across the board for all devs, but a
dev, and especially a volunteer dev, should not *have to* do more than
this. Related discussion:
<https://www.mediawiki.org/wiki/Thread:Manual_talk:Coding_conventions/Release_notes_and_bug_fixes>.
If we have reliable release notes, it's easier for the release manager
to distil important communication from them; if they're also timely,
more eyeballs will be on them to fill the occasional gap in
understanding. Where and how the WMF wants to put this distillation, is
another matter; it also depends on how WMF wants to handle WMF-specific
deploy-sensitive stuff (the "scaptrap without CR tags" problem mentioned
earlier): so, yes, IMHO there must be one person responsible of this at WMF.
Finally: once problems in steps 0–4 are fixed, the 5th can really have
the premise "There is now a reasonably good
list of important changes" and in the process you've also learnt who is
affected and what needs doing (flip switch A, notify set of wikis X
about B, write blog post Y two weeks before C, set up central notice or
magic WMF-users mind-reading tool Z a month before D).
Nemo
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
