I'd first like to extend the idea of bug #312977. It's basically about a
different level of detail for each question.

I think the quiz questions can be divided into different groups:

1) Questions that are fun to answer. People should either already know
the answer, know where to look, or be willing to figure the answers out
themselves without a hint to specific docs.

2) Questions about stuff that people NEED to know for day-to-day
development, but that aren't much fun to answer. Petteri's proposed
level of detail would be appropriate here.

3) Questions that aren't that important at all and would just be "nice
to know". These are the ones that make people give up on the quizzes
because they are boring and the answers hard to find. Most people would
like to see this kind of questions dropped entirely, but recruiter's
point is that people should know about them, even though they aren't
fun. This is why for these I'd add a more exact pointer to the docs,
similar to the way we do in the interviews when a recruit doesn't know
an answer. This way they won't be demotivated because they won't have to
search for too long, yet know the answer and remember it when they need
it someday.

Examples for these:

5.	What is the Gentoo Foundation? How does one apply for membership and
who are eligible?
	[Gentoo Foundation Bylaws, "Members"]

5. What is wrong with using $(somecommand) or `somecommand` or $ARCH
	inside SRC_URI, DEPEND, etc?
	[Devmanual, Caching]
	

I think this is a good starting point to get rid of the "some important
questions are too hard to answer" dilemma that can be implemented
relatively fast. On top of that I like Sebastian's idea to order the
quizzes by difficulty -- this means just ordering by the categories I
just mentioned would be sufficient: 1 first, then 2, then 3.

As soon as we have implemented that, we can think about how to make the
ebuild-related questions more interesting by using tasks and example
ebuilds. I guess this part will take a longer time.

basile wrote, on 04/04/2010 05:16 PM:
> The learning flow should go something like this:
> [..]

I like that idea. However, I would combine writing the example ebuild
(i.e. "doing the task") and answering questions. There's no need to show
twice what you have learnt. Also, some of our questions could pretty
easily be replaced by doing a task, some cannot.