Re-evaluation of GSoC Final Evaluation Result ( Apache Htrace Kudu Backend )

[Nisala Mendis <ni...@gmail.com>]

Hi Google Support,

I just got received my mentors evaluation and I would like request Google
to kindly reevaluate my final outcome. I would like to point out my mentors
each evaluation each point into you kind consideration.

I am sorry that the project seems to have failed. I mentioned on the
midterm evaluation that I was concerned about the lack of progress on the
project, and unfortunately the pace only got slower after that. I think
that the biggest problem that we had was that you simply did not dedicate
enough time to the project to succeed. When we were in the project
selection phase, you said that you could dedicate 35 hours a week to the
project. However, this turned out to be a wild overestimate. I doubt that
you spent more than 5 hours a week during any week, and for many weeks,

First of all my mentor I would like to mention my mentor has never spent
with me at lease one or two hour each week. Even  though we have agreed to
share the status by each twice week, he has always ask for status without
even let me what to do with my project without any guidance. Sometime I got
even stuck he has never even shed  light, right from the beginning I
learned their project deployment, and I worked out their development
environment from my own. Apache htrace is still incubator process doesnt
even have proper documentation. Expectation from my mentor is unacceptable
under this conditions. He always say "You need to ask questions" If you can
read until last of my mentor evaluation , he even himself agreed that even
at last moment I have worked towards completion of project. There s not
much left in this project. Theres no way one can do that without working at
5 hour per week. And

you seem to have spent 0 hours-- not even bothering to respond to emails or
send a status update. It's very frustrating when a student becomes
uncommunicative for almost a full month at a time.

This is a complete false statement I have never been in active for full one
month. I have only been inactive maximum close  for two weeks. This is
personal mail Colin my mentor and we agreed to move on. After two weeks
inactivity this is the email I got from my mentor,


Hi Nisala,

You've been unresponsive for half a month.  I'm concerned about the
project.  Frankly I feel like we might not have time to finish now,
since you took such a long unannounced break in the middle.  The final
evaluation is on August 15th.  Let's think about this more and how we
could prevent it from happening again in the future.

best,

Colin

This is his personal mail from him for my maximum inactivity for two weeks
and we agreed to move on by JULY 19.

My single biggest suggestion for improvement is to respond promptly when
other people try to communicate, and to stick to pre-agreed schedules of
project updates and meetings.

First of all we agreed only share status on emails we never had meetings,
we have never scheduled meetings.

This is the email from my mentor that we agreed to share status by only
mail. This is on Fri, May 6 during community bonding period.


Hmm.  Video calls seem to be difficult, owing to the time difference and
some of the technical issues.

Instead, how about we exchange status emails two times a week.  Monday and
Thursday seem like good days to email.

I'll start.

A big part of Google Summer of Code is learning to interact with the
community and learn some things about the project.

I have only communicated my status updates via JIRA ticket [1]
https://issues.apache.org/jira/browse/HTRACE-362 where all community sees
my project. You will notice I have completed his reviews which has put
during the final GSOC mentor evaluation period. Because we both agreed to
successfully completion in earlier.

When you try to complete a large portion of the code just a few days before
the end of GSoC, the community has no time to review it, let alone discuss
it. Code review takes time. It's also very important to respond to all the
comments people make in a code review. I remember having to make the same
comments several times before you would address them.

What I wanted to highlight is [1]
https://issues.apache.org/jira/browse/HTRACE-362 He still adds reviews for
code that I wrote in mid term.
 If you look at [1]
https://issues.apache.org/jira/browse/HTRACE-362?focusedCommentId=15333197&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15333197
He has never mentioned anything about kudu schema but now adding reviews
regarding that end of the project at [2]
https://issues.apache.org/jira/browse/HTRACE-362?focusedCommentId=15429907&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15429907

This is totally unacceptable rather if some one want to fail that project
do something like that. I agree in one time I couldn't address his all his
requirements at once. He is keeps on adding reviews for code that I written
for midterm regarding kudu schema and handling multiple parents of spans.
He mid term code review does not include them all. Even he has failed to
answer which schema should use.

In this [1]
https://issues.apache.org/jira/browse/HTRACE-362?focusedCommentId=15437201&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15437201
This was his response about kudu schema, where he claims I should have
looked some other code as he claims

This is one reason why I suggested that you look at LocalFileSpanReceiver
and HTracedSpanReceiver rather than HBaseSpanReceiver.

Which is completely false statement, He has never mentioned such to me even
in that thread or personal mail. I wonder whether he could prove that to
anyone. He wanted emphasize this project failed because of me this which is
completely a false statement.

I am glad that we have at least a little code to start from when building a
Kudu spanreceiver. What we need to do to get this merged is to actually
complete all the tasks mentioned in the original proposal document--
develop a way to run the full web interface against the Kudu SpanReceiver,
write good documentation for setup and deployment, understand what the
correct schema to use to store data in Kudu is, measure performance, and
write unit tests.

This my proposal under [1]
https://docs.google.com/document/d/14pnwHj5IsstCuBG3puD0x36KSmXxnglryRsfJcWP3Kg/edit?usp=sharing
This the last update which I gave to him under comment [2]
https://issues.apache.org/jira/browse/HTRACE-362?focusedCommentId=15428686&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15428686

Where I have completed second part of the project which has not been
reviewed, and If he could provide the answer whether to use the webapp ( in
previous comment ) similar to HBASE this project is done done. Where we
have similar webapp for like HBASE or integrate to current main Htrace
webapp. He never given answer because He wanted look this project failed.
Even the current HBASE htrace recever has have so many limitations, He too
much expect this KUDU receiver to be PERFECT which I believe, is completely
unacceptable.

In my proposal I have never mentioned anything about performance test for
different kudu schema. Even in this main thread [1]
https://issues.apache.org/jira/browse/HTRACE-362 he has never mentioned
such. These are totally false statements. However I agree on the
documentation.

The code I written for both span receiver and span viewer have unit tests
under pr [1] https://github.com/apache/incubator-htrace/pull/11 This
completely false I have written unit tests for both  span receiver and
viewer using KUDU mini cluster utility.

I hope Google and Apache Organization Admins will reconsider my evalution
for GSoC 2016. In
[1] https://gist.github.com/nisalanirmana/9ac0b8d34ee198f4dcafc64e6f84ba5a
I have mentioned all the work that I completed. Since my mentor is first
time mentoring, He think all code should be by mentor evaluation. Which I
believe it is not the expectation.

Regards
Nisala

Re: Re-evaluation of GSoC Final Evaluation Result ( Apache Htrace Kudu Backend )

[Nisala Mendis <ni...@gmail.com>]

Hi Colin,

My questions are all about false statement which you have made about final
evaluation making wrong impression. If you believe myself should be failed,
that is fine I agree with you, But I don't agree with any of the
facts related to final evaluation.
Specially regarding the fact I've been inactive for months, we scheduled
regular meetings that I have canceled, Where we have agreed performance
tests for different schemas at proposal, I didnt write unit tests for my
code and regarding JIRA threads mentioned in my first mail we had for
project. Most of them I see as unanswered.

One thing you are highlighting is my inactivity for two weeks, which I
believe after during that mid term period where I tested my code and wrote
unit tests for the where I have come back again and showed the progress.
What you are trying to prove is very pointless and justifying evaluation
over this really pointless too.
Other fact you trying to prove is I wrote the code for span viewer
spontaneously and put that during the last week. Nobody can write such code
for span viewer and test the code and write unit test as well. I have
worked towards it while dealing with your review for the first part. The
code I written for midterm was under review for until very last moment
adding new points kept on coming to same code you have already reviewed at
mid point.  There were some dependency span receiver and viewer regarding
the fact with schema. So how could I send a another PR for your review
regarding the fact that those two PR's have inter dependency. I was working
out the reviews very last moment. My activity even during final mentor
evaluation shows that I have addressed all your reviews. But at last I have
decided send that PR before the mentor review. Because that one includes
the second part of the project. But I need to mention that I have sent
second PR code ( Second part of project ) with unit tests for second part
before ending the student evaluation period. Isn't this the same procedure
we have followed for midterm? But shouldn't the mentor assist the student
what needs to be planned for the rest?

I think I made my points very clear, I hope those who goes through the
thread will understand and will judge GSoC evaluation points you brought
for the rest the other facts.
My argument is more towards false evaluation points you made rather your
final evaluation. I respect your responsibility of a mentor towards the
student and agree even you believe I should be failed
but not with these incorrect facts you brought out justifying the failure.
I strongly reject all of them as a Student because I've been through this,
anybody who s in that situation will understand the same.

I understand arguing this and you going back and forth would do nothing. I
ll stop from here.

Regards
Nisala

On Wed, Aug 31, 2016 at 7:54 AM, Colin McCabe <cm...@apache.org> wrote:

