Thanks so much for taking the time to reply to this important topic. A big effort, i can see.
I am going to reply to this in bits and pieces i.e. not all at once tonight. Please would other members of our community (everyone, not just PMC members) also add their view. More below ... Thorsten Scherler wrote: > Nicola Ken Barozzi wrote: > <snip valuable background information/> > > > > If we want to include "simple committership" as a role, I would like to > > hear someone explain how simple committership will solve more > > issues than it may cause, especially given the above. In particular, I > > would like to have some real-life examples that show how simple > > committership would have been useful. > > Like David and Nicola stated the Forrest project normally votes all > committer directly into the PMC as well. I personally see special > occasions (besides GSoC) where I would like to see a "simple > committership" or like I would call it "PMC incubation". Here you say "special occasions". We do already have the capability to add people as committers which are not being PMC members also. However you are actually talking below about this being the normal course. > It should > follow the basic idea of the Apache Incubator [1] which is for new > projects at Apache. > > "A large part of the Incubator's effort will be devoted to providing > documentation on how the Foundation works, and how to get things done > within its framework. As a consequence, it is expected that the > Incubator will also become a reference for new contributors to any of > the Apache projects." Unfortunately not much of that documentation has arisen. People seem to rush onwards and forget. People coming afterward need to learn all over again. > My reasoning is that we can ensure that this "newbies" can learn the > apache way to it fullest (which is one of the most important point in > the process to become a PMC member) without the "pressure" to be an > official PMC member. But it is a never-ending process. We are all continually learning. And most important, that "way" is evolving. So for "newbies" (all of us actually), the only way is to start walking. There should not be a fence across the path which causes us to wait until deemed capable. It is the mention of "pressure" that i wonder might be the key to your concerns. Apache projects should be fun, no pressure. I hope that you are aware that as a PMC member, or as a developer, you do as much work as you feel like doing. You do not need to participate in every discussion, just because it concerns the PMC. Neither do you need to participate in every vote or in every development issue. The more committers we have, the more pairs of eyes are watching the svn diff emails. But every committer cannot be expected to notice every problem. Unlax, doc. Let the averages work for us. As long as each of us do make some little effort, then the whole will work. > New committers have to learn > a) "how the Foundation works" > b) "how the Project works" > > One can argue that this should be learned before becoming a committer on > the mls but I see a certain process behind it which takes time (some > times too much). Therefore there should not be a "learn first" situation. > Now it was asked for a "real-life example". > > That could be myself. ;-) > > I have been a Wyona CMS committer before it became an official Apache > Incubator project. The company Wyona donated then the code base to the > ASF as cocoon subproject in incubation called Apache Lenya. I had > "general" experience in how a open source project and community is > working but that have been quite different from the ASF way that I had > to learn. > > Within the one year where Apache Lenya has been in the incubator I > learned the basics (IMO learning) on "how the Foundation works" (a) > (never stops). As Apache Lenya committer we were given not only > committing rights to lenya but as well to cocoon, forrest and xml. That was not the usual way. Normally one only becomes a committer for the specific project that you are directly involved with. This thing about Cocoon committers being given commit access to Forrest, happened a long time ago, before Forrest was a project of its own. We have already said that the situation needs review, now that we are a top-level project. It was an experiment to attempt to boost the Forrest base. At one stage the project was floundering with not enough developers. Interesting that it did not attract many people from the Cocoon community. I am sure glad that you are here, but i reckon that you would be here even if we did not have that arrangement. You would have contributed patches, and we would have noticed your commitment and made you a PMC member. Also it would have been only for "xml-commons", not for every project at xml.apache.org e.g. Xerces. > I started to use them here on forrest when getting into the > documentation for lenya. In lenya we are using forrest to create our > documentation and website. We had a custom skin and heaps problems with > maintaining it because forrest is developing very rapid. > > The lenya skin was nearly all div based. At the time I started here in > forrest there was an issue about an "all div based" skin. The result is > called "pelt". While I was developing the skin I had "simple > committership" to forrest. I am happy that I could concentrate on > developing the skin and meanwhile learning all the new responsibilities > of a PMC member. After a while I was invited to join the PMC and helping > on the long run of forrest. > > I could fully participate in the project as committer. I just did not > had a counting vote but normally forrest consider every concern. Thankfully we all agreed with your work. It could be disastrous if we didn't agree and you had no binding vote in the matter. > One thing that helped me is that the PMC normally watch the committs of > new committer more careful to ensure that e.g. all legal issues are > meet. > > PMC membersnot only have to help new committers to learn the duty of a > PMC member in the specific project (b) but also like the incubator teach > the values of an ASF project and its duties (a). There have been a > thread on all PMC lists about the duties (around 10 points) of a PMC > member by Davanum Srinivas. > > I was given committership to apply my own patches for cocoon, forrest > and xml. That leveraged this project (faster process) because other PMC > members do not had to do that. Then especially David taught me as well > the PMC duties and I became a PMC member. The main reason that there was a delay with you becoming a PMC member, was because we had to spend many months discussing our project guidelines before we could get any new people as PMC members/committers. Pulling in one of my comments from earlier in this thread: >> >> When we look for new committers, we need to see a few >> qualities. They should be helping other users and >> developers, able to work co-operatively, be a mentor, >> and be repectful of others opinions. Essentially be >> committed people who understand the Apache way. Rather than "understand", i meant: show that they have at least some clues and have the potential to learn the way. Not expected to know it all yet. Some people have no idea how to behave in a co-operative manner and only have respect for themselves. We do not encourage those types. > The important point is that new committer are generally > overwhelmed by the information and infrastructure of the project and the > ASF. Some learn better step by step understanding what is ASF all about > and what a PMC member have to do (I consider myself as such a > somebody). > > I was lucky and made my experience in the incubator *and* here but the > committers we vote in normally do not have this "incubator" experience > which I consider most valuable. Take me as a different case. Cocoon was my first real opensource project. I had no Incubator to go through. The Cocoon people were nice and helpful all the way. But still i had to figure most of it out for myself, before and after becoming a committer. That is still the case being an ASF member. I still stumble in the dark. It is ongoing, and only the committed remain. > > In essence, Jakarta became a small Apache, creating sub-roles where > > the > > PMC members were like Apache members, and committers were like PMC > > members. In Jakarta it's usual that committers vote, but in fact their > > vote is not legally valid, and they *cannot* release code without a > > PMC > > vote. > > This also created a big disconnect between the Board of Directors and > > Jakarta, and most projects were having little or no oversight, and the > > number of Jakarta committers that was an Apache member was extremely > > low. > > The point you are maybe up to is that we can create a closed group that > new committer are not able to enter. We limit the PMC membership to a > certain group of people for whatever particular reason. > > The downside is that committers cannot be responsible for the projects > because they are not in the "management" PMC. That will slow down the > progress of this project(s) because it slow down their processes. > > I guess it happened because many projects emerged from Jarkata (e.g. > tomcat, struts,...) and people felt better in having a good working team > then to better leverage their pmc duties in teaching new committer this > duties. > > One sentence of [2] seems very interesting at this point: > "Section 6.3. Project Management Committees. > ... > Each Project Management Committee shall be responsible for the active > management of one or more projects identified by resolution of the Board > of Directors which may include, without limitation, the creation or > maintenance of "open-source" software for distribution to the public at > no charge." > > Now *one or more projects* means that is thought of leveraging not only > e.g. jarkata but all sub projects that may emerge. That needs a good > working PMC team that can trust each other (most important on legal > issues etc.). Sorry i don't understand what you mean about Jakarta. The "one or more" in the ASF bylaws was to allow scope. However the umbrella project concept seems to be discouraged now. One PMC, and many committers that are not on that PMC, just does not work. > Why are we not adding to the committer role the 'PMC-incubation' label > and apply similar rules (we have in the incubator for exiting the > incubator cp [3]) to become a PMC member. That will as well make sure > that new members will *definitely* enter after "incubation" and overcome > the jarkata phenomenon. I do not see how we could make such "exit rules". It is okay to make rules for projects, but rules for measuring people is fraught with difficulty. > In another thread you wrote about becoming PMC/committer: > > "...But we should not try to measure this with an absolute metric: > > merit does not earn membership, it earns trust of others members. If > > other members trust him based on the contributions, then IMHO there is > > all there is to it." > > I develop trust with time. ...but I can trust somebody to make chances > (contributions) and I can trust someone making decisions. > > That is a different level of trust we are talking. I will need to ponder that before answering. -David > I consider a clean > process of learning about the ASF as better. I started in incubator > (with lenya) to learn about the ASF and I still learn everyday. > > Going from dev to committer and after "PMC-incubation" into the PMC is > IMO the best way to develop trust in someone. I think it is better as > limited committership or directly enter in the PMC (which normally takes > a good amount of time). > > I hope this "real life" use case shows, that there are persons that will > welcome a guided process that as well contain a simple committership > "PMC-incubation" role. > > [1] http://incubator.apache.org/ > [2] http://www.apache.org/foundation/bylaws.html > [3] > http://incubator.apache.org/incubation/Incubation_Policy.html#Exitting > +the+Incubator > -- > thorsten > > "Together we stand, divided we fall!" > Hey you (Pink Floyd)
