incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Goasguen <run...@gmail.com>
Subject Re: [DOCS][DISCUSS]Documentation for 4.1
Date Tue, 26 Feb 2013 13:47:17 GMT

On Feb 26, 2013, at 5:25 AM, Radhika Puthiyetath <radhika.puthiyetath@citrix.com> wrote:

> Hello Documentation contributors/ Localization maintainers,
> 
> Would it be possible for us to plan multiple localization drop for documentation ? In
that way, we can accommodate most of the late additions, for example, UI changes for AWS-Style
Regions or any defect fixes on features. 

Radhika, I don't understand what you mean by localization drop ? can you explain ?

> 
> Sorry about my ignorance if that is the way localization is dealt with currently by the
translation team.
> 
> Please do educate me also on the process followed for localizing the UI strings.

If by localization you mean translation, the UI strings are translated the same way than the
rest of the documentation. The source file has been uploaded to transifex and people are translating
there. We also received a patch for korean translation via review board.


> 
> Thanks
> 
> -Radhika
> 
> -----Original Message-----
> From: Sebastien Goasguen [mailto:runseb@gmail.com] 
> Sent: Tuesday, February 12, 2013 10:43 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [DOCS][DISCUSS]Documentation for 4.1
> 
> 
> On Feb 12, 2013, at 5:54 PM, Joe Brockmeier <jzb@zonker.net> wrote:
> 
>> On Tue, Feb 12, 2013 at 05:25:11PM +0100, Sebastien Goasguen wrote:
>>> After 2/28 we will just fix doc bugs, not add new docs, even if a 
>>> feature is included in 4.1 if its docs are not in by 2/28 then too bad.
>> 
>> -1 to this.
>> 
>> The reason for stopping feature development with a hard freeze is that 
>> new features have the potential to disrupt the codebase badly enough 
>> that it's a major issue.
>> 
>> Adding new docs makes it a problem for translators, but it doesn't 
>> carry the same level of disruption as new features. For example, think 
>> about the impact if Javelin landed a week later than it did into master vs.
>> the impact of adding another section to the install or admin guide. 
>> It's not really comparable.
>> 
>> Also - leaving a feature out of a release means it can be picked up in 
>> a later release. Failing to document features is, basically, a bug 
>> that should be fixed (if possible) before a release.
> 
> But if it cannot be fixed on-time it should not be a release blocker or a reason to slip
the release date.
> 
>> 
>>> That's a bit of tough love, but that's what will happen if we want to 
>>> stick to the schedule.
>> 
>> I'd like to stick to the schedule, but we should have more flexibility 
>> here than with features. It's also worth noting this is the first time 
>> through with a hard feature release and we're still finding our way
>> - and what we seem to be finding is that ~1 month for documentation is 
>> a bit tricky when a lot of features land (or don't) right on the 
>> feature deadline.
>> 
> 
> That's fine with me, it just means that we need to update the schedule.
> And we need to make sure that what's in the 4.1 documentation plan pointed out by Radhika
actually only targets features that made the 4.1 cut.
> 
> -sebastien
> 
> 
>> Best,
>> 
>> jzb
>> --
>> Joe Brockmeier
>> http://dissociatedpress.net/
>> Twitter: @jzb
> 


Mime
View raw message