Improvements for next time round [Was: Re: Application disappeared!?]

3 views
Skip to first unread message

Sam Lai

unread,
Apr 4, 2009, 12:56:11 AM4/4/09
to google-summer-...@googlegroups.com
2009/4/4 Sam Moffatt <pas...@gmail.com>:
> Perhaps that's an interesting reflection on society today that we
> don't expect deadlines to be firm, which hardly makes them a deadline.

I wonder what the etymology behind the word deadline is - if it has
something to do with death and people knew that, maybe they would
adhere to them more strictly :)

I think another contributing reason to this problem is that it isn't
immediately clear that once you submit your proposal, *you can still
edit it until the deadline*. As a result, everyone waited for their
proposals to be analysed, proof-read, critiqued off-site, before
submitting it.

It turns out that proposals also seem to be available for public
comments anyway (as I found out a few days ago via a notification), so
maybe using the GSoC site for critiquing should be encouraged? I saw
no mention of this, and indeed didn't even know it was possible until
I got a comment. (Or maybe they're only open to people in the org you
submitted to.)

It would also be nice if you could mark a proposal as 'incomplete' in
melange so when orgs read a half-written proposal during the
application period, they wouldn't immediately throw it in the trash.
(While I'm making suggestions, proposals should be versioned too,
especially given the bugs with strikethrough in the WYSIWYG editor.)

One of the overarching reasons for this, and also many of the RTFM
posts on the mailing list, is due to the fact that the GSoC website is
very documentation heavy. It is not very good at selling the GSoC
program and giving the average user the info they need quickly.

While I am not absolving those who choose not to read, the information
can be made available more clearly, particularly the important bits
like where to go to register and how, the participating orgs, and the
upcoming deadlines. Some graphics would be nice too. Having two
websites doesn't help either - code.google.com/soc and
socghop.appspot.com.

There will always be people who choose not to read anything, but it
would be nice for everyone else to get the important bits at a glance
without having to wade through page after page of text.

Just some thoughts for next time round,

Sam

Dirk Haun

unread,
Apr 4, 2009, 2:55:18 AM4/4/09
to Google Summer of Code Discuss
Sam Lai wrote:
>
> so
> maybe using the GSoC site for critiquing should be encouraged?

I would like to see additions to Melange that make it easier to review
proposals on-site. This year, we discussed a lot of draft proposals
outside of Melange, usually using Google Docs and public comments on
our mailing list. If these things were built into Melange, it could be
used as a central review and collaboration tool. It would also
eliminate the deadline problems, since students have at least an early
version of their proposal in the system already.

Actually, I suspect that the Melange team already has something like
this on their long-term roadmap. We have to take into account that
Melange is brand new and that the project is run by only a few people
in their spare time. As such, I think they did a great job. Thanks to
everyone involved!


> (While I'm making suggestions, proposals should be versioned too,
> especially given the bugs with strikethrough in the WYSIWYG editor.)

Don't forget to post them over in the melange-soc list and the issue
tracker.

bye, Dirk

Sam Moffatt

unread,
Apr 4, 2009, 8:14:00 AM4/4/09
to google-summer-...@googlegroups.com
On Sat, Apr 4, 2009 at 2:56 PM, Sam Lai <samue...@gmail.com> wrote:
>
> 2009/4/4 Sam Moffatt <pas...@gmail.com>:
>> Perhaps that's an interesting reflection on society today that we
>> don't expect deadlines to be firm, which hardly makes them a deadline.
>
> I wonder what the etymology behind the word deadline is - if it has
> something to do with death and people knew that, maybe they would
> adhere to them more strictly :)

With a quick look up of the online etymology dictionary seemed to
denote it had to do with death and a line in prison:
http://www.etymonline.com/index.php?term=deadline

deadline
"time limit," 1920, Amer.Eng. newspaper jargon. Perhaps influenced
by earlier use (1864) to mean the "do-not-cross" line in Civil War
prisons:
"Seventeen feet from the inner stockade was the 'dead-line,' over
which no man could pass and live." [Lossing, 1868]


