incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <>
Subject Re: accommodate non-native-English-writing developers
Date Thu, 30 Oct 2008 13:19:14 GMT
On Thu, Oct 30, 2008 at 5:09 AM, David Crossley <> wrote:
> Robert Burrell Donkin wrote:
>> David Crossley wrote:


>> > Obviously the non-English speaking people need
>> > to interpret any English changes to the code,
>> > and vice-versa.
>> >
>> > Mail lists:
>> > Should people just partipipate on the podling's
>> > dev mail list in their own languages? Then expect
>> > that someone summarises the outcomes and decisions
>> > into English/Japanese. Or would it be better to have
>> > separate dev language lists, with the same
>> > summarising outcome. The former would enable replies
>> > to be threaded with the other language.
>> i think one dev list is the right way to approach this problem. it's
>> important for the development community to have a single forum for
>> discussion and decision making.
> Yes. The key is for the project's PMC to ensure
> that there are always bi-lingual members active.
>> i'm not so sure about the user lists (perhaps someone from tuscany
>> could jump in and tell us about their chinese users forum)
> Thanks for the pointer. I expect that the issue
> of developer involvement has bigger impact than
> user involvement.

the recruitment of developers from users is important. if the dev
lists are english only then this would potentially create a barrier to

>> > In any case, i reckon that it would be desirable
>> > to have these lists at
>> i agree but the issue raised in the past has been moderation.
>> moderation volunteers would need to be found for every language
>> supported.
> We do intend to have some people who are bi-lingual
> on the project's PMC. So they would be mail moderators
> too.

bi-lingual monitors will probably be needed but it should be possible
for the moderation burden to be spread beyond those how are bilingual
since it just means being able to read and reject messages.

>> > Documentation has similar issues.
>> >
>> > Likewise the svn commit log messages.
>> one tactic which works ok is to use JIRA for task planning. commit
>> messages are necessarily concise. a JIRA allows a change to be tied
>> back into a more substantial task which can be explained in more
>> detailed and potentially translated. patches (in particular tests) can
>> be attached to demonstrate or illustrate points.
> Thanks. That is fine for larger issues.

i found that JIRA works surprisingly well for small issues too

> For the commit
> messages babelfish-type services can assist.


> I wonder if it would be possible to have some
> commit messages in Japanese, with another committer
> following up to use 'svn propedit svn:log ..." to
> add English comments.


>> > Does anyone here have some tips for conducting
>> > an open development project that accommodates
>> > multi-lingual developer participation?
>> i wonder whether we might need to raise this question more widely
> In what forum?

some of the linux distributions have similar problems. might be worth
asking on members first for contacts or personal experiences.

i can also think of a few committers who are knowlegable in this area
(but probably names are best discussed in private)

asking the lazy web might also be a good plan

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message