Interesting observations. I like the concept of "welcoming committee". I think most people do. The IPMC is supposed to be that welcoming committee. Problem is, IMHO, its sheet size and diversity of opinion makes it pretty unwelcoming and often contradictory in its advice - even when that advice is written in documents.
I certainly agree with your idea of nudging volunteers rather than controlling them. Again I think most people here would agree with it. Mentors, more often than not, do a great job of this. Problem is when the mentors are unable to help for some reason it's the IPMC that is supposed to step up and now we are back at the problem above. The IPMC is a place of endless process and often contradictory documentation. I'm not saying the Ombud role would solve this, but it is certainly a simple, easy to implement experiment. It could also be important to the deconstruction proposal some people support since the Ombud could be the necessary buffer between the board and struggling pTLP's. IMPORTANT: understand this is not a recommendation, there is no need for people to weigh in on this - it would be a distraction. I'm merely observing how one innocuous experiment might pave the way for another experiment (it could be the deconstruction process, it could be something completely different). Ross Ross Gardler (@rgardler) Senior Technology Evangelist Microsoft Open Technologies, Inc. A subsidiary of Microsoft Corporation On 30 July 2013 22:54, Alex Harui <aha...@adobe.com> wrote: > > > On 7/30/13 5:05 PM, "Marvin Humphrey" <mar...@rectangular.com> wrote: > > >Bertrand, Christian, Alex, > > > >On Tue, Jul 30, 2013 at 12:44 AM, Bertrand Delacretaz > ><bdelacre...@apache.org> wrote: > >> people should feel > >> free to contact people that they trust (IPMC members, mentors, ASF > >> members) privately if there's a need, and not having someone elected > >> in the ombudsman role means people are free to talk to whoever *they* > >> think will help. > > > >I question how well the Incubator communicates to newcomers that such > >resources are available to them. What if a podling contributor has no > >"people > >that they trust" because they don't know anybody around here? > I think an explanation of what to do if your mentors fail you would be a > good addition to "What to Expect". I think I proposed one in this thread > a while back. > > I've seen enough grumbling about how hard it is to find the right document > with the right information in Apache that I know it isn't just me. > Honestly, I thought I'd read all of the incubator docs when we entered but > don't recall reading the Process_Description document. But most of the > time, I learn by searching. Trying to read and remember all of the > incubator documentation is overwhelming and won't stick until it becomes > more applicable. That's the value of mentors, they try to keep tabs on > the discussion in the podling and give sage advice and point to the right > document when you need it. What we're discussing here is what to do if > the mentors run out of time to keep up with their podling. For me, I'm > pretty sure that if you or Jim Jag or anyone who thinks they have the time > had emailed our dev list with a friendly welcome and an "feel free to ask > if you need help" I would have remembered that. Maybe an alert needs to > be sent to general@ when a new podling's dev list is ready so friendly > folks can offer their help in a way that gets archived? That happens a > few days after the vote result and IIRC, the well-wishing and welcomes > where then left on general@. > > > > > >I'm also skeptical that the absence of an ombud makes things easier > >because newcomers are "free" to find the best person to talk to. That's > >like > >saying that an airport is better off without a help desk. > My conern with "ombud" is that you don't know who you are talking to. > Airports are relatively impersonal compared to Apache. And folks have > raised concerns about giving someone responsibility for covering ALL > podlings. One thing I learned from other volunteering is that you can't > formalize volunteers too much or force them to do things. It is better to > identify momentum and give it nudges in the right direction. > Creating a role could over formalize what should just be a welcoming > committee. The person with that role is negligent as soon as they run out > of time to welcome the latest podling. I think that's Bertrand's point. > Don't make one person do it, find a way to channel those motivated to do > it. One possibility is a wiki page where each new podling is listed. > Then you or JimJag or anyone can send the "ask if you need help" email and > mark on the wiki page that they did it. Other folks can also add their > welcomes, and you can see which podlings haven't been welcomed. But > nobody is "required" to do it. > > I suppose you could also have a help.a.o page where folks who have time to > back up the mentors can add their names so a podling can look to see who > currently says they have spare cycles to help. That would be your airport > help desk staffed by volunteers, not somebody who "has" to do it. And > then folks can pick who they want to start with. A small photo and > description of who you are would make such a page appear more friendly and > help folks choose. > > > > >The difference between the Incubator's overview documentation (what we > >think > >you need to know) and the information in WhatToExpect (what you really > >need to > >know) is jarring. > > > > http://incubator.apache.org/incubation/Process_Description.html > > http://wiki.apache.org/incubator/WhatToExpect > > > >If we're so approachable, why doesn't anybody know it? > This is another lesson I learned from other volunteering. Nothing ever > goes as planned. The process description is how it should work, but what > to expect is about what will probably happen as you try to execute how it > should work. I don't know if you have kids, but the What To Expect book > about pregnancy was also quite different from what I was taught in school > or saw in movies. > > -Alex > > > > >Marvin Humphrey > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >For additional commands, e-mail: general-h...@incubator.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
