On Tue, Jan 28, 2014 at 12:44 AM, scl wrote:

1) Do we want to participate this year, again?

Yes.

2) If yes, which programming tasks do we want to offer?

In my opinion, we should stick with the GEGL/OpenCL ports and integration of the results of former GSoC projects.

Yes for the former, no for the latter. Hiring a new student to complete the work of another one would be a horrible PR move. It means we failed to do our job in the first place.

Yes, it might sound boring, but on the other hand the GEGL and OpenCL ports have been our high priority for many years and there's still something to do, see the [GEGL Porting Matrix].

Both GEGL ports _and_ speeding up GEGL has to be done, but I'm not sure if the latter is GSoC material.

We also have tons of usability issues, such as:

- with the existing Text tool implementation, you can't select font in the on-canvas toolbar and start typing with it; - with transformation tools, the layer you are transforming blocks the view of layers beneath it, so you end up guessing what you are actually doing;
- when you change brush size/rotation with a slider using a Wacom pen or a mouse pointer, you can't preview the changes; - the whole floating selection thing.

A project that would focus on fixing usability issues could make a nice GSoC project. It would mean a lot for the community, especially for the most vocal part of it :) Of course, it only makes sense, if Peter can/wants to join us for the summer.

Building and prioritizing a list of most notorious usability issues that could be fixed as part of a GSoC project is perfectly doable.

Personally, I think that GIMP GAP is in need of help. Animation is a rather popular topic among GIMP users, but GAP's UI scares the living daylight out of people (me included) and being implemented as a set of plugins doesn't really help there. I don't think I've seen a well formulated opinion on GAP becoming part of GIMP (last time I asked, some developers were against, others were indifferent), but some streamlining of user experience regarding basic animation could be both useful and GSoC material. Of course, that's just my personal opinion, and besides, upcoming frame-by frame animation in Synfig could render the whole idea obsolete.

4) What can we learn from the former GSoCs: what have we done well,

Historically, students who performed best were the ones who joined early to study the code and maybe send a couple of patches, sticked around on IRC and were generally open about their work. They were also the students who came up with an idea of their own or even had done some prior work (last year's N-Point deformation tool is one such example).

what could be improved?

Off top of my head:

1) Even more explicitly encourage original thinking and genuine interest in a proposed project. Implementing something that stems from a cool SIGGRAPH paper is good, competing against 5 other students for a slot that isn't even all that critical for GIMP -- not so much :)

2) Make 100% sure that students are familiar with the code. Inkscape has a two-patches rule to even start considering a submitted application. We didn't want to do that before, but we did have disappearing students in the past. Something to think of, IMO.

3) Demand public weekly reports on progress, sent to gimp-developer@/gegl-developer@, no excuses.

4) Only allow UI-related projects if we have a usability person to design new interaction/UIs. Last year's selection tools project is why we need that.

Alexandre