"Fishy" Misinformation Was Re: Concerns about GCI

Andrew Whitworth wknight8111 at gmail.com
Mon Jan 3 18:14:19 UTC 2011


On Mon, Jan 3, 2011 at 12:50 PM, Jason Garrett-Glaser
<darkshikari at gmail.com> wrote:
> You have a student completing 10 difficult tasks in a day.  Are you
> batching tasks, or is he actually completing 10 difficult tasks in a
> day?

I'm one of the Parrot core developers who has been mentoring rfw and
several other students as well. We are not batching tasks.

We have been offering several different types of tasks for the GCI
students, the code coverage tasks that you mentioned are a relatively
recent addition to our queues. There is a limited number of these
tasks to go around, because there is only so much coverage that can be
added to bring critical systems up to 100%, and because we already had
a substantial test suite in place so nothing is starting from 0.

The code coverage tasks in particular are hard to gauge difficulty
for. Some of the tasks have indeed turned out to be easier than
expected. Others have proven quite hard and a small handful have
turned out to be all but impossible to test completely. On average I
would say that they are pretty challenging to do, though not all of
them are. As far as I am aware, we are not able to adjust the
difficulty or points value of a task after it has been claimed and we
become aware of the real effort involved. This is something that we
can discuss as a collective so we can be better prepared for next year
(if GCI is offered again next year, which I sincerely hope for).

Many code coverage tasks in Parrot are pretty straight-forward: Read
the code, figure out how to test it, write the tests, and re-run the
coverage numbers to verify an improvement. In several cases these
students have identified bits of dead code, and then things get
significantly more challenging: Remove the dead code without breaking
anything. Here, "anything" is not just Parrot, but also compilers,
runtimes, and other projects that run on top of the Parrot VM. In
several instances, students have found reaching a coverage goal is
impossible to do, which often takes a long time to figure out.

rfw and a handful of other students who have been completing many
Parrot tasks have become quite familiar with the system, and have an
intuitive insight into some tasks that helps them figure these tasks
out faster. A task that would be "difficult" for most students may be
"medium" or even "easy" for a student like rfw because of his
familiarity with our system. I am very open to suggestions about how
such situations should be handled.

> P.S. It was rfw who originally posted the complaint about us, which
> makes this even more stupid.  The exact same person who complains
> about someone else completing a lot of tasks goes on to do exactly
> what he complained about, while continuing to complain about us!
> We've had Google breathing down our throats because of his complaints,
> all while he did the exact same thing for another organization.  This
> is completely unreasonable.

I can't speak to rfw's comments on this mailing list or elsewhere, but
I can say that he has been an extremely dedicated and active
participant. His skill and his management of time are exemplary. We
have been having trouble keeping up with him, both in reviewing his
submitted work and writing up new tasks to keep him busy. We have
purposefully increased the size and scope of offered tasks to take
advantage of his skills. Tasks that we mark as "difficult" now are
much larger than tasks marked "difficult" at the beginning of the
program, but at the same time are being completed much faster today
than they were two months ago. I think this is a good thing.

--Andrew Whitworth


More information about the parrot-dev mailing list