So it appears to have been literally associated with death at some
point and if its from newspaper it probably has to deal with the point
at which new stories for the next run of the paper would have to be in
before they got dropped from being printed in the next edition. Print
has rather firm deadlines because of its nature, especially with a
daily paper. You need to get the article in, edited, typeset and the
lay out defined for the pages, the print set and then actually
printed. Makes you appreciate how much goes into the daily rag when
you think about it.


>
> I think another contributing reason to this problem is that it isn't
> immediately clear that once you submit your proposal, *you can still
> edit it until the deadline*. As a result, everyone waited for their
> proposals to be analysed, proof-read, critiqued off-site, before
> submitting it.

I agree this should probably be a bit better publicised as I believe
this has always been in part a feature. How far it extends is
something that could be better documented, e.g. does it work after the
deadline or is it only until the deadline. In the past I think
proposals have been editable after the deadline via comment.

>
> It turns out that proposals also seem to be available for public
> comments anyway (as I found out a few days ago via a notification), so
> maybe using the GSoC site for critiquing should be encouraged? I saw
> no mention of this, and indeed didn't even know it was possible until
> I got a comment. (Or maybe they're only open to people in the org you
> submitted to.)

Proposals were usually editable after a public comment even after the
deadline though you'd probably have to get this validated.

>
> It would also be nice if you could mark a proposal as 'incomplete' in
> melange so when orgs read a half-written proposal during the
> application period, they wouldn't immediately throw it in the trash.
> (While I'm making suggestions, proposals should be versioned too,
> especially given the bugs with strikethrough in the WYSIWYG editor.)

As with most Melange requests, you should probably add a feature
request on the tracker if you want to see it happen for the next year.

>
> One of the overarching reasons for this, and also many of the RTFM
> posts on the mailing list, is due to the fact that the GSoC website is
> very documentation heavy. It is not very good at selling the GSoC
> program and giving the average user the info they need quickly.

I think this is also good way of determining who is capable of basic
research. There is a lot of reading, but there is also a reasonable
amount of time to do this. A major aspect of open source I've seen is
the ability to process information and do something useful with it.

>
> While I am not absolving those who choose not to read, the information
> can be made available more clearly, particularly the important bits
> like where to go to register and how, the participating orgs, and the
> upcoming deadlines. Some graphics would be nice too. Having two
> websites doesn't help either - code.google.com/soc and
> socghop.appspot.com.

The FAQ was clearly linked from the soc home page and the time line is
linked multiple times on the FAQ page. There was also a specific email
sent for the timeline alone.

>
> There will always be people who choose not to read anything, but it
> would be nice for everyone else to get the important bits at a glance
> without having to wade through page after page of text.

Sounds almost like source code...


Sam Moffatt
http://pasamio.id.au

Sam Lai

unread,
Apr 4, 2009, 10:06:38 AM4/4/09
to google-summer-...@googlegroups.com
2009/4/4 Sam Moffatt <pas...@gmail.com>:

> I think this is also good way of determining who is capable of basic
> research. There is a lot of reading, but there is also a reasonable
> amount of time to do this. A major aspect of open source I've seen is
> the ability to process information and do something useful with it.

I guess it is a difference in intent - is Google trying to sell GSoC
to students, or is their primary goal to put it out there for people
find and apply once they have invested enough time and effort to make
sense of it all.

Many open-source projects have cottoned on to the fact that just
putting it out there with (often barebone) docs isn't enough to get
serious adoption - they need to sell the product in the same way
commercial companies do. Look at jquery.com, mozilla.com,
mono-project.com or rubyonrails.org - they do more than just offer
docs and a download link.