> Hi Nisala,
>
> The facts here are clear.  At the end of the day, you got in two patches
> over the summer and both of them were minor and not related to the Kudu
> span receiver.  You have a big patch that is still in review, but not
> yet ready to be committed.  You made 5 mailing list posts (2 of which
> are in this very thread).  There are a lot of casual contributors on
> this list who have done more than that in a week or two, let alone the
> whole summer.
>
> My midterm evaluation for you clearly stated that you needed to improve
> your communication, become more active, and get more done.  I clearly
> marked it as needing improvement.  I also sent repeated emails to you
> saying that the project was in trouble, some of which you posted to this
> very thread.
>
> The reason why we set up emails rather than video calls is because the
> first time we tried a video call, the picture and audio quality was very
> poor, and neither of us could understand the other.  That's why I asked
> you to email me twice a week.  Since you rarely sent status emails, I
> usually had to email you instead and ask for status.  I usually didn't
> get a response for several days, and sometimes I never got one.  This is
> what I meant by "communication problems."  Arguing over whether you were
> unresponsive for 2.5 weeks versus 3 weeks that one particular time
> really misses the point, which is that you were consistently
> unresponsive throughout the whole summer.  I understand that there is a
> timezone delay, but that shouldn't cause several days of delay.
>
> As to how much time per week I spent, I made a rough estimate.  Not very
> scientific.  Some weeks I did spend more than 3 hours, for sure.
> Writing an email or doing a review can take a surprisingly long time,
> especially a difficult one like the current one :(  Some weeks I spent
> much less than 3-- but that was usually because you were ignoring my
> emails, and my follow-up emails about why you were ignoring my emails :(
> :(
>
> I re-checked the original design document, and you are right, there is
> no mention of adding performance measurements in there.  I was thinking
> of a different GSoC proposal when I wrote that-- one which unfortunately
> didn't get accepted.  However, clearly some kind of rough performance
> test will eventually be needed in order to make this code production
> quality.  It didn't necessarily need to get done as part of this
> project, but we should have discussed plans for it in the future.
>
> I understand that you did start working on this again a few days before
> the end of GSoC, and made some progress on the SpanReceiver.  But there
> is a lot more to GSoC than just cranking out a rough draft of some code
> by the deadline.  Code often changes substantially during a code review.
>  Sometimes even fundamental assumptions need to be re-examined, like the
> schema or the threading model here.  Since the community needs to be
> able to support this code once it goes in, we can't rush it in in a day
> or two with minimal review.  We also need documentation on how to set
> things up.  In the last week or two of the project, you should have been
> finishing up documentation, answering questions on the mailing list, and
> discussing future improvements and projects.  Not desperately trying to
> crank out a rough draft of the very first deliverable in the design doc
> before the deadline hits.
>
> Lastly, HTrace is not a biased community-- we have contributors are from
> Hortonworks, NTT Data, Facebook, etc. etc.  I'm sure we are not perfect,
> but that is a heck of a lot better than many other projects.  This is
> all really clear if you read the board reports-- or just the mailing
> list, and see who is active.
>
> If there's anything else I can answer, or help with, just email me
> directly.  Like I said before, I don't think public mailing lists are
> the appropriate venue for this conversation.  Posting from a place of
> anger is never helpful and it can lead to you burning bridges.
>
> Colin
>
>
> On Tue, Aug 30, 2016, at 12:46, Nisala Mendis wrote:
> > Hi Colin,
> >
> > I understand it is your responsibility evaluate summer project as well I
> > strongly believe the community need to know truthful is your evaluation
> > facts you put into that Google evaluation.
> > I also believe putting untruthful evaluation facts even far worse than
> > exposing someone's personal emails.
> >
> > So I hand over to Kudu and HTrace communities to evaluate the stuff that
> > I
> > wrote whether those are agree with facts you put into that my evaluation.
> > I
> > believe those who in this list the have better understanding
> > of the technology can evaluate the facts of your evaluation against the
> > code and the JIRA we had those all discussions. I even put this thing,
> > knowing Apache Kudu and Apache Htrace
> > very much biased Cloudera backed communities does not meet Apache open
> > source standards by any means.
> >
> > Even Google or Apache Organization GSoC Admins re-evaluate my evaluation
> > or
> > not, I believe this will be a good incident Google or participating
> > Organization like Apache to evaluate their own mentors as well
> > and also mentors to be honest to GSoC program as well being honest when
> > you
> > are filling that evaluation, rather you put false facts to prove why you
> > have failed the student. If the student does not meet standards required
> > by
> > the program, It s your responsibility to fail the student but not by this
> > kind of untruthful facts. I am sorry to point your personal emails, but I
> > believe community need to know the truth which I believe I did mistake
> > for
> > all workI did not posted publicly in this mailing list, otherwise you
> > would
> > have never put untruthful facts as my evaluation.
> >
> > I also suggest before you are going to fail a student, be honest to
> > yourself whether you have spent at least a hour per week with the student
> > meeting other Google and Apache mentoring standards, I truly believe
> > mentor
> > is not some one who just ask for status. I also suggest as person who
> > works
> > for Cloudera full time could do that kind of effort without putting some
> > serious commitment.
> >
> > Hopefully this will shed some light on future GSoC students as well.
> >
> > Regards
> > Nisala
> >
> > On Tue, Aug 30, 2016 at 10:15 PM, Colin McCabe <cm...@apache.org>
> > wrote:
> >
> > > Hi Nisala,
> > >
> > > I'm truly sorry that our summer of code project didn't get completed.
> > > You showed a lot of potential in the beginning, but unfortunately the
> > > time commitment was just not there.  When students become unresponsive
> > > for weeks at a time, it's very difficult for mentors.
> > >
> > > I think that if you focus, you can improve and do better in the future.
> > > If you had told me that you were taking classes this summer, I might
> not
> > > have suggested doing the project.  I also said that I will continue to
> > > review any patches from you, and I stand by that.
> > >
> > > I don't think this really has any relevance to dev@htrace or dev@kudu.
> > > This is really about evaluating the summer project, and that's my
> > > responsibility.  I suggest taking the discussion off those lists.
> Also,
> > > I really suggest not reposting personal emails people send to you to
> > > public mailing lists in the future, unless you ask the sender
> > > beforehand.
> > >
> > > Colin
> > >
> > >
> > > On Tue, Aug 30, 2016, at 00:47, Nisala Mendis wrote:
> > > > Hi Google Support,
> > > >
> > > > I just got received my mentors evaluation and I would like request
> Google
> > > > to kindly reevaluate my final outcome. I would like to point out my
> > > > mentors
> > > > each evaluation each point into you kind consideration.
> > > >
> > > > I am sorry that the project seems to have failed. I mentioned on the
> > > > midterm evaluation that I was concerned about the lack of progress
> on the
> > > > project, and unfortunately the pace only got slower after that. I
> think
> > > > that the biggest problem that we had was that you simply did not
> dedicate
> > > > enough time to the project to succeed. When we were in the project
> > > > selection phase, you said that you could dedicate 35 hours a week to
> the
> > > > project. However, this turned out to be a wild overestimate. I doubt
> that
> > > > you spent more than 5 hours a week during any week, and for many
> weeks,
> > > >
> > > > First of all my mentor I would like to mention my mentor has never
> spent
> > > > with me at lease one or two hour each week. Even  though we have
> agreed
> > > > to
> > > > share the status by each twice week, he has always ask for status
> without
> > > > even let me what to do with my project without any guidance.
> Sometime I
> > > > got
> > > > even stuck he has never even shed  light, right from the beginning I
> > > > learned their project deployment, and I worked out their development
> > > > environment from my own. Apache htrace is still incubator process
> doesnt
> > > > even have proper documentation. Expectation from my mentor is
> > > > unacceptable
> > > > under this conditions. He always say "You need to ask questions" If
> you
> > > > can
> > > > read until last of my mentor evaluation , he even himself agreed that
> > > > even
> > > > at last moment I have worked towards completion of project. There s
> not
> > > > much left in this project. Theres no way one can do that without
> working
> > > > at
> > > > 5 hour per week. And
> > > >
> > > > you seem to have spent 0 hours-- not even bothering to respond to
> emails
> > > > or
> > > > send a status update. It's very frustrating when a student becomes
> > > > uncommunicative for almost a full month at a time.
> > > >
> > > > This is a complete false statement I have never been in active for
> full
> > > > one
> > > > month. I have only been inactive maximum close  for two weeks. This
> is
> > > > personal mail Colin my mentor and we agreed to move on. After two
> weeks
> > > > inactivity this is the email I got from my mentor,
> > > >
> > > >
> > > > Hi Nisala,
> > > >
> > > > You've been unresponsive for half a month.  I'm concerned about the
> > > > project.  Frankly I feel like we might not have time to finish now,
> > > > since you took such a long unannounced break in the middle.  The
> final
> > > > evaluation is on August 15th.  Let's think about this more and how we
> > > > could prevent it from happening again in the future.
> > > >
> > > > best,
> > > >
> > > > Colin
> > > >
> > > > This is his personal mail from him for my maximum inactivity for two
> > > > weeks
> > > > and we agreed to move on by JULY 19.
> > > >
> > > > My single biggest suggestion for improvement is to respond promptly
> when
> > > > other people try to communicate, and to stick to pre-agreed
> schedules of
> > > > project updates and meetings.
> > > >
> > > > First of all we agreed only share status on emails we never had
> meetings,
> > > > we have never scheduled meetings.
> > > >
> > > > This is the email from my mentor that we agreed to share status by
> only
> > > > mail. This is on Fri, May 6 during community bonding period.
> > > >
> > > >
> > > > Hmm.  Video calls seem to be difficult, owing to the time difference
> and
> > > > some of the technical issues.
> > > >
> > > > Instead, how about we exchange status emails two times a week.
> Monday
> > > > and
> > > > Thursday seem like good days to email.
> > > >
> > > > I'll start.
> > > >
> > > > A big part of Google Summer of Code is learning to interact with the
> > > > community and learn some things about the project.
> > > >
> > > > I have only communicated my status updates via JIRA ticket [1]
> > > > https://issues.apache.org/jira/browse/HTRACE-362 where all community
> > > sees
> > > > my project. You will notice I have completed his reviews which has
> put
> > > > during the final GSOC mentor evaluation period. Because we both
> agreed to
> > > > successfully completion in earlier.
> > > >
> > > > When you try to complete a large portion of the code just a few days
> > > > before
> > > > the end of GSoC, the community has no time to review it, let alone
> > > > discuss
> > > > it. Code review takes time. It's also very important to respond to
> all
> > > > the
> > > > comments people make in a code review. I remember having to make the
> same
> > > > comments several times before you would address them.
> > > >
> > > > What I wanted to highlight is [1]
> > > > https://issues.apache.org/jira/browse/HTRACE-362 He still adds
> reviews
> > > > for
> > > > code that I wrote in mid term.
> > > >  If you look at [1]
> > > > https://issues.apache.org/jira/browse/HTRACE-362?
> > > focusedCommentId=15333197&page=com.atlassian.jira.
> > > plugin.system.issuetabpanels:comment-tabpanel#comment-15333197
> > > > He has never mentioned anything about kudu schema but now adding
> reviews
> > > > regarding that end of the project at [2]
> > > > https://issues.apache.org/jira/browse/HTRACE-362?
> > > focusedCommentId=15429907&page=com.atlassian.jira.
> > > plugin.system.issuetabpanels:comment-tabpanel#comment-15429907
> > > >
> > > > This is totally unacceptable rather if some one want to fail that
> project
> > > > do something like that. I agree in one time I couldn't address his
> all
> > > > his
> > > > requirements at once. He is keeps on adding reviews for code that I
> > > > written
> > > > for midterm regarding kudu schema and handling multiple parents of
> spans.
> > > > He mid term code review does not include them all. Even he has
> failed to
> > > > answer which schema should use.
> > > >
> > > > In this [1]
> > > > https://issues.apache.org/jira/browse/HTRACE-362?
> > > focusedCommentId=15437201&page=com.atlassian.jira.
> > > plugin.system.issuetabpanels:comment-tabpanel#comment-15437201
> > > > This was his response about kudu schema, where he claims I should
> have
> > > > looked some other code as he claims
> > > >
> > > > This is one reason why I suggested that you look at
> LocalFileSpanReceiver
> > > > and HTracedSpanReceiver rather than HBaseSpanReceiver.
> > > >
> > > > Which is completely false statement, He has never mentioned such to
> me
> > > > even
> > > > in that thread or personal mail. I wonder whether he could prove
> that to
> > > > anyone. He wanted emphasize this project failed because of me this
> which
> > > > is
> > > > completely a false statement.
> > > >
> > > > I am glad that we have at least a little code to start from when
> building
> > > > a
> > > > Kudu spanreceiver. What we need to do to get this merged is to
> actually
> > > > complete all the tasks mentioned in the original proposal document--
> > > > develop a way to run the full web interface against the Kudu
> > > > SpanReceiver,
> > > > write good documentation for setup and deployment, understand what
> the
> > > > correct schema to use to store data in Kudu is, measure performance,
> and
> > > > write unit tests.
> > > >
> > > > This my proposal under [1]
> > > > https://docs.google.com/document/d/14pnwHj5IsstCuBG3puD0x36KSmXxn
> > > glryRsfJcWP3Kg/edit?usp=sharing
> > > > This the last update which I gave to him under comment [2]
> > > > https://issues.apache.org/jira/browse/HTRACE-362?
> > > focusedCommentId=15428686&page=com.atlassian.jira.
> > > plugin.system.issuetabpanels:comment-tabpanel#comment-15428686
> > > >
> > > > Where I have completed second part of the project which has not been
> > > > reviewed, and If he could provide the answer whether to use the
> webapp (
> > > > in
> > > > previous comment ) similar to HBASE this project is done done. Where
> we
> > > > have similar webapp for like HBASE or integrate to current main
> Htrace
> > > > webapp. He never given answer because He wanted look this project
> failed.
> > > > Even the current HBASE htrace recever has have so many limitations,
> He
> > > > too
> > > > much expect this KUDU receiver to be PERFECT which I believe, is
> > > > completely
> > > > unacceptable.
> > > >
> > > > In my proposal I have never mentioned anything about performance
> test for
> > > > different kudu schema. Even in this main thread [1]
> > > > https://issues.apache.org/jira/browse/HTRACE-362 he has never
> mentioned
> > > > such. These are totally false statements. However I agree on the
> > > > documentation.
> > > >
> > > > The code I written for both span receiver and span viewer have unit
> tests
> > > > under pr [1] https://github.com/apache/incubator-htrace/pull/11 This
> > > > completely false I have written unit tests for both  span receiver
> and
> > > > viewer using KUDU mini cluster utility.
> > > >
> > > > I hope Google and Apache Organization Admins will reconsider my
> evalution
> > > > for GSoC 2016. In
> > > > [1]
> > > > https://gist.github.com/nisalanirmana/9ac0b8d34ee198f4dcafc64e6f84ba
> 5a
> > > > I have mentioned all the work that I completed. Since my mentor is
> first
> > > > time mentoring, He think all code should be by mentor evaluation.
> Which I
> > > > believe it is not the expectation.
> > > >
> > > > Regards
> > > > Nisala
> > >
>

Re: Re-evaluation of GSoC Final Evaluation Result ( Apache Htrace Kudu Backend )

[Nisala Mendis <ni...@gmail.com>]

Hi Colin,

My questions are all about false statement which you have made about final
evaluation making wrong impression. If you believe myself should be failed,
that is fine I agree with you, But I don't agree with any of the
facts related to final evaluation.
Specially regarding the fact I've been inactive for months, we scheduled
regular meetings that I have canceled, Where we have agreed performance
tests for different schemas at proposal, I didnt write unit tests for my
code and regarding JIRA threads mentioned in my first mail we had for
project. Most of them I see as unanswered.

One thing you are highlighting is my inactivity for two weeks, which I
believe after during that mid term period where I tested my code and wrote
unit tests for the where I have come back again and showed the progress.
What you are trying to prove is very pointless and justifying evaluation
over this really pointless too.
Other fact you trying to prove is I wrote the code for span viewer
spontaneously and put that during the last week. Nobody can write such code
for span viewer and test the code and write unit test as well. I have
worked towards it while dealing with your review for the first part. The
code I written for midterm was under review for until very last moment
adding new points kept on coming to same code you have already reviewed at
mid point.  There were some dependency span receiver and viewer regarding
the fact with schema. So how could I send a another PR for your review
regarding the fact that those two PR's have inter dependency. I was working
out the reviews very last moment. My activity even during final mentor
evaluation shows that I have addressed all your reviews. But at last I have
decided send that PR before the mentor review. Because that one includes
the second part of the project. But I need to mention that I have sent
second PR code ( Second part of project ) with unit tests for second part
before ending the student evaluation period. Isn't this the same procedure
we have followed for midterm? But shouldn't the mentor assist the student
what needs to be planned for the rest?

I think I made my points very clear, I hope those who goes through the
thread will understand and will judge GSoC evaluation points you brought
for the rest the other facts.
My argument is more towards false evaluation points you made rather your
final evaluation. I respect your responsibility of a mentor towards the
student and agree even you believe I should be failed
but not with these incorrect facts you brought out justifying the failure.
I strongly reject all of them as a Student because I've been through this,
anybody who s in that situation will understand the same.

I understand arguing this and you going back and forth would do nothing. I
ll stop from here.

Regards
Nisala

On Wed, Aug 31, 2016 at 7:54 AM, Colin McCabe <cm...@apache.org> wrote:

> Hi Nisala,
>
> The facts here are clear.  At the end of the day, you got in two patches
> over the summer and both of them were minor and not related to the Kudu
> span receiver.  You have a big patch that is still in review, but not
> yet ready to be committed.  You made 5 mailing list posts (2 of which
> are in this very thread).  There are a lot of casual contributors on
> this list who have done more than that in a week or two, let alone the
> whole summer.
>
> My midterm evaluation for you clearly stated that you needed to improve
> your communication, become more active, and get more done.  I clearly
> marked it as needing improvement.  I also sent repeated emails to you
> saying that the project was in trouble, some of which you posted to this
> very thread.
>
> The reason why we set up emails rather than video calls is because the
> first time we tried a video call, the picture and audio quality was very
> poor, and neither of us could understand the other.  That's why I asked
> you to email me twice a week.  Since you rarely sent status emails, I
> usually had to email you instead and ask for status.  I usually didn't
> get a response for several days, and sometimes I never got one.  This is
> what I meant by "communication problems."  Arguing over whether you were
> unresponsive for 2.5 weeks versus 3 weeks that one particular time
> really misses the point, which is that you were consistently
> unresponsive throughout the whole summer.  I understand that there is a
> timezone delay, but that shouldn't cause several days of delay.
>
> As to how much time per week I spent, I made a rough estimate.  Not very
> scientific.  Some weeks I did spend more than 3 hours, for sure.
> Writing an email or doing a review can take a surprisingly long time,
> especially a difficult one like the current one :(  Some weeks I spent
> much less than 3-- but that was usually because you were ignoring my
> emails, and my follow-up emails about why you were ignoring my emails :(
> :(
>
> I re-checked the original design document, and you are right, there is
> no mention of adding performance measurements in there.  I was thinking
> of a different GSoC proposal when I wrote that-- one which unfortunately
> didn't get accepted.  However, clearly some kind of rough performance
> test will eventually be needed in order to make this code production
> quality.  It didn't necessarily need to get done as part of this
> project, but we should have discussed plans for it in the future.
>
> I understand that you did start working on this again a few days before
> the end of GSoC, and made some progress on the SpanReceiver.  But there
> is a lot more to GSoC than just cranking out a rough draft of some code
> by the deadline.  Code often changes substantially during a code review.
>  Sometimes even fundamental assumptions need to be re-examined, like the
> schema or the threading model here.  Since the community needs to be
> able to support this code once it goes in, we can't rush it in in a day
> or two with minimal review.  We also need documentation on how to set
> things up.  In the last week or two of the project, you should have been
> finishing up documentation, answering questions on the mailing list, and
> discussing future improvements and projects.  Not desperately trying to
> crank out a rough draft of the very first deliverable in the design doc
> before the deadline hits.
>
> Lastly, HTrace is not a biased community-- we have contributors are from
> Hortonworks, NTT Data, Facebook, etc. etc.  I'm sure we are not perfect,
> but that is a heck of a lot better than many other projects.  This is
> all really clear if you read the board reports-- or just the mailing
> list, and see who is active.
>
> If there's anything else I can answer, or help with, just email me
> directly.  Like I said before, I don't think public mailing lists are
> the appropriate venue for this conversation.  Posting from a place of
> anger is never helpful and it can lead to you burning bridges.
>
> Colin
>
>
> On Tue, Aug 30, 2016, at 12:46, Nisala Mendis wrote:
> > Hi Colin,
> >
> > I understand it is your responsibility evaluate summer project as well I
> > strongly believe the community need to know truthful is your evaluation
> > facts you put into that Google evaluation.
> > I also believe putting untruthful evaluation facts even far worse than
> > exposing someone's personal emails.
> >
> > So I hand over to Kudu and HTrace communities to evaluate the stuff that
> > I
> > wrote whether those are agree with facts you put into that my evaluation.
> > I
> > believe those who in this list the have better understanding
> > of the technology can evaluate the facts of your evaluation against the
> > code and the JIRA we had those all discussions. I even put this thing,
> > knowing Apache Kudu and Apache Htrace
> > very much biased Cloudera backed communities does not meet Apache open
> > source standards by any means.
> >
> > Even Google or Apache Organization GSoC Admins re-evaluate my evaluation
> > or
> > not, I believe this will be a good incident Google or participating
> > Organization like Apache to evaluate their own mentors as well
> > and also mentors to be honest to GSoC program as well being honest when
> > you
> > are filling that evaluation, rather you put false facts to prove why you
> > have failed the student. If the student does not meet standards required
> > by
> > the program, It s your responsibility to fail the student but not by this
> > kind of untruthful facts. I am sorry to point your personal emails, but I
> > believe community need to know the truth which I believe I did mistake
> > for
> > all workI did not posted publicly in this mailing list, otherwise you
> > would
> > have never put untruthful facts as my evaluation.
> >
> > I also suggest before you are going to fail a student, be honest to
> > yourself whether you have spent at least a hour per week with the student
> > meeting other Google and Apache mentoring standards, I truly believe
> > mentor
> > is not some one who just ask for status. I also suggest as person who
> > works
> > for Cloudera full time could do that kind of effort without putting some
> > serious commitment.
> >
> > Hopefully this will shed some light on future GSoC students as well.
> >
> > Regards
> > Nisala
> >
> > On Tue, Aug 30, 2016 at 10:15 PM, Colin McCabe <cm...@apache.org>
> > wrote:
> >
> > > Hi Nisala,
> > >
> > > I'm truly sorry that our summer of code project didn't get completed.
> > > You showed a lot of potential in the beginning, but unfortunately the
> > > time commitment was just not there.  When students become unresponsive
> > > for weeks at a time, it's very difficult for mentors.
> > >
> > > I think that if you focus, you can improve and do better in the future.
> > > If you had told me that you were taking classes this summer, I might
> not
> > > have suggested doing the project.  I also said that I will continue to
> > > review any patches from you, and I stand by that.
> > >
> > > I don't think this really has any relevance to dev@htrace or dev@kudu.
> > > This is really about evaluating the summer project, and that's my
> > > responsibility.  I suggest taking the discussion off those lists.
> Also,
> > > I really suggest not reposting personal emails people send to you to
> > > public mailing lists in the future, unless you ask the sender
> > > beforehand.
> > >
> > > Colin
> > >
> > >
> > > On Tue, Aug 30, 2016, at 00:47, Nisala Mendis wrote:
> > > > Hi Google Support,
> > > >
> > > > I just got received my mentors evaluation and I would like request
> Google
> > > > to kindly reevaluate my final outcome. I would like to point out my
> > > > mentors
> > > > each evaluation each point into you kind consideration.
> > > >
> > > > I am sorry that the project seems to have failed. I mentioned on the
> > > > midterm evaluation that I was concerned about the lack of progress
> on the
> > > > project, and unfortunately the pace only got slower after that. I
> think
> > > > that the biggest problem that we had was that you simply did not
> dedicate
> > > > enough time to the project to succeed. When we were in the project
> > > > selection phase, you said that you could dedicate 35 hours a week to
> the
> > > > project. However, this turned out to be a wild overestimate. I doubt
> that
> > > > you spent more than 5 hours a week during any week, and for many
> weeks,
> > > >
> > > > First of all my mentor I would like to mention my mentor has never
> spent
> > > > with me at lease one or two hour each week. Even  though we have
> agreed
> > > > to
> > > > share the status by each twice week, he has always ask for status
> without
> > > > even let me what to do with my project without any guidance.
> Sometime I
> > > > got
> > > > even stuck he has never even shed  light, right from the beginning I
> > > > learned their project deployment, and I worked out their development
> > > > environment from my own. Apache htrace is still incubator process
> doesnt
> > > > even have proper documentation. Expectation from my mentor is
> > > > unacceptable
> > > > under this conditions. He always say "You need to ask questions" If
> you
> > > > can
> > > > read until last of my mentor evaluation , he even himself agreed that
> > > > even
> > > > at last moment I have worked towards completion of project. There s
> not
> > > > much left in this project. Theres no way one can do that without
> working
> > > > at
> > > > 5 hour per week. And
> > > >
> > > > you seem to have spent 0 hours-- not even bothering to respond to
> emails
> > > > or
> > > > send a status update. It's very frustrating when a student becomes
> > > > uncommunicative for almost a full month at a time.
> > > >
> > > > This is a complete false statement I have never been in active for
> full
> > > > one
> > > > month. I have only been inactive maximum close  for two weeks. This
> is
> > > > personal mail Colin my mentor and we agreed to move on. After two
> weeks
> > > > inactivity this is the email I got from my mentor,
> > > >
> > > >
> > > > Hi Nisala,
> > > >
> > > > You've been unresponsive for half a month.  I'm concerned about the
> > > > project.  Frankly I feel like we might not have time to finish now,
> > > > since you took such a long unannounced break in the middle.  The
> final
> > > > evaluation is on August 15th.  Let's think about this more and how we
> > > > could prevent it from happening again in the future.
> > > >
> > > > best,
> > > >
> > > > Colin
> > > >
> > > > This is his personal mail from him for my maximum inactivity for two
> > > > weeks
> > > > and we agreed to move on by JULY 19.
> > > >
> > > > My single biggest suggestion for improvement is to respond promptly
> when
> > > > other people try to communicate, and to stick to pre-agreed
> schedules of
> > > > project updates and meetings.
> > > >
> > > > First of all we agreed only share status on emails we never had
> meetings,
> > > > we have never scheduled meetings.
> > > >
> > > > This is the email from my mentor that we agreed to share status by
> only
> > > > mail. This is on Fri, May 6 during community bonding period.
> > > >
> > > >
> > > > Hmm.  Video calls seem to be difficult, owing to the time difference
> and
> > > > some of the technical issues.
> > > >
> > > > Instead, how about we exchange status emails two times a week.
> Monday
> > > > and
> > > > Thursday seem like good days to email.
> > > >
> > > > I'll start.
> > > >
> > > > A big part of Google Summer of Code is learning to interact with the
> > > > community and learn some things about the project.
> > > >
> > > > I have only communicated my status updates via JIRA ticket [1]
> > > > https://issues.apache.org/jira/browse/HTRACE-362 where all community
> > > sees
> > > > my project. You will notice I have completed his reviews which has
> put
> > > > during the final GSOC mentor evaluation period. Because we both
> agreed to
> > > > successfully completion in earlier.
> > > >
> > > > When you try to complete a large portion of the code just a few days
> > > > before
> > > > the end of GSoC, the community has no time to review it, let alone
> > > > discuss
> > > > it. Code review takes time. It's also very important to respond to
> all
> > > > the
> > > > comments people make in a code review. I remember having to make the
> same
> > > > comments several times before you would address them.
> > > >
> > > > What I wanted to highlight is [1]
> > > > https://issues.apache.org/jira/browse/HTRACE-362 He still adds
> reviews
> > > > for
> > > > code that I wrote in mid term.
> > > >  If you look at [1]
> > > > https://issues.apache.org/jira/browse/HTRACE-362?
> > > focusedCommentId=15333197&page=com.atlassian.jira.
> > > plugin.system.issuetabpanels:comment-tabpanel#comment-15333197
> > > > He has never mentioned anything about kudu schema but now adding
> reviews
> > > > regarding that end of the project at [2]
> > > > https://issues.apache.org/jira/browse/HTRACE-362?
> > > focusedCommentId=15429907&page=com.atlassian.jira.
> > > plugin.system.issuetabpanels:comment-tabpanel#comment-15429907
> > > >
> > > > This is totally unacceptable rather if some one want to fail that
> project
> > > > do something like that. I agree in one time I couldn't address his
> all
> > > > his
> > > > requirements at once. He is keeps on adding reviews for code that I
> > > > written
> > > > for midterm regarding kudu schema and handling multiple parents of
> spans.
> > > > He mid term code review does not include them all. Even he has
> failed to
> > > > answer which schema should use.
> > > >
> > > > In this [1]
> > > > https://issues.apache.org/jira/browse/HTRACE-362?
> > > focusedCommentId=15437201&page=com.atlassian.jira.
> > > plugin.system.issuetabpanels:comment-tabpanel#comment-15437201
> > > > This was his response about kudu schema, where he claims I should
> have
> > > > looked some other code as he claims
> > > >
> > > > This is one reason why I suggested that you look at
> LocalFileSpanReceiver
> > > > and HTracedSpanReceiver rather than HBaseSpanReceiver.
> > > >
> > > > Which is completely false statement, He has never mentioned such to
> me
> > > > even
> > > > in that thread or personal mail. I wonder whether he could prove
> that to
> > > > anyone. He wanted emphasize this project failed because of me this
> which
> > > > is
> > > > completely a false statement.
> > > >
> > > > I am glad that we have at least a little code to start from when
> building
> > > > a
> > > > Kudu spanreceiver. What we need to do to get this merged is to
> actually
> > > > complete all the tasks mentioned in the original proposal document--
> > > > develop a way to run the full web interface against the Kudu
> > > > SpanReceiver,
> > > > write good documentation for setup and deployment, understand what
> the
> > > > correct schema to use to store data in Kudu is, measure performance,
> and
> > > > write unit tests.
> > > >
> > > > This my proposal under [1]
> > > > https://docs.google.com/document/d/14pnwHj5IsstCuBG3puD0x36KSmXxn
> > > glryRsfJcWP3Kg/edit?usp=sharing
> > > > This the last update which I gave to him under comment [2]
> > > > https://issues.apache.org/jira/browse/HTRACE-362?
> > > focusedCommentId=15428686&page=com.atlassian.jira.
> > > plugin.system.issuetabpanels:comment-tabpanel#comment-15428686
> > > >
> > > > Where I have completed second part of the project which has not been
> > > > reviewed, and If he could provide the answer whether to use the
> webapp (
> > > > in
> > > > previous comment ) similar to HBASE this project is done done. Where
> we
> > > > have similar webapp for like HBASE or integrate to current main
> Htrace
> > > > webapp. He never given answer because He wanted look this project
> failed.
> > > > Even the current HBASE htrace recever has have so many limitations,
> He
> > > > too
> > > > much expect this KUDU receiver to be PERFECT which I believe, is
> > > > completely
> > > > unacceptable.
> > > >
> > > > In my proposal I have never mentioned anything about performance
> test for
> > > > different kudu schema. Even in this main thread [1]
> > > > https://issues.apache.org/jira/browse/HTRACE-362 he has never
> mentioned
> > > > such. These are totally false statements. However I agree on the
> > > > documentation.
> > > >
> > > > The code I written for both span receiver and span viewer have unit
> tests
> > > > under pr [1] https://github.com/apache/incubator-htrace/pull/11 This
> > > > completely false I have written unit tests for both  span receiver
> and
> > > > viewer using KUDU mini cluster utility.
> > > >
> > > > I hope Google and Apache Organization Admins will reconsider my
> evalution
> > > > for GSoC 2016. In
> > > > [1]
> > > > https://gist.github.com/nisalanirmana/9ac0b8d34ee198f4dcafc64e6f84ba
> 5a
> > > > I have mentioned all the work that I completed. Since my mentor is
> first
> > > > time mentoring, He think all code should be by mentor evaluation.
> Which I
> > > > believe it is not the expectation.
> > > >
> > > > Regards
> > > > Nisala
> > >
>

Re: Re-evaluation of GSoC Final Evaluation Result ( Apache Htrace Kudu Backend )

[Colin McCabe <cm...@apache.org>]

Hi Nisala,

The facts here are clear.  At the end of the day, you got in two patches
over the summer and both of them were minor and not related to the Kudu
span receiver.  You have a big patch that is still in review, but not
yet ready to be committed.  You made 5 mailing list posts (2 of which
are in this very thread).  There are a lot of casual contributors on
this list who have done more than that in a week or two, let alone the
whole summer.

My midterm evaluation for you clearly stated that you needed to improve
your communication, become more active, and get more done.  I clearly
marked it as needing improvement.  I also sent repeated emails to you
saying that the project was in trouble, some of which you posted to this
very thread.

The reason why we set up emails rather than video calls is because the
first time we tried a video call, the picture and audio quality was very
poor, and neither of us could understand the other.  That's why I asked
you to email me twice a week.  Since you rarely sent status emails, I
usually had to email you instead and ask for status.  I usually didn't
get a response for several days, and sometimes I never got one.  This is
what I meant by "communication problems."  Arguing over whether you were
unresponsive for 2.5 weeks versus 3 weeks that one particular time
really misses the point, which is that you were consistently
unresponsive throughout the whole summer.  I understand that there is a
timezone delay, but that shouldn't cause several days of delay.

As to how much time per week I spent, I made a rough estimate.  Not very
scientific.  Some weeks I did spend more than 3 hours, for sure. 
Writing an email or doing a review can take a surprisingly long time,
especially a difficult one like the current one :(  Some weeks I spent
much less than 3-- but that was usually because you were ignoring my
emails, and my follow-up emails about why you were ignoring my emails :(
:(

I re-checked the original design document, and you are right, there is
no mention of adding performance measurements in there.  I was thinking
of a different GSoC proposal when I wrote that-- one which unfortunately
didn't get accepted.  However, clearly some kind of rough performance
test will eventually be needed in order to make this code production
quality.  It didn't necessarily need to get done as part of this
project, but we should have discussed plans for it in the future.

I understand that you did start working on this again a few days before
the end of GSoC, and made some progress on the SpanReceiver.  But there
is a lot more to GSoC than just cranking out a rough draft of some code
by the deadline.  Code often changes substantially during a code review.
 Sometimes even fundamental assumptions need to be re-examined, like the
schema or the threading model here.  Since the community needs to be
able to support this code once it goes in, we can't rush it in in a day
or two with minimal review.  We also need documentation on how to set
things up.  In the last week or two of the project, you should have been
finishing up documentation, answering questions on the mailing list, and
discussing future improvements and projects.  Not desperately trying to
crank out a rough draft of the very first deliverable in the design doc
before the deadline hits.

Lastly, HTrace is not a biased community-- we have contributors are from
Hortonworks, NTT Data, Facebook, etc. etc.  I'm sure we are not perfect,
but that is a heck of a lot better than many other projects.  This is
all really clear if you read the board reports-- or just the mailing
list, and see who is active.

If there's anything else I can answer, or help with, just email me
directly.  Like I said before, I don't think public mailing lists are
the appropriate venue for this conversation.  Posting from a place of
anger is never helpful and it can lead to you burning bridges.

Colin


On Tue, Aug 30, 2016, at 12:46, Nisala Mendis wrote:
> Hi Colin,
> 
> I understand it is your responsibility evaluate summer project as well I
> strongly believe the community need to know truthful is your evaluation
> facts you put into that Google evaluation.
> I also believe putting untruthful evaluation facts even far worse than
> exposing someone's personal emails.
> 
> So I hand over to Kudu and HTrace communities to evaluate the stuff that
> I
> wrote whether those are agree with facts you put into that my evaluation.
> I
> believe those who in this list the have better understanding
> of the technology can evaluate the facts of your evaluation against the
> code and the JIRA we had those all discussions. I even put this thing,
> knowing Apache Kudu and Apache Htrace
> very much biased Cloudera backed communities does not meet Apache open
> source standards by any means.
> 
> Even Google or Apache Organization GSoC Admins re-evaluate my evaluation
> or
> not, I believe this will be a good incident Google or participating
> Organization like Apache to evaluate their own mentors as well
> and also mentors to be honest to GSoC program as well being honest when
> you
> are filling that evaluation, rather you put false facts to prove why you
> have failed the student. If the student does not meet standards required
> by
> the program, It s your responsibility to fail the student but not by this
> kind of untruthful facts. I am sorry to point your personal emails, but I
> believe community need to know the truth which I believe I did mistake
> for
> all workI did not posted publicly in this mailing list, otherwise you
> would
> have never put untruthful facts as my evaluation.
> 
> I also suggest before you are going to fail a student, be honest to
> yourself whether you have spent at least a hour per week with the student
> meeting other Google and Apache mentoring standards, I truly believe
> mentor
> is not some one who just ask for status. I also suggest as person who
> works
> for Cloudera full time could do that kind of effort without putting some
> serious commitment.
> 
> Hopefully this will shed some light on future GSoC students as well.
> 
> Regards
> Nisala
> 
> On Tue, Aug 30, 2016 at 10:15 PM, Colin McCabe <cm...@apache.org>
> wrote:
> 
> > Hi Nisala,
> >
> > I'm truly sorry that our summer of code project didn't get completed.
> > You showed a lot of potential in the beginning, but unfortunately the
> > time commitment was just not there.  When students become unresponsive
> > for weeks at a time, it's very difficult for mentors.
> >
> > I think that if you focus, you can improve and do better in the future.
> > If you had told me that you were taking classes this summer, I might not
> > have suggested doing the project.  I also said that I will continue to
> > review any patches from you, and I stand by that.
> >
> > I don't think this really has any relevance to dev@htrace or dev@kudu.
> > This is really about evaluating the summer project, and that's my
> > responsibility.  I suggest taking the discussion off those lists.  Also,
> > I really suggest not reposting personal emails people send to you to
> > public mailing lists in the future, unless you ask the sender
> > beforehand.
> >
> > Colin
> >
> >
> > On Tue, Aug 30, 2016, at 00:47, Nisala Mendis wrote:
> > > Hi Google Support,
> > >
> > > I just got received my mentors evaluation and I would like request Google
> > > to kindly reevaluate my final outcome. I would like to point out my
> > > mentors
> > > each evaluation each point into you kind consideration.
> > >
> > > I am sorry that the project seems to have failed. I mentioned on the
> > > midterm evaluation that I was concerned about the lack of progress on the
> > > project, and unfortunately the pace only got slower after that. I think
> > > that the biggest problem that we had was that you simply did not dedicate
> > > enough time to the project to succeed. When we were in the project
> > > selection phase, you said that you could dedicate 35 hours a week to the
> > > project. However, this turned out to be a wild overestimate. I doubt that
> > > you spent more than 5 hours a week during any week, and for many weeks,
> > >
> > > First of all my mentor I would like to mention my mentor has never spent
> > > with me at lease one or two hour each week. Even  though we have agreed
> > > to
> > > share the status by each twice week, he has always ask for status without
> > > even let me what to do with my project without any guidance. Sometime I
> > > got
> > > even stuck he has never even shed  light, right from the beginning I
> > > learned their project deployment, and I worked out their development
> > > environment from my own. Apache htrace is still incubator process doesnt
> > > even have proper documentation. Expectation from my mentor is
> > > unacceptable
> > > under this conditions. He always say "You need to ask questions" If you
> > > can
> > > read until last of my mentor evaluation , he even himself agreed that
> > > even
> > > at last moment I have worked towards completion of project. There s not
> > > much left in this project. Theres no way one can do that without working
> > > at
> > > 5 hour per week. And
> > >
> > > you seem to have spent 0 hours-- not even bothering to respond to emails
> > > or
> > > send a status update. It's very frustrating when a student becomes
> > > uncommunicative for almost a full month at a time.
> > >
> > > This is a complete false statement I have never been in active for full
> > > one
> > > month. I have only been inactive maximum close  for two weeks. This is
> > > personal mail Colin my mentor and we agreed to move on. After two weeks
> > > inactivity this is the email I got from my mentor,
> > >
> > >
> > > Hi Nisala,
> > >
> > > You've been unresponsive for half a month.  I'm concerned about the
> > > project.  Frankly I feel like we might not have time to finish now,
> > > since you took such a long unannounced break in the middle.  The final
> > > evaluation is on August 15th.  Let's think about this more and how we
> > > could prevent it from happening again in the future.
> > >
> > > best,
> > >
> > > Colin
> > >
> > > This is his personal mail from him for my maximum inactivity for two
> > > weeks
> > > and we agreed to move on by JULY 19.
> > >
> > > My single biggest suggestion for improvement is to respond promptly when
> > > other people try to communicate, and to stick to pre-agreed schedules of
> > > project updates and meetings.
> > >
> > > First of all we agreed only share status on emails we never had meetings,
> > > we have never scheduled meetings.
> > >
> > > This is the email from my mentor that we agreed to share status by only
> > > mail. This is on Fri, May 6 during community bonding period.
> > >
> > >
> > > Hmm.  Video calls seem to be difficult, owing to the time difference and
> > > some of the technical issues.
> > >
> > > Instead, how about we exchange status emails two times a week.  Monday
> > > and
> > > Thursday seem like good days to email.
> > >
> > > I'll start.
> > >
> > > A big part of Google Summer of Code is learning to interact with the
> > > community and learn some things about the project.
> > >
> > > I have only communicated my status updates via JIRA ticket [1]
> > > https://issues.apache.org/jira/browse/HTRACE-362 where all community
> > sees
> > > my project. You will notice I have completed his reviews which has put
> > > during the final GSOC mentor evaluation period. Because we both agreed to
> > > successfully completion in earlier.
> > >
> > > When you try to complete a large portion of the code just a few days
> > > before
> > > the end of GSoC, the community has no time to review it, let alone
> > > discuss
> > > it. Code review takes time. It's also very important to respond to all
> > > the
> > > comments people make in a code review. I remember having to make the same
> > > comments several times before you would address them.
> > >
> > > What I wanted to highlight is [1]
> > > https://issues.apache.org/jira/browse/HTRACE-362 He still adds reviews
> > > for
> > > code that I wrote in mid term.
> > >  If you look at [1]
> > > https://issues.apache.org/jira/browse/HTRACE-362?
> > focusedCommentId=15333197&page=com.atlassian.jira.
> > plugin.system.issuetabpanels:comment-tabpanel#comment-15333197
> > > He has never mentioned anything about kudu schema but now adding reviews
> > > regarding that end of the project at [2]
> > > https://issues.apache.org/jira/browse/HTRACE-362?
> > focusedCommentId=15429907&page=com.atlassian.jira.
> > plugin.system.issuetabpanels:comment-tabpanel#comment-15429907
> > >
> > > This is totally unacceptable rather if some one want to fail that project
> > > do something like that. I agree in one time I couldn't address his all
> > > his
> > > requirements at once. He is keeps on adding reviews for code that I
> > > written
> > > for midterm regarding kudu schema and handling multiple parents of spans.
> > > He mid term code review does not include them all. Even he has failed to
> > > answer which schema should use.
> > >
> > > In this [1]
> > > https://issues.apache.org/jira/browse/HTRACE-362?
> > focusedCommentId=15437201&page=com.atlassian.jira.
> > plugin.system.issuetabpanels:comment-tabpanel#comment-15437201
> > > This was his response about kudu schema, where he claims I should have
> > > looked some other code as he claims
> > >
> > > This is one reason why I suggested that you look at LocalFileSpanReceiver
> > > and HTracedSpanReceiver rather than HBaseSpanReceiver.
> > >
> > > Which is completely false statement, He has never mentioned such to me
> > > even
> > > in that thread or personal mail. I wonder whether he could prove that to
> > > anyone. He wanted emphasize this project failed because of me this which
> > > is
> > > completely a false statement.
> > >
> > > I am glad that we have at least a little code to start from when building
> > > a
> > > Kudu spanreceiver. What we need to do to get this merged is to actually
> > > complete all the tasks mentioned in the original proposal document--
> > > develop a way to run the full web interface against the Kudu
> > > SpanReceiver,
> > > write good documentation for setup and deployment, understand what the
> > > correct schema to use to store data in Kudu is, measure performance, and
> > > write unit tests.
> > >
> > > This my proposal under [1]
> > > https://docs.google.com/document/d/14pnwHj5IsstCuBG3puD0x36KSmXxn
> > glryRsfJcWP3Kg/edit?usp=sharing
> > > This the last update which I gave to him under comment [2]
> > > https://issues.apache.org/jira/browse/HTRACE-362?
> > focusedCommentId=15428686&page=com.atlassian.jira.
> > plugin.system.issuetabpanels:comment-tabpanel#comment-15428686
> > >
> > > Where I have completed second part of the project which has not been
> > > reviewed, and If he could provide the answer whether to use the webapp (
> > > in
> > > previous comment ) similar to HBASE this project is done done. Where we
> > > have similar webapp for like HBASE or integrate to current main Htrace
> > > webapp. He never given answer because He wanted look this project failed.
> > > Even the current HBASE htrace recever has have so many limitations, He
> > > too
> > > much expect this KUDU receiver to be PERFECT which I believe, is
> > > completely
> > > unacceptable.
> > >
> > > In my proposal I have never mentioned anything about performance test for
> > > different kudu schema. Even in this main thread [1]
> > > https://issues.apache.org/jira/browse/HTRACE-362 he has never mentioned
> > > such. These are totally false statements. However I agree on the
> > > documentation.
> > >
> > > The code I written for both span receiver and span viewer have unit tests
> > > under pr [1] https://github.com/apache/incubator-htrace/pull/11 This
> > > completely false I have written unit tests for both  span receiver and
> > > viewer using KUDU mini cluster utility.
> > >
> > > I hope Google and Apache Organization Admins will reconsider my evalution
> > > for GSoC 2016. In
> > > [1]
> > > https://gist.github.com/nisalanirmana/9ac0b8d34ee198f4dcafc64e6f84ba5a
> > > I have mentioned all the work that I completed. Since my mentor is first
> > > time mentoring, He think all code should be by mentor evaluation. Which I
> > > believe it is not the expectation.
> > >
> > > Regards
> > > Nisala
> >

Re: Re-evaluation of GSoC Final Evaluation Result ( Apache Htrace Kudu Backend )

[Colin McCabe <cm...@apache.org>]

Hi Nisala,

The facts here are clear.  At the end of the day, you got in two patches
over the summer and both of them were minor and not related to the Kudu
span receiver.  You have a big patch that is still in review, but not
yet ready to be committed.  You made 5 mailing list posts (2 of which
are in this very thread).  There are a lot of casual contributors on
this list who have done more than that in a week or two, let alone the
whole summer.

My midterm evaluation for you clearly stated that you needed to improve
your communication, become more active, and get more done.  I clearly
marked it as needing improvement.  I also sent repeated emails to you
saying that the project was in trouble, some of which you posted to this
very thread.

The reason why we set up emails rather than video calls is because the
first time we tried a video call, the picture and audio quality was very
poor, and neither of us could understand the other.  That's why I asked
you to email me twice a week.  Since you rarely sent status emails, I
usually had to email you instead and ask for status.  I usually didn't
get a response for several days, and sometimes I never got one.  This is
what I meant by "communication problems."  Arguing over whether you were
unresponsive for 2.5 weeks versus 3 weeks that one particular time
really misses the point, which is that you were consistently
unresponsive throughout the whole summer.  I understand that there is a
timezone delay, but that shouldn't cause several days of delay.

As to how much time per week I spent, I made a rough estimate.  Not very
scientific.  Some weeks I did spend more than 3 hours, for sure. 
Writing an email or doing a review can take a surprisingly long time,
especially a difficult one like the current one :(  Some weeks I spent
much less than 3-- but that was usually because you were ignoring my
emails, and my follow-up emails about why you were ignoring my emails :(
:(

I re-checked the original design document, and you are right, there is
no mention of adding performance measurements in there.  I was thinking
of a different GSoC proposal when I wrote that-- one which unfortunately
didn't get accepted.  However, clearly some kind of rough performance
test will eventually be needed in order to make this code production
quality.  It didn't necessarily need to get done as part of this
project, but we should have discussed plans for it in the future.

I understand that you did start working on this again a few days before
the end of GSoC, and made some progress on the SpanReceiver.  But there
is a lot more to GSoC than just cranking out a rough draft of some code
by the deadline.  Code often changes substantially during a code review.
 Sometimes even fundamental assumptions need to be re-examined, like the
schema or the threading model here.  Since the community needs to be
able to support this code once it goes in, we can't rush it in in a day
or two with minimal review.  We also need documentation on how to set
things up.  In the last week or two of the project, you should have been
finishing up documentation, answering questions on the mailing list, and
discussing future improvements and projects.  Not desperately trying to
crank out a rough draft of the very first deliverable in the design doc
before the deadline hits.

Lastly, HTrace is not a biased community-- we have contributors are from
Hortonworks, NTT Data, Facebook, etc. etc.  I'm sure we are not perfect,
but that is a heck of a lot better than many other projects.  This is
all really clear if you read the board reports-- or just the mailing
list, and see who is active.

If there's anything else I can answer, or help with, just email me
directly.  Like I said before, I don't think public mailing lists are
the appropriate venue for this conversation.  Posting from a place of
anger is never helpful and it can lead to you burning bridges.

Colin


On Tue, Aug 30, 2016, at 12:46, Nisala Mendis wrote:
> Hi Colin,
> 
> I understand it is your responsibility evaluate summer project as well I
> strongly believe the community need to know truthful is your evaluation
> facts you put into that Google evaluation.
> I also believe putting untruthful evaluation facts even far worse than
> exposing someone's personal emails.
> 
> So I hand over to Kudu and HTrace communities to evaluate the stuff that
> I
> wrote whether those are agree with facts you put into that my evaluation.
> I
> believe those who in this list the have better understanding
> of the technology can evaluate the facts of your evaluation against the
> code and the JIRA we had those all discussions. I even put this thing,
> knowing Apache Kudu and Apache Htrace
> very much biased Cloudera backed communities does not meet Apache open
> source standards by any means.
> 
> Even Google or Apache Organization GSoC Admins re-evaluate my evaluation
> or
> not, I believe this will be a good incident Google or participating
> Organization like Apache to evaluate their own mentors as well
> and also mentors to be honest to GSoC program as well being honest when
> you
> are filling that evaluation, rather you put false facts to prove why you
> have failed the student. If the student does not meet standards required
> by
> the program, It s your responsibility to fail the student but not by this
> kind of untruthful facts. I am sorry to point your personal emails, but I
> believe community need to know the truth which I believe I did mistake
> for
> all workI did not posted publicly in this mailing list, otherwise you
> would
> have never put untruthful facts as my evaluation.
> 
> I also suggest before you are going to fail a student, be honest to
> yourself whether you have spent at least a hour per week with the student
> meeting other Google and Apache mentoring standards, I truly believe
> mentor
> is not some one who just ask for status. I also suggest as person who
> works
> for Cloudera full time could do that kind of effort without putting some
> serious commitment.
> 
> Hopefully this will shed some light on future GSoC students as well.
> 
> Regards
> Nisala
> 
> On Tue, Aug 30, 2016 at 10:15 PM, Colin McCabe <cm...@apache.org>
> wrote:
> 
> > Hi Nisala,
> >
> > I'm truly sorry that our summer of code project didn't get completed.
> > You showed a lot of potential in the beginning, but unfortunately the
> > time commitment was just not there.  When students become unresponsive
> > for weeks at a time, it's very difficult for mentors.
> >
> > I think that if you focus, you can improve and do better in the future.
> > If you had told me that you were taking classes this summer, I might not
> > have suggested doing the project.  I also said that I will continue to
> > review any patches from you, and I stand by that.
> >
> > I don't think this really has any relevance to dev@htrace or dev@kudu.
> > This is really about evaluating the summer project, and that's my
> > responsibility.  I suggest taking the discussion off those lists.  Also,
> > I really suggest not reposting personal emails people send to you to
> > public mailing lists in the future, unless you ask the sender
> > beforehand.
> >
> > Colin
> >
> >
> > On Tue, Aug 30, 2016, at 00:47, Nisala Mendis wrote:
> > > Hi Google Support,
> > >
> > > I just got received my mentors evaluation and I would like request Google
> > > to kindly reevaluate my final outcome. I would like to point out my
> > > mentors
> > > each evaluation each point into you kind consideration.
> > >
> > > I am sorry that the project seems to have failed. I mentioned on the
> > > midterm evaluation that I was concerned about the lack of progress on the
> > > project, and unfortunately the pace only got slower after that. I think
> > > that the biggest problem that we had was that you simply did not dedicate
> > > enough time to the project to succeed. When we were in the project
> > > selection phase, you said that you could dedicate 35 hours a week to the
> > > project. However, this turned out to be a wild overestimate. I doubt that
> > > you spent more than 5 hours a week during any week, and for many weeks,
> > >
> > > First of all my mentor I would like to mention my mentor has never spent
> > > with me at lease one or two hour each week. Even  though we have agreed
> > > to
> > > share the status by each twice week, he has always ask for status without
> > > even let me what to do with my project without any guidance. Sometime I
> > > got
> > > even stuck he has never even shed  light, right from the beginning I
> > > learned their project deployment, and I worked out their development
> > > environment from my own. Apache htrace is still incubator process doesnt
> > > even have proper documentation. Expectation from my mentor is
> > > unacceptable
> > > under this conditions. He always say "You need to ask questions" If you
> > > can
> > > read until last of my mentor evaluation , he even himself agreed that
> > > even
> > > at last moment I have worked towards completion of project. There s not
> > > much left in this project. Theres no way one can do that without working
> > > at
> > > 5 hour per week. And
> > >
> > > you seem to have spent 0 hours-- not even bothering to respond to emails
> > > or
> > > send a status update. It's very frustrating when a student becomes
> > > uncommunicative for almost a full month at a time.
> > >
> > > This is a complete false statement I have never been in active for full
> > > one
> > > month. I have only been inactive maximum close  for two weeks. This is
> > > personal mail Colin my mentor and we agreed to move on. After two weeks
> > > inactivity this is the email I got from my mentor,
> > >
> > >
> > > Hi Nisala,
> > >
> > > You've been unresponsive for half a month.  I'm concerned about the
> > > project.  Frankly I feel like we might not have time to finish now,
> > > since you took such a long unannounced break in the middle.  The final
> > > evaluation is on August 15th.  Let's think about this more and how we
> > > could prevent it from happening again in the future.
> > >
> > > best,
> > >
> > > Colin
> > >
> > > This is his personal mail from him for my maximum inactivity for two
> > > weeks
> > > and we agreed to move on by JULY 19.
> > >
> > > My single biggest suggestion for improvement is to respond promptly when
> > > other people try to communicate, and to stick to pre-agreed schedules of
> > > project updates and meetings.
> > >
> > > First of all we agreed only share status on emails we never had meetings,
> > > we have never scheduled meetings.
> > >
> > > This is the email from my mentor that we agreed to share status by only
> > > mail. This is on Fri, May 6 during community bonding period.
> > >
> > >
> > > Hmm.  Video calls seem to be difficult, owing to the time difference and
> > > some of the technical issues.
> > >
> > > Instead, how about we exchange status emails two times a week.  Monday
> > > and
> > > Thursday seem like good days to email.
> > >
> > > I'll start.
> > >
> > > A big part of Google Summer of Code is learning to interact with the
> > > community and learn some things about the project.
> > >
> > > I have only communicated my status updates via JIRA ticket [1]
> > > https://issues.apache.org/jira/browse/HTRACE-362 where all community
> > sees
> > > my project. You will notice I have completed his reviews which has put
> > > during the final GSOC mentor evaluation period. Because we both agreed to
> > > successfully completion in earlier.
> > >
> > > When you try to complete a large portion of the code just a few days
> > > before
> > > the end of GSoC, the community has no time to review it, let alone
> > > discuss
> > > it. Code review takes time. It's also very important to respond to all
> > > the
> > > comments people make in a code review. I remember having to make the same
> > > comments several times before you would address them.
> > >
> > > What I wanted to highlight is [1]
> > > https://issues.apache.org/jira/browse/HTRACE-362 He still adds reviews
> > > for
> > > code that I wrote in mid term.
> > >  If you look at [1]
> > > https://issues.apache.org/jira/browse/HTRACE-362?
> > focusedCommentId=15333197&page=com.atlassian.jira.
> > plugin.system.issuetabpanels:comment-tabpanel#comment-15333197
> > > He has never mentioned anything about kudu schema but now adding reviews
> > > regarding that end of the project at [2]
> > > https://issues.apache.org/jira/browse/HTRACE-362?
> > focusedCommentId=15429907&page=com.atlassian.jira.
> > plugin.system.issuetabpanels:comment-tabpanel#comment-15429907
> > >
> > > This is totally unacceptable rather if some one want to fail that project
> > > do something like that. I agree in one time I couldn't address his all
> > > his
> > > requirements at once. He is keeps on adding reviews for code that I
> > > written
> > > for midterm regarding kudu schema and handling multiple parents of spans.
> > > He mid term code review does not include them all. Even he has failed to
> > > answer which schema should use.
> > >
> > > In this [1]
> > > https://issues.apache.org/jira/browse/HTRACE-362?
> > focusedCommentId=15437201&page=com.atlassian.jira.
> > plugin.system.issuetabpanels:comment-tabpanel#comment-15437201
> > > This was his response about kudu schema, where he claims I should have
> > > looked some other code as he claims
> > >
> > > This is one reason why I suggested that you look at LocalFileSpanReceiver
> > > and HTracedSpanReceiver rather than HBaseSpanReceiver.
> > >
> > > Which is completely false statement, He has never mentioned such to me
> > > even
> > > in that thread or personal mail. I wonder whether he could prove that to
> > > anyone. He wanted emphasize this project failed because of me this which
> > > is
> > > completely a false statement.
> > >
> > > I am glad that we have at least a little code to start from when building
> > > a
> > > Kudu spanreceiver. What we need to do to get this merged is to actually
> > > complete all the tasks mentioned in the original proposal document--
> > > develop a way to run the full web interface against the Kudu
> > > SpanReceiver,
> > > write good documentation for setup and deployment, understand what the
> > > correct schema to use to store data in Kudu is, measure performance, and
> > > write unit tests.
> > >
> > > This my proposal under [1]
> > > https://docs.google.com/document/d/14pnwHj5IsstCuBG3puD0x36KSmXxn
> > glryRsfJcWP3Kg/edit?usp=sharing
> > > This the last update which I gave to him under comment [2]
> > > https://issues.apache.org/jira/browse/HTRACE-362?
> > focusedCommentId=15428686&page=com.atlassian.jira.
> > plugin.system.issuetabpanels:comment-tabpanel#comment-15428686
> > >
> > > Where I have completed second part of the project which has not been
> > > reviewed, and If he could provide the answer whether to use the webapp (
> > > in
> > > previous comment ) similar to HBASE this project is done done. Where we
> > > have similar webapp for like HBASE or integrate to current main Htrace
> > > webapp. He never given answer because He wanted look this project failed.
> > > Even the current HBASE htrace recever has have so many limitations, He
> > > too
> > > much expect this KUDU receiver to be PERFECT which I believe, is
> > > completely
> > > unacceptable.
> > >
> > > In my proposal I have never mentioned anything about performance test for
> > > different kudu schema. Even in this main thread [1]
> > > https://issues.apache.org/jira/browse/HTRACE-362 he has never mentioned
> > > such. These are totally false statements. However I agree on the
> > > documentation.
> > >
> > > The code I written for both span receiver and span viewer have unit tests
> > > under pr [1] https://github.com/apache/incubator-htrace/pull/11 This
> > > completely false I have written unit tests for both  span receiver and
> > > viewer using KUDU mini cluster utility.
> > >
> > > I hope Google and Apache Organization Admins will reconsider my evalution
> > > for GSoC 2016. In
> > > [1]
> > > https://gist.github.com/nisalanirmana/9ac0b8d34ee198f4dcafc64e6f84ba5a
> > > I have mentioned all the work that I completed. Since my mentor is first
> > > time mentoring, He think all code should be by mentor evaluation. Which I
> > > believe it is not the expectation.
> > >
> > > Regards
> > > Nisala
> >

Re: Re-evaluation of GSoC Final Evaluation Result ( Apache Htrace Kudu Backend )

[Nisala Mendis <ni...@gmail.com>]

Hi Colin,

I understand it is your responsibility evaluate summer project as well I
strongly believe the community need to know truthful is your evaluation
facts you put into that Google evaluation.
I also believe putting untruthful evaluation facts even far worse than
exposing someone's personal emails.

So I hand over to Kudu and HTrace communities to evaluate the stuff that I
wrote whether those are agree with facts you put into that my evaluation. I
believe those who in this list the have better understanding
of the technology can evaluate the facts of your evaluation against the
code and the JIRA we had those all discussions. I even put this thing,
knowing Apache Kudu and Apache Htrace
very much biased Cloudera backed communities does not meet Apache open
source standards by any means.

Even Google or Apache Organization GSoC Admins re-evaluate my evaluation or
not, I believe this will be a good incident Google or participating
Organization like Apache to evaluate their own mentors as well
and also mentors to be honest to GSoC program as well being honest when you
are filling that evaluation, rather you put false facts to prove why you
have failed the student. If the student does not meet standards required by
the program, It s your responsibility to fail the student but not by this
kind of untruthful facts. I am sorry to point your personal emails, but I
believe community need to know the truth which I believe I did mistake for
all workI did not posted publicly in this mailing list, otherwise you would
have never put untruthful facts as my evaluation.

I also suggest before you are going to fail a student, be honest to
yourself whether you have spent at least a hour per week with the student
meeting other Google and Apache mentoring standards, I truly believe mentor
is not some one who just ask for status. I also suggest as person who works
for Cloudera full time could do that kind of effort without putting some
serious commitment.

Hopefully this will shed some light on future GSoC students as well.

Regards
Nisala

On Tue, Aug 30, 2016 at 10:15 PM, Colin McCabe <cm...@apache.org> wrote:

> Hi Nisala,
>
> I'm truly sorry that our summer of code project didn't get completed.
> You showed a lot of potential in the beginning, but unfortunately the
> time commitment was just not there.  When students become unresponsive
> for weeks at a time, it's very difficult for mentors.
>
> I think that if you focus, you can improve and do better in the future.
> If you had told me that you were taking classes this summer, I might not
> have suggested doing the project.  I also said that I will continue to
> review any patches from you, and I stand by that.
>
> I don't think this really has any relevance to dev@htrace or dev@kudu.
> This is really about evaluating the summer project, and that's my
> responsibility.  I suggest taking the discussion off those lists.  Also,
> I really suggest not reposting personal emails people send to you to
> public mailing lists in the future, unless you ask the sender
> beforehand.
>
> Colin
>
>
> On Tue, Aug 30, 2016, at 00:47, Nisala Mendis wrote:
> > Hi Google Support,
> >
> > I just got received my mentors evaluation and I would like request Google
> > to kindly reevaluate my final outcome. I would like to point out my
> > mentors
> > each evaluation each point into you kind consideration.
> >
> > I am sorry that the project seems to have failed. I mentioned on the
> > midterm evaluation that I was concerned about the lack of progress on the
> > project, and unfortunately the pace only got slower after that. I think
> > that the biggest problem that we had was that you simply did not dedicate
> > enough time to the project to succeed. When we were in the project
> > selection phase, you said that you could dedicate 35 hours a week to the
> > project. However, this turned out to be a wild overestimate. I doubt that
> > you spent more than 5 hours a week during any week, and for many weeks,
> >
> > First of all my mentor I would like to mention my mentor has never spent
> > with me at lease one or two hour each week. Even  though we have agreed
> > to
> > share the status by each twice week, he has always ask for status without
> > even let me what to do with my project without any guidance. Sometime I
> > got
> > even stuck he has never even shed  light, right from the beginning I
> > learned their project deployment, and I worked out their development
> > environment from my own. Apache htrace is still incubator process doesnt
> > even have proper documentation. Expectation from my mentor is
> > unacceptable
> > under this conditions. He always say "You need to ask questions" If you
> > can
> > read until last of my mentor evaluation , he even himself agreed that
> > even
> > at last moment I have worked towards completion of project. There s not
> > much left in this project. Theres no way one can do that without working
> > at
> > 5 hour per week. And
> >
> > you seem to have spent 0 hours-- not even bothering to respond to emails
> > or
> > send a status update. It's very frustrating when a student becomes
> > uncommunicative for almost a full month at a time.
> >
> > This is a complete false statement I have never been in active for full
> > one
> > month. I have only been inactive maximum close  for two weeks. This is
> > personal mail Colin my mentor and we agreed to move on. After two weeks
> > inactivity this is the email I got from my mentor,
> >
> >
> > Hi Nisala,
> >
> > You've been unresponsive for half a month.  I'm concerned about the
> > project.  Frankly I feel like we might not have time to finish now,
> > since you took such a long unannounced break in the middle.  The final
> > evaluation is on August 15th.  Let's think about this more and how we
> > could prevent it from happening again in the future.
> >
> > best,
> >
> > Colin
> >
> > This is his personal mail from him for my maximum inactivity for two
> > weeks
> > and we agreed to move on by JULY 19.
> >
> > My single biggest suggestion for improvement is to respond promptly when
> > other people try to communicate, and to stick to pre-agreed schedules of
> > project updates and meetings.
> >
> > First of all we agreed only share status on emails we never had meetings,
> > we have never scheduled meetings.
> >
> > This is the email from my mentor that we agreed to share status by only
> > mail. This is on Fri, May 6 during community bonding period.
> >
> >
> > Hmm.  Video calls seem to be difficult, owing to the time difference and
> > some of the technical issues.
> >
> > Instead, how about we exchange status emails two times a week.  Monday
> > and
> > Thursday seem like good days to email.
> >
> > I'll start.
> >
> > A big part of Google Summer of Code is learning to interact with the
> > community and learn some things about the project.
> >
> > I have only communicated my status updates via JIRA ticket [1]
> > https://issues.apache.org/jira/browse/HTRACE-362 where all community
> sees
> > my project. You will notice I have completed his reviews which has put
> > during the final GSOC mentor evaluation period. Because we both agreed to
> > successfully completion in earlier.
> >
> > When you try to complete a large portion of the code just a few days
> > before
> > the end of GSoC, the community has no time to review it, let alone
> > discuss
> > it. Code review takes time. It's also very important to respond to all
> > the
> > comments people make in a code review. I remember having to make the same
> > comments several times before you would address them.
> >
> > What I wanted to highlight is [1]
> > https://issues.apache.org/jira/browse/HTRACE-362 He still adds reviews
> > for
> > code that I wrote in mid term.
> >  If you look at [1]
> > https://issues.apache.org/jira/browse/HTRACE-362?
> focusedCommentId=15333197&page=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-15333197
> > He has never mentioned anything about kudu schema but now adding reviews
> > regarding that end of the project at [2]
> > https://issues.apache.org/jira/browse/HTRACE-362?
> focusedCommentId=15429907&page=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-15429907
> >
> > This is totally unacceptable rather if some one want to fail that project
> > do something like that. I agree in one time I couldn't address his all
> > his
> > requirements at once. He is keeps on adding reviews for code that I
> > written
> > for midterm regarding kudu schema and handling multiple parents of spans.
> > He mid term code review does not include them all. Even he has failed to
> > answer which schema should use.
> >
> > In this [1]
> > https://issues.apache.org/jira/browse/HTRACE-362?
> focusedCommentId=15437201&page=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-15437201
> > This was his response about kudu schema, where he claims I should have
> > looked some other code as he claims
> >
> > This is one reason why I suggested that you look at LocalFileSpanReceiver
> > and HTracedSpanReceiver rather than HBaseSpanReceiver.
> >
> > Which is completely false statement, He has never mentioned such to me
> > even
> > in that thread or personal mail. I wonder whether he could prove that to
> > anyone. He wanted emphasize this project failed because of me this which
> > is
> > completely a false statement.
> >
> > I am glad that we have at least a little code to start from when building
> > a
> > Kudu spanreceiver. What we need to do to get this merged is to actually
> > complete all the tasks mentioned in the original proposal document--
> > develop a way to run the full web interface against the Kudu
> > SpanReceiver,
> > write good documentation for setup and deployment, understand what the
> > correct schema to use to store data in Kudu is, measure performance, and
> > write unit tests.
> >
> > This my proposal under [1]
> > https://docs.google.com/document/d/14pnwHj5IsstCuBG3puD0x36KSmXxn
> glryRsfJcWP3Kg/edit?usp=sharing
> > This the last update which I gave to him under comment [2]
> > https://issues.apache.org/jira/browse/HTRACE-362?
> focusedCommentId=15428686&page=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-15428686
> >
> > Where I have completed second part of the project which has not been
> > reviewed, and If he could provide the answer whether to use the webapp (
> > in
> > previous comment ) similar to HBASE this project is done done. Where we
> > have similar webapp for like HBASE or integrate to current main Htrace
> > webapp. He never given answer because He wanted look this project failed.
> > Even the current HBASE htrace recever has have so many limitations, He
> > too
> > much expect this KUDU receiver to be PERFECT which I believe, is
> > completely
> > unacceptable.
> >
> > In my proposal I have never mentioned anything about performance test for
> > different kudu schema. Even in this main thread [1]
> > https://issues.apache.org/jira/browse/HTRACE-362 he has never mentioned
> > such. These are totally false statements. However I agree on the
> > documentation.
> >
> > The code I written for both span receiver and span viewer have unit tests
> > under pr [1] https://github.com/apache/incubator-htrace/pull/11 This
> > completely false I have written unit tests for both  span receiver and
> > viewer using KUDU mini cluster utility.
> >
> > I hope Google and Apache Organization Admins will reconsider my evalution
> > for GSoC 2016. In
> > [1]
> > https://gist.github.com/nisalanirmana/9ac0b8d34ee198f4dcafc64e6f84ba5a
> > I have mentioned all the work that I completed. Since my mentor is first
> > time mentoring, He think all code should be by mentor evaluation. Which I
> > believe it is not the expectation.
> >
> > Regards
> > Nisala
>

Re: Re-evaluation of GSoC Final Evaluation Result ( Apache Htrace Kudu Backend )

[Nisala Mendis <ni...@gmail.com>]

Hi Colin,

I understand it is your responsibility evaluate summer project as well I
strongly believe the community need to know truthful is your evaluation
facts you put into that Google evaluation.
I also believe putting untruthful evaluation facts even far worse than
exposing someone's personal emails.

So I hand over to Kudu and HTrace communities to evaluate the stuff that I
wrote whether those are agree with facts you put into that my evaluation. I
believe those who in this list the have better understanding
of the technology can evaluate the facts of your evaluation against the
code and the JIRA we had those all discussions. I even put this thing,
knowing Apache Kudu and Apache Htrace
very much biased Cloudera backed communities does not meet Apache open
source standards by any means.

Even Google or Apache Organization GSoC Admins re-evaluate my evaluation or
not, I believe this will be a good incident Google or participating
Organization like Apache to evaluate their own mentors as well
and also mentors to be honest to GSoC program as well being honest when you
are filling that evaluation, rather you put false facts to prove why you
have failed the student. If the student does not meet standards required by
the program, It s your responsibility to fail the student but not by this
kind of untruthful facts. I am sorry to point your personal emails, but I
believe community need to know the truth which I believe I did mistake for
all workI did not posted publicly in this mailing list, otherwise you would
have never put untruthful facts as my evaluation.

I also suggest before you are going to fail a student, be honest to
yourself whether you have spent at least a hour per week with the student
meeting other Google and Apache mentoring standards, I truly believe mentor
is not some one who just ask for status. I also suggest as person who works
for Cloudera full time could do that kind of effort without putting some
serious commitment.

Hopefully this will shed some light on future GSoC students as well.

Regards
Nisala

On Tue, Aug 30, 2016 at 10:15 PM, Colin McCabe <cm...@apache.org> wrote:

> Hi Nisala,
>
> I'm truly sorry that our summer of code project didn't get completed.
> You showed a lot of potential in the beginning, but unfortunately the
> time commitment was just not there.  When students become unresponsive
> for weeks at a time, it's very difficult for mentors.
>
> I think that if you focus, you can improve and do better in the future.
> If you had told me that you were taking classes this summer, I might not
> have suggested doing the project.  I also said that I will continue to
> review any patches from you, and I stand by that.
>
> I don't think this really has any relevance to dev@htrace or dev@kudu.
> This is really about evaluating the summer project, and that's my
> responsibility.  I suggest taking the discussion off those lists.  Also,
> I really suggest not reposting personal emails people send to you to
> public mailing lists in the future, unless you ask the sender
> beforehand.
>
> Colin
>
>
> On Tue, Aug 30, 2016, at 00:47, Nisala Mendis wrote:
> > Hi Google Support,
> >
> > I just got received my mentors evaluation and I would like request Google
> > to kindly reevaluate my final outcome. I would like to point out my
> > mentors
> > each evaluation each point into you kind consideration.
> >
> > I am sorry that the project seems to have failed. I mentioned on the
> > midterm evaluation that I was concerned about the lack of progress on the
> > project, and unfortunately the pace only got slower after that. I think
> > that the biggest problem that we had was that you simply did not dedicate
> > enough time to the project to succeed. When we were in the project
> > selection phase, you said that you could dedicate 35 hours a week to the
> > project. However, this turned out to be a wild overestimate. I doubt that
> > you spent more than 5 hours a week during any week, and for many weeks,
> >
> > First of all my mentor I would like to mention my mentor has never spent
> > with me at lease one or two hour each week. Even  though we have agreed
> > to
> > share the status by each twice week, he has always ask for status without
> > even let me what to do with my project without any guidance. Sometime I
> > got
> > even stuck he has never even shed  light, right from the beginning I
> > learned their project deployment, and I worked out their development
> > environment from my own. Apache htrace is still incubator process doesnt
> > even have proper documentation. Expectation from my mentor is
> > unacceptable
> > under this conditions. He always say "You need to ask questions" If you
> > can
> > read until last of my mentor evaluation , he even himself agreed that
> > even
> > at last moment I have worked towards completion of project. There s not
> > much left in this project. Theres no way one can do that without working
> > at
> > 5 hour per week. And
> >
> > you seem to have spent 0 hours-- not even bothering to respond to emails
> > or
> > send a status update. It's very frustrating when a student becomes
> > uncommunicative for almost a full month at a time.
> >
> > This is a complete false statement I have never been in active for full
> > one
> > month. I have only been inactive maximum close  for two weeks. This is
> > personal mail Colin my mentor and we agreed to move on. After two weeks
> > inactivity this is the email I got from my mentor,
> >
> >
> > Hi Nisala,
> >
> > You've been unresponsive for half a month.  I'm concerned about the
> > project.  Frankly I feel like we might not have time to finish now,
> > since you took such a long unannounced break in the middle.  The final
> > evaluation is on August 15th.  Let's think about this more and how we
> > could prevent it from happening again in the future.
> >
> > best,
> >
> > Colin
> >
> > This is his personal mail from him for my maximum inactivity for two
> > weeks
> > and we agreed to move on by JULY 19.
> >
> > My single biggest suggestion for improvement is to respond promptly when
> > other people try to communicate, and to stick to pre-agreed schedules of
> > project updates and meetings.
> >
> > First of all we agreed only share status on emails we never had meetings,
> > we have never scheduled meetings.
> >
> > This is the email from my mentor that we agreed to share status by only
> > mail. This is on Fri, May 6 during community bonding period.
> >
> >
> > Hmm.  Video calls seem to be difficult, owing to the time difference and
> > some of the technical issues.
> >
> > Instead, how about we exchange status emails two times a week.  Monday
> > and
> > Thursday seem like good days to email.
> >
> > I'll start.
> >
> > A big part of Google Summer of Code is learning to interact with the
> > community and learn some things about the project.
> >
> > I have only communicated my status updates via JIRA ticket [1]
> > https://issues.apache.org/jira/browse/HTRACE-362 where all community
> sees
> > my project. You will notice I have completed his reviews which has put
> > during the final GSOC mentor evaluation period. Because we both agreed to
> > successfully completion in earlier.
> >
> > When you try to complete a large portion of the code just a few days
> > before
> > the end of GSoC, the community has no time to review it, let alone
> > discuss
> > it. Code review takes time. It's also very important to respond to all
> > the
> > comments people make in a code review. I remember having to make the same
> > comments several times before you would address them.
> >
> > What I wanted to highlight is [1]
> > https://issues.apache.org/jira/browse/HTRACE-362 He still adds reviews
> > for
> > code that I wrote in mid term.
> >  If you look at [1]
> > https://issues.apache.org/jira/browse/HTRACE-362?
> focusedCommentId=15333197&page=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-15333197
> > He has never mentioned anything about kudu schema but now adding reviews
> > regarding that end of the project at [2]
> > https://issues.apache.org/jira/browse/HTRACE-362?
> focusedCommentId=15429907&page=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-15429907
> >
> > This is totally unacceptable rather if some one want to fail that project
> > do something like that. I agree in one time I couldn't address his all
> > his
> > requirements at once. He is keeps on adding reviews for code that I
> > written
> > for midterm regarding kudu schema and handling multiple parents of spans.
> > He mid term code review does not include them all. Even he has failed to
> > answer which schema should use.
> >
> > In this [1]
> > https://issues.apache.org/jira/browse/HTRACE-362?
> focusedCommentId=15437201&page=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-15437201
> > This was his response about kudu schema, where he claims I should have
> > looked some other code as he claims
> >
> > This is one reason why I suggested that you look at LocalFileSpanReceiver
> > and HTracedSpanReceiver rather than HBaseSpanReceiver.
> >
> > Which is completely false statement, He has never mentioned such to me
> > even
> > in that thread or personal mail. I wonder whether he could prove that to
> > anyone. He wanted emphasize this project failed because of me this which
> > is
> > completely a false statement.
> >
> > I am glad that we have at least a little code to start from when building
> > a
> > Kudu spanreceiver. What we need to do to get this merged is to actually
> > complete all the tasks mentioned in the original proposal document--
> > develop a way to run the full web interface against the Kudu
> > SpanReceiver,
> > write good documentation for setup and deployment, understand what the
> > correct schema to use to store data in Kudu is, measure performance, and
> > write unit tests.
> >
> > This my proposal under [1]
> > https://docs.google.com/document/d/14pnwHj5IsstCuBG3puD0x36KSmXxn
> glryRsfJcWP3Kg/edit?usp=sharing
> > This the last update which I gave to him under comment [2]
> > https://issues.apache.org/jira/browse/HTRACE-362?
> focusedCommentId=15428686&page=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-15428686
> >
> > Where I have completed second part of the project which has not been
> > reviewed, and If he could provide the answer whether to use the webapp (
> > in
> > previous comment ) similar to HBASE this project is done done. Where we
> > have similar webapp for like HBASE or integrate to current main Htrace
> > webapp. He never given answer because He wanted look this project failed.
> > Even the current HBASE htrace recever has have so many limitations, He
> > too
> > much expect this KUDU receiver to be PERFECT which I believe, is
> > completely
> > unacceptable.
> >
> > In my proposal I have never mentioned anything about performance test for
> > different kudu schema. Even in this main thread [1]
> > https://issues.apache.org/jira/browse/HTRACE-362 he has never mentioned
> > such. These are totally false statements. However I agree on the
> > documentation.
> >
> > The code I written for both span receiver and span viewer have unit tests
> > under pr [1] https://github.com/apache/incubator-htrace/pull/11 This
> > completely false I have written unit tests for both  span receiver and
> > viewer using KUDU mini cluster utility.
> >
> > I hope Google and Apache Organization Admins will reconsider my evalution
> > for GSoC 2016. In
> > [1]
> > https://gist.github.com/nisalanirmana/9ac0b8d34ee198f4dcafc64e6f84ba5a
> > I have mentioned all the work that I completed. Since my mentor is first
> > time mentoring, He think all code should be by mentor evaluation. Which I
> > believe it is not the expectation.
> >
> > Regards
> > Nisala
>

Re: Re-evaluation of GSoC Final Evaluation Result ( Apache Htrace Kudu Backend )

[Colin McCabe <cm...@apache.org>]

Hi Nisala,

I'm truly sorry that our summer of code project didn't get completed. 
You showed a lot of potential in the beginning, but unfortunately the
time commitment was just not there.  When students become unresponsive
for weeks at a time, it's very difficult for mentors.

I think that if you focus, you can improve and do better in the future. 
If you had told me that you were taking classes this summer, I might not
have suggested doing the project.  I also said that I will continue to
review any patches from you, and I stand by that.

I don't think this really has any relevance to dev@htrace or dev@kudu. 
This is really about evaluating the summer project, and that's my
responsibility.  I suggest taking the discussion off those lists.  Also,
I really suggest not reposting personal emails people send to you to
public mailing lists in the future, unless you ask the sender
beforehand.

Colin


On Tue, Aug 30, 2016, at 00:47, Nisala Mendis wrote:
> Hi Google Support,
> 
> I just got received my mentors evaluation and I would like request Google
> to kindly reevaluate my final outcome. I would like to point out my
> mentors
> each evaluation each point into you kind consideration.
> 
> I am sorry that the project seems to have failed. I mentioned on the
> midterm evaluation that I was concerned about the lack of progress on the
> project, and unfortunately the pace only got slower after that. I think
> that the biggest problem that we had was that you simply did not dedicate
> enough time to the project to succeed. When we were in the project
> selection phase, you said that you could dedicate 35 hours a week to the
> project. However, this turned out to be a wild overestimate. I doubt that
> you spent more than 5 hours a week during any week, and for many weeks,
> 
> First of all my mentor I would like to mention my mentor has never spent
> with me at lease one or two hour each week. Even  though we have agreed
> to
> share the status by each twice week, he has always ask for status without
> even let me what to do with my project without any guidance. Sometime I
> got
> even stuck he has never even shed  light, right from the beginning I
> learned their project deployment, and I worked out their development
> environment from my own. Apache htrace is still incubator process doesnt
> even have proper documentation. Expectation from my mentor is
> unacceptable
> under this conditions. He always say "You need to ask questions" If you
> can
> read until last of my mentor evaluation , he even himself agreed that
> even
> at last moment I have worked towards completion of project. There s not
> much left in this project. Theres no way one can do that without working
> at
> 5 hour per week. And
> 
> you seem to have spent 0 hours-- not even bothering to respond to emails
> or
> send a status update. It's very frustrating when a student becomes
> uncommunicative for almost a full month at a time.
> 
> This is a complete false statement I have never been in active for full
> one
> month. I have only been inactive maximum close  for two weeks. This is
> personal mail Colin my mentor and we agreed to move on. After two weeks
> inactivity this is the email I got from my mentor,
> 
> 
> Hi Nisala,
> 
> You've been unresponsive for half a month.  I'm concerned about the
> project.  Frankly I feel like we might not have time to finish now,
> since you took such a long unannounced break in the middle.  The final
> evaluation is on August 15th.  Let's think about this more and how we
> could prevent it from happening again in the future.
> 
> best,
> 
> Colin
> 
> This is his personal mail from him for my maximum inactivity for two
> weeks
> and we agreed to move on by JULY 19.
> 
> My single biggest suggestion for improvement is to respond promptly when
> other people try to communicate, and to stick to pre-agreed schedules of
> project updates and meetings.
> 
> First of all we agreed only share status on emails we never had meetings,
> we have never scheduled meetings.
> 
> This is the email from my mentor that we agreed to share status by only
> mail. This is on Fri, May 6 during community bonding period.
> 
> 
> Hmm.  Video calls seem to be difficult, owing to the time difference and
> some of the technical issues.
> 
> Instead, how about we exchange status emails two times a week.  Monday
> and
> Thursday seem like good days to email.
> 
> I'll start.
> 
> A big part of Google Summer of Code is learning to interact with the
> community and learn some things about the project.
> 
> I have only communicated my status updates via JIRA ticket [1]
> https://issues.apache.org/jira/browse/HTRACE-362 where all community sees
> my project. You will notice I have completed his reviews which has put
> during the final GSOC mentor evaluation period. Because we both agreed to
> successfully completion in earlier.
> 
> When you try to complete a large portion of the code just a few days
> before
> the end of GSoC, the community has no time to review it, let alone
> discuss
> it. Code review takes time. It's also very important to respond to all
> the
> comments people make in a code review. I remember having to make the same
> comments several times before you would address them.
> 
> What I wanted to highlight is [1]
> https://issues.apache.org/jira/browse/HTRACE-362 He still adds reviews
> for
> code that I wrote in mid term.
>  If you look at [1]
> https://issues.apache.org/jira/browse/HTRACE-362?focusedCommentId=15333197&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15333197
> He has never mentioned anything about kudu schema but now adding reviews
> regarding that end of the project at [2]
> https://issues.apache.org/jira/browse/HTRACE-362?focusedCommentId=15429907&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15429907
> 
> This is totally unacceptable rather if some one want to fail that project
> do something like that. I agree in one time I couldn't address his all
> his
> requirements at once. He is keeps on adding reviews for code that I
> written
> for midterm regarding kudu schema and handling multiple parents of spans.
> He mid term code review does not include them all. Even he has failed to
> answer which schema should use.
> 
> In this [1]
> https://issues.apache.org/jira/browse/HTRACE-362?focusedCommentId=15437201&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15437201
> This was his response about kudu schema, where he claims I should have
> looked some other code as he claims
> 
> This is one reason why I suggested that you look at LocalFileSpanReceiver
> and HTracedSpanReceiver rather than HBaseSpanReceiver.
> 
> Which is completely false statement, He has never mentioned such to me
> even
> in that thread or personal mail. I wonder whether he could prove that to
> anyone. He wanted emphasize this project failed because of me this which
> is
> completely a false statement.
> 
> I am glad that we have at least a little code to start from when building
> a
> Kudu spanreceiver. What we need to do to get this merged is to actually
> complete all the tasks mentioned in the original proposal document--
> develop a way to run the full web interface against the Kudu
> SpanReceiver,
> write good documentation for setup and deployment, understand what the
> correct schema to use to store data in Kudu is, measure performance, and
> write unit tests.
> 
> This my proposal under [1]
> https://docs.google.com/document/d/14pnwHj5IsstCuBG3puD0x36KSmXxnglryRsfJcWP3Kg/edit?usp=sharing
> This the last update which I gave to him under comment [2]
> https://issues.apache.org/jira/browse/HTRACE-362?focusedCommentId=15428686&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15428686
> 
> Where I have completed second part of the project which has not been
> reviewed, and If he could provide the answer whether to use the webapp (
> in
> previous comment ) similar to HBASE this project is done done. Where we
> have similar webapp for like HBASE or integrate to current main Htrace
> webapp. He never given answer because He wanted look this project failed.
> Even the current HBASE htrace recever has have so many limitations, He
> too
> much expect this KUDU receiver to be PERFECT which I believe, is
> completely
> unacceptable.
> 
> In my proposal I have never mentioned anything about performance test for
> different kudu schema. Even in this main thread [1]
> https://issues.apache.org/jira/browse/HTRACE-362 he has never mentioned
> such. These are totally false statements. However I agree on the
> documentation.
> 
> The code I written for both span receiver and span viewer have unit tests
> under pr [1] https://github.com/apache/incubator-htrace/pull/11 This
> completely false I have written unit tests for both  span receiver and
> viewer using KUDU mini cluster utility.
> 
> I hope Google and Apache Organization Admins will reconsider my evalution
> for GSoC 2016. In
> [1]
> https://gist.github.com/nisalanirmana/9ac0b8d34ee198f4dcafc64e6f84ba5a
> I have mentioned all the work that I completed. Since my mentor is first
> time mentoring, He think all code should be by mentor evaluation. Which I
> believe it is not the expectation.
> 
> Regards
> Nisala

Re: Re-evaluation of GSoC Final Evaluation Result ( Apache Htrace Kudu Backend )

[Colin McCabe <cm...@apache.org>]

Hi Nisala,

I'm truly sorry that our summer of code project didn't get completed. 
You showed a lot of potential in the beginning, but unfortunately the
time commitment was just not there.  When students become unresponsive
for weeks at a time, it's very difficult for mentors.

I think that if you focus, you can improve and do better in the future. 
If you had told me that you were taking classes this summer, I might not
have suggested doing the project.  I also said that I will continue to
review any patches from you, and I stand by that.

I don't think this really has any relevance to dev@htrace or dev@kudu. 
This is really about evaluating the summer project, and that's my
responsibility.  I suggest taking the discussion off those lists.  Also,
I really suggest not reposting personal emails people send to you to
public mailing lists in the future, unless you ask the sender
beforehand.

Colin


On Tue, Aug 30, 2016, at 00:47, Nisala Mendis wrote:
> Hi Google Support,
> 
> I just got received my mentors evaluation and I would like request Google
> to kindly reevaluate my final outcome. I would like to point out my
> mentors
> each evaluation each point into you kind consideration.
> 
> I am sorry that the project seems to have failed. I mentioned on the
> midterm evaluation that I was concerned about the lack of progress on the
> project, and unfortunately the pace only got slower after that. I think
> that the biggest problem that we had was that you simply did not dedicate
> enough time to the project to succeed. When we were in the project
> selection phase, you said that you could dedicate 35 hours a week to the
> project. However, this turned out to be a wild overestimate. I doubt that
> you spent more than 5 hours a week during any week, and for many weeks,
> 
> First of all my mentor I would like to mention my mentor has never spent
> with me at lease one or two hour each week. Even  though we have agreed
> to
> share the status by each twice week, he has always ask for status without
> even let me what to do with my project without any guidance. Sometime I
> got
> even stuck he has never even shed  light, right from the beginning I
> learned their project deployment, and I worked out their development
> environment from my own. Apache htrace is still incubator process doesnt
> even have proper documentation. Expectation from my mentor is
> unacceptable
> under this conditions. He always say "You need to ask questions" If you
> can
> read until last of my mentor evaluation , he even himself agreed that
> even
> at last moment I have worked towards completion of project. There s not
> much left in this project. Theres no way one can do that without working
> at
> 5 hour per week. And
> 
> you seem to have spent 0 hours-- not even bothering to respond to emails
> or
> send a status update. It's very frustrating when a student becomes
> uncommunicative for almost a full month at a time.
> 
> This is a complete false statement I have never been in active for full
> one
> month. I have only been inactive maximum close  for two weeks. This is
> personal mail Colin my mentor and we agreed to move on. After two weeks
> inactivity this is the email I got from my mentor,
> 
> 
> Hi Nisala,
> 
> You've been unresponsive for half a month.  I'm concerned about the
> project.  Frankly I feel like we might not have time to finish now,
> since you took such a long unannounced break in the middle.  The final
> evaluation is on August 15th.  Let's think about this more and how we
> could prevent it from happening again in the future.
> 
> best,
> 
> Colin
> 
> This is his personal mail from him for my maximum inactivity for two
> weeks
> and we agreed to move on by JULY 19.
> 
> My single biggest suggestion for improvement is to respond promptly when
> other people try to communicate, and to stick to pre-agreed schedules of
> project updates and meetings.
> 
> First of all we agreed only share status on emails we never had meetings,
> we have never scheduled meetings.
> 
> This is the email from my mentor that we agreed to share status by only
> mail. This is on Fri, May 6 during community bonding period.
> 
> 
> Hmm.  Video calls seem to be difficult, owing to the time difference and
> some of the technical issues.
> 
> Instead, how about we exchange status emails two times a week.  Monday
> and
> Thursday seem like good days to email.
> 
> I'll start.
> 
> A big part of Google Summer of Code is learning to interact with the
> community and learn some things about the project.
> 
> I have only communicated my status updates via JIRA ticket [1]
> https://issues.apache.org/jira/browse/HTRACE-362 where all community sees
> my project. You will notice I have completed his reviews which has put
> during the final GSOC mentor evaluation period. Because we both agreed to
> successfully completion in earlier.
> 
> When you try to complete a large portion of the code just a few days
> before
> the end of GSoC, the community has no time to review it, let alone
> discuss
> it. Code review takes time. It's also very important to respond to all
> the
> comments people make in a code review. I remember having to make the same
> comments several times before you would address them.
> 
> What I wanted to highlight is [1]
> https://issues.apache.org/jira/browse/HTRACE-362 He still adds reviews
> for
> code that I wrote in mid term.
>  If you look at [1]
> https://issues.apache.org/jira/browse/HTRACE-362?focusedCommentId=15333197&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15333197
> He has never mentioned anything about kudu schema but now adding reviews
> regarding that end of the project at [2]
> https://issues.apache.org/jira/browse/HTRACE-362?focusedCommentId=15429907&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15429907
> 
> This is totally unacceptable rather if some one want to fail that project
> do something like that. I agree in one time I couldn't address his all
> his
> requirements at once. He is keeps on adding reviews for code that I
> written
> for midterm regarding kudu schema and handling multiple parents of spans.
> He mid term code review does not include them all. Even he has failed to
> answer which schema should use.
> 
> In this [1]
> https://issues.apache.org/jira/browse/HTRACE-362?focusedCommentId=15437201&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15437201
> This was his response about kudu schema, where he claims I should have
> looked some other code as he claims
> 
> This is one reason why I suggested that you look at LocalFileSpanReceiver
> and HTracedSpanReceiver rather than HBaseSpanReceiver.
> 
> Which is completely false statement, He has never mentioned such to me
> even
> in that thread or personal mail. I wonder whether he could prove that to
> anyone. He wanted emphasize this project failed because of me this which
> is
> completely a false statement.
> 
> I am glad that we have at least a little code to start from when building
> a
> Kudu spanreceiver. What we need to do to get this merged is to actually
> complete all the tasks mentioned in the original proposal document--
> develop a way to run the full web interface against the Kudu
> SpanReceiver,
> write good documentation for setup and deployment, understand what the
> correct schema to use to store data in Kudu is, measure performance, and
> write unit tests.
> 
> This my proposal under [1]
> https://docs.google.com/document/d/14pnwHj5IsstCuBG3puD0x36KSmXxnglryRsfJcWP3Kg/edit?usp=sharing
> This the last update which I gave to him under comment [2]
> https://issues.apache.org/jira/browse/HTRACE-362?focusedCommentId=15428686&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15428686
> 
> Where I have completed second part of the project which has not been
> reviewed, and If he could provide the answer whether to use the webapp (
> in
> previous comment ) similar to HBASE this project is done done. Where we
> have similar webapp for like HBASE or integrate to current main Htrace
> webapp. He never given answer because He wanted look this project failed.
> Even the current HBASE htrace recever has have so many limitations, He
> too
> much expect this KUDU receiver to be PERFECT which I believe, is
> completely
> unacceptable.
> 
> In my proposal I have never mentioned anything about performance test for
> different kudu schema. Even in this main thread [1]
> https://issues.apache.org/jira/browse/HTRACE-362 he has never mentioned
> such. These are totally false statements. However I agree on the
> documentation.
> 
> The code I written for both span receiver and span viewer have unit tests
> under pr [1] https://github.com/apache/incubator-htrace/pull/11 This
> completely false I have written unit tests for both  span receiver and
> viewer using KUDU mini cluster utility.
> 
> I hope Google and Apache Organization Admins will reconsider my evalution
> for GSoC 2016. In
> [1]
> https://gist.github.com/nisalanirmana/9ac0b8d34ee198f4dcafc64e6f84ba5a
> I have mentioned all the work that I completed. Since my mentor is first
> time mentoring, He think all code should be by mentor evaluation. Which I
> believe it is not the expectation.
> 
> Regards
> Nisala