[gnu-soc] GSoC 2024 Ranking

[Simon Sobisch]

On Sat, Apr 20, 2024 at 11:56 PM Jose E. Marchesi <jemarch@gnu.org> wrote:
> Hello participating projects.
>
> At this point you should have received good (or bad) proposals for your
> ideas at the GSOC site [1].
>
> Now it is the time for participating organizations to rank the proposals
> they would like to accept.  In order to do so, we need to know the
> proposals that you (the maintainers of each participating project) would
> like to get accepted.
>
> We would like to have a list of ranked proposals by the end of day of
> Monday 22 April, so please send to this mailing list the list of
> proposals you would like to accept before then.
>
> For each proposal, please make sure:
>
> - That it has at least one mentor assigned to it.
> - That you identify it fully and clearly by the full URL in the GSOC
>    site.
>
> Tuesday 23 morning we will send a list with a summary of the ranked
> proposals to this list.  Then it will be up to Google to decide how many
> slots will be given to us this year.
>
> Thanks!
>
> [1] https://summerofcode.withgoogle.com

Thank you for your work on this. Here's the ranking from the GnuCOBOL 
project (originally with 5 proposals, but 2 duplicates) in order of the 
student's submission:

1 Implement XML PARSE in GnuCOBOL using libxml2
by Ammar Almorsi

https://summerofcode.withgoogle.com/organizations/gnu-project/programs/2024/proposals/details/6crlKvvA

Project size:    small

Primary mentor:  Simon Sobisch
Backup mentor:   James K. Lowden


2 Add source encoding and literal conversion to the GnuCOBOL compiler
by Ahmed Maher

https://summerofcode.withgoogle.com/organizations/gnu-project/programs/2024/proposals/details/qXa7h6J4

Project size:    small

Primary mentor:  James K. Lowden
Backup mentor:   Simon Sobisch


3 Java interoperability from/to COBOL modules
by Vedant Tewari

https://summerofcode.withgoogle.com/organizations/gnu-project/programs/2024/proposals/details/gdLOvNQH

Project size:    large

Primary mentor:  N. Berthier
Backup mentor:   Simon Sobisch


> On Sun, 21 Apr 2024 10:03:43 AM Christian Grothoff <grothoff@gmail.com> wrote:
>
> Hi Jose,
>
> For GNU Taler & GNU Anastasis, we'd like to mentor the mutual integration
> proposal from Amr Abdelhady
> (
> https://summerofcode.withgoogle.com/organizations/gnu-project/programs/2024/proposals/details/Ac9SnLkn
> );

Congrats for a good proposal and mentors.

> Looks like we have 3 mentored proposals on GnuCOBOL, which I cannot rank.

I couldn't rank other project's proposals either. At least that would be 
extremely hard. Therefore Jose asked the maintainers of each project to 
rank their own :-)

I assume that the maintainers/mentors all follow the GSOC guidelines, 
especially:

* Never accept a proposal unless a mentor has had at least one 
conversation with the GSoC contributor. Many people can write great 
proposals, especially with the help of AI, that doesn't mean they have 
the skills or drive to be a great GSoC contributor for your community.
Don’t even think about selecting a GSoC contributor with whom you’ve had 
no contact. You should establish an active back-and-forth prior to 
making a decision. If you or your GSoC contributor have failed to make 
this happen, do not proceed.

* Do not accept proposals that are just "okay". You should only be 
accepting very good or excellent proposals. A mediocre proposal rarely 
results in a successful GSoC project at the end of the summer.


> We also have 3 mentored proposals
> on GNUnet, which Martin will send a ranking for (I hope).  I would ask for
> the Taler/Anastasis proposal to be ranked somewhere on place 2-4 overall
> depending on how strongly GnuCOBOL feels about their students: this will be
> timely work for us as we need to prepare similar integrations with banks,
> but also we'll live if it doesn't happen.

I'm grateful that the final ranking is up to the org admins, it is hard 
to do (but at least Google gives hints about how to do that in order to 
get the maximum amount of possible slots and to have a successful GSOC 
for both the students and the projects they work with).

> My general feeling:
> - only 1 student: to GNUnet (gtk4?) or GNU Cobol
> - only 2 students: to GNUnet (gtk4?) and GNU Cobol
> - 3 students: one for each?
> - 4 students: one for each, one extra for cobol or GNUnet
> - 5 students: one for each, one extra for cobol and GNUnet (unlikely)
> - 6 students: luxury problem, maybe drop GNUnet TNG? (unlikely)
> - 7 students: luxury problem, fund all that are mentored (unlikely)
>
> My 2 cents
>
> Christian

Just to highlight that, it is GnuCOBOL :-)

This is not how it works. The org ranks non-conflicting proposals (= one 
per topic and student, not conflicting on the mentors) and google 
allocates slots. The highest ranked proposals automatically become 
accepted projects (which is also the reason to not use "duplicate" 
mentors in that list). There is no reason for not ranking good 
non-conflicting projects.

If you want to know more about that: have a look at 
https://developers.google.com/open-source/gsoc/help/slot-allocation
and
https://google.github.io/gsocguides/mentor/selecting-a-student

Also from the later:

> If your org has 10 great contributors and you rank the 7 large 
projects 1-7, then the 3 medium projects as 8-10 be prepared to get less 
slots than if you had mixed up medium and large in the top 7. If you 
have some small (90 hour) projects mixed in you’ll also me be likely to 
receive more slots.

I therefore see that for example the large proposal for GnuCOBOL (Java 
interoperability, which is of course important, otherwise we'd not spend 
that huge dual-mentor time on it) will have it "hard" to get a high 
rank, while I _guess_ the only two small sized projects under the GNU 
umbrella org will have a relative easy standing :-)

Kind regards,
Simon