Could you say a little about "subprojects" and how they work at Apache? Are they the same as "components"? Do they have their own PMCs and their own list of committers?
-Rob On Mon, Jun 20, 2011 at 5:23 AM, Christian Grobmeier <[email protected]> wrote: > Rob, > >> And then there are other functions that helped promote and support the >> releases and the users who adopted the releases: >> >> - marketing >> - support forums >> - event organizers >> - and many other similar functions >> >> I think these groups are welcome to join the Apache project, but they would >> need to consider the trade-offs. If they have autonomy now, run their own >> servers, elect or appoint their own leaders, etc., then moving to Apache >> means merging their structures into the Apache project, mapping their roles >> into contributor/committer/PMC member roles, adopting their web sites to the >> Apache infrastructure, working openly on the Apache mailing lists, allowing >> anyone to work on it, as well as allowing anyone to review and comment on >> their work. In other words, they give up some control and in return have a >> potentially larger group of people to help them. > > You are right, they share control. This is what every apache project > has to consider. But anyway I would welcome every of the groups which > wants to join. There is a Community project at the ASF (Ross is active > there) and there is an Event-Project around, who already organize > Barcamps and such things. I can imagine that a merge of that groups to > the other ASF groups will give some kind of turboboost to all related > parties. > > Marketing: this is so important for ooo. Do you think it would be > efficient to let them do their job "somewhere outside"? I am afraid in > that case communication will start leaking and marketing will finally > stop somehow. The near "location" of these two groups, dev and > marketing is a benefit. And if marketing people would like to join, I > think I would be very glad. > >> But let's be honest. If the Romanian language project decided to work >> entirely in Apache on their translations, the chances are that very few >> existing Apache members would be of much assistance to them, as a volunteer >> or as a reviewer. So I'm not seeing a compelling benefit for all of the >> language projects to join Apache. But I could see something like this: >> >> - Language projects remain autonomous, but agree to put a compatible >> license on all of their work, e.g., the Apache 2.0 license >> - Each language project appoints one of their members to join the Apache >> OOo list, so we can stay coordinated. >> - Ideally, there will be one or more volunteers from the language >> projects who get more involved, in larger localization issues, and via >> their >> feedback and patches, ensure that OOo continues to meet the needs of a >> international audience. These volunteers would likely then be voted in as >> committers and PMC members. > > So, if the language projects are outside from the ASF, do we need to > copy over their files into our own source control? Or is it "just a > dependency"? If we need to copy the files over, how can we make sure > the IP is clean? > > Maybe the language project should be treated as an own subproject > within OOo. But I don't think it would be so much easier for all the > language people to stay outside the project. At least when you start > having some "core volunteers" at the ASF doing the bigger chunks > you'll end up having a i18n structure at the ooo project and probably > a subproject. > > At least I guess it is not very motivating for people. I mean, one > could say, he has done something for OOo, but is not part of the team. > >> For marketing, user forums, event organizers, etc., I can easily see these >> being done in the Apache project, to the extent they are "international" in >> scope. But It isn't clear how in an Apache project we would coordinate a >> group that, for example, was only interested in planning marketing, support >> and events for Romanian OOo users. > > Please look at this page: > http://barcamp.org/ > > This might be a good starting point for such a discussion. > > I am not 100% sure how these barcamp stuff all works. I just know > there are ASF fellows who work with that. > > Additionally we could collaborate with community.apache.org. > > If we can propose some kind of a standard way for the organizing > people, then we have made the game. I somehow believe it could happen > with the three elements: > - Orga-ooo for generel questions, tipps, announcments > - community.apache.org for - no idea - ASF wide marketing, help, > community building? > - barcamp for the organizing of events > > >> I'd be interested in other views on this. In particular, if we went down >> the other road, and assimilated all language projects into Apache, how does >> the process of lose consensus and meritocracy work if project members are >> segregated into mailing lists where discussions occur in, e,g., Romanian. > > Good question. > > My first idea would be, ooo needs subprojects. > > ooo-language as a global i18n container > ooo-romania as a local part of this project > > I believe the romania people can have their consens on language > related matters on their own (wording, grammar etc.). > For all things which are more global (whatever that could be) the > ooo-language list is needed. For example, format of the i18n files, > new language discussions, or other decisions. > > >> So in summary, I think the different function groups need to consider the >> costs and benefits of adapting to an Apache project model, which would >> include: > > Yes. > > Not sure what the others mentors say. But my personal feeling is, a > project should work on one place. I am not sure if a separated ooo > will survive. > > BTW, my answer are feelings and opinions, not "mentor advises". In > fact I have no experience with what I responded too and just want to > help to get out the best. > > Cheers, > Christian > >> >> - Working openly on the Apache mailing lists, allowing anyone to >> participate and allowing anyone to review your work, and potentially even >> veto it. >> - Moving servers and websites onto Apache infrastructure >> - Giving up titles from other organizations and working in the Apache >> project meritocracy >> - Agreeing that your product contributions will be available under Apache >> 2.0 license >> >> >> >> -Rob >> > > > > -- > http://www.grobmeier.de >
