Re: [cdt-dev] Mentoring new contributors

[scalpel4k <scalpel4k@xxxxxxxxx>]

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