cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: Help with review
Date Sat, 24 Mar 2007 16:14:15 GMT
Grzegorz Kossakowski wrote:
> Reinhard Poetz napisał(a):
>> Grzegorz Kossakowski wrote:
>>> Hello,
>>>
>>> I've put the proposal I'm willing to apply to Google here:
>>> http://wiki.apache.org/general/SummerOfCode2007/cocoon-expression
>>>
>>> I'd would be grateful for any review, comments and even edits fixing
>>> language mistakes. I'm sorry it took so long, I had some personal
>>> affairs to settle.
>>>
>>> Thanks for any help.
>> I take this as your 'deliverables', right?
>>
>> 1. revise EL handling implemented in Cocoon's template block and find
>> out if
>>    improvements are needed
>> 2. get rid of Avalon dependencies in EL and OM handling code
>> 3. provide consistent, complete object model for expressions
>> everywhere they are
>>    used
>> 4. implement converter concept and provide basic converters'
>> implementations
>> 5. refactor at least portion of Cocoon samples so they use new ELs
>>    implementation
>> 6. document new architecture, create migration guides and promote the
>> use of new
>>    implementation across the community
> 
> Hmm, I think that I do not understand exact meaning of 'deliverables'.

i'd define it as "measureable" goals. How does your mentor, who isn't only 
mentor but also assessor, know that you reached your goals or not. If we don't 
define deliverables properly, there would be much more room for interpretation.

I'm perfectly fine if you say "I will work on problem X and provide a solution 
at May, 31th. Then there are 7 days for discussions. Starting with June, 8th, I 
will start with the implementation.".

> In abstract I should provide overview on my main goals right? What
> should be putted in 'deliverables' section? More detailed,
> project-specific info on what kind of contributions I plan to add?
> Something like:
> * new module cocoon-expression-api
>   * ELs and OM API (already exists but must be moved from template block)
>   * converters API
> * new module cocoon-expression-impl
>   * implementation for expression langauges for JS, JXPath, JEXL (most
> code already exist but needs clean up), possibly XReporter would be
> implemented if time permits
>   * implementation of automatic, context-aware Object Model creation
>   * default converters, basically the same as in
> org.apache.cocoon.forms.datatype.convertor package
> * refactored samples
>   * cocoon-ajax-sample
>   * cocoon-forms-sample
>   * cocoon-core-additional-sample
>   * possibly new module cocoon-expression-sample with stuff focused only
> on ELs
> * documentation in Daisy
>   * design documents
>   * tutorials on explaining how to create own EL or converter
> implementation and how to extend OM
>   * migration guide
> * evangelism and fuzz on mailing lists
> 
> My impression was that I do not have to provide every small detail and
> address all doubts.

you don't have to and you can't because you will learn and find out things that 
you don't know today. Also the opinion of your mentor and the feedback from the 
community will influence your project.

  If so, I would like to make use of this right when
> it comes to converter concept. This is one is little bit fuzzy now and I
> would have to ask Daniel more questions about it. Can we leave
> converters scope little unspecified?
> 
>> Some comments:
>>
>> In general: Could you please also add some timeline when you want to
>> finish what? See the project proposals of previos GSoC students to
>> find out what I mean.
>>
>> In particular:
>>
>> 1. When do you think will you be finished with it? Make it a milestone in
>>    your project timeline.
>> 2. ok
>> 3. see 1.
>> 4. What basic converters do you want to implement?
>> 5. Which samples do you want to improve?
>> 6. ok (as long as you do it in Daisy ;-)
>>
>> Thanks for your proposal. I really like that you will provide weekly
>> reports which will make it easy for others to follow your work.
>>
> 
> Ok, I'll add the timeline.

ok, forget my comment 4 and 5 and leave it open for now. Only add a paragraph to 
the timeline about when you will let us know what converters and samples you 
want to implement.

This and adding a timeline and a deliverables section should be all that needs 
to be done IMO.

> One more issue: as most students in most
> countries, I'm going to have exam session in mid of June. It means that
> on the beginning of GSoC I'll not able to devote myself fully, I'd say
> that my activity will be narrowed only to discussion and research. Is it
> a serious obstacle?

no, just take it into account when you propose a timeline.

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

Mime
View raw message