git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Michael Haggerty <mhagger@alum.mit.edu>
Cc: Eric Sunshine <sunshine@sunshineco.com>, Git List <git@vger.kernel.org>
Subject: Re: [PATCH] GSoC Change multiple if-else statements to be table-driven
Date: Mon, 17 Mar 2014 12:12:33 -0700	[thread overview]
Message-ID: <xmqqeh20ej1a.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <5327027D.6090500@alum.mit.edu> (Michael Haggerty's message of "Mon, 17 Mar 2014 15:11:09 +0100")

Michael Haggerty <mhagger@alum.mit.edu> writes:

> On 03/17/2014 08:31 AM, Junio C Hamano wrote:
>
>> So in short, yes it would have been nicer if we had more micros than
>> candidates, but I do not think it was detrimental for the purpose of
>> these micro exercises that multiple candidates ended up attempting
>> the same micro.
>
> I wish I had had time to invent more microprojects.  I think we were
> lucky: since students didn't seem to learn from each other's attempts,
> the fact that many people tried the same microprojects wasn't much of a
> problem.  But if a student had arrived with a "perfect" solution to a
> well-trodden microproject on his/her first attempt, I would hate to have
> to be suspicious that the student plagiarized from somebody else's
> answer plus all of the review comments about the earlier answer,
> especially since a perfect solution would itself reduce the amount of
> interaction between the cheating student and the mailing list compared
> to a student who required several iterations.

It may probably be not a huge problem.  If anything, a cheater would
have also learned how the mailing interaction goes when trying to
plagiarise.  And not really having interacted us, a cheater would
have left us no impression on his or her communication skills, so it
would probably have been detrimental for his or her own chance to be
chosen as a student, compared to the ones who started from their own
solution and polished it by responding to reviews.

> I also hope that students
> didn't feel unwelcomed during the times when the list of untaken
> microprojects was nearly empty.

Yeah, that is why I said I was of multiple minds.  I wasn't enthused
by seeing the ones that somebody is attempting marked as "taken" in
the first place.  Solving one that others attempted in his or her
own way and interacting with reviewers seemed to have just as much
information on the candidate, at least to me.

> If we really wanted to make this system cheat-proof, there would have to
> be not only enough microprojects to go around, but also some mechanism
> to ensure that student B didn't start work on a microproject that
> student A was just about to submit a solution to.

Nah, I do not think there is any need to go there.  It is over for
this year anyway, but I do not think such a provision is necessary
for future years, if Git project will participate in future GSoCs;
see above.

> Maybe in the future our microprojects should have two parts:
>
> a. Fix ...
> b. Invent a microproject for the next student.
>
> (Just kidding.)

;-)

  reply	other threads:[~2014-03-17 19:12 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-12  3:47 [PATCH] SoC 2014 MicroProject No.8:change multiple if-else statement to table-driven approach Yao Zhao
2014-03-12  9:21 ` Eric Sunshine
2014-03-13 20:20   ` [PATCH] GSoC Change multiple if-else statements to be table-driven Yao Zhao
2014-03-14  2:16     ` Eric Sunshine
2014-03-14 16:54       ` Junio C Hamano
2014-03-17  6:29         ` Eric Sunshine
2014-03-17  7:31           ` Junio C Hamano
2014-03-17 14:11             ` Michael Haggerty
2014-03-17 19:12               ` Junio C Hamano [this message]
2014-03-17 19:27               ` Eric Sunshine
2014-03-17 20:39                 ` Quint Guvernator
2014-03-16  6:08       ` [PATCH/GSoC_v3] branch.c: turn nested if-else logic to table-driven Yao Zhao
2014-03-17  7:54         ` Eric Sunshine

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqeh20ej1a.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=mhagger@alum.mit.edu \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).