Ross Gardler wrote: > Addi wrote: > >David Crossley wrote: > >>Thorsten Scherler wrote: > >> > >>><snip valuable background information/> > >>>...snip lots of good discussion... > >> > >>>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. > > There are *no* additional requirements to being a PMC member than there > are to being a committer, therefore no additional "pressure". ...
(I need to clarify Ross' statements, so i split this paragraph apart. Also it is good to build upon this, to ensure that everyone who cares can know our background.) The PMC as a whole does have additional responsibilities: http://forrest.apache.org/guidelines.html#roles > The only > reason for a PMC is that some things need to be discussed in private. That is creating confusion between "the PMC" and the "private pmc mailing list". Ross is talking about the reasons for the private mailing list. The PMC does as much business as possible on the dev mailing list. The main reason for a PMC is the Apache Software Foundation, being a corporation, needs to meet statutory requirements and also have a mechanism for oversight of communities and software distributions. The board establishes various committees to have such management oversight, with each PMC chair having primary responsibility. I don't dare to explain further. We carefully evolved this document to say it as well as possible: http://www.apache.org/foundation/how-it-works.html#structure Back to the reasons for a private discussion list: > These things are few and far between, votes for new committers, reports > to the Board, security issues etc. Mainly for a place to discuss private things when necessary, e.g. personal and security issues. At Apache Forrest we decided to also conduct votes for new PMC members/committers in private so that we can speak frankly and any one of us can say, "No we need to wait a while for this person, for these reasons". We feel that such stuff is not good to do in public. Other ASF projects do it differently. You mention "Board report" as being a private issue. Not really. The quarterly board report is entirely my responsibility as the PMC chair. I don't need to discuss it with anyone beforehand. However i do seek the input of the Forrest PMC, as that is the way that i do things. Until now i have been doing that on the private PMC mailing list. I reckon that will change. Of course the board minutes become public anyway: http://www.apache.org/foundation/board/calendar.html (Forrest reports start May 2004, then Aug, Nov, Feb.) > (PMC members have a binding vote, I'll come to that later) > > >>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. > > > >Maybe this concept should be added to the new committer doc so it is > >stated clearly what the expectations of a comitter are. I am not > >terribly involved in Forrest at this time, but even I feel guilty when I > >don't have time to read the mail lists or tinker in Forrest for a > >while. Now, that is part of my personality but I suspect that many > >people who commit themselves to projects like this naturally have a > >similar feeling of responsibilty (and internal pressure). > > +1 You are so insightful. That is spot on. Committed people create their own internal pressure by virtue of their dedication. Being able to manage one's personal pressure is life's art. This is the perfect point to ask everyone to read these two important messages about what it means to be committed and then managing one's energy and dealing with volunteeritis. http://www.apache.org/dev/committers.html#volunteer As usual, Roy's messages cut straight to the point and there is no need for any reply. > Davids words are very important. There are *no* expectations on any > member of an Apache project. We like people to be involved and we reward > contributions (meritocracy), but we do not punish a lack of > contributions. People come and go as their needs change and we adapt to > those changes. > > >>>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. > > I would say there *can't* be a "learn first" approach. When have you > learnt everything? > > >While I agree with Thorsten that these are important things to know, I > >don't believe it is a focus limited to committers. I believe it should > >be something that devs pick up as well and I think that spending a > >decent amount of time on the dev list and really reading what is going > >on serves this purpose maybe more than you think. See below for more. > > +1 > [ snip a stack of good stuff ] > > In other words, I totally agree with Addi, if you are trusted to commit > you should be trusted to vote. > > >it seems to me > >that they have looked at that person's work and attitude for a certain > >amount of time and decided that they trust that person enough to let > >them tinker directly with the code. That is a huge responsibility from > >my perspective and to allow that but not really allow them into the > >project itself strikes me as a little weird. Sort of giving them a > >direct hand in the DoC part of CoPDoC, but not letting them fully into > >the CoP part. > > +1 Very well said. > > >If the concern for an incubation place is not code, but project > >management, then why not consider the opposite of the "incubator" being > >proposed and create a PMC incubator where potential committers can be > >given more direct involvement in the project management/infrastructure > >side of things without the right to commit yet? I don't know how/if > >that could work because obviously I'm not in the PMC and honestly I'm > >not sure what all that entails. > > Actually, I think the PMC is its own incubator. I'm not sure that we > need some "school" for PMC members. > > >I am also not entirely sure that I think a distinct incubator is a good > >idea altogether. It seems to me, that if used properly by the PMC, the > >dev list is already a good place for incubation and assessment of > >potential committers. A lot is in here if you pay attention. Perhaps > >taking the mentor role more directly on the list (like when Ross put on > >his mentor hat with Anil) would serve our purposes. You are absolutely right Addison. The project's public mailing lists are the real community. The dev list is the place where such "incubation" should happen. We already do such mentoring as individuals (no need for specific hats). We need to do more such reminders and discussion about the ASF community ways. You will notice that my technique is to deliberately over-describe when people ask a question and i make an example out of the situation. The receiver needs to know that the target is really the wider community. Sometimes i manage to go the extra step and re-use those words in documentation, e.g. our project guidelines and where possible raise topics to the top-level documentation at w.a.o/dev/ and /foundation/ Hint: Anyone can contribute: www.apache.org/dev/infra-site.html These topics seem to need to be discussed over and over, e.g. new people need the background. The repetiton does take time to read for the old hands, but we learn something new each time and the way evolves. Oftentimes we should be able to refer to documentation. Ross continued: > > I have a background in training and education, such a "mentor" role > comes naturally to me. In the case of the GSoC I have a responsibility > to Anil to act as his mentor. Before GSoC started the Forrest PMC > requested that I conduct all *relevant* mentoring onlist because it is > of value to the community as a whole. > > Perhaps the PMC Incubator that Thorsten feels there is a need for should > actually be more effort on the part of the community (not just PMC > members) to ensure that we are all aware of the responsibilities of a > committer to the community. > > For example, this thread started on the PMC list but was moved here at > the insistence of some of our more experienced PMC members, who pointed > out that this is a community issue not a private issue. Without this > positive mentoring from experienced PMC members we would never have > heard Addi's excellent contribution to the thread. > > (I call it excellent because it is well reasoned and community focused. > It is a coincidence that I agree with his views. I am sure others will > agree with Thorstens proposal so please don't stay quiet, read Addi's > words and recognise that the focus is on community contributions - we > need you contributions to make this thread even more valuable - > especially if you stand on the other "side" of the debate) Hear, hear. We don't intend to squash anyone's concerns. We need more talking to get to the core of this thread's topic. Identifying the perceived pressure situation is one step closer. > --- > > One last point not raise yet. One of the dangers of giving early commit > access is that you can end up with lots of code that is not supported. > This is OK if it goes into the whiteboard where we can retire it easily. > But full commit access means people are free to add stuff to trunk, > often too early. The ANT project had a big problem with this and, as a > result, they made it harder to become a committer. That is another key observation. Thanks. David
