1 |
I'd first like to extend the idea of bug #312977. It's basically about a |
2 |
different level of detail for each question. |
3 |
|
4 |
I think the quiz questions can be divided into different groups: |
5 |
|
6 |
1) Questions that are fun to answer. People should either already know |
7 |
the answer, know where to look, or be willing to figure the answers out |
8 |
themselves without a hint to specific docs. |
9 |
|
10 |
2) Questions about stuff that people NEED to know for day-to-day |
11 |
development, but that aren't much fun to answer. Petteri's proposed |
12 |
level of detail would be appropriate here. |
13 |
|
14 |
3) Questions that aren't that important at all and would just be "nice |
15 |
to know". These are the ones that make people give up on the quizzes |
16 |
because they are boring and the answers hard to find. Most people would |
17 |
like to see this kind of questions dropped entirely, but recruiter's |
18 |
point is that people should know about them, even though they aren't |
19 |
fun. This is why for these I'd add a more exact pointer to the docs, |
20 |
similar to the way we do in the interviews when a recruit doesn't know |
21 |
an answer. This way they won't be demotivated because they won't have to |
22 |
search for too long, yet know the answer and remember it when they need |
23 |
it someday. |
24 |
|
25 |
Examples for these: |
26 |
|
27 |
5. What is the Gentoo Foundation? How does one apply for membership and |
28 |
who are eligible? |
29 |
[Gentoo Foundation Bylaws, "Members"] |
30 |
|
31 |
5. What is wrong with using $(somecommand) or `somecommand` or $ARCH |
32 |
inside SRC_URI, DEPEND, etc? |
33 |
[Devmanual, Caching] |
34 |
|
35 |
|
36 |
I think this is a good starting point to get rid of the "some important |
37 |
questions are too hard to answer" dilemma that can be implemented |
38 |
relatively fast. On top of that I like Sebastian's idea to order the |
39 |
quizzes by difficulty -- this means just ordering by the categories I |
40 |
just mentioned would be sufficient: 1 first, then 2, then 3. |
41 |
|
42 |
As soon as we have implemented that, we can think about how to make the |
43 |
ebuild-related questions more interesting by using tasks and example |
44 |
ebuilds. I guess this part will take a longer time. |
45 |
|
46 |
basile wrote, on 04/04/2010 05:16 PM: |
47 |
> The learning flow should go something like this: |
48 |
> [..] |
49 |
|
50 |
I like that idea. However, I would combine writing the example ebuild |
51 |
(i.e. "doing the task") and answering questions. There's no need to show |
52 |
twice what you have learnt. Also, some of our questions could pretty |
53 |
easily be replaced by doing a task, some cannot. |