Hi,
On 10 November 2011 13:46, Rob Weir <robw...@apache.org> wrote: > It is not clear to me whether the diversity in N-L pages was by design > or simply from lack of coordination. Intentional. My purpose in permitting the project leads in N-L (and for that matter, all the other projects) was based on two principals: 1. pragmatic reality: I didn't have the time to inspect, police, correct all that I envisioned being created, nor did I want to; 2. I believed then and believe now that local autonomy allows for fastest growth and expansion. And I was right. That said, I did have some provisions in place. No ads, for instance, and no offensive material; and the trademarked material could not be altered. As well, I encouraged colour coherence, and, of course, strongly urged parsimony when it came to creating project lists. License had to be the same as the domain-wide licenses. (We did grudgingly allow for some projects to differ, e.g., the Authors' group associated with Documentation, as they strongly argued for CC licenses. As well, the wikis we used could have been clearer as to which licenses were permitted and what the relation of the wiki was to the other domain projects.) Charles and I posted suggestions at http://native-lang.openoffice.org/ (Charles was effectively appointed to front the N-L category but did little in actually scripting the policies or imposing them.) Just has, for example, all > Apache pages have a similar navigational structure, as well as > mandatory content, I think we should enforce the same for N-L pages. > Remember, these pages represent the AOOo project, and therefore > Apache, to visitors who may never see the main English project page. > So we need to make sure that all of our bases are covered in on that > page: license, how to download, ToU, mailing lists, support forums, > etc. And this needs to be done for any entry point the user makes. > So I think we're better off with a cookie cutter approach for the > webpages, with specific areas for extensibility according to N-L > needs. I agree. The issue with the wiki on OOo is a case in point. We need to make it very clear at the outset. There were several attempts to do this, and we can repurpose them, I daresay. The license and aesthetic claims for N-L projects can also be a) repurposed and b) strengthened, if that is our desire. I think at this point, it is. But we also have to clarify what the N-L projects are to be about, if we wish to reconstitute them. On OOo, I designed them to be about education, information, and local marketing; not coding, though localization was strongly encouraged. Primarily, the N-L projects differed from l10n, where coding and much localization was done, in that discussions on N-L lists were in the native tongue of the speakers. I saw this as important and as a powerful lever to open the market. I was right. (That said, it was always my goal and design that the N-L projects would evolve to include more development. There were very few developers of OOo code, and my reasoning was that by progressively introducing OOo both as a product for users in their language, and as a community who operates in their language, and as code they can work with—they would take to it, either out of personal desire or for commercial reasons, even though all code discussions had to be in English. Again, it seemed I was not incorrect in this reasoning, but it just took too long and I had too little support from the contributor companies who by and large could not see the point of the N-Ls anyway.) But I'm not sure that Apache would be right for that kind of logistic, where there are any number of projects operating in the native tongue of the speaker, though where all coding discussions must be in English. However, I do think re-using (or just using plus updates) the extant language for the OOo N-L projects ought to be considered. -louis -louis
