Code Recommenders incubator project aims to provide a platform to new and innovative research ideas in the area of 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 your 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 increases the likelihood to get your papers accepted. You proved it works by presenting it to a large user community already!
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 finding participants for user studie .
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 code should live longer than "for a single paper" or master thesis, i.e., we are interested in tools that survive the first publication and want to deliver something valuable to the Eclipse community. 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?
- Say 'Hi' on the recommenders-dev mailing list and introduce your idea, its current status, and all other 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 a 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 research idea 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 path a new incubator would take.
What else must be considered?
Even Recommenders' incubator makes it very easy to start your research area 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 to work on a new topic there should be a basic working implementation; if you would like to join an existing topic, you should have provided a number of patches to it 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 in which every existing committer votes for the new candidate - and some paperwork to be done after the election passed.
Also note that all committers in the incubator have uniform access to all code within the incubator. There are no dividing walls between research topics. This is managed via social convention. i.e. don't mess with my stuff and I won't mess with yours.
All "research areas or topics" get their own individual Git repository.
In addition, there can be no official "releases" from the incubator. Milestone builds can be created and disseminated, but nothing that is an official release. If research area has matured to the point where they want to do a release, they should create a proper project and move their code into it. Or maybe move the code out of the incubator and into the parent project.
What does it mean to bring an existing tool 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 IP review process. We may also provide git repositories at Eclipse Labs to support your student projects. If you have students working constantly on your code making many small changes (i.e., create patches under 200 lines of code) they can be merged immediately after your review using Gerrit. Note that large patches also need to be reviewed by legal team which may take several weeks.
(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).
What other expectation does the incubator have for new tools?
Not as many as you may think. We want to see you make your idea happen at eclipse.org.
We would like to see you using Eclipse's Common Build Infrastructure and set up an automated build. We would love to see you blogging about it an tell the community about your ideas.
That's it. But that's what you wanted to do anyways, right?
Tools and ideas we are looking for may contribute to the following areas - but are not limited to:
- innovative code completion engines (intelligent or not)
- documentation mining approaches (from simple to complex)
- Next-gen code and example snippet search engines
- Stacktrace search engines,
- Next-gen bug detection systems
and any kind of recommender that leverages the Big Data we have today in software engineering is welcome. There is no limitation except it should be related to Eclipse.