On Mon, Feb 22, 2016 at 01:56:52PM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > I agree that there are a lot of different ways to resolve each instance, > > and it will vary from case to case. I think the original point of a > > microproject was to do something really easy and not contentious, so > > that the student could get familiar with all of the other parts of the > > cycle: writing a commit message, formatting the patch, posting to the > > list, etc. > > I had an impression that Micros are also used as an aptitude test, > and one important trait we want to see in a potential developer is > how well s/he interacts with others in such a discussion. So "easy > and not contentious" might not be a very good criteria. > > I dunno. I sort-of agree. I think of the microprojects as more of a "fizz-buzz", where you intentionally keep the technical level very low so that you can evaluate the other things. So I think a little back and forth is good; almost everybody does something a little wrong in their first patch submission. But I'd worry about a topic that is going to involve a lot of bikeshedding or subtle nuances to finding the correct solution. I certainly think _some_ candidates can handle that, but for the ones who cannot, it may frustrate all involved. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html