Who is responsible for communicating changes in MediaWiki to WMF sites?

List overview All Threads
Download

newer

older

[RFC] performance standards for...

Cannot run the maintenance script

Niklas Laxström

21 Mar 2013 21 Mar '13

10:55 a.m.

I've seen a couple of instances where changes to MediaWiki are blocked until someone informs the community. Someone is a volunteer. Community is actually just the Wikimedia project communities. Or at least the biggest ones which are expected to complain and where the complaining would hurt. This situation seems completely unfair to me. WMF should be able to communicate upcoming changes itself, not throw it to volunteers. Volunteers can help, but they should not be responsible for this to happen. -Niklas -- Niklas Laxström

Show replies by date

Platonides

21 Mar 21 Mar

5:28 p.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

Is sending an email to wikitech-ambassadors enough for unblocking it? Although such should contain a timeframe expectation, which probably only WMF can give.

Quim Gil

5:43 p.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

On 03/21/2013 02:55 AM, Niklas Laxström wrote:

...

Can you point to the changes blocked, or to anything that would give a better idea to those of us that don't know what are the cases you are talking about? I agree with the principle, but without more details it is difficult to help fixing the problem. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

Paul Selitskas

7:05 p.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

Example: We are running a fix in category sorting collations. That was a fix for the bug (introduced by developers, 3rd party software, whatever), not an enhancement. Anyway, notifying the community and its approval was requested. On Thursday, March 21, 2013, Quim Gil <qgil(a)wikimedia.org> wrote:

...

On 03/21/2013 02:55 AM, Niklas Laxström wrote:

Can you point to the changes blocked, or to anything that would give a

better idea to those of us that don't know what are the cases you are talking about?

...

I agree with the principle, but without more details it is difficult to

help fixing the problem.

...

-- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects

Tyler Romeo

7:07 p.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

Brian Wolff

7:13 p.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

On 2013-03-21 3:08 PM, "Tyler Romeo" <tylerromeo(a)gmail.com> wrote:

...

Well, as part of the community and a volunteer, I can safely say that I don't think I (or anybody else) needs notification before bug fixes. :P *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo(a)gmail.com _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

That depends on the bug. Some fixes do cause disruption. To pick a random clear cut example from a while ago - consider adding the token to the login api action. It was very important that got fixed, but it did cause disruption. -bawolff

Tyler Romeo

7:51 p.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

On Thu, Mar 21, 2013 at 2:13 PM, Brian Wolff <bawolff(a)gmail.com> wrote:

...

Oh yeah. Trust me. I know. Does anybody even remember the thread I sent out not too long ago? There were like three breaking changes applied to the core that would have caused fatal errors in my extensions. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo(a)gmail.com

Quim Gil

7:44 p.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

On 03/21/2013 11:05 AM, Paul Selitskas wrote:

...

Thank you, having examples helps. It is a good practice to notify stakeholders when fixing something might break or disrupt other things. Usually our bug tracking, code review and release/deployment processes should be enough to involve and notify in real time whoever needs to be warned or is likely to complain. If you need more, then there are at least 4 people that can help you. https://www.mediawiki.org/wiki/Wikimedia_Platform_Engineering#Engineering_C… If we are talking about bugs, then Andre Klapper aka bugmeister is a natural default. If anybody else needs to be involved he will know. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

Isarra Yos

7:48 p.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

Another example would be changing default options in core - recently I tried to push for making the enhanced recentchanges the default, but one of the blockers was that I'd need to let the Wikimedia communities know as the change would be applied there as well. Unfortunately I didn't have any idea when such a change could or would be merged or deployed, so not only did I not have any timeframe to give said the communities, I didn't even know when it would be appropriate to tell them (if it happens months later, mentioning now would not be very helpful) - or even if it ever would really happen at all. As it was the change just sat in gerrit for a month before James Forrester agreed to merge it. In this case it turns out there was another problem and now we're waiting on the wikidata folks to resolve that issue (namely that the enhanced recentchanges code kind of sucks), but the point is in many cases there is just no way volunteers can even know if something will actually be merged, let alone the timeframe, and thus expecting us to inform folks in these circumstances is a little ridiculous in general. Don't get me wrong, I'd personally be happy to let folks know of such changes, but given how utterly unreliable the review process can be for changes coming from volunteers, it's just not a reasonable expectation. On 21/03/13 16:43, Quim Gil wrote:

