[Haskell-cafe] [haskell.org Google Summer of Code 2013] Approved Projects

[Edward Kmett]

The majority of the rejections are of precisely that form, or just were
slightly out-competed by another similar proposal in their space.

These items either are stated or should be stated in the student
application guidelines, but a successful summer of code submission probably
has most of the following attributes:

* *A good timeline* -- It is easy to miss this one! At one extreme, we've
had proposals that just never submitted any details beyond a paragraph
saying something would be nice to have. Other red flags are projects that
promise the moon, but come from someone nobody knows (there is nothing
wrong with promising the moon if everyone knows you can deliver it!) or
which look like they close out an easy issue that someone could bang out in
a weekend. We've passed on otherwise decent proposals that just completely
lacked any details about how they were going to get there, as there is
really no good way for a mentor to judge progress. Speaking of whom, it is
useful to have...

* *Some idea of who the mentor could be* -- We came very close to not
finding mentors for a couple of projects, despite community interest. As a
corollary, if you are interested in having something happen in the
community, stepping up to mentor it along is a good first step to making it
a reality! We generally can find mentors for projects, but having already
reached out to someone beforehand helps show that you have...

* *A student who has already started to get involved in the community* --
Haskell generally has a long ramp up, its rather hard to learn it on the
fly if you've never really used it, and still accomplish some other goal.
Students with a long history of good commits to a project are generally
taken before ones of whom we're less sure. Without knowledge of haskell you
are unlikely to have...

* *Demonstrable impact on the community as a whole* -- Proposals that work
on a specific aspect of something we all use generally see good responses.
We definitely tend to favor projects that benefit the community as a whole
over ones that improve niches. Work on Cabal, GHC, Hackage is a much easier
to sell, than say me getting someone to hack on my kan-extensions library,
which doesn't have many users, but at least it is...

* *Not a greenfield project* -- In general we're a bit gunshy about
students designing libraries from scratch. Your MMORPG example fits that
mold. It'd likely be a completely new project, which brings with it a lot
of design decisions, and it comes with no pre-existing users impacted by
the project, so it is easy to flounder and have nobody care. For instance,
we have routinely received submissions to build a library for type level
programming, but we already have several that have failed to gain much
traction. What discriminates the new design from the old? Now, if the
library already exists and has begun to pick up traction and has users? You
might be able to make a case for a summer of code project to improve it. I
just can't think of such a proposal that we've had in recent years.

-Edward



On Tue, May 28, 2013 at 8:24 PM, Ben Lippmeier <benl at ouroborus.net> wrote:

>
> On 29/05/2013, at 1:11 AM, Edward Kmett wrote:
>
> This unfortunately means, that we can't really show the unaccepted
> proposals with information about how to avoid getting your proposal
> rejected.
>
>
> You can if you rewrite the key points of proposal to retain the overall
> message, but remove identifying information. I think it would be helpful to
> write up some of the general reasons for projects being rejected.
>
> I tried to do this for Haskell experience reports, on the Haskell
> Symposium experience report advice page.
>  http://www.haskell.org/haskellwiki/HaskellSymposium/ExperienceReports
>
>
> I'd imagine you could write up some common proposal / rejection / advice
> tuples like:
>
> Proposal: I want to write a MMORPG in Haskell, because this would be a
> good demonstration for Haskell in a large real world project. We can use
> this as a platform to develop the networking library infrastructure.
>
> Rejection: This project is much too big, and the production of a MMORPG
> wouldn't benefit the community as a whole.
>
> Advice: If you know of specific problems in the networking library
> infrastructure, then focus on those, using specific examples of where
> people have tried to do something and failed.
>
>
> Ben.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130528/70805a4a/attachment.htm>