Re: Rules for new languages getting into Aurora

[Staś Małolepszy]

Hey Dwayne,

Thanks for this really thorough write-up. You raise a lot of good
points and I'm glad that you started this thread.

Dwayne Bailey, Fri Sep 23 11:05:41 +0200 2011:
> * Deadline:
> [..snip..]
> time to address any issues raised. 4 Weeks seems unreasonable
> because you need to squeeze a load of translations into two weeks.

We've seen a couple of migrations so far; is the workload from cycle
to cycle really big enough to require more than two weeks?

> * Proposal:
> I'd like to propose some changes which I believe could reduce the burden
> on everyone involved:
> 1) Mercurial is setup as soon as your language is approved. Benefits:
> a) You are in VC from the start, b) you get language builds from the
> start so its easy to grow your community
> 2) The review happens the first time you want to move from Aurora to
> Beta. So we delay the review till a point where it makes more sense but
> we don't lose the benefits of Aurora as a staging platform for new teams.

The current process starts with an hg account on bitbucket where the
localizers can work on their translations in progress. There are a few
reasons for this:

- if something goes wrong, it's safer to break a bitbucket repo than
a hg.mozilla.org repo; the bitbucket repo is a playground for
learning hg.

- committing to h.m.o currently requires an LDAP account and a signed
committer's agreement sent to Mozilla. For that reason, before we
grant accesss to the l10n repo, ideally we would have already seen
the quality and the hygiene of work with hg by the localizer.

The subject of requiring the agreement is a heavily discussed one
at this point. We will be dropping it for the SVN account, IIRC.
I believe that we should investigate if dropping it for HG is
a possibility.

I agree that the rapid release channels give us a great framework to
get the localized buids out early and thus help build the community,
help spot mistakes faster and, equally importantly, provide the
much-needed sense of reward, or impact, that a contribution has had.

If we can figure out how to solve the issues I listed above that made
us choose bitbucket and reach the goal of getting the language builds
earlier, I'd consider it a huge win.

Maybe we can build using the bitbucket repos? Or automatically clone
them into non-writable repos on h.m.o? Or set up h.m.o/incubator from
which we'd produce Aurora-class builds? Let's brainstorm possible
solutions in this thread.


> The following are other requirements that could be considered to help
> sets milestones for a translator and to reduce burdens on Mercurial
> account setups, etc
> 1) Set a minimum number of files that must be translated to get the
> account approved. This could be reviewed as we currently do. Files
> such as browser.dtd and browser.properties could be candidates as
> they're big enough that you would actually have had to turned your
> desire for a localised Firerfox into effort.
> 2) Set a minimum coverage level before you start getting Firefox
> builds. For the African teams we have a set of files that give a good
> first time experience, it's about 20% of the total but could let you
> browse in your language.

I really like this idea. Disclaimer: I've been a big fan of the phase
list the you guys have set up and always recommended to new localizers
to go by it :)

Can 1) and 2) be treated as the same? Is 2) a subset of 1)? If we
required the 1 level from the phase list, would we hit both 1) and 2)?
It might be simpler to merge this into a one criterion.

Thanks, Dwayne, for bringing this up and summarizing the challenge so
nicely.

-stas
--
Staś Małolepszy
mozilla.org

[Dwayne Bailey]

On 2011-09-27 22:56, Staś Małolepszy wrote:
> Hey Dwayne,
>
> Thanks for this really thorough write-up. You raise a lot of good
> points and I'm glad that you started this thread.
>
> Dwayne Bailey, Fri Sep 23 11:05:41 +0200 2011:
>> * Deadline:
>> [..snip..]
>> time to address any issues raised. 4 Weeks seems unreasonable
>> because you need to squeeze a load of translations into two weeks.
> We've seen a couple of migrations so far; is the workload from cycle
> to cycle really big enough to require more than two weeks

As it stands there is Wolof and Fulah that didn't get in. They spent 4
weeks updating translations, 7 to 8. They also spent time testing and
correcting and getting to a place where they passed Pootle tests and
compare-locale tests. They submitted there translations for review 2
weeks before the cutover. Don't forget that these are two very dedicated
teams.

So I would regard these two as pretty good yardsticks of top end new teams.

While I wouldn't have thought it too hard to get things done in 2 weeks,
it does seem as if its too much. We can't forget that we're dealing with
new teams here. The above two are very dedicated so others I expect
could be worse.

