Bug 393430

Comment 1 Deepak Azad 2012-11-14 17:50:32 EST

Yesterday I attended the Vancouver Eclipse Hackathon [1]. It was fun and the people hacking on JDT managed to create a few patches. A hackthon, where you work on real bugs, indicates to the participants that - it is not that hard to fix some bugs and that Contributions are welcome.

I am wondering if hackathons should be more popular than they currently are. Instead of organizing a demo camp you could organize a hackathon. Hackathons could maybe also happen in evenings at EclipseCons.

Just thinking aloud...

[1] http://wiki.eclipse.org/Eclipse_DemoCamps_November_2012/Vancouver

Comment 2 Martin Oberhuber 2012-11-15 09:33:27 EST

Bugdays / Hackathons are a great idea. Do we currently have any common scheme for marking up bugs that are suitable for a bugday ?

I just added a "bugday" keyword on bug 209780 but I'm opening to any other markup if something exists already. We could document the agreed-on markup on the Architecture Council Wiki.

Comment 3 Dani Megert 2012-11-15 09:35:55 EST

(In reply to comment #2)
> Bugdays / Hackathons are a great idea. Do we currently have any common
> scheme for marking up bugs that are suitable for a bugday ?
> 
> I just added a "bugday" keyword on bug 209780 but I'm opening to any other
> markup if something exists already. We could document the agreed-on markup
> on the Architecture Council Wiki.

We also use that one in JDT.

Comment 4 John Arthorne 2012-11-15 11:45:37 EST

Someone privately came to me with some good feedback. Their point was that one barrier for contributors is that the steps required to become a committer are unclear. It's like being told to start running a race, but you don't know how long the race will be, or where the finish line is. If you cross the finish line, we'll let you know, otherwise keep running ;)

A counter-argument is that it is quite difficult to quantify or describe how much contribution it takes to become a committer. Metrics like number of bugs fixed, or lines modified, are not much help. Sometimes a single line change can require a week of investigation and require great expertise, and sometimes modifying many lines is simply fixing compiler warnings, typos or other mechanical tasks.

To me, the main criterion is not necessarily expertise in all aspects of the code, but familiarity with the practices of the project. Do they know how to run all the tests, how to write new tests to verify regressions, when it is safe to make changes depending on the project's rhythm (releasing big changes early in dev cycle and progressively smaller/safer close to a milestone or release). Do they know when to ask for review if they are unsure of a change, and who to ask.

It is hard to measure these goals, but it is easy to see you need a great deal of communication with the project's committers to learn this. I think the best approach is for contributors be open about their interest in becoming committers, and then the existing committers need to treat it as a priority to mentor this contributor. Maybe it would help to make this contributor/mentor relationship more explicit, and have the mentor come up with a plan or set of more visible goals that the contributor can work towards. 

I would be really curious to hear other suggestions about how improve this process, and not have contributors feel like they are running a race with no visible finish line.

Comment 5 Martin Oberhuber 2012-11-15 12:12:12 EST

The idea of contributing only for the sake of becoming committer seems really odd to me.

Pretty much all the contributions I've dealt with so far have been made because the contributor had a genuine interest in the subject and wanted to get something fixed. I've even had cases who refused commit privileges when I offered it to them.

Maybe things are different in the university / hacker scene, and maybe there's folk who want to move up in their Open Source reputation not caring what project they contribute to. Would such folk move to another project (Apache, KDE, Linuxkernel, Ubuntu, ...) if the career path at Eclipse is unclear or appears to be too steep ?

Would be interesting to get more background about why it is important for somebody to know how and when getting commit privileges are granted.

Comment 6 Lars Vogel 2012-11-15 12:46:48 EST

I think the path to create a contribution is relatively complex for new potential contributors.

IMHO Open Source projects must enable external people to build the tooling without any difficulties. That is for example how Android and Linux work. They have clear and concise descriptions and steps how to build Android or Linux. 

Building Eclipse or the step to create update sites is difficult and I think that was a barrier not many potential contributors can overcome.

Also finding the right place in the source code is difficult for new contributors and it is also difficult to find things to work one.

Hence I think the following will attract new contributors:

1.) Continue to make CBI simpler to build the platform (currently it still involved some patching)

2.) Include the unit tests into the Tycho build files to run them automatically after the build (maybe this is already done)

3.) Include in every fixed bug report a weblink to the Git commit so that potential contributors can see how existing committers are working (e4 tools and platform are doing that already)

4.) Split existing (huge) plug-ins into smaller bits as this makes contributions easier. Contributing to something small is usually simpler.

Comment 7 Ian Bull 2012-11-15 13:27:47 EST

