Re: [PATCH] GSoC Change multiple if-else statements to be table-driven

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 17, 2014, 07:31 UTC
Message-ID: <7v38ihuvq7.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAPig+cSG0YsdTGWWyxWrg+s235qDe7Xr-jXT2mOkpvA6OaGWyg@mail.gmail.com>

Eric Sunshine <sunshine@sunshineco.com> writes:

Show 5 quoted lines

> Perhaps it is time to mark this microproject as "taken" on the GSoC
> page [2], along a fews others for which we have received multiple
> submissions.
>
> [2]: https://github.com/git/git.github.io/blob/master/SoC-2014-Microprojects.md

I actually have been of multiple minds on this.

 * After seeing that many candidates tried to solve the same micro,
   apparently without checking answers by other people, and seeing
   how they responded to the reviews given to them, I found that we
   had as equally good interactions with them to judge their skills,
   both techincal and social, as we would have had if each of them
   solved different micros.

 * Many reviewers may have gotten tired of seeing many novice
   attempts on the same micro over and over again, giving gentle
   suggestions for improvements. Because the _sole_ purpose of these
   micros were to help candidates get their toes wet in the process,
   duplicated efforts on the candidates' side are not wasted---they
   each hopefully learned how to interact with this community.

   But it is true that, if we were wishing to also get some trivial
   clean-ups in the codebase as a side effect of these micros, we
   have wasted reviewer bandwidth by not having enough micros, and
   reviewers may have had some feeling that their efforts did not
   fully contribute to improving our codebase, which may have been
   discouraging.

   Big thanks go to all reviewers who participated despite this.  If
   we had more micros, the apparent wastage of the reviewer efforts
   might have been avoided.

 * Many candidates did not even bother to check if others are
   working on the same micro, however, which would be a bad sign by
   itself. Concentrating on one's own topic, without paying any
   attention to what others are working on the same software, is
   never a good discipline.

   Some may argue that it would be unfair to blame the candidates on
   this---they may have picked up micros that haven't been solved if
   we had more---but after seeing that many candidates' submissions
   apparently did not take into account the reviews given to others'
   submissions on the same micro and/or had many exactly the same
   issues like log message styles as submissions on other micros
   that have already been reviewed, I personally do not think they
   are blameless.

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.

Again, Big Thanks to Michael for the excellent "micro" idea, and all reviewers who participated.