Great Fixes for Mars

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.

EclipseCon 2015

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.

  1. Deadline: March 10/2015; the three top-prize winners will be announced on March 12 at EclipseCon
  2. Deadline: April 1/2015; the three top-prize winners will be announced on April 3 (Mars M6)
  3. Deadline: May 6/2015; the four top-prize winners will be announced on May 8 (Mars M7)

To qualify:

  1. Pick a bug;
  2. Take ownership of a bug (i.e. assign the bug to yourself);
  3. Add the “greatfix” keyword to that bug and use a comment to commit to a completion date; and
  4. 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.

Nexus 9 Android Tablets

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!

This entry was posted in Community, Java and tagged , , , . Bookmark the permalink.

2 Responses to Great Fixes for Mars

  1. timothy says:

    These bugs or viruses would getting to anything else would it ?

    • waynebeaton says:

      I don’t understand the question. Eclipse projects track issues via our Bugzilla instance, so we tend to refer to all issues (be them bug reports or feature requests) as “bugs”.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s