Gentoo Archives: gentoo-commits

From: "Donnie Berkholz (dberkholz)" <dberkholz@g.o>
To: gentoo-commits@l.g.o
Subject: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/userrel/soc: applying.xml
Date: Wed, 21 Apr 2010 01:47:12
Message-Id: 20100421014703.42BC92C04B@corvid.gentoo.org
1 dberkholz 10/04/21 01:47:03
2
3 Modified: applying.xml
4 Log:
5 Minor formatting.
6
7 Revision Changes Path
8 1.8 xml/htdocs/proj/en/userrel/soc/applying.xml
9
10 file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/userrel/soc/applying.xml?rev=1.8&view=markup
11 plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/userrel/soc/applying.xml?rev=1.8&content-type=text/plain
12 diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/userrel/soc/applying.xml?r1=1.7&r2=1.8
13
14 Index: applying.xml
15 ===================================================================
16 RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/userrel/soc/applying.xml,v
17 retrieving revision 1.7
18 retrieving revision 1.8
19 diff -u -r1.7 -r1.8
20 --- applying.xml 21 Apr 2010 01:09:26 -0000 1.7
21 +++ applying.xml 21 Apr 2010 01:47:03 -0000 1.8
22 @@ -52,21 +52,21 @@
23 is not sufficient in most cases to sway anyone.
24 </p>
25 <ol>
26 - <li>Objective - What problem does the project solve. This does not need to
27 + <li><e>Objective</e> - What problem does the project solve. This does not need to
28 be a long section. Generally software tries to help make people more
29 efficient, or foster communication, or entertain folks. Any proposed
30 software should have a purpose and applicants should define that purpose
31 here.</li>
32 - <li>Abstract - What does the project do; try to keep this section to one
33 + <li><e>Abstract</e> - What does the project do; try to keep this section to one
34 paragraph. It should not be an in depth analysis but is helpful when
35 someone desires an overview of the project.</li>
36 - <li>Deliverables - What will the project consist of when it is finished?
37 + <li><e>Deliverables</e> - What will the project consist of when it is finished?
38 Source code, documentation, a build system, libraries, binaries; these should
39 all be enumerated in your proposal. Without a concrete set of deliverables
40 it is difficult to judge if a student finished their proposal. If it is
41 difficult to judge if the proposal was finished, it is difficult to pay for
42 the work as well.</li>
43 - <li>Timeline - When will the deliverables be done? This is <b>very</b>
44 + <li><e>Timeline</e> - When will the deliverables be done? This is <b>very</b>
45 important for the mid-term evaluation as the mentor has to determine if a
46 given student has made enough progress to award them money. A student should
47 strive to make this as easy for the mentor as possible by providing a bar
48 @@ -74,7 +74,7 @@
49 make good judgements in time costs and if the student slips behind he/she
50 should alert their mentor to this fact and explain why the estimates were
51 wrong.</li>
52 - <li>Biography - The student should talk about themselves: where they are from
53 + <li><e>Biography</e> - The student should talk about themselves: where they are from
54 what they like to study, what they do in their free time, etc. Part of this
55 contest is to make new friends and learn about each other and this is an
56 important part of that goal. This section should include things like previous