> 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?
If you look at logging.apache.org, you see log4j, log4php and log4net among others. These projects have only little in common, except they have similar configuration files. I (log4php) am not even subscribed to the log4net lists. They do not have the same list of committers in common, but sometimes they overlap. But the PMC is global across all products. Guess you can name it "components" as well. There are no guidelines on that. Here is a link which illustrates a bit more: http://people.apache.org/committers-by-project.html Look for the "logging*" sections. Cheers, Christian > > -Rob > > On Mon, Jun 20, 2011 at 5:23 AM, Christian Grobmeier > <grobme...@gmail.com> 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 >> > -- http://www.grobmeier.de
