+1 I'd also add to the list: explaining the reasons behind some of the things how projects at ASF works. Often people new to the ASF complain about the release checks and procedure. When you explain them the legal impact and our quality goals and the community aspects then they quickly understand and even actively support the way we run projects.
People should not do it 'the Apache way' because it is some ceremony, but because it actually makes a lot of sense! Some the interpretation of the mentor role also depends on whether oneself is using the project as well. There are projects (like NetBeans, ISIS) where I mainly help with/focus on legal and infra stuff. And there are other projects where I'm also an active committer. Both cases are fine. But of course as committing mentor one has a way deeper insight into the projects health! LieGrue, strub > Am 03.04.2018 um 08:05 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > Hi John, > > for me it is close to what JB described: > > 1. be there when needed (how do I create a git repo? how do I ask a > JIRA?Why do I need X?....). Even documented, having somebody you can ask > more directly is often valuable. > 2. ensure the releases are legal (+ respect mandatory ASF rules + point out > not mandatory but recommanded rules) > 3. be there to remind community is important and not only code to prepare a > good graduation > > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > 2018-04-03 7:31 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > >> Hi John, >> >> IMHO, a mentor is not necessary involved in the project technics/codebase >> (it's >> actually a bonus). >> >> As a mentor, I'm focusing: >> 1. Insure of the legal aspect of the project (ICLA/CCLA, SGA, ...) >> 2. Help around infra and release preparation according to Apache rules >> 3. Help to promote the project and build communities around >> 4. See if there's potential interaction with other podlings and existing >> TLPs >> 5. Help to go to graduation (following the graduation checklist) >> 6. (optional) Help on the contribution (codebase, website, ...) >> >> My $0.01 >> >> Regards >> JB >> >> On 04/03/2018 12:54 AM, John D. Ament wrote: >>> I've been following along the absent mentors discussion. But I'm >> curious, >>> from both an IPMC member's perspective as well as a member of a podling, >>> what roles do you see for a mentor? What are their responsibilities to >> the >>> podling? >>> >>> We have a few things written down, and I'm not too interested in >> rehashing >>> the written version. But what do podlings need from their mentors? >> Point >>> you in a direction to run with? Do the apache work for the podling? Do >> we >>> (the ASF) need mentors to ensure that podlings are operating within >> certain >>> bounds? Do we rely on mentors to be a read of the pulse of a podling? >>> >>> John >>> >> >> -- >> Jean-Baptiste Onofré >> jbono...@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> >> --------------------------------------------------------------------- >> 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
