[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: mentoring new members (was: Re: prboom icon removed)



OK, lets set the basis of how we're gonna handle that mentors-mentees
stuff. Shall it also affect the most recent additions to the team, or
we set the zero time right now? If any of the newest member
voluntarily want me as a mentor, please email me, I guess I can have
time for one or two if they're not too time demanding.

Thanks for taking care of that, Gerfried. I guess the wiki might be a
good place to have all that documentation, what do you think about it?

From now on, every addition or removal from/to the team will have to
be announced in this list beforehand, and a current member of the team
assigned as a responsible person for the newest member. If there are
no objections, we will go ahead. I'm not sure if we have to regulate
the case when there are objections, we'll better face it in a case by
case basis as they arise, which I don't expect to be too frequently.

The mentor will be in charge of introducing the newer member to the
current team practices, and monitor the changes that person does in
SVN. It is at mentor's discretion to prefer not to grant inmediate SVN
permissions from the beginning and commit changes him/herself from
patches sent by the newer contributor, or grant him/her SVN access if
s/he feels it's adequate. Lets not overregulate it too much anyway.

That's my proposal at least. Any comments?

Greetings,
Miry

2007/10/29, Gerfried Fuchs <rhonda@deb.at>:
> * Miriam Ruiz <little.miry@gmail.com> [2007-10-29 11:38:03 CET]:
> > 2007/10/29, Eddy Petrișor <eddy.petrisor@gmail.com>:
> > > Do you think my proposed solution (add people with a sponsor) is good enough?
> >
> > I agree that having any newer member assigned to a former member of
> > the team who becomes responsible for checking and mentoring them makes
> > sense. Not that I want to restrict them access to SVN to those that I
> > have assigned to me, but I'd understand that others might prefer to
> > have patches delivered to them for a while before granting them
> > permissions.
>
>  I'm willing to write up some short'n'easy quicksteps about how to
> do the svn checkout and produce a svn diff, mailing it to the mentor
> (including suggested commit message so that part will get taken into
> account, too), that shouldn't be too much hassle. And to be honest, I
> see far more gain in having people in the team that understand that some
> basic checkups are done before giving direct svn commit access, and
> people that would shy away from that are usually not that big loss. I
> wouldn't even be surprised if we not already have people listed as part
> of the team that just signed up for the sake of it and never did
> anything or neither really plan to do so in the future, at all...
>
> > We should decide how to formally do it, so that we don't scare new
> > members, they can have a fair amount of trust, and they can be
> > mentored in our way of doing things inside the team.
>
>  Usually people pretty much understand that trust is something that gets
> earned and not thrown around like candies - such people make a far
> better and especially longer lasting base to build on, they will trust
> in return.
>
> > Also.. will all this apply for newer DDs that join the team? I won't
> > feel right if I had to mentor a DD myself.
>
>  Personally I would be seriously puzzled about DDs creating seriously
> broken stuff, and even though I do have some trust issues with some DDs
> I consider them to be major enough to still work professional to some
> degree. Going through NM should give them pretty better guidelines than
> what we ever want to turn up with.
>
>  So long,
> Rhonda
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-games-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>

Reply to: