You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Martin Heidegger <mh...@leichtgewicht.at> on 2012/02/12 07:58:38 UTC
Working groups - different approach
Hello List,
I know we discussed working groups before. This time I want to focus on
a different aspect.
One person can not know or do everything. Flex has a variety of task in
front of it -
tasks that are better not ignored - that require a lot of expertise (man
power) and coordination.
I think of:
*) Translation: Right now the asdoc is translated in many languages.
Will we drop the translation? How to keep that up?
*) Testing & Building: Boring, exhausting, peticular - many
programmers are not laid out for it and it will be a lot of work,
specially if we change the code rapidly.
*) Documentation: Writing solid code is a entirely different ability
from writing/recording good understandable documentation & examples.
*) Presentation: Logos, Homepage design, Skins, UX, creativity in
general ... not the strong suit for many programmers
I think it would help the process if there were mailing-lists and
persons who can answer in this topics
clearly & have authority: managed working groups.
yours
Martin.
Re: Working groups - different approach
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
The code in the SVN is already translated using resource bundles. [1]
"a professional 3rd party vendor" ? That sounds very strange to me.
But back to the original topic: There should be mailing lists and
working-group mentors assigned to such working group.
That is at least my opinion.
yours
Martin.
[1] Example
https://svn.apache.org/repos/asf/incubator/flex/whiteboard/frameworks/projects/charts/bundles/fr_FR/docs/mx.charts.chartClasses.xml
On 13/02/2012 13:34, David Francis Buhler wrote:
> Regarding 1& 2:
>
> Here's one possible way (with ANT) to begin creating localized content
> for the SDK.:
>
> We copy a RAW SDK into locale-specific folder names during a build.
> We add @Tokens@ in the .as / .mxml (?) files that correspond to help
> content (stored in properties' files)
> We use English as the master locale (all localization is done with a
> Master Locale)
> We use Google's translation service to manage the localization of the
> properties files by volunteers (note: I've never used this service and
> cannot speak to it specifically). With a small financial backing, a
> professional 3rd party vendor could translate the documentation, at
> least for major locales.
> Using AS Docs, we could generate locale-specific help for the SDKs
> during each build.
>
> [1] http://support.google.com/translate/toolkit/?hl=en
>
> On Sun, Feb 12, 2012 at 1:58 AM, Martin Heidegger<mh...@leichtgewicht.at> wrote:
>> Hello List,
>>
>> I know we discussed working groups before. This time I want to focus on a
>> different aspect.
>> One person can not know or do everything. Flex has a variety of task in
>> front of it -
>> tasks that are better not ignored - that require a lot of expertise (man
>> power) and coordination.
>> I think of:
>>
>> *) Translation: Right now the asdoc is translated in many languages. Will
>> we drop the translation? How to keep that up?
>> *) Testing& Building: Boring, exhausting, peticular - many programmers are
>> not laid out for it and it will be a lot of work, specially if we change the
>> code rapidly.
>> *) Documentation: Writing solid code is a entirely different ability from
>> writing/recording good understandable documentation& examples.
>> *) Presentation: Logos, Homepage design, Skins, UX, creativity in general
>> ... not the strong suit for many programmers
>>
>> I think it would help the process if there were mailing-lists and persons
>> who can answer in this topics
>> clearly& have authority: managed working groups.
>>
>> yours
>> Martin.
>>
>>
>>
>>
>>
>
Re: Working groups - different approach
Posted by David Francis Buhler <da...@gmail.com>.
Regarding 1 & 2:
Here's one possible way (with ANT) to begin creating localized content
for the SDK.:
We copy a RAW SDK into locale-specific folder names during a build.
We add @Tokens@ in the .as / .mxml (?) files that correspond to help
content (stored in properties' files)
We use English as the master locale (all localization is done with a
Master Locale)
We use Google's translation service to manage the localization of the
properties files by volunteers (note: I've never used this service and
cannot speak to it specifically). With a small financial backing, a
professional 3rd party vendor could translate the documentation, at
least for major locales.
Using AS Docs, we could generate locale-specific help for the SDKs
during each build.
[1] http://support.google.com/translate/toolkit/?hl=en
On Sun, Feb 12, 2012 at 1:58 AM, Martin Heidegger <mh...@leichtgewicht.at> wrote:
> Hello List,
>
> I know we discussed working groups before. This time I want to focus on a
> different aspect.
> One person can not know or do everything. Flex has a variety of task in
> front of it -
> tasks that are better not ignored - that require a lot of expertise (man
> power) and coordination.
> I think of:
>
> *) Translation: Right now the asdoc is translated in many languages. Will
> we drop the translation? How to keep that up?
> *) Testing & Building: Boring, exhausting, peticular - many programmers are
> not laid out for it and it will be a lot of work, specially if we change the
> code rapidly.
> *) Documentation: Writing solid code is a entirely different ability from
> writing/recording good understandable documentation & examples.
> *) Presentation: Logos, Homepage design, Skins, UX, creativity in general
> ... not the strong suit for many programmers
>
> I think it would help the process if there were mailing-lists and persons
> who can answer in this topics
> clearly & have authority: managed working groups.
>
> yours
> Martin.
>
>
>
>
>
Re: Working groups - different approach
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 2012/02/10 06:50, Rob Weir said:
> On Thu, Feb 9, 2012 at 5:28 PM, Michael Bauer <fi...@akerbeltz.org>
> wrote:
>> Putting it the other way, would you give just anyone the right to
>> commit new (structural) code?
>>
>> Community translation has its good sides and it's bad sides. What
>> will undoubtedly happen is that there will be disagreements over
>> style, terminology and orthography. Unless you have the option of
>> making someone the "arbiter" of that locale, you end up with the most
>> nauseating hotchpotch of style, terminology and orthography. Some of
>> the Google interface languages are like that. I have read a little in
>> the mailing list. Openoffice uses a pootle server for translation[1].
>> It might be worth to think if that might be useful for us too.
>
> Apache projects tend to look at this slightly differently.
>
> Traditional, vertical organization: Someone (or group of persons) is
> in charge and decides what will be done, and then delegates that
> authority to other individuals who have that authority and decide such
> matters. Parts of Apache are like this, at the foundation-level. For
> legal reasons there are individual officers with formal
> responsibilities and authority that supports those responsibilities.
>
> But within a project, it is more like horizontal organization,
> consensus based. The community agrees that it wants consistency in
> terminology in the UI translations. Someone volunteers to define a
> basic terminology, the community adopts it as a "coding standard" and
> agrees to treat deviations like a bug. Someone might volunteer to
> review these items and fix errors and general facilitate consistency
> in the translations.
>
> So I think you end up in the same place in both models. You achieve
> consistency. In both cases there is leadership, but in the 2nd case
> there is no appointed leader with authority. There is just a volunteer
> who, by his efforts exerts a kind of personal leadership in that area.
>
I think that is a pretty good summary.
yours
Martin.
Re: Working groups - different approach
Posted by David Francis Buhler <da...@gmail.com>.
Pootle looks very cool. For contrast, the approach I was suggesting
above would provide localized content inside the Flex SDK classes. I
believe Pootle would allow us to provide localized help content
similar to help.adobe.com.
On Mon, Feb 13, 2012 at 9:58 AM, Martin Heidegger <mh...@leichtgewicht.at> wrote:
> On 13/02/2012 22:20, Bertrand Delacretaz wrote:
>>
>> If people can communicate in english that can happen here (at least
>> initially), otherwise I agree that you'd need separate lists. Note that the
>> http://incubator.apache.org/openofficeorg/ probably has similar issues w.r.t
>> translation, you might want to talk to them. -Bertrand
>
>
> I have read a little in the mailing list. Openoffice uses a pootle server
> for translation[1]. It might be worth to think if that might be useful for
> us too.
>
> yours
> Martin.
>
> [1] http://translate.sourceforge.net/wiki/pootle/index
>
Re: Working groups - different approach
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 13/02/2012 22:20, Bertrand Delacretaz wrote:
> If people can communicate in english that can happen here (at least
> initially), otherwise I agree that you'd need separate lists. Note
> that the http://incubator.apache.org/openofficeorg/ probably has
> similar issues w.r.t translation, you might want to talk to them.
> -Bertrand
I have read a little in the mailing list. Openoffice uses a pootle
server for translation[1]. It might be worth to think if that might be
useful for us too.
yours
Martin.
[1] http://translate.sourceforge.net/wiki/pootle/index
Re: Working groups - different approach
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Feb 13, 2012 at 2:13 PM, Martin Heidegger <mh...@leichtgewicht.at> wrote:
> On 13/02/2012 21:56, Bertrand Delacretaz wrote:
>>
>> the one I posted to previously, at
>> http://grep.codeconsult.ch/2011/12/06/stefanos-mazzocchis-busy-list-pattern/
>> (it's my blog - as I said, shameless but IMO useful plug)
>
> I can only find information about the proper use of the list not about
> proper management...
Ah ok, sorry about that - by "management" I meant using precise
Subject lines, [tags], one topic per thread etc.
>>
>> The best is to reach consensus without a vote, people agree and commit
>> code (or translations, whatever) that they find good.
>>
>
> I found it difficult to judge the point when a consensus without a vote has
> been reached...
You can use lazy consensus if unsure, use [lazy] in the subject line
and say something like "I'll do that unless someone opposes within 24
hours".
> ...One question still: What about different languages: Japanese/Chinese/French
> etc. how does a integration of people with other language-skills usually
> work?...
If people can communicate in english that can happen here (at least
initially), otherwise I agree that you'd need separate lists.
Note that the http://incubator.apache.org/openofficeorg/ probably has
similar issues w.r.t translation, you might want to talk to them.
-Bertrand
Re: Working groups - different approach
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 13/02/2012 21:56, Bertrand Delacretaz wrote:
> the one I posted to previously, at
> http://grep.codeconsult.ch/2011/12/06/stefanos-mazzocchis-busy-list-pattern/
> (it's my blog - as I said, shameless but IMO useful plug)
I can only find information about the proper use of the list not about
proper management. I suspect that is just my lack of understanding and
leave it with that. Thanks!
> you could predefine some but they usually evolve as soon as people see a pattern.
Okay, I will just continue to list them in the wiki as soon as they are
established.
>
> The best is to reach consensus without a vote, people agree and commit
> code (or translations, whatever) that they find good.
>
I found it difficult to judge the point when a consensus without a vote
has been reached.
> Any committer can then veto that code, with justification. For topics
> that need a vote, the rules at
> http://www.apache.org/foundation/voting.html apply. It's quite easy to
> have informal sub-groups who each take care of different modules in
> that way, without requiring specific organization.
The link with the voting rules is very informative.
One question still: What about different languages:
Japanese/Chinese/French etc. how does a integration of people with other
language-skills usually work?
thank you
Martin.
Re: Working groups - different approach
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Mon, Feb 13, 2012 at 12:08 PM, Martin Heidegger <mh...@leichtgewicht.at> wrote:
> On 13/02/2012 19:01, Bertrand Delacretaz wrote:
>>
>> I disagree - busy mailing lists are good if well managed.
>
> I have not too much experience with good management of mailing-lists. Is
> there some good article/thing to read about that?
the one I posted to previously, at
http://grep.codeconsult.ch/2011/12/06/stefanos-mazzocchis-busy-list-pattern/
(it's my blog - as I said, shameless but IMO useful plug)
>> Using [translation], [testing] and similar tags in message subjects...
> Do you think it would be good to predefine such tags in order for other
> people to not confuse them?
> A definition would be a lot like a own mailing list (for example one could
> pre-set filters in his mail client of choice)...
you could predefine some but they usually evolve as soon as people see
a pattern.
There are some proposals at
https://cwiki.apache.org/confluence/display/FLEX/Getting+Started
already.
>> As for people in charge, the PPMC is in charge of such things, and if
>> only a subset of it is interested in translations, for example,
>> getting votes for those people, while others abstain,
>
> How does that work? In what time span can a PPMC member intercept? Is one
> PPMC that raises its voice enough?
> What if no PPMC raises its voice?..
The best is to reach consensus without a vote, people agree and commit
code (or translations, whatever) that they find good.
Any committer can then veto that code, with justification.
For topics that need a vote, the rules at
http://www.apache.org/foundation/voting.html apply.
It's quite easy to have informal sub-groups who each take care of
different modules in that way, without requiring specific
organization.
-Bertrand
Re: Working groups - different approach
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 13/02/2012 19:01, Bertrand Delacretaz wrote:
> I disagree - busy mailing lists are good if well managed.
I have not too much experience with good management of mailing-lists. Is
there some good article/thing to read about that?
> Using [translation], [testing] and similar tags in message subjects. As a
> shameless but IMO useful plug, see my blog post at [1] for a more
> detailed explanation based on Stefano Mazzocchi's "busy list pattern".
Do you think it would be good to predefine such tags in order for other
people to not confuse them?
A definition would be a lot like a own mailing list (for example one
could pre-set filters in his mail client of choice).
> As for people in charge, the PPMC is in charge of such things, and if
> only a subset of it is interested in translations, for example,
> getting votes for those people, while others abstain,
How does that work? In what time span can a PPMC member intercept? Is
one PPMC that raises its voice enough?
What if no PPMC raises its voice?
> is good enough to make progress, no need to appoint specialists.
There are a lot of topics, i assume, where there are simply no
specialists. However: If one is available
for "mentoring" a aspect (like translation) of Flex then I think, like a
mentor, he should be addressable.
So analogue to:
[TRANSLATION] my topic [MENTOR]
that requests for a project mentor. I can see special tagging like:
[TRANSLATION] my topic [COUNSEL]
that requests for a PPMC member to chime in as the community can't reach
a green path.
The phrasing "counsel" might not be adequate but I guess it shows where
I am coming from.
> If such topics become too noisy on this list the project *might*
> decide to split lists, but splitting from the start is totally wrong
> IMO, as you'd split community and create an "us and them" mindset
> which is not good.
We already have a us and them mindset established. Namely: People that
are not
efficient in a specific language (say Japanese/chinese/german) are the
"them" as opposed
to "us" - the english speaking folks. Particularly for translation and
group management this is
a important factor: But also in general: a japanese speaker that has a
weak english might have
relevant questions/points. Do you know how this is addressed at
established open source
projects?
> In summary, I think working groups can form right here and now, based
> on [tags] and people doing stuff.
Alright!
yours
Martin.
Re: Working groups - different approach
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Sun, Feb 12, 2012 at 7:58 AM, Martin Heidegger <mh...@leichtgewicht.at> wrote:
> I know we discussed working groups before. This time I want to focus on a
> different aspect.
> One person can not know or do everything. Flex has a variety of task in
> front of it -
> tasks that are better not ignored - that require a lot of expertise (man
> power) and coordination....
>... I think it would help the process if there were mailing-lists and persons
> who can answer in this topics
> clearly & have authority: managed working groups...
I disagree - busy mailing lists are good if well managed. Using
[translation], [testing] and similar tags in message subjects. As a
shameless but IMO useful plug, see my blog post at [1] for a more
detailed explanation based on Stefano Mazzocchi's "busy list pattern".
As for people in charge, the PPMC is in charge of such things, and if
only a subset of it is interested in translations, for example,
getting votes for those people, while others abstain, is good enough
to make progress, no need to appoint specialists.
If such topics become too noisy on this list the project *might*
decide to split lists, but splitting from the start is totally wrong
IMO, as you'd split community and create an "us and them" mindset
which is not good.
In summary, I think working groups can form right here and now, based
on [tags] and people doing stuff.
-Bertrand
[1] http://grep.codeconsult.ch/2011/12/06/stefanos-mazzocchis-busy-list-pattern/