[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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