...

On 03/21/2013 02:55 AM, Niklas Laxström wrote:

-- -— Isarra

Quim Gil

8:15 p.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

On 03/21/2013 11:48 AM, Isarra Yos wrote:

...

Unfortunately I didn't have any idea when such a change could or would be merged or deployed, so not only did I not have any timeframe to give said the communities, I didn't even know when it would be appropriate to tell them (if it happens months later, mentioning now would not be very helpful) - or even if it ever would really happen at all.

This is so clear that anybody will understand it. I believe mentioning potential problems when you see them coming is always helpful. Do it in the related bug report and share the URL with the affected parties e.g. at wikitech-ambassadors. Invite them to follow the bug to have the same information than you, at the same time than you, with the same chances of giving feedback and participating than you. Ideally, by the time a deployment date can be decided they will be the ones communicating with their own communities. Otherwise you can simply go and say "Remember what we told you (link)? Ok, it's coming now." -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

Isarra Yos

8:49 p.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

On 21/03/13 19:15, Quim Gil wrote:

...

On 03/21/2013 11:48 AM, Isarra Yos wrote:

You speak of an ideal world, which this is not. Those most affected by these things generally do not use bugzilla at all (it's not just an extra hassle, but given the peculiar login system it uses, many wikimedians have incentive to not even try), so linking the bug won't help. For that matter, do you have any idea how *many* random proposals like this people come up with? Of those that make it to bugzilla at all, only some go through, most don't. And those that do can take months, if not years, to actually be implemented/merged - even after implementation, changes can and often sit in gerrit for months with no indication of progress, even the most trivial things. So it seems frankly ridiculous to me to suggest effectively going around announcing to folks that 'hey, some things may change sometime this year, but then again they may not, but in the meantime you can go to this strange site that doesn't accept your login and follow its massive forms and disorganised comments!' when instead we could just... I dunno, maybe get more staff and other folks who have merge rights to help work out a real timeframe (or even if it is likely to get merged at all) before expecting *anyone* to announce the matter, then announce something more concrete. (Which would be good because communities tend to be more receptive to that - give them a timeframe, and they'll speak their minds. Give them something vague and it just teaches them to ignore it, since who knows if it'll ever actually be a thing.) Alternately maybe we could just not expect the volunteers to announce these themselves in the first place like Niklas suggested, since on top of everything else he mentioned, said volunteers tend to lack some key details, along with access to the usual announcement methods in the first place. -- -— Isarra

Federico Leva (Nemo)

10:12 p.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

Quim, you seem to be answering the question "how does one communicate changes", but the question of this thread is "who is responsible" for doing so. It's quite a difference. Usually volunteers know the communities better and have less problems with the "how" than others, but that's not the point. Nemo

Quim Gil

11:11 p.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

On 03/21/2013 02:12 PM, Federico Leva (Nemo) wrote:

...

Quim, you seem to be answering the question "how does one communicate changes", but the question of this thread is "who is responsible" for doing so. It's quite a difference.

I don't think there is a single name for this responsibility. As it happens in so many tasks at the Wikimedia community. Andre Klapper and me should be good contact points for bugfixes and other "changes in MediaWiki" requiring communication beyond Bugzilla / Gerrit. Put us in CC or contact us directly. The sooner the better. We will take it from there. As for the current case(s?), Niklas or whoever else in the know: send us the URLs or the background so we can do something about it. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

Tim Starling

22 Mar 22 Mar

2:54 a.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

On 21/03/13 20:55, Niklas Laxström wrote:

...

I would assume that "do it yourself" is usually code for "we don't consider this deployment to be important enough to spend any time on it at the moment." Fair enough, volunteers don't have an automatic right to dictate other people's priorities, a fact which might need to be communicated with tact. Also, community managers generally see it as their responsibility to extract as much work from volunteers as possible, and will ask a volunteer to do something whether or not a WMF staff member would be more than happy to do it. -- Tim Starling

Sumana Harihareswara

5:26 p.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

On 03/21/2013 09:54 PM, Tim Starling wrote:

...

Also, community managers generally see it as their responsibility to extract as much work from volunteers as possible

The community managers for MediaWiki (Quim and me) don't think like this. If you believe we do, please say so. :-)

...

and will ask a volunteer to do something whether or not a WMF staff member would be more than happy to do it. -- Tim Starling

You're implying that we should always check whether there is a WMF staffer available and eager to do a particular task before asking a volunteer to help out. That would be impractical, and would prevent us from helping eager volunteers learn. However, that's separate from the question in *this* thread about who is and who ought to be responsible for managing and communicating about certain kinds of blockages. I'd say, as a first approximation: release managers for WMF and for MediaWiki (so, Greg & hexmode), and product managers, who are staff members and volunteers. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation

Tim Starling

25 Mar 25 Mar

3:27 a.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

On 23/03/13 03:26, Sumana Harihareswara wrote:

...

On 03/21/2013 09:54 PM, Tim Starling wrote:

Also, community managers generally see it as their responsibility to extract as much work from volunteers as possible

The community managers for MediaWiki (Quim and me) don't think like this. If you believe we do, please say so. :-)

Maybe I was mistaken, then. It seems like an excellent goal to me, I don't know why you're upset with the allegation.

...

and will ask a volunteer to do something whether or not a WMF staff member would be more than happy to do it. -- Tim Starling

You're implying that we should always check whether there is a WMF staffer available and eager to do a particular task before asking a volunteer to help out.

Not at all. I think you should try to extract as much work from volunteers as possible, and delegating all volunteer-driven tasks to staff members would undermine that. Not that it's up to me, of course.

...

That would be impractical, and would prevent us from helping eager volunteers learn.

I thought it was so obviously impractical that it wasn't necessary to say that it is impractical. My comments were aimed at encouraging broader direct contact between volunteers and staff. A roadblock can only happen on a one-dimensional surface. Nobody has all the information, and deployment policies created by an individual with respect to their own work are not globally enforceable. Maybe you can clear roadblocks by appointing someone "chief roadblock clearer", but I think encouraging some awareness of the broader landscape and the multiple people who are empowered to get things done would help volunteers to work around their own problems. -- Tim Starling

Rob Lanphier

8:06 p.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

On Sun, Mar 24, 2013 at 7:27 PM, Tim Starling <tstarling(a)wikimedia.org> wrote:

...

On 23/03/13 03:26, Sumana Harihareswara wrote:

On 03/21/2013 09:54 PM, Tim Starling wrote:

Also, community managers generally see it as their responsibility to extract as much work from volunteers as possible

The community managers for MediaWiki (Quim and me) don't think like this. If you believe we do, please say so. :-)

Maybe I was mistaken, then. It seems like an excellent goal to me, I don't know why you're upset with the allegation.

I think many of us bristle at the word "extract" to describe the work that the ECT does. Lemonade is extracted from lemons, leaving the sad little husk of a lemon behind, and that's the image the word "extract" conjures up. It implies a finite resource to be depleted of value, discarding what remains. A good volunteer manager will encourage mutually-beneficial activities, and build long-term relationships with contributors. If we can help volunteers achieve personal goals in addition to helping out the Wikimedia movement and/or the MediaWiki ecosystem, we will often try, because that attracts and retains volunteers, and because its The Right Thing To Do(tm). To Niklas's original point: sometimes, it makes sense to ask volunteer developers to notify the community of changes before they make those changes. Sometimes it makes sense for us to help. There is no blanket policy we can institute. Rob

Greg Grossmeier

22 Mar 22 Mar

10:56 p.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

Hello Niklas and all, <quote name="Niklas Laxström" date="2013-03-21" time="11:55:24 +0200">

...

I've seen a couple of instances where changes to MediaWiki are blocked until someone informs the community.

Just so I know, could you share these? Either on list or in a private email to me if you don't want to cause more stress in a sensitive situation. But, generally, on this issue, I think we need to make this better. I have some ideas that I want to work on, but, I've been mostly getting caught up on things thus far (I'm one month in now, pretty soon that excuse no longer flies!). For one thing, I'm the one who condenses down all of the changes that happened in a wmfXX release to the most important ones, see, eg: https://www.mediawiki.org/wiki/MediaWiki_1.21/wmf12 (NOTE: that page doesn't yet include the reverts we did to fix the Page Move issue.) Now, here's the problem with the current process around the creation of that page: 0) On every other Monday morning (pacific time) Reedy picks a commit on master and says "right here, this is wmfXX." 1) That gets deployed to our phase 1 list of wikis (mediawiki.org, test., test2.) 2) The Release Notes page for that wmfXX is created with the list of changes. 3) I then start my review of it. This usually takes me about an hour of concerted effort. There are a lot of changes and I'm unfamiliar with about 100% of them (some bugs I may be aware of, but not all). 4) I update that release notes page with the important/breaking changes. 5) Now, from here, what should I/we do? There is now a reasonably good list of important changes for a specific wmfXX release, with references to bug reports (usually). I don't know EXACTLY which things will be important to various communities/wikis and I don't want to be noisy about things. So, your suggestions welcome if I should do something and what after that release notes page is done. Now, this is just one part of the process, yes. But it is one that I have a large hand in. Official X.XX releases of MW are more in Mark H's hands, but I don't think that's the situation you're talking about here. Thanks, Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

Federico Leva (Nemo)

23 Mar 23 Mar

12:18 p.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

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

Greg Grossmeier

25 Mar 25 Mar

6:39 p.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

I'm going to jump to my conclusion instead of sending all of the 6 paragraphs I just wrote: <quote name="Federico Leva (Nemo)" date="2013-03-23" time="12:18:01 +0100">

...

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).

Can we actually start thinking about #5? I think that will inform what happens with 0-4 in many ways. What's the goal I'm working for in 0-4 for #5 to be effective? That's what I hoped to accomplish with my previous email :) It might take some re-thinking of what is the purpose of RELEASE-NOTES and what should be in there, as well (given all of the previous discussions that you mentioned and linked to). It will take some clarification of what the purpose of the wmfXX "deployment notes" (for lack of a better name) are, probably. My (personal) thoughts: == RELEASE-NOTES file == Audience: Third-party users of MediaWiki (ie: not admins on enwp, for instance). Contents: * Important new features (ie: not everything and the kitchen sink that's new). * Breaking changes (API and non-API sections) * Language Support Changes (Additional languages, coverage and such) * Deprecations - SELF-TODO: We don't have any guarantee, that I can see, that we deprecate for X releases before we remove * Number of bugs closed, broken down by severity if we wanted, with a link to a bugzilla page listing them all (why have 100/200+ lines of bug numbers and titles in the text file without clickable URLs? Or why double the number of lines with clickable URLs? Bugzilla is "great" (for certain values of great) at listing bug reports.) == Release Announcement (for X.XX releases) == Audience: Third-parties, mostly. This would be blogged, mailed out to the widest number of applicable lists, etc. Contents: * "Yay, we accomplished something big" type messaging. * Probably just the short list of new features and breaking changes. * A link to the "full release notes" (above), which is mirrored on a mediawiki.org page instead of pointing people to a gerrit URL. == -wmfXX branch notes == Audience: all Mediawiki developers, interested technical Wikimedia project members. SELF-TODO: This should probably be mailed out to the wikitech-ambassadors list along with wikitech-l. Contents: * List of important changes/bug fixes including new features, breaking changes, language support, and deprecations (ie: list of things in RELEASE-NOTES file, mostly) * Also, raw list of merges (this list comes in handy when debugging breakages, notably) * Raw list of closed bugs? This one is tougher given we don't have the -wmfXX branches as a 'version' in Bugzilla, and it would be annoying to have to reset bug target versions for each -wmfXX release. That outline was helpful for me, at least. Am I totally wrong anywhere? What should be added/removed/edited? Thanks! Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

Mark A. Hershberger

7:44 p.m.

New subject: Work starting on the 1.21 release candidates and announcement

On 03/25/2013 01:39 PM, Greg Grossmeier wrote:

...

== Release Announcement (for X.XX releases) == Audience: Third-parties, mostly. This would be blogged, mailed out to the widest number of applicable lists, etc. Contents: * "Yay, we accomplished something big" type messaging. * Probably just the short list of new features and breaking changes. * A link to the "full release notes" (above), which is mirrored on a mediawiki.org page instead of pointing people to a gerrit URL.

Serendipitously, I'd like to start making RC releases this weekend. To that end, could those of you who are interested in helping out with the Release announcement look over https://www.mediawiki.org/wiki/MediaWiki_1.21 and fill in those sections that are marked "FIX"? Under "What's new?" there are currently the following sections, each of which needs some love: 1.1 Skins 1.2 ContentHandler 1.3 High-resolution image support 1.4 Ajax patrolling 1.5 Internationalization: gender neutrality and other 1.6 New accounts 1.7 Account creation welcome 1.8 Other 1.9 Password Recovery system uses Tokens 1.10 Wikitext now supported in JavaScript messages 1.11 Several minor HTML changes 1.12 Extended collation support 1.13 Bundled extensions If you had a hand in any of this work, please look over that page so it is ready for an announcement. If you are just learning about these changes, please make sure it clearly describes what has changed. -- http://hexmode.com/ [We are] immortal ... because [we have] a soul, a spirit capable of compassion and sacrifice and endurance. -- William Faulker, Nobel Prize acceptance speech

Tyler Romeo

7:47 p.m.

New subject: Work starting on the 1.21 release candidates and announcement

For mine (1.9), it's ready, but just needs to be CRed and merged before it gets merge conflicted yet again. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo(a)gmail.com On Mon, Mar 25, 2013 at 2:44 PM, Mark A. Hershberger <mah(a)everybody.org>wrote;wrote:

...

On 03/25/2013 01:39 PM, Greg Grossmeier wrote:

Bartosz Dziewoński

9:03 p.m.

New subject: Work starting on the 1.21 release candidates and announcement

On Mon, 25 Mar 2013 19:44:20 +0100, Mark A. Hershberger <mah(a)everybody.org> wrote:

...

1.1 Skins

This one's mine; I expanded the comment a little. There were plans to remove the legacy skins in 1.21 (see https://gerrit.wikimedia.org/r/#/c/25170/). These seem to have ultimately failed (see discussion on the changeset).

...

1.4 Ajax patrolling

(Not mine) https://gerrit.wikimedia.org/r/#/c/41196/ - needs "someone who's firm with memcached and DB performance" to take a look. That should probably be a WMF someone, and there's apparently nobody willing to do that.

...

1.11 Several minor HTML changes

These are all mine as well. The two outstanding patchsets (https://gerrit.wikimedia.org/r/#q,I4ecd0659,n,z and https://gerrit.wikimedia.org/r/#q,I6a6c12a9,n,z) are blocked by there being nobody willing to review them, even though I've been repeatedly told people care at least about the second one.

...

1.12 Extended collation support

Yet another entry of mine. The number of languages being actually supported is in flux right now, as some minor issues were discovered (and fixed) with a few of them when deploying on WMF wikis, and I suspect similar ones might lurk around the corner in the untested ones; I'd say about a dozen are currently fully supported, and the rest should mostly work, but no promises. I'll update the entry and the config variable docs once I know exactly what's the status. The quality of this feature would probably greatly improve if https://gerrit.wikimedia.org/r/#/c/55503/ was merged before the release, though. -- Matma Rex

Platonides

11:03 p.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

On 25/03/13 18:39, Greg Grossmeier wrote:

...

* Deprecations - SELF-TODO: We don't have any guarantee, that I can see, that we deprecate for X releases before we remove

Not exactly a guarantee, but the general rule we use is to keep deprecated for a couple releases before removing. It's briefly explained at http://www.mediawiki.org/wiki/Deprecation

Greg Grossmeier

11:35 p.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

...

Not exactly a guarantee, but the general rule we use is to keep deprecated for a couple releases before removing. It's briefly explained at http://www.mediawiki.org/wiki/Deprecation

Thanks for the link, but the reason I brought it up is because my first week here I saw a removal of a function without an explicit @deprecated warning. :-) Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

Platonides

26 Mar 26 Mar

3:14 p.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

On 25/03/13 23:35, Greg Grossmeier wrote:

...

Thanks for the link, but the reason I brought it up is because my first week here I saw a removal of a function without an explicit @deprecated warning. :-) Greg

