Re: [GSoC] Make WebKit run on top of GNUstep

[Ivan Vučica]

On Mon, Apr 3, 2017 at 12:27 AM, Daniel Ferreira (theiostream) <bnmvco@gmail.com> wrote:

On Sun, Apr 2, 2017 at 11:57 AM, Ivan Vučica <ivan@vucica.net> wrote:
> I think we can work with the goal of 'get something up and running' and 'have
> a good idea of what needs to be done to get WebCore ported'.

Although it's hard to come up with something better, I don't like
either – the former is too vague (what is "something"?) and the
latter, if set as the project's *FINAL* goal, presupposes little would
actually get done.

I did not mean you should write it that way in the proposal, of course. I meant that a large part of the project is going to be exploring how to execute the project; it's hard to do that without significant time investment, and thus hard to put into a proposal in advance.

You do already have goals; I was trying to state that I'd be happy if we know a lot more about the problem area, and have some progress (initial GNUstep port inside WebCore, etc).

 

But these proposals might be interesting to consider if not for the
final evaluations, for the mid-term ones: the first is on June 30, the
other on July 28. For the first one, we could work with the concrete
goal of "compiling WebCore and solving linking issues with
Base/CoreBase"; for the second one, we could go with something more
abstract like "document in great detail what challenges lay ahead for
successfully porting WebCore" (a derivation of your "get a good idea"
formulation). This would be an actual contribution to the effort, and
would set a more detailed roadmap for the last month of work on GSoC.
I am just unsure whether it would be allowed/decent to only know the
final evaluation's goal well into the project's coding period.

I think it's okay for the final goals to drift as the project goes on. There needs to be a formal proposal; I believe the goal of the proposal is to show that a student has a good idea about what's going on, to show responsibility, and to show understanding of the problem area. Should the student be judged based on the initial proposal, or on the work? I believe it's the work that counts.

GSoC mentoring manual talks a lot about setting precise goals (which we are going to have a super-hard time doing this late), but it sounds like it's intended to make evaluation easier. Especially considering this sentence (context; emphasis added):

Be prepared for slippage, and be willing to revise the plan as necessary, especially at midterm. Student learning is a primary goal of GSoC, so try to provide a learning experience.

You've provided a lot of detail already, so unless there are objections, I think it's better to start with your existing proposal, and revise plans as we go along. 'Document in great detail challenges for porting WebCore' sounds like a nice addition to the proposal, if you'd like to formalize it.