While it's not like GSoC is lacking in demand, I don't think they're
reaching their full potential. Making the information more easily
available benefits everyone - open-source shouldn't only be within the
reach of those who read every word on a website or spend the time to
follow link after link to find information (an exaggeration, but it
sometimes feels like that). Rather than completely blaming the user,
it's worth considering why and whether the situation can be improved.
Sometimes a fresh set of eyes is needed to point out things that may
seem obvious to long-time users.

After all, who reads instruction manuals before they start playing
with their brand new toy?

David Anderson

unread,
Apr 4, 2009, 10:19:43 AM4/4/09
to google-summer-...@googlegroups.com
My brand new toys don't pay me to play with them. If they did, maybe
I'd read the instructions first, to figure out how I should be playing
with them, rather than disrespect the investment, both financial and
temporal, that they're going to put in me.

I think that is the fundamental difference. Nobody asked to deliver a
fully functional cold fusion reactor here. We're talking about
spending an hour, tops, to read some basic documentation. People who
are unwilling to do this should not be handheld, unless it's to guide
them to the exit.

SoC and open source is about sharing, but it's a two way operation.
Google, orgs, mentors and volunteers already invest both millions of
real monies and a huge amount of man-hours into SoC. As a counterpart,
doesn't it seem the least of courtesies that students should spend a
man-hour or two understanding how to get with the program?

- Dave, mildly pissed off at the idea that we should go out of our way
to help lazy entitled people

>
> >
>

Jan J. Roman

unread,
Apr 4, 2009, 10:35:59 AM4/4/09
to google-summer-...@googlegroups.com
Hi
1. GSoC is a competition and one part of it is to send application on time.
2. It is not mandatory to take part in GSoC.
3. After reading "Advice for GSoC Students Page" It becomes obvious that you can modify sent application.
4. If someone does not respect organizers why they should respect him?
5.
statement: 1 second doesn't make a difference so:
19:00:00 UTC 3.04.2009 equals 19:00:01 UTC 3.04.2009
19:00:01 UTC 3.04.2009 equals 19:00:02 UTC 3.04.2009
19:00:03 UTC 3.04.2009 equals 19:00:04 UTC 3.04.2009
...
18:59:59 UTC 3.04.2010 equals 19:00:00 UTC 3.04.2010 equals 19:00:00 UTC 3.04.2009

Deduction: If 1 second doesn't make a difference there is no deadline.

People which are in developing usually know that sometimes single come makes very big difference ;-)

bye
Jan J. Roman

Sam Moffatt

unread,
Apr 4, 2009, 10:40:19 AM4/4/09
to google-summer-...@googlegroups.com
On Sun, Apr 5, 2009 at 12:06 AM, Sam Lai <samue...@gmail.com> wrote:
>
> 2009/4/4 Sam Moffatt <pas...@gmail.com>:
>> I think this is also good way of determining who is capable of basic
>> research. There is a lot of reading, but there is also a reasonable
>> amount of time to do this. A major aspect of open source I've seen is
>> the ability to process information and do something useful with it.
>
> I guess it is a difference in intent - is Google trying to sell GSoC
> to students, or is their primary goal to put it out there for people
> find and apply once they have invested enough time and effort to make
> sense of it all.

I think neither, its for people to use their brains during summer
instead of going into dummy mode and flipping burgers not bits. It
serves a number of purposes but if you keep with the flipping bits not
burgers theme using their brain and putting a bit of effort in doesn't
seem too far out there.

>
> Many open-source projects have cottoned on to the fact that just
> putting it out there with (often barebone) docs isn't enough to get
> serious adoption - they need to sell the product in the same way
> commercial companies do. Look at jquery.com, mozilla.com,
> mono-project.com or rubyonrails.org - they do more than just offer
> docs and a download link.

Sure, but I'd not call the SoC stuff barebone docs. Between the posted
issues, mailing lists and other items I fail to see how SoC isn't
offering more. I've been talking with different students about their
proposals, I even sent a reminder note on our project SoC specific
list around 24 hours prior to the deadline and still students managed
to miss the deadline and then posted back to that list if there was
any chance.

