Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of dave2wave@comcast.net
 designates 76.96.30.80 as permitted sender)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Contributors versus Committers versus PMC members - AND USERS
From: Dave Fisher <dave2wave@comcast.net>
In-Reply-To: <BANLkTikPQ8niYd1rk2Fgy-Oj2uTpzx2r6A@mail.gmail.com>
Date: Sat, 25 Jun 2011 10:40:41 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <50D36BD9-DD3A-4A5D-882C-2641E2F6F535@comcast.net>
References: <00d301cc32b3$f5e4f760$e1aee620$@acm.org>
 <BANLkTikT-ch-Xa_=Aeo+i7G1RnqkyprJug@mail.gmail.com>
 <4E050863.7000106@the-martin-byrd.net>
 <00e301cc32bf$66275da0$327618e0$@acm.org>
 <BANLkTimLNv=2W3rno+68Rs6ZSSOPbWjdhg@mail.gmail.com>
 <4E0571F6.7090603@wtnet.de>
 <BANLkTimfDRKCJR-0ke+851bXmDxMeC=N7g@mail.gmail.com>
 <1309007103.2923.39.camel@fedora> <4E05E43F.9090702@quicknet.nl>
 <BANLkTikhD8Oc0ETxOSFvZ0nfsigCYkoSXQ@mail.gmail.com>
 <BANLkTino8cQUO42kxKNeW0nMZVMJwJhXiQ@mail.gmail.com>
 <BANLkTikCc4=LxKXn4Qh26pm=JO9orqn59Q@mail.gmail.com>
 <BANLkTikCVUfvU4zjpDSiGGA+FBfA0GmKJw@mail.gmail.com>
 <BANLkTikPQ8niYd1rk2Fgy-Oj2uTpzx2r6A@mail.gmail.com>
To: ooo-dev@incubator.apache.org


On Jun 25, 2011, at 9:59 AM, Alexandro Colorado wrote:

