[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Mentoring new contributors
|
On 03/09/15 10:27, Jan Baeyens wrote:
<snip>
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 the same experience with mails to the list, bug reports and
patches (on the bugtracker and gerrit). Another big problem I see is the
complexity of gerrit. It took me more than an hour to push a patch and -
from following the list - I have the impression that it's not a seldom
thing that people have problems with gerrit.
Because of that I'm sitting on quite a few patches and improvements I
just maintain privately. Even worse, when I found something not quite
working in CDT (comment handling, AST pretty printing, bindings, type
evaluation, ...) it was faster and easier to just rewrite it from
scratch than improving the code already in CDT.
I agree with Jantjes feedback; I don't think the lack of familiarity
with the codebase is the biggest issue. A good enough programmer can
work around that. But of course even better if he gets some help from
the community.
Thanks!
Marco
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
