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
Is sending an email to wikitech-ambassadors enough for unblocking it?
Although such should contain a timeframe expectation, which probably
only WMF can give.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman
On 03/21/2013 02:55 AM, Niklas Laxström wrote:
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 com
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 wrote:
> On 03/21/2013 02:55
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 | tylerro...@gmail.com
_
On 2013-03-21 3:08 PM, "Tyler Romeo" 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
>
On 03/21/2013 11:05 AM, Paul Selitskas wrote:
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.
Thank you, having
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
On Thu, Mar 21, 2013 at 2:13 PM, Brian Wolff wrote:
> 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.
>
> -baw
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,
On 21/03/13 19:15, Quim Gil wrote:
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
tel
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 poin
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
On 21/03/13 20:55, Niklas Laxström wrote:
> 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
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 as
Hello Niklas and all,
> 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
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 – t
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
I'm going to jump to my conclusion instead of sending all of the 6
paragraphs I just wrote:
> 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 affe
On Sun, Mar 24, 2013 at 7:27 PM, Tim Starling 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
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 briefl
> 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 functi
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
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 M
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 pub
> 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 GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> 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
27 matches
Mail list logo
