[ease-dev] GSoC 2016 expectations & grading

[Christian Pontesegger <christian.pontesegger@xxxxxx>]

Hi students,

I am currently working to get access to your applications to give 
feedback. Hope this topic gets sorted out in the next days. In the 
meanwhile I would like to share some expectations from my side and give 
some details on grading and what is expected for mid term and final 
evaluations:

1) communication

Every student shall post his/her progress/thoughts/problems at least 
once a week on the mailing list. Missing 2 posts during summer is 
accepted, a third one will result in a failed evaluation. There might be 
reasons why you are not available for a week or two, but this could be 
clarified before, so we can agree that this does not count on a missed 
report. Of course you may post more frequently :)

Further I would like to have a chat on mattermost:
https://mattermost-test.eclipse.org/eclipse/channels/ease
once a week with every student. This is to discuss design decisions, ask 
questions (there are no dumb questions!) and share ideas. I hope 
mattermost works for this case otherwise we could also use google 
hangout. We can agree on the time we meet and I will try to be available 
on mattermost on a daily basis during this summer.


2) code quality

Your task is not only to implement functionality. It is also expected 
that public API is documented using JavaDoc accordingly. Further JUnit 
test cases are required to pass the evaluations. It is not important 
that you write tons of code. If you find a short, elegant solution to 
the task this will be well appreciated. To make this clear: even if your 
code works, if it is untested/undocumented it will not be sufficient to 
pass the evaluations.


3) work packages

Your proposal should contain several work packages. So best divide the 
topic into smaller chunks which are deliverable step by step. Each 
package should contain documentation/tests. Do not propose "package 1: 
implementation", "package 2: unit tests", ... Packages should have a 
delivery date so we can track your progress during this summer. I guess 
a good package size would be something you can finish in 2-3 weeks. 
While you should try to meet your delivery dates, we might adapt that 
plan during summer in case we see we cannot hold to the original plan.


4) commits

Commit often, commit small chunks of work. As all commits need to be 
reviewed manually, make sure your commits do not contain 1000s of lines 
of code. The sooner you commit stuff, the sooner we can react in case 
things go into the wrong direction. As we use gerrit a commit cannot 
break anything, it is a safe environment which should encourage you not 
to be shy with your code. Typically we will discuss on commits, might 
address some changes to the committed code and do another iteration. It 
is quite common to have 3-4 iterations on a commit before it meets 
expectations and gets pushed to the master branch.
Commit early! If you start 2 days before an evaluation you will very 
likely be too late to bring your code through the review process. 
Remember that reviews take some time and I might not be available all 
the time.



These rules should help to guide you in the right direction. They will 
also allow me to detect when you might need some help.

If you have questions to these guidelines, please post them here on the list

cheers
Christian