>
> While it's not like GSoC is lacking in demand, I don't think they're
> reaching their full potential. Making the information more easily
> available benefits everyone - open-source shouldn't only be within the
> reach of those who read every word on a website or spend the time to
> follow link after link to find information (an exaggeration, but it
> sometimes feels like that). Rather than completely blaming the user,
> it's worth considering why and whether the situation can be improved.
> Sometimes a fresh set of eyes is needed to point out things that may
> seem obvious to long-time users.

Many of the issues I saw didn't need you to read much, the good old
"find" option in most browsers would have found their issues either on
the timeline page or the FAQ page. Failing that, Google Group's search
functionality for the mailing list would have found most of the
questions and their answers as well. Most of the information of use
was on either the FAQ page or the timeline page. I feel 90% of
questions asked were answered from one of those two pages. More
information and support is available for those who wish to seek it.

>
> After all, who reads instruction manuals before they start playing
> with their brand new toy?

As with David, it depends on if I'm being paid to play with them or
not. If someone is offering me a USD$4500 grant to do some work I read
the fine print. Its like applying for anything, such as a scholarship,
grant funding or perhaps even a job application. Usually each of those
will have paperwork I'm expected to read and understand depending on
the task at hand. Scholarships usually have interesting requirements
(e.g. you are a citizen of the country, etc) and also have points at
which they can kick you out and request their money back. Grant
funding is in some places so complex that people are alone paid to
study the requirements and write documents (sad but true). Job
applications in my experience can have deadlines where if you don't
submit you application before this point you're not considered in
addition to having stuff like key selection criteria or similar that
require you to interpret and understand information and situations
specific to the position or organisation.

Sam Moffatt
http://pasamio.id.au

Sergiu Dumitriu

unread,
Apr 4, 2009, 4:16:46 PM4/4/09
to Google Summer of Code Discuss


On Apr 4, 6:56 am, Sam Lai <samuel....@gmail.com> wrote:
> I wonder what the etymology behind the word deadline is - if it has
> something to do with death and people knew that, maybe they would
> adhere to them more strictly :)

Deadline: a line drawn within or around a prison that a prisoner
passes at the risk of being shot. Merriam-Webster's Dictionary

Christopher Sean Morrison

unread,
Apr 4, 2009, 6:10:27 PM4/4/09
to Google Summer of Code Discuss
> > 2009/4/4 Sam Moffatt <pasa...@gmail.com>:
>
> > While it's not like GSoC is lacking in demand, I don't think they're
> > reaching their full potential. Making the information more easily
> > available benefits everyone - open-source shouldn't only be within the
> > reach of those who read every word on a website or spend the time to
> > follow link after link to find information (an exaggeration, but it
> > sometimes feels like that). Rather than completely blaming the user,
> > it's worth considering why and whether the situation can be improved.
> > Sometimes a fresh set of eyes is needed to point out things that may
> > seem obvious to long-time users.

I do think that there are many ways the application process can be
improved and generally agree that many here (often the vocal
responders) are often very quick to judge and blame those coming
forward without doing an introspection on how the process itself could
be improved. There are human nature and personality differences at
play on most of these issues. With deadlines and schedules in
particular, there are potentially even major cultural differences.

As many on this list I'm sure are aware, not every culture has the
same view on a deadline being firm by default. There are indeed major
discrepancies on how thick the line is and at what point you've
actually crossed it. Having grown up abroad, even business deadlines
were entirely flexible guidelines that were fluid and negotiated. It
permeated *all* of society for one country where absolutely nothing
ran on time or with any sort of 'firmness', and that was the accepted
norm.

That notion is frankly frighteningly foreign to many here, especially
obsessive/compulsive thinking personalities that need their world in
tight order with firm deadlines and their socks neatly organized by
color. :-) Particularly to the "zero-tolerance" extent found within
this context, I'm not at all surprised that even non-procrastinators
would end up not getting a submission in on time for a variety of
conceivable reasons.

