| 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 |
Archives