> On Sat, Jun 25, 2011 at 11:36 AM, Rob Weir <apache@robweir.com> wrote:
>=20
>> On Sat, Jun 25, 2011 at 12:10 PM, Alexandro Colorado =
<jza@openoffice.org>
>> wrote:
>>> On Sat, Jun 25, 2011 at 10:23 AM, Rob Weir <apache@robweir.com> =
wrote:
>>>=20
>>>> Thanks for the list.  I looked around.  Some lists are very active.
>>>> Some have not seen activity for a year or more.  Some seem to never
>>>> have been active.  And some are just full of spam :-(
>>>>=20
>>>> I can see three ways to decide what to do (but maybe someone has =
other
>>>> ideas?):
>>>>=20
>>>> 1) Recreate the structure of the OOo lists, making lists for all
>>>> language groups, whether or not they are active.
>>>>=20
>>>> 2) Define activity criteria for what we will create, such as number =
of
>>>> posts in last 12 months.  Create lists of whatever was active (by =
an
>>>> agreed on definition).
>>>>=20
>>>> 3) Create lists only when there is a sufficient number of project
>>>> members on the Apache list asking for new list.
>>>>=20
>>>> I think I like approach #3 better.  There are downsides to having =
more
>>>> lists than we need. It fragments the discussion.  If we have 93
>>>> language projects with each one having dev/marketing/user, etc.,
>>>> lists, then we have 500 or so mailing lists, most of which see =
little
>>>> or no traffic.  Do we really want to recreate that at Apache?
>>>>=20
>>>> Right now we have just a single discussion pubic list, ooo-dev.  I =
can
>>>> easily imagine, that once we have some code checked in and start
>>>> actively working on making our first release, that the traffic in =
that
>>>> one list will be larger enough that we'll want to split into
>>>> specialized functional lists, maybe:
>>>>=20
>>>> ooo-general =3D=3D general project discussion that crosses over =
functional
>>>> areas of project.  Everything that doesn't fit elsewhere goes here.
>>>>=20
>>>> ooo-user =3D=3D user discussion threads
>>>>=20
>>>> ooo-dev =3D=3D programming, including QA, UI design, accessibility, =
etc.
>>>>=20
>>>> ooo-doc =3D=3D help and documentation
>>>>=20
>>>> ooo-translate =3D=3D translation
>>>>=20
>>>> I don't think we're there yet, but I can certainly see that =
happening
>>>> in the next few weeks/months.
>>>>=20
>>>> It is also possible that when we get very active, that the
>>>> conversation level on ooo-translate becomes so high that we need to
>>>> split some language discussions into their own list:
>>>>=20
>>>> ooo-translate-jp, ooo-translate-es, ooo-translate-pt, etc.
>>>>=20
>>>> I think we might want that to be driven by actual observed demand.  =
We
>>>> can always create new lists when they are actually needed.
>>>>=20
>>>> But I think for now we want to keep the discussion together in =
larger
>>>> groups.  For example, before we think of having a detailed group on
>>>> Japanese translation, we should probably have higher level =
discussions
>>>> in common, like:
>>>>=20
>>>> 1) Do we want Apache to host a Pootle server?  If so, we need to =
put
>>>> together that request and make it happen.
>>>>=20
>>>> 2) Did the Oracle SGA include all of the language translation =
sources?
>>>> If not, we need to identify what is missing.
>>>>=20
>>>> Another thing to consider is this.  We've all heard the complaints
>>>> about Sun/Oracle and how they managed the OOo project.  Maybe the =
core
>>>> development project was not as open as it could have been to =
outside
>>>> contributions.  Maybe the project leadership was centralized with
>>>> their employees.  Maybe the power was not shared broadly.  These =
are
>>>> all valid criticisms of *that* project.  The natural tendency of =
this
>>>> was to create satellite power centers in the language projects,
>>>> because that was the primary place where you were permitted a =
sphere
>>>> of influence and control.
>>>>=20
>>>> I don't think the new Apache project needs to be, or should be, the
>>>> same way.  There is no central corporate control.  Volunteers from =
all
>>>> former OOo language projects are welcome, and are even encouraged, =
to
>>>> participate directly in all functions of the project.  I'd like OOo =
to
>>>> be a strong *global* open source project.
>>>>=20
>>>> I guess I'm saying this:  Let's not automatically create the same
>>>> project structures as OOo had.  Those were partially created to =
work
>>>> within a corporate-led open source project that distributed power =
in a
>>>> very different way.  Some of the hierarchical structures of that
>>>> project were made to deal with that power arrangement and the =
friction
>>>> is produced.  Apache is different.
>>>>=20
>>>> Of course, language differences and the need to encourage
>>>> participation by all is critical as well.  We may all speak C++ =
very
>>>> well, but not all speak English well.  But I wonder if things like
>>>> Google translate are now good enough that we could manage, with a
>>>> little patience and understanding, to have multilingual =
conversations
>>>> on a single list, at least until the traffic is so high that we =
need
>>>> to split the lists?
>>>>=20
>>>=20
>>> Wow I am getting a very bleak view of all this, maybe I have just =
watched
>>> too many world wide II movies recently. But this seems a lot like =
the
>>> hanging of the Japanese military generals after the war. Or to quote =
one
>> of
>>> the classics:
>>>=20
>>> "Do they speak English in What?" -- Pulp fiction
>>>=20
>>=20
>> I hope you don't get that impression.  Language is one cross-cutting
>> concern.  Another is operating system.  I could argue that Windows
>> programmers don't want to look at all the Linux-specific discussions
>> on the list.  And the 32-bit Windows programmings could say that they
>> don't want to deal with the 64-bit Windows threads.  But I think we
>> would agree that having a list called ooo-dev-windows-64bit-es would
>> be fragmenting things too far.
>>=20
>> The question in my mind is not whether we will need more lists, but
>> when and which ones.
>>=20
>> I think it is absolutely imperative that the programmers be aware of
>> the work going in on the code on *all* platforms, regardless of what
>> platform the programmer is working on personally.  It is one project,
>> one repository.  We can't segregate it.
>>=20
>> On the localization side, I also think it is necessary for all
>> programmers to be aware of all the issues, since they are the ones
>> writing and maintaining the code.  Maybe they won't be experts, but
>> they need to know the basics and be aware of the issues.  So an issue
>> in Japan localization may also be an issue in China and Korea.  We
>> need to have a core discussion on localization and translation that
>> everyone participates in.  Remember also that the issues that come up
>> for us, may be also issues in the ODF standard, and that needs to be
>> escalated, in English, to OASIS and ISO.  And new localization
>> capabilities get added to the standard, in English, and this needs to
>> be discussed in the project, together.
>>=20
>> I understand that when it comes to the translation of individual UI
>> strings, that the discussion then becomes very narrow and specialized
>> and that this will not be of interest to everyone.  But that is no
>> different than a discussion that is only relevant to 64bit Windows.
>>=20
>>> I don't think we should hold a gun to people's head to join a ML =
that
>> they
>>> might not be interested on the first place. Even if it's just to =
request
>> a
>>> new one.
>>>=20
>>=20
>> Would you agree that we need at least a single list, like =
ooo-general,
>> that everyone on the project subscribes to?  I think that is hard to
>> avoid and still call us one project.
>>=20
>=20
> We did had that list http://www.openoffice.org/mail_list.html#general =
and
> even myself wasn't subscribed. So from experince I will say that just
> because we have it doesn't mean that all people in teh project will =
use it.
> Also the issue that we asume that everything will happen on an ML =
might not
> be true.
>=20
> As an example, if you find a bug, you can submit it to the issue =
tracker,
> then a dev will inquiry for additional data and replicate it, forward =
it to
> another dev and fix it. -- No ML necessary. If all the only truly =
unique
> conversation happening should be the comments on the DSCR. Which is a
> monolitic tree and isn't really replicated.

