How to Improve GHOP
2 views
Skip to first unread message
LH (Leslie Hawthorn)
Jul 16, 2008, 11:44:03 PM7/16/08
to GHOP Contest Administrative List
<standard disclaimer>
Google does not preannounce products or programs. We are talking about
how to improve our student outreach programs should the company run
them again.
</standard disclaimer>
On Friday, 11 July in the evening, all the families of our GHOPers,
the winners and most mentors, plus Todd Larsen from Google engineering
(Tech Lead for Melange: http://code.google.com/p/soc/) met to discuss
how to improve GHOP. Here are edited/annotated notes:
> How can we can improve GHOP?
> Tailored web-app for actual workflow. Feature requests:
> Automating/efficient. Open source, app engine.
> The Melange web app itself could be an organization accepting students to work
> on it for GHOP/GSoC/
> Bullk upload of tasks, from spreadsheet
> Some form of export (perhaps CSV?)
> Atom feeds for keeping up with progress.
Workflow Notes & Melange Feature Requests:
> Create new tasks, begin in state "open."
> When a student clicks "I claim this task", status immediately changes; student cannot claim additional tasks.
> Student can use system to ping mentor to say "review", and then mentor either closes task (student can then claim a new task) or leave it open - needs more work, does not meet spec, etc.
> Can edit tasks when added to the system. (ed note: it is *not good* to edit a task when it is in play. you can comment on how to do it, but you cannot change the parameters once it is out there.)
> Allow mentors to privately score tasks.
> Email reminders to students, e.g. 24 hours left to provide task submissions, when task is overdue, etc.
> Report to show overdue tasks. Nice to have a select all to reopen all delinquent tasks.
> Student can re-open (unassign) task themselves.
> Public to go to a task and "Digg It" (e.g. your work really made by day?).
> Set priority of tasks (mentors to suggest they really would like X task done over task Y) - a task is a task is a task is a task by contest rules. you're welcome to talk about what the project needs with students and should - this is a great means of "community bonding"
> Allow tasks to be uploaded, hidden, so you can release then with a simple single click "Publish".
We should make this a P1.
Extension could be automatically publish (invisible) pending tasks,
when others are finished.
I feel like this is a P4. I want mentors to have a good handle on how
much is going on, when things get finished, talking to their students,
etc. Too much automation precludes this.
> Allow reviewer to specify a limit (e.g. 5) on maximim the number of tasks that can be set as claimed/for review, so they do not get overwhelmed.
I think the best way to deal with this is to queue tasks and not
publish until you know you're ready (or can find more volunteers to
review).
> Rate-limiting maximum number of items (e.g. 20) for an organization, set by Google (host in melange terms) org admin.
> Provide mechanism for mentoring organizations to apply.
> This years winners will be eligible to enter next year.
> GHOP might or might not happen, but we might have more to say around the same time this year as last year. Melange readiness is a gating factor.
> Concern from Mono and Gnome: Hard to come up with short coding tasks.
> Problem with students trying to perform a task throughout the full review period.
> Goal is for student to do the best "overall" job (to win.)
> Subjective as "throughness", including community engagement. Not do the most tasks. Lots of discussion.
The Money:
> Suggestion to do 3 tasks per $50. What about $50 for first we tasks, then $16 for each task thereafter, up to $500?
- we can only get AMEX checks in multiples of 100 USD easily; I think
the cost structure is actually not that bad. More thoughts?
> There is no way to deal with $500 being less valuable to US students than
> to East European ones.
> Question: Shall we propose a difficulty rating for tasks? So that achieving
> it is weighted and rewarded accordingly? (Need to check with the lawyers,
> but they had previously wished to make them all the same difficulty.)
> Students say reviews are a problem. Students go on IRC and bug mentors to review now. (Countered by this is only an issue for the top few students?)
> To mitigate, have more reviewers.
> Reviewers might provide inconsistent feedback (e.g. that work is good/crap.) Projects should provide guidelines to reviewers for projects to augment/tailor.
> Time limit to perform a task stays. (Roughly 1 week?) - can be days or a bit more than a week; no less than 24 hours.
> Initial GHOP was very secret and this will be less so this time. To allow reviewers.
> Students: Many more programming languages / projects available ++
> Was it about the money? No one asked for more; some said they'd do it for no money.
> It is okay to (succesfully) close a task if the student is unable to complete a task when it is not their fault (e.g. they hit a bug beyond a student's ability.). Ergo, trust your instincts.
> It is okay to stipulate for a reply or some small activity earlier than the main deadline (e.g. you must tell us your favourite colour within 24 hours of starting a task), e.g. step one is introduce yourself on this mailing list if you haven't yet
> Try and Check with lawyers if students can do tasks they've failed?
> Is the 10-week duration of being able to claim tasks ok? Some mentors suggested less time, LH wishes to keep as is.
> (Note: Several winners hadn't done significant coding before GHOP.)
> Start recruiting students now so that they were prepared .
> Start was busy, xmas was hard with mentors being absent, but then settled down.
> Elim: mentoring GHOP is very different to GSOC mentoring.
> Todd suggested to do GHOP web-app responsibilies. Pawel is going to be helping. Patches (and lots more code) welcome at http://code.google.com/p/soc/
Parent:
> Parents find it important that the contest is of a precise duration, scope,
> with set and understable rules, etc. Safely, not taken advantage of, be
> over-loaded with work, without the ability to negotiate timing or saying
> "no.", or be given responsibility, due to power dynamics. For them to work
> outside the contest (e.g. communication participation), is scary. This
> causes friction with the GHOP goals of getting students to become entrenched
> in the community.
> Suggest to write a welcome letter to parents "This is how we choose the
> orgs, the mentors, these are the risks around involvement, it is our not so
> secret hope students of today become mentors of tomorrow, and what that
> means is that students may be encouraged to be voluntary on-going work.
> Explain basics of open source communities/contributors. Parents won't know!"
Definitely. And send 'em to http://www.producingoss.com
Thanks to Siggy for the initial set of notes. Other should feel free
to comment/add items missed.
Cheers,
LH
Google does not preannounce products or programs. We are talking about
how to improve our student outreach programs should the company run
them again.
</standard disclaimer>
On Friday, 11 July in the evening, all the families of our GHOPers,
the winners and most mentors, plus Todd Larsen from Google engineering
(Tech Lead for Melange: http://code.google.com/p/soc/) met to discuss
how to improve GHOP. Here are edited/annotated notes:
> How can we can improve GHOP?
> Tailored web-app for actual workflow. Feature requests:
> Automating/efficient. Open source, app engine.
> The Melange web app itself could be an organization accepting students to work
> on it for GHOP/GSoC/
> Bullk upload of tasks, from spreadsheet
> Some form of export (perhaps CSV?)
> Atom feeds for keeping up with progress.
Workflow Notes & Melange Feature Requests:
> Create new tasks, begin in state "open."
> When a student clicks "I claim this task", status immediately changes; student cannot claim additional tasks.
> Student can use system to ping mentor to say "review", and then mentor either closes task (student can then claim a new task) or leave it open - needs more work, does not meet spec, etc.
> Can edit tasks when added to the system. (ed note: it is *not good* to edit a task when it is in play. you can comment on how to do it, but you cannot change the parameters once it is out there.)
> Allow mentors to privately score tasks.
> Email reminders to students, e.g. 24 hours left to provide task submissions, when task is overdue, etc.
> Report to show overdue tasks. Nice to have a select all to reopen all delinquent tasks.
> Student can re-open (unassign) task themselves.
> Public to go to a task and "Digg It" (e.g. your work really made by day?).
> Set priority of tasks (mentors to suggest they really would like X task done over task Y) - a task is a task is a task is a task by contest rules. you're welcome to talk about what the project needs with students and should - this is a great means of "community bonding"
> Allow tasks to be uploaded, hidden, so you can release then with a simple single click "Publish".
We should make this a P1.
Extension could be automatically publish (invisible) pending tasks,
when others are finished.
I feel like this is a P4. I want mentors to have a good handle on how
much is going on, when things get finished, talking to their students,
etc. Too much automation precludes this.
> Allow reviewer to specify a limit (e.g. 5) on maximim the number of tasks that can be set as claimed/for review, so they do not get overwhelmed.
I think the best way to deal with this is to queue tasks and not
publish until you know you're ready (or can find more volunteers to
review).
> Rate-limiting maximum number of items (e.g. 20) for an organization, set by Google (host in melange terms) org admin.
> Provide mechanism for mentoring organizations to apply.
> This years winners will be eligible to enter next year.
> GHOP might or might not happen, but we might have more to say around the same time this year as last year. Melange readiness is a gating factor.
> Concern from Mono and Gnome: Hard to come up with short coding tasks.
> Problem with students trying to perform a task throughout the full review period.
> Goal is for student to do the best "overall" job (to win.)
> Subjective as "throughness", including community engagement. Not do the most tasks. Lots of discussion.
The Money:
> Suggestion to do 3 tasks per $50. What about $50 for first we tasks, then $16 for each task thereafter, up to $500?
- we can only get AMEX checks in multiples of 100 USD easily; I think
the cost structure is actually not that bad. More thoughts?
> There is no way to deal with $500 being less valuable to US students than
> to East European ones.
> Question: Shall we propose a difficulty rating for tasks? So that achieving
> it is weighted and rewarded accordingly? (Need to check with the lawyers,
> but they had previously wished to make them all the same difficulty.)
> Students say reviews are a problem. Students go on IRC and bug mentors to review now. (Countered by this is only an issue for the top few students?)
> To mitigate, have more reviewers.
> Reviewers might provide inconsistent feedback (e.g. that work is good/crap.) Projects should provide guidelines to reviewers for projects to augment/tailor.
> Time limit to perform a task stays. (Roughly 1 week?) - can be days or a bit more than a week; no less than 24 hours.
> Initial GHOP was very secret and this will be less so this time. To allow reviewers.
> Students: Many more programming languages / projects available ++
> Was it about the money? No one asked for more; some said they'd do it for no money.
> It is okay to (succesfully) close a task if the student is unable to complete a task when it is not their fault (e.g. they hit a bug beyond a student's ability.). Ergo, trust your instincts.
> It is okay to stipulate for a reply or some small activity earlier than the main deadline (e.g. you must tell us your favourite colour within 24 hours of starting a task), e.g. step one is introduce yourself on this mailing list if you haven't yet
> Try and Check with lawyers if students can do tasks they've failed?
> Is the 10-week duration of being able to claim tasks ok? Some mentors suggested less time, LH wishes to keep as is.
> (Note: Several winners hadn't done significant coding before GHOP.)
> Start recruiting students now so that they were prepared .
> Start was busy, xmas was hard with mentors being absent, but then settled down.
> Elim: mentoring GHOP is very different to GSOC mentoring.
> Todd suggested to do GHOP web-app responsibilies. Pawel is going to be helping. Patches (and lots more code) welcome at http://code.google.com/p/soc/
Parent:
> Parents find it important that the contest is of a precise duration, scope,
> with set and understable rules, etc. Safely, not taken advantage of, be
> over-loaded with work, without the ability to negotiate timing or saying
> "no.", or be given responsibility, due to power dynamics. For them to work
> outside the contest (e.g. communication participation), is scary. This
> causes friction with the GHOP goals of getting students to become entrenched
> in the community.
> Suggest to write a welcome letter to parents "This is how we choose the
> orgs, the mentors, these are the risks around involvement, it is our not so
> secret hope students of today become mentors of tomorrow, and what that
> means is that students may be encouraged to be voluntary on-going work.
> Explain basics of open source communities/contributors. Parents won't know!"
Definitely. And send 'em to http://www.producingoss.com
Thanks to Siggy for the initial set of notes. Other should feel free
to comment/add items missed.
Cheers,
LH
Pat
Jul 17, 2008, 7:55:28 AM7/17/08
to GHOP Contest Administrative List
I've something I wanna say.
More contestant, More open source project, more mentors. Get the
contest to reach more people. I think less than 50 people from
thailand know about this, and less than 5 participated.
Actually I never want to contribute to open source community before. I
used Windows Vista, Microsoft Office. I didn't use open source except
firefox.
Today I still use Vista and MS Office. But I begin using Ubuntu, GIMP,
OpenOffice and interested in open source development. My friend who
joined this contest thinking about starting the opensource project but
he stop developing it since schoolwork is killing him. So the more
people join this contest, the better opensource community will be.
Any more ideas? some of you may not be comfortable to talk at 11 July.
So you might consider add it here.
Pat
> > Todd suggested to do GHOP web-app responsibilies. Pawel is going to be helping. Patches (and lots more code) welcome athttp://code.google.com/p/soc/
More contestant, More open source project, more mentors. Get the
contest to reach more people. I think less than 50 people from
thailand know about this, and less than 5 participated.
Actually I never want to contribute to open source community before. I
used Windows Vista, Microsoft Office. I didn't use open source except
firefox.
Today I still use Vista and MS Office. But I begin using Ubuntu, GIMP,
OpenOffice and interested in open source development. My friend who
joined this contest thinking about starting the opensource project but
he stop developing it since schoolwork is killing him. So the more
people join this contest, the better opensource community will be.
Any more ideas? some of you may not be comfortable to talk at 11 July.
So you might consider add it here.
Pat
>
> Parent:
>
> > Parents find it important that the contest is of a precise duration, scope,
> > with set and understable rules, etc. Safely, not taken advantage of, be
> > over-loaded with work, without the ability to negotiate timing or saying
> > "no.", or be given responsibility, due to power dynamics. For them to work
> > outside the contest (e.g. communication participation), is scary. This
> > causes friction with the GHOP goals of getting students to become entrenched
> > in the community.
> > Suggest to write a welcome letter to parents "This is how we choose the
> > orgs, the mentors, these are the risks around involvement, it is our not so
> > secret hope students of today become mentors of tomorrow, and what that
> > means is that students may be encouraged to be voluntary on-going work.
> > Explain basics of open source communities/contributors. Parents won't know!"
>
> Definitely. And send 'em tohttp://www.producingoss.com
> Parent:
>
> > Parents find it important that the contest is of a precise duration, scope,
> > with set and understable rules, etc. Safely, not taken advantage of, be
> > over-loaded with work, without the ability to negotiate timing or saying
> > "no.", or be given responsibility, due to power dynamics. For them to work
> > outside the contest (e.g. communication participation), is scary. This
> > causes friction with the GHOP goals of getting students to become entrenched
> > in the community.
> > Suggest to write a welcome letter to parents "This is how we choose the
> > orgs, the mentors, these are the risks around involvement, it is our not so
> > secret hope students of today become mentors of tomorrow, and what that
> > means is that students may be encouraged to be voluntary on-going work.
> > Explain basics of open source communities/contributors. Parents won't know!"
>
Reply all
Reply to author
Forward
0 new messages