Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Recommenders/Incubator"

m (What to do (Roadmap)?)
m (What to do (Roadmap)?)
Line 55: Line 55:
 
** Register your update site with the Incubator aggregator update site,
 
** Register your update site with the Incubator aggregator update site,
 
** Prepare a 'Hello World!' blog post to let Eclipse Community know that you are here,
 
** Prepare a 'Hello World!' blog post to let Eclipse Community know that you are here,
** Set up a 1-page website briefly describing your project and goals.
+
** Set up a 1-page website briefly describing your project and goals (may have large overlap with the welcome blog post).
 
* Start working!
 
* Start working!
  
 
Over time you may refine all these items. But that's roughly the roadmap a new incubator would take.
 
Over time you may refine all these items. But that's roughly the roadmap a new incubator would take.

Revision as of 04:52, 13 June 2012

Why?

Code Recommenders incubator project aims to provide a platform to new and innovative research ideas in the area mining software repositories and building recommender systems for software engineering. Projects can leverage the existing Eclipse infrastructure like Eclipse's

  • common build infrastructure
  • continuous integration servers,
  • public visible update sites,
  • public visible web sites and wikis,
  • public visible blogs,
  • twitter retweeters and the like

to promote their tools.

Especially you will have access to Recommenders Incubator blog to announce their tools to the broader public with relatively small effort but maximized outreach. In general, the goal of this incubator is to give your research ideas a platform that allows you to quickly obtain feedback on your ideas, ease to conduct user studies and, thus, makes your research more solid and also increases the likelihood to get your papers accepted. You proved it works by presenting it to a large user community!

Code Recommenders will do its best to assist you to get started at Eclipse and will support you when it comes to announcing your tools, attracting users - and we encourage all committers to participate in user studies to provide tool authors with the necessary feedback.

You may also get the awareness of others and get submissions to industry conferences accepted or frequently talk at Java user Groups and Eclipse Demo Camps. You may have noticed, we are presenting Recommenders at JavaOne. Same can happen to you if you want and work for this.


Eclipse Recommenders Incubator is about fostering IDE research at Eclipse!

Who can join?

University and industry research groups as well as individuals with innovative ideas that match the incubator's scope. One serious restriction is that projects should live longer than "for a single paper", i.e., we are interested in projects that survive the first publication and have the goal to bring something valuable to the Eclipse community in the large. This also puts some demands on the quality of your work - but if you wouldn't care you wouldn't read this, right?

How can we join?

Send a email to the recommenders-dev mailing list, express your interest and present your idea or tool. We provide the platform. You donate your time to make it happen :)

What else must be considered?

Even Recommenders' incubator makes it very easy to start your research project at eclipse.org, there are a few things to consider.

First, we generally expect committers to come with code (and code to come with committers), i.e., if you want to start a new project there should be a basic working implementation; if you would like to join an existing project, you should have provided a number of patches to the project via Gerrit and participate in the recommenders-dev mailing list, Bugzilla etc. The incubator is subject to the same rules and process regarding committers. The technology PMC (top-level project that finally hosts this incubator) does allow more latitude with regard to merit. Even with that latitude, however, PMC would still take issue with making somebody a committer "just because";

And finally, becoming a committer requires a formal election and some paperwork to be done.

What does it mean to bring an existing project to Eclipse?

Are you coming from a university environment? Then the intellectual property checks (short, IP checks) will be the hardest change to embrace. However, it's there for good reasons. What does it mean?

  • First, your initial code contribution needs to be reviewed once by the Eclipse Legal team. This may take a few weeks.
  • Second, dependencies to other libraries need to be IP checked too. You won't be able to use GPL or LGPL license software in your code. EPL, FreeBSD, APL and the like are all good - but GPL is not. This is a serious constraint that may prevent you from joining. On the other hand, there are quite a few projects at Eclipse that do great stuff without GPL code. It works. Even for you :)
  • Third, external contributions, e.g., from students working on a thesis or doing a hands-on, also need to be reviewed by Eclipse Legal team. This means that at the end of their project, students agree to put their code under EPL by submitting their code to Eclipse Bugzilla and starting the review process. If you have students working constantly on the project and making many small changes (i.e., create patches under 200 lines of code) they can be merged immediately after your review. Large patches also need to be reviewed by Legal team. (Note to Eclipse Foundation: can we simplify this, e.g., by creating "IP checkpoints" where the legal team is checking the whole code of an incubator at once? Not sure this makes sense but frequent IP checks are a burden as they take quite a while). We may also provide git repositories at Eclipse Labs to support your student projects.


What other expectation does the incubator have for new projects?

Not as many as you may think. We want to see you make your idea happen. We would like to see you using Eclipse's Common Build Infrastructure and set up an automated build. And we want to see you working on your vision at eclipse.org. That's it.

What to do (Roadmap)?

  • Say 'Hi' on the recommenders-dev mailing list and introduce your idea, project status, and information you feel makes sense
  • Prepare your code for review by Eclipse Legal team
  • Open a Bugzilla entry and attach the code to it. Take care of the appropriate license headers and copyrights in the files and clarify with your potential employer that you are allowed to contribute this code to Eclipse under EPL.
  • After review is passed, we start committer election for one or two new committers you name for that new incubator.
  • After the vote successfully concluded, you are ready to move in:
    • Commit your code to a brand new Git repository,
    • Set up an automated build,
    • Register your update site with the Incubator aggregator update site,
    • Prepare a 'Hello World!' blog post to let Eclipse Community know that you are here,
    • Set up a 1-page website briefly describing your project and goals (may have large overlap with the welcome blog post).
  • Start working!

Over time you may refine all these items. But that's roughly the roadmap a new incubator would take.

Back to the top