All commits to svn will end up in the ooo-commits mailing list. That =
qualifies as everything in the mailing list.

Also bug reports from either bugzilla or JIRA are typically directed to =
the dev list when that is done it ought to be ooo-dev@i.a.o.
So we are in the mailing list even with the bug tracker. In fact that is =
important because then it is easy for a developer to JFDI.

I like this discussion, in time we'll come up with a good balance =
between what exists and landing at Apache. I see this discussion falling =
into a matrix.

On one axis - Roles - at one or two levels
Marketing -
	?
Users -
	in general
	native language - special needs
Developers -
	code,
	qa,
	language,
	docs,=20
PPMC -=20

On the other axis - Tools
Mailing list
User Forum
Issue Tracker
Wikis
Web Site
Pootle Server
Build Servers
What else?

In each cell describe the interaction with the tool, if any.

There can be three versions of this matrix - The existing =
openoffice.org, a functional plan and finally a map to Apache =
Infrastructure

Best Regards,
Dave


>=20
> At the moment different facebook groups and conversations on linkedin =
and
> twitter are happening that we can argue that is not on one channel or =
even
> ever will connect. I got a user asking a few minutes ago asking on the
> linkedin about if this group will continue now that apache is taking =
over.
>=20
> So again, diversity, key fact to keep in mind.
>=20
>=20
>=20
>>> So I am gonna partially play devils advocate and partially push some
>> things
>>> I have considered a good choice here.
>>>=20
>>> play 1: "Another thing to consider is this.  We've all heard the
>> complaints
>>> about Sun/Oracle and how they managed the OOo project.  Maybe the =
core
>>> development project was not as open as it could have been to outside
>>> contributions.  Maybe the project leadership was centralized with
>>> their employees.  Maybe the power was not shared broadly.  These are
>>> all valid criticisms of *that* project.  The natural tendency of =
this
>>> was to create satellite power centers in the language projects,
>>> because that was the primary place where you were permitted a sphere
>>> of influence and control."
>>>=20
>>> The funny things about complains is that the minute you stop =
listening to
>>> them, is the minute you start listening to the opposite ones. So I'm
>> foward
>>> on the idea that fragmentation of communication is bad. At the same =
time,
>>> ignoring the size and the diverse of the project is also bad.
>>>=20
>>=20
>> Agreed.  Those are the forces we need to understand: diversity and
>> fragmentation.
>>=20
>>> play 2: "I guess I'm saying this:  Let's not automatically create =
the
>> same
>>> project structures as OOo had.  Those were partially created to work
>>> within a corporate-led open source project that distributed power in =
a
>>> very different way."  ---
>>>=20
>>> Aren't you using your corporate power exactly to do this in an =
opposite
>> way?
>>> The structure of OOo had issues, but changing for changing sake also
>> seems a
>>> bit of an overkill. Like I said, we needed a change of the way we =
did
>>> things, but flipping it completely oppoiste is not an answer. I
>> acknowledge
>>> thtat positons in OOo were too bureacratic. But at the same time, it =
gave
>> me
>>> a good framwork to se who to address if there was a need to do =
anything.
>> And
>>> believe me, throwing a question on a general ML was not a good way =
to
>>> identify people responsible in certain part of the site, code, etc.
>>>=20
>>=20
>>=20
>> I don't think I'm using any corporate power.
>>=20
>> I agree that "change for change's sake" is not a good idea.  But I
>> hope you'll agree that preserving the past forms, just because they
>> are familiar, is not necessary the best choice either, especially if
>> we're now in a different environment.
>>=20
>> I think we need to think about what did OOo do before because it had
>> no other choice?  Versus what it did because that is, in the
>> collective experience of the community, the best way of =
collaborating?
>>=20
>=20
> I think we should solve one problem at a time. Trying to engage in too =
many
> battles might make this a big mess. So first I would say, lets find a =
home
> (servers) for OOo. And then hack on it's management, communication =
channels,
> localization processes etc..
>=20
>=20
>=20
>>=20
>>=20
>>> As a general reference, when Google got usenet, he got it all, along =
with
>>> Viagra commercials, and questionable material. I think we should =
first
>> focus
>>> on the migration in its entirety.
>>>=20
>>> The idea of let's start from scratch and grow organically does sound
>> cute,
>>> but I think it will do more damage than good in the close future.
>>>=20
>>=20
>> I think it is worth a discussion, to see what the consensus is.
>>=20
>> -Rob
>>=20
>>>=20
>>>>=20
>>>> -Rob
>>>>=20
>>>> On Sat, Jun 25, 2011 at 10:11 AM, Kazunari Hirano =
<khirano@gmail.com>
>>>> wrote:
>>>>> Hi Rob,
>>>>>=20
>>>>> Please take a look at the Native Language Confederation Projects =
of
>>>>> OpenOffice.org page.
>>>>> http://projects.openoffice.org/native-lang.html
>>>>>=20
>>>>> Every language project has mailing lists.
>>>>> You can check which list is active or not.
>>>>>=20
>>>>> 1 - Afar - http://openoffice.org/projects/aa/lists
>>>>> 2 - Albanian - http://openoffice.org/projects/sq/lists
>>>>> 3 - Afrikaans - http://openoffice.org/projects/af/lists
>>>>> 4 - Amharic - http://openoffice.org/projects/am/lists
>>>>> 5 - Arabic - http://openoffice.org/projects/ar/lists
>>>>> 6 - Armenian - http://openoffice.org/projects/hy/lists
>>>>> 7 - Asturian - http://openoffice.org/projects/ast/lists
>>>>> 8 - Azeri - http://openoffice.org/projects/az/lists
>>>>> 9 - Balochi - http://openoffice.org/projects/bal/lists
>>>>> 10 - Basque - http://openoffice.org/projects/eu/lists
>>>>> 11 - Bengali - http://openoffice.org/projects/bn/lists
>>>>> 12 - Bosnian - http://openoffice.org/projects/bs/lists
>>>>> 13 - Breton - http://openoffice.org/projects/bre/lists
>>>>> 14 - Bulgarian - http://openoffice.org/projects/bg/lists
>>>>> 15 - Burmese - http://openoffice.org/projects/my/lists
>>>>> 16 - Catalan - http://openoffice.org/projects/ca/lists
>>>>> 17 - ChiNyanja - http://openoffice.org/projects/ny/lists
>>>>> 18 - Chinese - http://openoffice.org/projects/zh/lists
>>>>> 19 - Czech - http://openoffice.org/projects/cs/lists
>>>>> 20 - Croatian - http://openoffice.org/projects/hr/lists
>>>>> 21 - Danish - http://openoffice.org/projects/da/lists
>>>>> 22 - Dutch - http://openoffice.org/projects/nl/lists
>>>>> 23 - Dzongkha - http://openoffice.org/projects/dz/lists
>>>>> 24 - Esperanto - http://openoffice.org/projects/eo/lists
>>>>> 25 - Estonian - http://openoffice.org/projects/et/lists
>>>>> 26 - Finnish - http://openoffice.org/projects/fi/lists
>>>>> 27 - French - http://openoffice.org/projects/fr/lists
>>>>> 28 - Friulian - http://openoffice.org/projects/fur/lists
>>>>> 29 - Galician - http://openoffice.org/projects/gl/lists
>>>>> 30 - Gaelic Irish - http://openoffice.org/projects/ga/lists
>>>>> 31 - Gaelic Scottish - http://openoffice.org/projects/gd/lists
>>>>> 32 - Georgian - http://openoffice.org/projects/ka/lists
>>>>> 33 - German - http://openoffice.org/projects/de/lists
>>>>> 34 - Greek - http://openoffice.org/projects/el/lists
>>>>> 35 - Gujarati - http://openoffice.org/projects/gu/lists
>>>>> 36 - Haitian Creole - http://openoffice.org/projects/ht/lists
>>>>> 37 - Hebrew - http://openoffice.org/projects/he/lists
>>>>> 38 - Hindi - http://openoffice.org/projects/hi/lists
>>>>> 39 - Hungarian - http://openoffice.org/projects/hu/lists
>>>>> 40 - Icelandic - http://openoffice.org/projects/is/lists
>>>>> 41 - Indonesian - http://openoffice.org/projects/id/lists
>>>>> 42 - Irish Gaelic - http://openoffice.org/projects/ga/lists
>>>>> 43 - Italiano - http://openoffice.org/projects/it/lists
>>>>> 44 - Japanese - http://openoffice.org/projects/ja/lists
>>>>> 45 - Khmer - http://openoffice.org/projects/km/lists
>>>>> 46 - Korean - http://openoffice.org/projects/ko/lists
>>>>> 47 - Kurdish - http://openoffice.org/projects/ku/lists
>>>>> 48 - Lao - http://openoffice.org/projects/lo/lists
>>>>> 49 - Latvian - http://openoffice.org/projects/lv/lists
>>>>> 50 - Lithuanian - http://openoffice.org/projects/lt/lists
>>>>> 51 - Macedonian - http://openoffice.org/projects/mk/lists
>>>>> 52 - Malayalam - http://openoffice.org/projects/ml/lists
>>>>> 53 - Marathi - http://openoffice.org/projects/mr/lists
>>>>> 54 - Malagasy - http://openoffice.org/projects/mg/lists
>>>>> 55 - Malaysian - http://openoffice.org/projects/ms/lists
>>>>> 56 - Miskito - http://openoffice.org/projects/miq/lists
>>>>> 57 - Mongolian - http://openoffice.org/projects/mn/lists
>>>>> 58 - Nepali - http://openoffice.org/projects/ne/lists
>>>>> 59 - Norwegian - http://openoffice.org/projects/no/lists
>>>>> 60 - Oromoo - http://openoffice.org/projects/om/lists
>>>>> 61 - Papmiento - http://openoffice.org/projects/pa/lists
>>>>> 62 - Pashto - http://openoffice.org/projects/ps/lists
>>>>> 63 - Persian - http://openoffice.org/projects/fa/lists
>>>>> 64 - Polish - http://openoffice.org/projects/pl/lists
>>>>> 65 - Portuguese - http://openoffice.org/projects/pt/lists
>>>>> 66 - Portuguese of Brasil -
>> http://openoffice.org/projects/br-pt/lists
>>>>> 67 - Punjabi - http://openoffice.org/projects/pa/lists
>>>>> 68 - Romanian - http://openoffice.org/projects/ro/lists
>>>>> 69 - Russian - http://openoffice.org/projects/ru/lists
>>>>> 70 - S=E4ng=F6 - http://openoffice.org/projects/sg/lists
>>>>> 71 - Serbian - http://openoffice.org/projects/sr/lists
>>>>> 72 - Shuswa - http://openoffice.org/projects/shs/lists
>>>>> 73 - Sidama - http://openoffice.org/projects/dm/lists
>>>>> 74 - Sinhala - http://openoffice.org/projects/si/lists
>>>>> 75 - Slovenian - http://openoffice.org/projects/sl/lists
>>>>> 76 - Slovakian - http://openoffice.org/projects/sk/lists
>>>>> 77 - Somali - http://openoffice.org/projects/so/lists
>>>>> 78 - Spanish - http://openoffice.org/projects/es/lists
>>>>> 79 - Swedish - http://openoffice.org/projects/sv/lists
>>>>> 80 - Tajik - http://openoffice.org/projects/tg/lists
>>>>> 81 - Tamil - http://openoffice.org/projects/ta/lists
>>>>> 82 - Tatar - http://openoffice.org/projects/tt-crh/lists
>>>>> 83 - Telugu - http://openoffice.org/projects/te/lists
>>>>> 84 - Tetum - http://openoffice.org/projects/tet/lists
>>>>> 85 - Thai - http://openoffice.org/projects/th/lists
>>>>> 86 - Tibetan - http://openoffice.org/projects/bo/lists
>>>>> 87 - Tigrinya - http://openoffice.org/projects//lists
>>>>> 88 - Turkish - http://openoffice.org/projects/tr/lists
>>>>> 89 - Ukrainian - http://openoffice.org/projects/uk/lists
>>>>> 90 - Urdu - http://openoffice.org/projects/urd/lists
>>>>> 91 - Uzbek - http://openoffice.org/projects/uz/lists
>>>>> 92 - Vietnamese - http://openoffice.org/projects/vi/lists
>>>>> 93 - Welsh - http://openoffice.org/projects/cy/lists
>>>>>=20
>>>>> Thanks,
>>>>> khirano
>>>>>=20
>>>>=20
>>>=20
>>>=20
>>>=20
>>> --
>>> *Alexandro Colorado*
>>> *OpenOffice.org* Espa=F1ol
>>> http://es.openoffice.org
>>>=20
>>=20
>=20
>=20
>=20
> --=20
> *Alexandro Colorado*
> *OpenOffice.org* Espa=F1ol
> http://es.openoffice.org