(In reply to comment #6)
> 
> IMHO Open Source projects must enable external people to build the tooling
> without any difficulties. That is for example how Android and Linux work.
> They have clear and concise descriptions and steps how to build Android or
> Linux. 

I don't want to downplay the importance of easy build system, but we should keep in mind that Eclipse has a very easy way to self-host. Checking out a bundle, making a change, and testing your change shouldn't require you to setup the CBI (or any other external build system). IMHO, this is a real strength of Eclipse and we should continue to push this workflow forward.

Comment 8 Lars Vogel 2012-11-15 13:33:02 EST

@Ian: I agree that this is important but not something new people automatically get. When I started with the Eclipse platform, I tried to figure out how to compile it from source before I learned how to write plug-ins. Having the option to checkout the source, open a file, change the source of the file and compile the IDE is another great entry point for potential new contributors.

Comment 9 Nobody - feel free to take it 2012-11-15 13:44:01 EST

(In reply to comment #5)
> The idea of contributing only for the sake of becoming committer seems
> really odd to me.
> 
> Pretty much all the contributions I've dealt with so far have been made
> because the contributor had a genuine interest in the subject and wanted to
> get something fixed. I've even had cases who refused commit privileges when
> I offered it to them.
> 
> Maybe things are different in the university / hacker scene, and maybe
> there's folk who want to move up in their Open Source reputation not caring
> what project they contribute to. Would such folk move to another project
> (Apache, KDE, Linuxkernel, Ubuntu, ...) if the career path at Eclipse is
> unclear or appears to be too steep ?
> 
> Would be interesting to get more background about why it is important for
> somebody to know how and when getting commit privileges are granted.

Investigating and picking on the reasons why an individual wants to become a committer is completely irrelevant in my opinion. 

I (graduate and not a hacker folk) have been contributing on projects just because I like the technology and originally because I saw that help was needed in a community I am proud to be part of. I don't think you will find a more genuine interest than this. And I'm still around, did not reject commit rights when offered and still contributing e4 fixes completely orthogonal to my daily job in which I use Indigo. My inner motivations in becoming a committer ranged from the need to satisfy my engineering juices to personal and professional satisfaction but turns out that they are less genuine than fixing my project-specific bug.

I am really less likely to go contribute to linuxkernel than that contributor with genuine interest who rejected commit rights.

I also think it is discouraging to be asked to elaborate on why someone wants to know the rules but in the end it is just my humble opinion.

Hope my background helps.

Comment 10 Deepak Azad 2012-11-15 14:52:10 EST

(In reply to comment #4) 
> To me, the main criterion is not necessarily expertise in all aspects of the
> code, but familiarity with the practices of the project. Do they know how to
> run all the tests, how to write new tests to verify regressions, when it is
> safe to make changes depending on the project's rhythm (releasing big
> changes early in dev cycle and progressively smaller/safer close to a
> milestone or release). Do they know when to ask for review if they are
> unsure of a change, and who to ask.

I think most projects have a 'How to contribute' wiki page which gives out details on where to find the code, how to run the tests etc. But I do not recall seeing a 'How to become a committer' wiki page. As a first step maybe each project needs to define/document the process and the responsibilities/expectations from a committer. 

> I would be really curious to hear other suggestions about how improve this
> process, and not have contributors feel like they are running a race with no
> visible finish line.
One way could be to define in terms of time period. When I started contributing I was told that the finish line is <x months> away (based on how much time other committers had taken in the past), and that gave me a some indication of what it will take to become a committer. (Now I was contributing full time, so the time period may change if some one is only working part time, or there are different expectations. )

Comment 11 John Arthorne 2012-11-15 16:15:08 EST

(In reply to comment #5)
> The idea of contributing only for the sake of becoming committer seems
> really odd to me.
> 
> Pretty much all the contributions I've dealt with so far have been made
> because the contributor had a genuine interest in the subject and wanted to
> get something fixed. I've even had cases who refused commit privileges when
> I offered it to them.

I don't think people are only contributing for the sake of becoming a committer, but it is a clear sign of recognition and respect. I can certainly imagine personal, professional, or business reasons why it is valuable. In the end I don't think it matters why someone might want to become a committer. I don't think anyone's disagreeing that there should be some kind of barrier, but I think the issue is that the barrier is opaque - why is one person made a committer and not someone else. It can lead to suspicion of bias, etc.

But it's also important to keep an eye on the core issue, which is increasing the rate of *contribution* rather than purely increasing the number of committers. Our experience in e4 was that simply removing barriers to commit rights didn't actually translate into any increase in real contributions, so the two issues aren't strongly related. I suspect Lars and Deepak's suggestions focusing on simplifying contribution are more valuable in the end.

Comment 12 John Arthorne 2013-05-22 16:20:59 EDT

This is an area where we can never do enough and there is always room for improvement, but I am marking this "fixed" to conclude the Kepler plan item that this bug tracks. The Eclipse Platform had 112 unique contributors during the Kepler development period, and averaged 31 unique contributors per month, a slight increase from last year. We welcomed 4 new JDT committers, 3 new SWT committers, one releng committer, and 5 new e4 committers during Kepler (that is excluding election of existing Eclipse project committers to new component areas, of which there were also several). Some other steps taken during this release:

 - Committers attended hack days in Poznan and Boston and encouraged community members to come work on Eclipse alongside project committers.
 - The platform team instituted "bug days" where committers spent a full day each milestone reviewing community contributions
 - We migrated to the CBI build system which makes it easier for others in the community to hack on and build the platform for themselves.

We will need to continue making a conscious effort to keep improving in the next release and the team is always open to suggestions on how we can go about doing that.

Comment 13 John Arthorne 2013-05-23 12:11:16 EDT

(In reply to comment #12)
>  - Committers attended hack days in Poznan and Boston and encouraged
> community members to come work on Eclipse alongside project committers.

Correction, the event in Poland was in Krakow, not Poznan.

Comment 14 Szymon Ptaszkiewicz 2013-05-23 12:26:20 EDT

(In reply to comment #13)
> (In reply to comment #12)
> >  - Committers attended hack days in Poznan and Boston and encouraged
> > community members to come work on Eclipse alongside project committers.
> 
> Correction, the event in Poland was in Krakow, not Poznan.

Thanks for correcting, I almost got heart attack when I saw that I missed the Poznan one ;-)