On Mon, Apr 3, 2017 at 12:27 AM, Daniel Ferreira (theiostream) < [email protected]> wrote:
> On Sun, Apr 2, 2017 at 11:57 AM, Ivan Vučica <[email protected]> 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 <http://write.flossmanuals.net/gsoc-mentoring/the-quick-guide/>; 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.
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
