summer-of-code
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: slots request


From: Bastien
Subject: Re: slots request
Date: Mon, 09 Apr 2012 14:33:22 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux)

Hi Nikos,

Nikos Mavrogiannopoulos <address@hidden> writes:

> On Mon, Apr 9, 2012 at 10:28 AM, Bastien <address@hidden> wrote:
>
>>> Thus we can safely say the amazing should be at least 10, and
>>> recommended be 14?
>> This suggests the implicit rule that, if GNU gets 10 slots for
>> amazing projects, we will have to give one slot per project.
>
> Why is this a problem? 

It is a problem if we consider the Org-mode related projects 
being parts of the same "Org" virtual project.

It is not a problem if all projects (whether they are related
to the same software or not) are treated equally.

> Couldn't each project have one amazing
> proposal? 

If that's so, let's find out by defining "amazing".

>> I suggest mentors review all projects (as we are supposed to do,
>> right?), rate them 5 if they find them "amazing", and below five
>> otherwise.
>
> I disagree with that. 

Another option is to let GNU admins decide what is amazing what is not.
Without asking the mentors.  In that case, rating a proposal should be
independant of other proposals.

> 2. wget proposal, vs octave proposal vs lillypond proposal vs bison
> proposal. How would you compare them? There are no objective criteria
> and there can be many subjective. 

We can set some more-objective-than-subjective criterium. 

I suggest this ones:

- size of the community
- number of mentors
- past activity of the student in the project
- favoring new students over returning students

> I agree on the idea, but not on the implementation. I believe the ones
> who agreed to mentor, or other mentors who are somehow related to the
> project should vote. The people of a project should be allowed/trusted
> to set a proposal on their project as "amazing", otherwise big
> projects with many mentors could set aside the smaller ones (and might
> not even be intentional).

If every mentor only vote for his project, he will have a tendancy to
rate his proposals as "amazing".

As suggested above, maybe the GNU admins should be the only one to
decide on that.

> Otherwise we must set some concrete objective goals for mentors to
> vote, which is not feasible given the deadline (and might still not be
> fair because the number of mentors varies from project to project).

I agree the deadline is too short and will certainly lead to many
frustrations for mentors that cannot spent easter holidays on this.
So again, in this pressing situation, I guess the best thing to do
is to let admins decide.

But hopefully we can discuss this online (IRC) at 6:30pm!

Best,

-- 
 Bastien



reply via email to

[Prev in Thread] Current Thread [Next in Thread]