I'm picking up Wayne's and Konstantin's ideas:
How would the process of adding a new project to an project incubator look like? Paperwork for one or two committers, a project description with a mission statement, initial code IP check, "and go!"? One or more project committers could take over the mentor part and help with things like IP, CQs, and processes etc.?
For Recommenders, I would like to take the opportunity to attract other research groups and set up the infrastructure and guidelines to make the move to an Eclipse Incubator attractive. I understand this as an experiment and an offering we could present to interested research groups and see how the responses are (before taking any actions upfront).
Would technology-pmc and foundation agree with this? If so, I would announce this to "Recommendation Systems in Software Engineering" (RSSE) and "Mining Software Repositories" (MSR) research communities in, say, July to get their feedback on this.
Marcel
On 12.06.2012, at 17:39, Wayne Beaton wrote:
We can pretty easily create incubators under an existing project.
With graduation, for example, Code Recommenders can request that an
incubator be created for related work. The incubator does have to
work within the scope of the parent project.
I'm keen to make the process of creating a project easier. I do not,
however, have any designs on making it as easy as creating a new
project at Source Forge or GitHub. That's just not the space we live
in.
I'm not convinced that every "research" project should be created
under Technology. Technology was originally created as an incubator
for new ideas that either grew and moved to Tools or some other
appropriate home; or reached some natural conclusion and were
terminated. Over time, Technology has become a place for stuff that
doesn't fit anywhere else.
There's really no reason why a "research" project couldn't be
started under Mylyn, for example, where it would receive far more
attention from the ALM community (assuming that's the community
being targeted).
What is the point of bringing a "research" project to Eclipse? I
find it hard to believe that the main motivation would be to connect
with other researchers. Rather, I'd expect that it would be to
extend the reach into the broader community and eco-system.
This is is an area where I think we could do better. I've been
trying to help new projects sort out the most appropriate home and
otherwise set themselves up for success. But this has the effect of
prolonging the proposal process and making it even harder to get
started (in a good way, though).
FWIW, Mylyn is the ultimate research success story. It did start off
life as a research project in Technology and moved to Tools before
being promoted to a Top-Level project. Maybe Mik has a different
opinion, but I don't think that being classified as "research" is
what lead to success. Success, I believe, came from a combination of
game-changing technology, and hard work. Lots of hard work. This is
the same combination that we're seeing in Code Recommenders.
Wayne
On 06/11/2012 12:26 PM, Marcel Bruch wrote:
Resend from different address. + added comment on CBI.
On 11.06.2012, at 18:08, Marcel Bruch wrote:
Hi Ian,
Hi Wayne,
IMHO research projects are most interested in more
publicity and assistance in building a community. I don't
think that a forge or a wiki page helps much here. Even
forums won't help as developers don't know anything about
the projects behind them.
As you both propose, a page that lists all ongoing
research projects under, say, http://eclipse.org/research/projects
would be nice. Such a page could be driven by some tags in
the Eclipse Marketplace with relatively low effort I
think.
Wayne, regarding the proposal process. I know it's
there for good reasons. But at the same time I think that
projects like Snipmatch wouldn't have considered joining
Eclipse if they had to declare a committer team, a project
proposal, a project plan and the like. This is too
heavyweight.
I think Incubators are the right way to go. They don't
need a project proposal nor naming a committer team nor
declaring a project plan (even it would be great to have
one for Snipmatch ;)) I think, there should be a
lightweight process that enables research projects to join
another project and naming one or two committers without
the need of a big commit history. Then, there should be
incubator update sites that make is easy that projects get
their tools out to the users. The hosting project should
also make the marketing (blog-posts, tweets etc.) to get
these tools out to the developers - at least enable
incubators to use existing channels. CBI is good as it
enables quality assurance and build automation with
minimal effort.
And these things and expectations should be documented
somewhere. I had hard times to figure out where to ask for
permission of whatever. Something like the committer
resources wiki page for research projects would be nice.
Wayne, I think technology project is fine if one of
it's goals is to host research projects. It should just be
more present, i.e., more actively advertising itself as
such. FWIW, I wasn't sure which top-level to pick as
tools, mylyn and technology all looked good to me. I'm not
sure if another top-level project like "research" would
help much. Maybe if eclipse would make it a large sandbox
for research projects as I described above :)
These are just some unfiltered thoughts I had after
discussing ideas with some researchers.
Thanks,
Marcel
On 11.06.2012, at 15:59, Wayne Beaton wrote:
Hi Marcel. I'm a member of the Technology PMC;
of course I'm listening (FWIW, I listen on all PMC
list and a great many project lists).
We've been doing a lot of work lately to try and
make a few things easier for projects. The Common
Build Infrastructure should make building a lot
easier. A lot of projects just use the metadata
driven websites rather than create their own; we're
doing some work to make this even better and easier
with the new Project Management Infrastructure
initiative.
Can you be more specific about what parts of the
entry barrier should be lowered? Is the proposal
process too difficult/too time-consuming?
The Technology project was originally intended (at
least partially) as a place for research projects. I
think it's fair to say that it has evolved away from
that. Maybe, as Ian suggests, we can start by making
university research projects be more prominent on
the site. We can do all of the things that you
suggest within the scope of the Technology Project.
Or maybe it's time to create a new top-level
project.
Wayne
On 11.06.2012, at 15:19, Ian Skerrett wrote:
Marcel,
I think we should always be looking to improve how
we reach out to different communities, the
research community certainly being an important
one.
EclipseLabs was an attempt to create an extend
community for projects that didn't want to be
'official' projects but wanted to be closer to the
community. It was setup so the researchers didn't
have to worry about setting up their own forge and
the project code was available in the open.
It seems like you are looking for a bit more
exposure for research projects or 'home' for these
types of projects. I wonder if some type of wiki
page and/or forum would be a starting point?
Ian
On 06/10/2012 05:10 AM, Marcel Bruch wrote:
Hi technology-pmc,
If this reads a bit like a rant, please
excuse. It's not. Its intent is to get one or
two ideas how to improve the current situation.
I'm just back from a research conference and
have been asked by a bunch of researchers how
potential collaborations with Eclipse and Code
Recommenders in particular could look like. The
scope of these works varies from applying
Natural Language processing (NLP) on
documentation, bringing NLP into code
completion, integrating Code Recommenders into
Code Bubbles, developing a parameter guessing
recommender, collaborations on code search
engines, mining on user interactions, and
generally extending the idea of IDE 2.0 for lots
of other ideas.
I don't think that many of these ideas will
actually turn into code at eclipse.org but
if a few projects or ideas will do so, it would
be a great success.
I wonder whether Eclipse could do more to get
more research ideas into Eclipse and provide
them a platform for their work. In my opinion
putting something into the marketplace is not
enough - research people don't get the feeling
that they have a huge outreach there. Can't we
do a little more that they get the feeling of
being "part of Eclipse" rather than "yet another
research prototype using Eclipse"?
Or can we lower the entrance barrier for
research at Eclipse? I know that eclipselabs.org
was (also) designed for this case, but do they
work as expected? And: is providing a repository
a useful support? What distinguishes it from
SourceForge or GitHub? I think these research
projects should be coupled more to existing
Eclipse projects; they should be treated more
like incubators with associated (top-level?)
projects giving them a platform for instance
with an aggregator update site, blog posts etc.
Also, projects still have to provide the
whole infrastructure like a build server, a web
server etc. on their own. We, for instance, have
a shadow infrastructure with Bugzilla, Gerrit,
Jenkins etc. running at the university from the
first days which was a huge invest we had to
make upfront. And at the end everything still
stays in the university network. This doesn't
feel like open source then and such a huge
support from my (very personal) viewpoint.
A few thoughts on whether or how we can
change some things a little would be great. I
hope the technology-pmc list is appropriate for
this as I'm only hoping for some small changes
inside technology top-level project but not for
changes in the Eclipse bylaws ;) But maybe this
should just go to the foundation. If so, I hope
Wayne is listening.
Thanks,
Marcel
P.S.: I know the discussions
about "researchers want to publish
papers and don't want to support
tools for long time". This is not
the direction I would like to take
in this post. It's about simplifying
the process iff someone wants to go
a few steps further - like we did
with recommenders. It just doesn't
need to be that hard as it was for
us.
_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev
--
Wayne Beaton
The Eclipse Foundation
Twitter: @waynebeaton
Explore Eclipse
Projects
_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev
_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev
_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/technology-pmc
--
Wayne Beaton
The Eclipse Foundation
Twitter: @waynebeaton
Explore Eclipse
Projects
_______________________________________________ technology-pmc mailing list technology-pmc@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/technology-pmc
|