One good less to take from this (extended) discussion, is to perhaps
annotate the FAQ to explicitly state that all deadlines on the
timeline are firm and with no exceptions. Make it very clear whenever
a date is declared/published. Another potential improvement for the
future would be to modify the web application to make the firm
deadline apparent during editing. We could inform the user that the
(firm) deadline is approaching if they're in the middle of editing
their application. Relying on an interpretation of the word
'deadline' or 'timeline' or 'due date' is insufficient. The fact
alone that many have posted on this topic make it FAQ-worthy.

On Apr 4, 10:19 am, David Anderson <david.jc.ander...@gmail.com>
wrote:
>
> - Dave, mildly pissed off at the idea that we should go out of our way
> to help lazy entitled people

For many, I'm sure it has absolutely nothing whatsoever to do with
being lazy. It's egregiously presumptuous to assume they're just lazy
procrastinators that missed the deadline and that this is a matter
about deserving special consideration. They're all students and I'd
hope they would all put health, family, and their education above
involvement with GSoC or Open Source. Any one of those matters might
cause the student to put together an application at the last minute,
or just past the last minute, hoping to participate. Doesn't mean
they are eligible or entitled to participate or that they deserve
consideration, but we should still be respectful.

Cheers!
Sean
BZFlag & BRL-CAD

David Anderson

unread,
Apr 4, 2009, 6:53:58 PM4/4/09
to google-summer-...@googlegroups.com
On Sun, Apr 5, 2009 at 12:10 AM, Christopher Sean Morrison
<brl...@gmail.com> wrote:
> As many on this list I'm sure are aware, not every culture has the
> same view on a deadline being firm by default.  There are indeed major
> discrepancies on how thick the line is and at what point you've
> actually crossed it.  Having grown up abroad, even business deadlines
> were entirely flexible guidelines that were fluid and negotiated.  It
> permeated *all* of society for one country where absolutely nothing
> ran on time or with any sort of 'firmness', and that was the accepted
> norm.

What is "abroad" ? I've studied and worked in France, the UK, the US,
and now Switzerland. In none of those did I find it acceptable to just
turn up after a deadline and presume that my work/application/results
would be accepted.

I can't say that I've never missed a deadline, but I don't then feel
offended if whoever set the deadline doesn't flex. I *know* I messed
up, and that they are well within their rights to tell me to sod off.
It's just lack of respect to assume that people giving you deadlines
are amenable to working on *your* schedule, despite dictating the
timeline.

Maybe that's my "cultural background" coming out, and I'm sorry that I
can't take people thinking that deadlines are more like guidelines in
my stride, but that's the way it is. I clearly haven't spent enough
time in this place you did where deadlines have error bars.

> That notion is frankly frighteningly foreign to many here, especially
> obsessive/compulsive thinking personalities that need their world in
> tight order with firm deadlines and their socks neatly organized by
> color. :-)  Particularly to the "zero-tolerance" extent found within
> this context, I'm not at all surprised that even non-procrastinators
> would end up not getting a submission in on time for a variety of
> conceivable reasons.

And I'm not saying that very late submissions are all the result of
people slacking off. What I am saying is that I get mildly annoyed at
the entitlement displayed by *some* (note the emphasis) of them. If I
were to submit very close to a deadline and miss it, I'd be
justifiably pissed off, but at myself, for leaving it so late. Being
pissed off at the deadline setters because they didn't bend over
backwards to accept *your* procrastination is just entitlement.

Just a note that you may classify me among the obsessively ordered
people for what I'm saying here. You would be wrong. I have very poor
organizational skills, procrastinate like there's no tomorrow, and
occasionally get into trouble for it. However, despite this, I don't
somehow establish the belief that it would be anyone's problem or
fault but mine if I were to miss out on something due to this.