>> * Proposal:
>> I'd like to propose some changes which I believe could reduce the burden
>> on everyone involved:
>> 1) Mercurial is setup as soon as your language is approved. Benefits:
>> a) You are in VC from the start, b) you get language builds from the
>> start so its easy to grow your community
>> 2) The review happens the first time you want to move from Aurora to
>> Beta. So we delay the review till a point where it makes more sense but
>> we don't lose the benefits of Aurora as a staging platform for new teams.
> The current process starts with an hg account on bitbucket where the
> localizers can work on their translations in progress. There are a few
> reasons for this:
>
> - if something goes wrong, it's safer to break a bitbucket repo than
> a hg.mozilla.org repo; the bitbucket repo is a playground for
> learning hg.

The teams I'm supervising are pretty much divorced from HG at the
moment. I'm, at the moment, not sure if all will progress to doing their
own commits to HG.

>
> - committing to h.m.o currently requires an LDAP account and a signed
> committer's agreement sent to Mozilla. For that reason, before we
> grant accesss to the l10n repo, ideally we would have already seen
> the quality and the hygiene of work with hg by the localizer.
>
> The subject of requiring the agreement is a heavily discussed one
> at this point. We will be dropping it for the SVN account, IIRC.
> I believe that we should investigate if dropping it for HG is
> a possibility.

Ah forgot about that.

>
> I agree that the rapid release channels give us a great framework to
> get the localized buids out early and thus help build the community,
> help spot mistakes faster and, equally importantly, provide the
> much-needed sense of reward, or impact, that a contribution has had.
>
> If we can figure out how to solve the issues I listed above that made
> us choose bitbucket and reach the goal of getting the language builds
> earlier, I'd consider it a huge win.
>
> Maybe we can build using the bitbucket repos? Or automatically clone
> them into non-writable repos on h.m.o? Or set up h.m.o/incubator from
> which we'd produce Aurora-class builds? Let's brainstorm possible
> solutions in this thread.

Maybe we can restate this in terms of goals:
1) We want Aurora class builds - easier testing, build community, check
for errors
2) We want to make the migration into Aurora easier - easy to commit
files, easy to request a review, easy to migrate the work into Mozilla HG.

I like the idea of cloning as it would allow the translators to put the
files anywhere they choose. The build scripts simply update the repo and
then proceed.

Would it be possible to list languages in an incubator section using the
current shipping sign-off process? Once there signoff is approved then
they move into Aurora.

>
>
>> The following are other requirements that could be considered to help
>> sets milestones for a translator and to reduce burdens on Mercurial
>> account setups, etc
>> 1) Set a minimum number of files that must be translated to get the
>> account approved. This could be reviewed as we currently do. Files
>> such as browser.dtd and browser.properties could be candidates as
>> they're big enough that you would actually have had to turned your
>> desire for a localised Firerfox into effort.
>> 2) Set a minimum coverage level before you start getting Firefox
>> builds. For the African teams we have a set of files that give a good
>> first time experience, it's about 20% of the total but could let you
>> browse in your language.
> I really like this idea. Disclaimer: I've been a big fan of the phase
> list the you guys have set up and always recommended to new localizers
> to go by it :)
>
> Can 1) and 2) be treated as the same? Is 2) a subset of 1)? If we
> required the 1 level from the phase list, would we hit both 1) and 2)?
> It might be simpler to merge this into a one criterion.

In the current phase list 1 is a subset of 2. They could be treated as
the same it really depends on what goals milestones make sense. If we
don't care about the cost of building and are using bitbucket (so we
don't care about the effort involved in accounts) we could setup 1) as
being the requirement to request your language be build as part of the
incubation stage. We might then not care about 2) but its a good one to
set the direction for the translator.

So maybe we have goals like:
1) Accepting someone into incubator building - that's 1) above
2) Directing their initial effort - that's 2) above but not a decision point
3) Moving from incubation to Aurora - could be 2) above or could be our
current user[1234]

>
> Thanks, Dwayne, for bringing this up and summarizing the challenge so
> nicely.
>
> -stas


--

regards
Dwayne

[smo]

I feel, it would make sense to separate l10n cases into "starting-from-
zero" (or "far-behind") and "starting-from-previous-aurora". SOPs for
the latter should be much simpler than what's been written up so far
in this thread.

Regards

smo

[Dwayne Bailey]

I'm talking about teams not yet in Mercurial, so this distinction is not
important in this case. Where they came from isn't important since they
will need a review regardless. The issue for me is getting them into
Mercurial in such a way that they can actually hit the Mozilla process
running instead of being excluded because the review couldn't be done in
time.

If they where a team in Mercurial then the distinction you raise might
be an important one to consider.
--
regards
Dwayne