We’re launching the “Great Fixes for Mars” programme. As is suggested by the name, we’re looking for great fixes in the form of contributions to Eclipse open source projects. There will be prizes.
A “Great Fix” is a contribution from a non-committer that provides a significant improvement in the Java development experience using Eclipse. Ultimately, the committers will decide what constitutes a “Great Fix”, but special consideration will be given to performance or stability improvements, and patches that improve the user experience.
Now this is important: to qualify, a “Great Fix” must be a fix, not a new feature or enhancement. And, we’re particular about the nature of the fix: it must improve the Java development experience. I’ve asked committers from the Java development tools (JDT) project to suggest some bugs that they’re particularly keen to have addressed to seed the discussion. You can, of course, pick other bugs, but the suggested ones are most likely to result in success. We’ll be including other Java development related projects in this as well.
The first 100 bugs on the Eclipse Platform 4.5 Planning Bugs page are a great place to start. The Platform UI project provides a very comprehensive How to Contribute guide to get you started. I recommend that you use the Oomph Eclipse Installer to build and configure your complete development environment (Oomph provides a very intuitive workflow for provisioning an Eclipse-based development environment, complete with cloned Git repositories, that gets you ready to contribute patches via Gerrit in minutes; I’ll post a demonstration video later).
I mean no disrespect to the beginners out there, but this is also important: a “Great Fix” must be fixed by the contributor on their own qualifications. If your starting point is “I want to fix a bug, but don’t know much about the code; please explain how I should start”, then—respectfully—this programme isn’t for you. We’re looking specifically for “Great Fixes” that don’t take a lot of time for the committers to assess and accept (committer effort is part of the judging criteria).
The programme runs in cycles; submissions must be accepted by a project committer before 900h ET on the specified deadline date. We’ll announce the winners at the end of each cycle.
- Deadline: March 10/2015; the three top-prize winners will be announced on March 12 at EclipseCon
- Deadline: April 1/2015; the three top-prize winners will be announced on April 3 (Mars M6)
- Deadline: May 6/2015; the four top-prize winners will be announced on May 8 (Mars M7)
To qualify:
- Pick a bug;
- Take ownership of a bug (i.e. assign the bug to yourself);
- Add the “greatfix” keyword to that bug and use a comment to commit to a completion date; and
- Submit a patch via the preferred channel (likely Gerrit).
If a committer thinks that your fix has potential, they’ll +1 your comment in the bug. The +1 means that the committer is interested and will plan to review your contribution when it you submit it. I can’t guarantee that a committer will accept your fix, but if they do and it qualifies, you’ll be in the running for a prize.
Full details are on the web site. I’ll update that page periodically with more “seed” bugs and status.
To answer what I expect is an obvious question: you can qualify for this if you are already a committer on a different Eclipse open source project. In fact, I’d love for you to participate if you’re a committer on another Eclipse open source project.
So, what are the prizes? We have some state-of-the-art Nexus 9 Android tablets compliments of the good people at Google.
We’re picking multiple winners in each cycle. Runners up will get an awesome Eclipse t-shirt.
The EclipseCon Hackathon is a good place to get a leg up on the competition!