> For many, I'm sure it has absolutely nothing whatsoever to do with
> being lazy.  It's egregiously presumptuous to assume they're just lazy
> procrastinators that missed the deadline and that this is a matter
> about deserving special consideration.  They're all students and I'd
> hope they would all put health, family, and their education above
> involvement with GSoC or Open Source.  Any one of those matters might
> cause the student to put together an application at the last minute,
> or just past the last minute, hoping to participate.  Doesn't mean
> they are eligible or entitled to participate or that they deserve
> consideration, but we should still be respectful.

And yet, I'm almost 100% certain that if we were to look at
applications that came in in a 5 minute band around the deadline (both
early and late), we would find that the reason for late submission in
all cases is either procrastination, or finding out about the program
late and rushing to apply. And if we were to map that onto the people
who were almost indignant that the deadline turned out to not be a
guideline, but, like, a deadline, I'm equally sure that it would map
onto the first group. The heart-warming story about their sick
sister's dog who ate their application is nice, but I seriously doubt
that it accounts for even 1% of those submissions.

You are incorrectly assuming that I am pissed off at people who submit
late. I am not. I am one of them.

I am pissed off at people who submit too late, and are then pissed off
at *me* (or the program, or anyone other than themselves) because
things didn't happen exactly the way *they* expected. And I object to
focusing changes to the process/software to support these people,
because it gives them more reason to whine in the future, rather than
refocus their frustrations at the right target.

Just my opinion. It may be tarnished by the number of private irc
conversations I've had on this and similar topics in this and past
years around deadlines. Mileage may vary, don't do this at home, store
in a dry dark place, do not expose to naked flame, do not open.

- Dave

Sam Lai

unread,
Apr 4, 2009, 8:57:33 PM4/4/09
to google-summer-...@googlegroups.com
Personally, it isn't about respect or money (whichever way it goes).
If I can make someone else's life easier and improve their experience
at a minimal expense to myself, I'd try to do it (not immediately of
course, and it'll be scheduled against my list of priorities). I'm
also a bit of a UX nut so I'm probably just blowing a tiny issue into
a big one.

2009/4/5 David Anderson <david.jc...@gmail.com>:


> And I object to
> focusing changes to the process/software to support these people,
> because it gives them more reason to whine in the future, rather than
> refocus their frustrations at the right target.
>
> Just my opinion. It may be tarnished by the number of private irc
> conversations I've had on this and similar topics in this and past
> years around deadlines. Mileage may vary, don't do this at home, store
> in a dry dark place, do not expose to naked flame, do not open.

Maybe some changes could reduce the number of such conversations, or
maybe I have too much faith in humankind.

Let's agree to disagree and get back to the topic in the subject - how
can the application stage of GSoC be made better, without extending or
otherwise manipulating the deadline. At least you're open to
suggestions for making the people who submitted their proposals on
time happier throughout the process?

P.S. I didn't start this thread as a subtle way of complaining for my
personal benefit - I submitted my proposal with time to spare, and
even had a chance to revise it after receiving public reviews.

Galloth

unread,
Apr 5, 2009, 7:30:03 AM4/5/09
to google-summer-...@googlegroups.com
I think, that the great improvement for the apps would be indicating
of the review. That if someone put the review of student's proposal,
or something changes. Student will be notified on the email, or at
least it will show on the list of proposal. I believe, this would be a
nice feature.
Jan

2009/4/5 Sam Lai <samue...@gmail.com>:
--
Jan Kastil
gal...@jabbim.cz

slash

unread,
Apr 6, 2009, 5:48:58 AM4/6/09
to Google Summer of Code Discuss
> I think, that the great improvement for the apps would be indicating
> of the review. That if someone put the review of student's proposal,
> or something changes. Student will be notified on the email, or at
> least it will show on the list of proposal. I believe, this would be a
> nice feature.
> Jan

I guess that is already implemented... you can subscribe to updates on
your
proposal and will be informed per e-mail when there is a review
Reply all
Reply to author
Forward
0 new messages