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 Wed, 29 Oct 2008 13:16:42 GMT
On Tue, Oct 28, 2008 at 7:45 AM, David Crossley <> wrote:
> I am assisting a new project to potentially
> come to the Incubator.
> It will be producing an implementation of a
> multi-part ISO standard. Hence the strong
> country-based nature, means that international
> language issues will be paramount.

interesting :-)

> My initial question was about how to conduct the
> mailing list discussions. Of course the issues
> are much wider. Some feeling for how to handle
> these issues will help us to make a better
> proposal to the Incubator.
> For example, some key parts of its puzzle are
> developed by Japanese people. Other parts by
> English-speaking people. Some of these people
> can read/write English, but others are not
> at all comfortable.
> Some code contributions would have Japanese
> variable names and internal code documentation.
> I understand that the code documentation could
> be augmented with English. However, i don't see
> how to deal with actual code and ongoing
> contributions.

in my experience, ongoing code and contributions is much easier than
discussion. one useful accommodation is to use more diagrams and less
chat. for example, using UML diagrams to explain. some infrastructure
is required (mailing lists and UML don't tend to get on). an area for
diagrams in subversion works ok.

decision making tends to be ok. developers can use babelfish to
translate the proposition in a formal VOTE thread and then cast their
votes appropriately.

discussion is the major PITA. even on conventional apache projects,
it's hard for developers who are not confident in english. it's very
easy for misunderstandings to spiral out of all proportion. this is
especially true of questions about code.

large slices of patience, understanding and goodwill are definitely required

> 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.

i'm not so sure about the user lists (perhaps someone from tuscany
could jump in and tell us about their chinese users forum)

> 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

> 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.

> 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

one of my concerns is that we're unlikely to be able to recruit
Mentors with a sufficiently wide range of language skills to be able
to monitor all discussions on list. we may need to consider asking for
additional volunteers from the pool of committers to act as community
mentors (with a small 'm').

- robert

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

View raw message