[Translators-l] Ready for early translation: (short) Tech News #35 (2014)

[Bohdan Melnychuk]

Hm, but it is already deployed on MWW and Test wikis, isn't it? It was 
in recent's section in all the issues before so I don't quite understand 
need to change the location. But I'm not a great fun of any changes of 
things I'm used to at all :) Perhaps others should leave a comment about 
that piece.

Well if the changes you don't want to put in future's yet are really 
quite minor then I think it's OK for me. Thought I can't see how it'd 
harm to advance notify about them and then  announce the changes after 
deployment again either. Latter way could be useful for users who read 
tech news on tech forums and do it quite irregularly.

But any way there will be always topics with panic about what happened 
right next to the section with tech news which explains it :)

---Base
22.08.2014 18:44, Guillaume Paumier написав(ла):
> Hi Bohdan,
>
> On Fri, Aug 22, 2014 at 4:46 PM, Bohdan Melnychuk <base-w at yandex.ru> wrote:
>> brr, somewhat confusing. Why the news about MW version is on Future changes
>> section?
> Tech News is sent on Monday, and the new version is deployed on
> Tuesday and Thursday, so it makes more sense to call it a "future
> change".
>
>> And there are no other recent changes? Sad( I didn't quite
>> understand about "moved some of the non-urgent items to next week, so that
>> people learn about them when they can actually see the changes and test the
>> new features " you mean that they'd be already deployed at the time of
>> puplication next issue? Or just nearer in future?
> Yes, I mean that the changes will be already deployed at the time of
> publication. There are no "Recent changes" this week, but they'll be
> in the "Recent changes" next week. That way, users who read Tech News
> can test the new features as soon as they learn about them. Otherwise,
> they need to wait several days before testing, and they might forget
> about it.
>
> Note that this is only for things that don't disrupt people's
> workflow. For disruptive changes, we still want to give them advance
> warning.
>
> I hope this is clearer; let me know if it isn't :)
>