[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Mentoring new contributors
|
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
