Hi, This is best time to talk about goals. Migrating to new infrastructure is best time to hard thinking about whole project.
In my base conception we should use minimal structure for new OOo. In my level this should view like that: 1. users (they don't know anythings except release version program, they performance and stable working in they work), 2. translators (they don't want develop, but can translate contents to native languages), template designers, web page maintainers etc. (publishers at all), 3. developers (big group with inner structure with access to sub-repositories and own goals) - testers - with higher priority bugs (than normal users) report, test case prepare and check before release version - coders - you can try guess :) - user interface planing and resource preparing -> images, new interfaces concepts etc. - planing headmasters - create compact specification and development road map. (decision level) I create first message based on this. Please forgive me if I start this topic too early, but as You can see, this have very deep consequences. 3 master groups is enough to create efficiently best office software. We can easy visual this as flow and apply on creating new structure. I have question for everybody: What we have accomplish? At the moment we have only this: http://www.chip.pl/images/logotypy/tumblr_kvgfz0ehyf1qacd5ko1_500.jpg/image_mini http://lwn.net/Articles/446093/ That's isn't enough... 2011/6/22 Dave Fisher <dave2w...@comcast.net>: > > On Jun 22, 2011, at 12:25 PM, Rob Weir wrote: > >> On Tue, Jun 21, 2011 at 6:25 PM, Grzegorz Rajda <melloned...@gmail.com> >> wrote: >>> Good evening, >>> >>> All write this to other mailing-list as response to mail from Key Schenk. I >>> wan't discus this with You and back to OOo development. What You think about >>> that? >>> >>> Last changes in infrastructure (Oracle, LibreOffice etc.) needs from us new >>> goals to create reborn release of OOo. I have some ideas and proposals. >>> >>> 1. Easy structure: >>> - one page in native languages (auto-detect language, use right strings) >>> - one repository for code (if somebody can commit, they can do something for >>> whole source code, one method, without individual keys) >>> - one bug-tracker for any language with bugs merging (developers who know >>> english and navive lang should merge bug reports.) >>> - one code, one standard, one development guide for everyone. (should have >>> specification of interface planing/create and programming) >>> >> >> "Make things as simple as possible, but no simpler", as Einstein said. >> >> There is a natural tendency toward fragmentation and wall-building. >> Coordination has a cost and it is very easy to break into small >> groups, by language, as well as by function groups (QA, marketing, >> etc.) and to further subdivide by sub-functionary areas. That is how >> bureaucracies form. "I am the chief assistant secretary to the >> assistant chief director". It is also how specialists find a >> specialty. "I am a ear doctor, but I specialize in left ears only". >> >> So there are danger of having too many groups. It narrows the our >> focus, I think. >> >> On the other hand, we probably cannot put 200 active people into a >> single mailing list. >> >> So I'd propose that we answer the question: What is the *least* >> amount of project structure necessary for us to succeed? We can >> always add more structure and more layers later. But once we've built >> community walls, it is hard to later tear them down. > > I propose that we use ooo-dev - there are some good long running threads > going. > > Until we start seeing how the native language projects go, then we can > evaluate the true need and available support for additional mailing lists. > > I think the "Commit then Review" committer/PPMC member peer group vs. the > "Review then Commit" developers with and without ICLA is a big distinction. > > We've been overusing ooo-private (because there is a lot to establish and > learn) we need to stop and make sure that we are all one community on one > list. It's going to be chaotic, but a new order will form. > > Individuals now have the option of using the Community Wiki to put together > ideas and then come here and discuss these and refine them. I've got some > about PDF workflow, but I am waiting for awhile ... > > Regards, > Dave > >> >> >> Regards, >> >> -Rob >> >>> Result: >>> - openoffice.org - in native language direct >>> - openoffice.org - easy to use one support (language automatic) >>> - openoffice.org - have only required and optional files in source code >>> repository >>> - openoffice.org - have easy to contribute web interface (for example for >>> translating [web, help, etc.]) >>> - openoffice.org - easy to programmers contribution, >>> - openoffice.org - is best than MS Office in all releases! >>> >>> 2. In future: >>> - every day we have new developers >>> - every day we have more optimized algorithms >>> - every day we have best closed standards reverse engineering >>> - every day we have more happy users >>> - every day we win in all categories with our competition! >>> >>> We can do it together! How You think? >>> >>> -- >>> Best regards, >>> Grzegorz alias Mellonedain >>> > > -- Pozdrawiam, Grzegorz
