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 |