summaryrefslogtreecommitdiff
path: root/community
diff options
context:
space:
mode:
authorantrik <antrik@users.sf.net>2010-03-12 15:54:47 +0100
committerantrik <antrik@users.sf.net>2010-03-12 15:54:47 +0100
commitb6a58c6837b338eb3661580d9e76b47e764f1489 (patch)
tree12b5f7e1e3267b2d855af252b42634344ec46e50 /community
parent74ee772de9661c54fe7658589f79e520bb8e0171 (diff)
gsoc/organization_application: Improve wording
Mostly based on suggestions from tschwinge.
Diffstat (limited to 'community')
-rw-r--r--community/gsoc/organization_application.mdwn16
1 files changed, 8 insertions, 8 deletions
diff --git a/community/gsoc/organization_application.mdwn b/community/gsoc/organization_application.mdwn
index 471f3bdc..a376ffaa 100644
--- a/community/gsoc/organization_application.mdwn
+++ b/community/gsoc/organization_application.mdwn
@@ -77,7 +77,7 @@ Aside from that, it is a way to make progress with tasks that require an amount
focused work, that is hard to do for volunteers working in their spare time
only.
-Also it is a good opportunity to get valuable input from new people, as well as
+Also, the Google Summer of Code is a good opportunity to get valuable input from new people, as well as
spreading technical and other knowledge about the Hurd among actual and
potential contributors.
@@ -98,8 +98,8 @@ In 2009, we were rejected as an organisation, so we participated under the GNU
umbrella again.
While the 2006 student disappeared midway, in all the later years all of our
-students were successful -- including even one who worked on his project in
-spite of not getting a slot. Half of them are regular Hurd contributors now.
+students were successful -- even including one who worked on his project in
+spite of not getting an official slot. Half of them are regular Hurd contributors now.
Selecting the most promising students, as well as suitable mentors, turned out
to be the most tricky part of GSoC participation -- but we learned our lesson
@@ -149,7 +149,7 @@ won't be left on their own with any problems they face.
The plan is mostly to avoid that happening in the first place. To this end, we
are particularily careful with selection of students: Making sure
-that they have no other obligations during that time; that they are motivated
+that they have no other major obligations during that time; that they are motivated
enough; that they actually have the necessary skills to complete the task; that
they fit in our community.
@@ -163,7 +163,7 @@ project can perhaps be scaled down, or at least wrapped up to bring it in a
state where it is useful even if not finished.
We will also try to limit damage by insisting that students regularily check in
-their work, so that we get partial results at least if someone disappears.
+their work to our source repositories, so that we get partial results at least if someone disappears.
* What is your plan for dealing with disappearing mentors?
@@ -178,15 +178,15 @@ should go smoothly.
* What steps will you take to encourage students to interact with your project's community before, during and after the program?
We try to make it very clear that we expect the students to get into regular
-contact with us before the end of the student selection process, and won't
+contact with us early during the student selection process already, and won't
consider their applications otherwise. This way we know that the students are
able and willing to communicate with us in the first place.
After selection, the regular contact is kept up: we require the
students to participate in IRC meetings up to twice a week, where we ask the students
actively about the work they do, problems they face, decisions they take, etc.
-Furthermore, we ask them to hang out on IRC most of the time while
-working on their projects, so we keep in close contact.
+Furthermore, we ask them to be available on IRC while working on their
+projects, so we can communicate easily.
We also require the students to join our main development mailing list, so any
design questions, etc. can be discussed there. We encourage them to take