Is it possible that it was a recently-introduced function that hadn't been published on any release yet?

Greg Grossmeier

5:30 p.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

...

Is it possible that it was a recently-introduced function that hadn't been published on any release yet?

The commit message was something like: "Removing XYZ function that hasn't been used in a long long time." So no ;) Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

Tim Starling

12:50 a.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

On 26/03/13 09:03, Platonides wrote:

...

On 25/03/13 18:39, Greg Grossmeier wrote:

* Deprecations - SELF-TODO: We don't have any guarantee, that I can see, that we deprecate for X releases before we remove

Not exactly a guarantee, but the general rule we use is to keep deprecated for a couple releases before removing. It's briefly explained at http://www.mediawiki.org/wiki/Deprecation

It's hard to make an incontrovertible rule. Sometimes, removal of an interface is urgently required to support a rewrite of code which the interface depends on. If the interface is rarely or never used, it's hard to support the assertion that the rewrite should be delayed for a deprecation period of a year or two. On the other hand, I think that code which is harmless, and uses stable interfaces, thus requiring little maintenance, can be kept for decades. I don't think removal of deprecated code should be routine. Routine removal breaks extensions (especially those outside our git repo) with little benefit in return. -- Tim Starling

Federico Leva (Nemo)

1:20 a.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

Greg, «Can we actually start thinking about #5?» Fine with me. As step #5 was about what you have to do as in communicate (from what I understand) and you ask us not to start with the other steps, can I summarise that the answer to the question "Who is responsible for communicating changes in MediaWiki to WMF sites?" is "the WMF release manager" (or anyway the WMF) and that we can stop blocking development with WMF communication dependencies? Thanks, Nemo

Greg Grossmeier

5:32 p.m.

New subject: Who is responsible for communicating changes in MediaWiki to WMF sites?

...

can I summarise that the answer to the question "Who is responsible for communicating changes in MediaWiki to WMF sites?" is "the WMF release manager" (or anyway the WMF) and that we can stop blocking development with WMF communication dependencies?

Sure, that makes sense, Nemo, I just need some guidance on what you want, the goal of the communication. It sounds like you have a specific situation that happened in mind, could you share that with me/the list? Privately if sharing it/debating it publicly again wouldn't be useful, thanks. Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

4048

days inactive

4053

days old

wikitech-l@lists.wikimedia.org

Manage subscription

29 comments

14 participants

tags (0)

participants (14)

Bartosz Dziewoński
Brian Wolff
Federico Leva (Nemo)
Greg Grossmeier
Isarra Yos
Mark A. Hershberger
Niklas Laxström
Paul Selitskas
Platonides
Quim Gil
Rob Lanphier
Sumana Harihareswara
Tim Starling
Tyler Romeo