On Sat, Jun 25, 2011 at 11:36 AM, Rob Weir <apa...@robweir.com> wrote:
> On Sat, Jun 25, 2011 at 12:10 PM, Alexandro Colorado <j...@openoffice.org> > wrote: > > On Sat, Jun 25, 2011 at 10:23 AM, Rob Weir <apa...@robweir.com> wrote: > > > >> 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 :-( > >> > >> I can see three ways to decide what to do (but maybe someone has other > >> ideas?): > >> > >> 1) Recreate the structure of the OOo lists, making lists for all > >> language groups, whether or not they are active. > >> > >> 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). > >> > >> 3) Create lists only when there is a sufficient number of project > >> members on the Apache list asking for new list. > >> > >> 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? > >> > >> 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: > >> > >> ooo-general == general project discussion that crosses over functional > >> areas of project. Everything that doesn't fit elsewhere goes here. > >> > >> ooo-user == user discussion threads > >> > >> ooo-dev == programming, including QA, UI design, accessibility, etc. > >> > >> ooo-doc == help and documentation > >> > >> ooo-translate == translation > >> > >> I don't think we're there yet, but I can certainly see that happening > >> in the next few weeks/months. > >> > >> 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: > >> > >> ooo-translate-jp, ooo-translate-es, ooo-translate-pt, etc. > >> > >> I think we might want that to be driven by actual observed demand. We > >> can always create new lists when they are actually needed. > >> > >> 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: > >> > >> 1) Do we want Apache to host a Pootle server? If so, we need to put > >> together that request and make it happen. > >> > >> 2) Did the Oracle SGA include all of the language translation sources? > >> If not, we need to identify what is missing. > >> > >> 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. > >> > >> 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. > >> > >> 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. > >> > >> 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? > >> > > > > 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: > > > > "Do they speak English in What?" -- Pulp fiction > > > > 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. > > The question in my mind is not whether we will need more lists, but > when and which ones. > > 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. > > 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. > > 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. > > > 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. > > > > 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. > 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. 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. 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. So again, diversity, key fact to keep in mind. > > So I am gonna partially play devils advocate and partially push some > things > > I have considered a good choice here. > > > > 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." > > > > 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. > > > > Agreed. Those are the forces we need to understand: diversity and > fragmentation. > > > 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." --- > > > > 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. > > > > > I don't think I'm using any corporate power. > > 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. > > 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? > 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.. > > > > 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. > > > > 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. > > > > I think it is worth a discussion, to see what the consensus is. > > -Rob > > > > >> > >> -Rob > >> > >> On Sat, Jun 25, 2011 at 10:11 AM, Kazunari Hirano <khir...@gmail.com> > >> wrote: > >> > Hi Rob, > >> > > >> > Please take a look at the Native Language Confederation Projects of > >> > OpenOffice.org page. > >> > http://projects.openoffice.org/native-lang.html > >> > > >> > Every language project has mailing lists. > >> > You can check which list is active or not. > >> > > >> > 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ängö - 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 > >> > > >> > Thanks, > >> > khirano > >> > > >> > > > > > > > > -- > > *Alexandro Colorado* > > *OpenOffice.org* Español > > http://es.openoffice.org > > > -- *Alexandro Colorado* *OpenOffice.org* Español http://es.openoffice.org
