Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Mentoring new contributors

A few observations. 

Since joined the list I have observed that most proficient committers active
on this list are driven by their employer having self interest in the code
base. As an example you can look at the CDT/whoswho:
https://wiki.eclipse.org/CDT/whoswho . And I saw that other proficient
committers are quite involve in the academic world as well. For example I am
aware about a few of them working with Trace Compass at Ecole Polytechnique
School (Montreal,QC). And in fact my point of view is that the mentoring
proposed Nathan Ridge works well and is already in place for the CDT code
base. The problem is that if you don't joint a company who's already
involved in the code base you are of luck for potential mentoring.

I understand quite well how mentoring can be time consuming. Your employer
doesn't pay you for this and this is understandable. 

If it happens you work with a code base within CDT which is quite active
then you might have more luck and any fix might be much more likely to be
reviewed and commited. This is true if the code is critical for the
experience of the CDT code base. Thus this is why Michi was well served from
my point of view.

On my side unfortunately most of my fixes belonged to the Managed Build CDT
code base. And the QA owner of this code base (Chris Recoskie) doesn't seem
to have the availability to coach or help people of this list with the code
base (this is not a blame). Thus I was out of luck and I agree that a good
programmer will eventually find its way through the code base. But having
had a mentor to guide me would have spared me a lot of time (many days) to
understand the code.

Note that I am observing if my Gerrit commit to add feature/fix bug to
support a full implementation of the Visual Studio toolchains will be
reviewed. If after some time (I am patient) there is no interest to review
and commit the code then.oh well.I am already so busy at work.why bother.

BTW thank Nathan for the suggestion of mentoring. I am available to be a
guinea pig.

Guy

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of scalpel4k
> Sent: Monday, March 09, 2015 10:54 AM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Mentoring new contributors
> 
> What about adopting the process in place?
> What I can tell, the gerrit workflow works pretty well. Personally, I have
> always been "serviced" instantly and adequately.
> I really can't see any other hurdles than those outlined by Nathan - a
huge
> code base where you have to find your way around ....
> 
> just _my_ 2 cents
> 
> bye Michi
> 
> On Monday 09 March 2015 10:27:26 Jan Baeyens wrote:
> > Thanks for bringing up this issue.
> > Before going into solutions I think a look at the root cause is
appropriate.
> > From past experiences I think I know part of the root cause of a
> > fairly large backlog of unfixed bugs and unimplemented feature
> > requests for a developer used tool.
> > I reported bugs and provided fixes in the past (not as pull request
> > but as code) and basically I never got any response.
> > I have seen other people experiencing similar things. IMHO the
> > non-responsiveness on bug fix proposals of the community is a major
> > showstopper to have the community help fixing bugs.
> > Being a IBM employe I fully understand the complexity of legal
> > implications of "accepting code" which makes I understand it is never
> > easy to accept a bug fix from an external source.
> > However IMHO there is no process to accept code that is not offered as
> > a "pull request" or that process is not executed properly.
> > I feel this issue needs to be looked upon closely before jumping to
> > solutions.
> >
> > Just my 2 cents.
> > Jantje
> >
> > On 03/09/2015 01:12 AM, Nathan Ridge wrote:
> > > Hi,
> > >
> > > As you're aware, CDT has a fairly large backlog of unfixed bugs and
> > > unimplemented feature requests.
> > >
> > > As an IDE, our users are themselves programmers, and therefore
> > > likely have the programming skills necessary to fix many of these
> > > bugs. As an open-source project, "fixing bugs yourself" is not only
> > > possible but encouraged.
> > >
> > > The remaining factor that I believe holds back many users from
> > > fixing bugs they care about, is lack of familiarity with the
> > > codebase, and the high learning curve required to dig into it.
> > >
> > > I wonder if we could help address this by offering to mentor /
> > > provide guidance to contributors wishing to fix bugs themselves.>
> > > Mozilla - another large open-source project - has a somewhat
> > > formalized
> system of mentorship, where experienced contributors can mark bugs as
> being mentored. Such a marking means:
> > >    - That the bug is simple enough that, with some guidance from
> someone
> > >    more experienced,>
> > >       someone new to the codebase should be able to fix it.
> > >
> > >    - That the contributor marking the bug as such commits to walking a
> new
> > >    contributor>
> > >       through the process of fixing the bug.
> > >
> > > Logistically, such marking is done by adding "[mentor=<mentor
> > > name>]" to the Whiteboard field of the bug in bugzilla, along with
> > > any other relevant tags, such as "[good first bug]" in the case of a
> > > bug which is particularly simple and thus suited as the first bug
> > > for a new contributor to work on.
> > >
> > > What do you think about adopting a similar system? I can think of
> > > several bugs which would be suitable for mentorship, and which I
> > > would be willing to mentor, under such a system.
> > >
> > > Regards,
> > > Nate
> > >
> > > _______________________________________________
> > > cdt-dev mailing list
> > > cdt-dev@xxxxxxxxxxx
> > > To change your delivery options, retrieve your password, or
> > > unsubscribe from this list, visit
> > > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or
> > unsubscribe from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit https://dev.eclipse.org/mailman/listinfo/cdt-dev



Back to the top