Application Period Closing Soon, Next Steps

[Federico Capoano]

Hi everyone,

thanks for your participation and patience!
We've been avalanched with pull requests and applications to review and it's hard to keep up with everyone.

Github Discussions

I took some time to reply to questions in the Github Discussion Forum.
If you have doubts, I encourage you to ask more questions there.

Submit Your Application ASAP

Edit Before Deadline: You can edit your proposal as many times as you wish before the application deadline.
Submit Early for Feedback: It is strongly recommended to submit a draft early. Mentors can view the submitted proposal, provide feedback, and allow you to make it stronger before the final deadline.
Replacement Proposals: If you need to make major changes, you can submit a new proposal, which will replace the previous one up until the deadline.
After the Deadline: Once the application deadline passes, you generally cannot make changes to the proposal, as it is locked for review by organizations.

Support the Community: GitHub Stars & Participation

I have insisted a lot with this in the dev chat.

Applying to GSoC without interacting with the rest of the community and supporting the project shows that the applicant hasn't understood the spirit of this program and the spirit of open source communities.

The spirit of Open Source is to share our work and help one another whenever possible.

OpenWISP needs active community members, people that will help us propel the project forward and mentor new contributors in the future.

Starring our pinned repositories on Github is a free way to support OpenWISP. If you haven't done this, it suggests you are either not reading these communications or actively ignoring them, which doesn't look good.

Interacting with other participants and offering help whenever possible is also encouraged because mentors and maintainers cannot always respond to every chat message, issue comment, GitHub discussion, email, or pull request. We have almost 300 open pull requests, reviewing and testing each one takes hours.

Having fellow community members who can lend a helping hand can really make a difference.

I hope this helps, let's follow up via the dev chat.

Best regards

Federico Capoano

OpenWISP OÜ

Kotkapoja tn 2a-10, 10615, Harju maakond, Tallinn, Estonia

VAT: EE101989729

+372 59361689

openwisp.io

[Federico Capoano (nemesisdesign)]

I am looking at some applications.

I can't respond to everyone but I am extracting some generic recurring comments so you can get the gist and apply this feedback to your proposals.

I'll be sending more as I find them.

Bold claims have to be triple checked

A good way to verify a bold claim is to ask a question in the github discussions.

For example, here's a bold claim:

AbstractBatchUpgradeOperation gets a persistent boolean field. Issue #379 mentions placing it on UpgradeOperation, but I'm proposing it on BatchUpgradeOperation instead — persistence is a policy decision made once at batch creation time, not per-device.

This contradicts the GSoC idea text, which can be ok, however, it doesn't keep into account the fact that upgrades are not always performed in batch, often upgrades are performed on 1 device only, what if the user wants to initialize a persistent upgrade on only one device?

Hence, this is a bold claim, but doesn't offer convincing evidence that it's going to work in all the cases supported by the current feature set.

Therefore, it would have been better if this specific detail was asked in the Github Discussion thread.

LLM Abuse is a Turnoff

Most of the text I am seeing looks AI generated, the — and the tone scream LLM. I have no way to know if this blunder was made by the human or by the LLM, both possibilities are perfectly realistic, however, having text which screams LLM like this is a turn off for me

if I have to work with an AI I may as well just work with Claude and Codex directly, without having to deal with a human proxy.

I understand that many of us don't write perfect English and it's fine for us if you use LLM tools to improve your proposals, but there's a fine line between using AI to improve the text you write and use the AI to do the thinking and all the hard work for you.

You may think we don't notice, but we do notice. The fight against regurgitated AI slop is real.  

Linking Issues Number without Providing Titles

The application is not github, if you type an issue number, the title doesn't magically appear.

Issue numbers make our life harder, please use the full github issue title and issue ID in the anchor text, eg:

[feature] Add support for captive-portal API #947

Conflicting Obligations

State your conflicting obligations. Let us know if you will be busy in specific periods.

Do not lie to us, as it can backfire later and it's a valid reason to fail a project: if an accepted contributor disappears for weeks and by the first deadline hasn't produced tangible results, and has have lied to us about their conflicting obligations, it's a sure fail, the GSoC staff themselves are the first ones to recommend failing in these cases.

Whatsapp, Signal, Telegram or other IM based on Phone Number

We need  to have a direct contact  with you in case you disappear. 
Whatsapp is preferred as it's used by most people.

This is used only in case of urgent matters.

Please add this to your application.

[Federico Capoano (nemesisdesign)]

Linking Issues Number without Providing Titles

The application is not github, if you type an issue number, the title doesn't magically appear.

Issue numbers make our life harder, please use the full github issue title and issue ID in the anchor text, eg:

[feature] Add support for captive-portal API #947

This was sent in my previos post but I didn't format it properly so I wanted to be sure you don't miss it.

Prototypes Best Practices

• If the gsoc idea aims at existing repositories, I'd avoid creating a completely new repository.
  Forking/cloning the original repo would make it easier for us to review as we're already familiar with our codebase.
  
  
• Focus on having a clear README and an updated video recording which works as a demo.
  
  
• In your application, I suggest adding screenshots of the prototype, it's fine to cite parts of the code of the prototype as well.

Code Samples

Prefer prose explanation and plain text code samples when needed, feel free to color format the code.

If you have images, make sure the code is readable.

But TEXT is king.

Diagrams

Diagrams that summarize your proposed solution are a good idea.

ChatGPT and Gemini are pretty good at generating these, but make sure to triple check the text you feed into it, avoid publishing slop for the sake of having a diagram. 

Addressing Open Questions

Most GSoC ideas have some open ended questions or gaps in which we expect contributors to do their own research and propose the best options according to the avaialble technical literature, make sure to explicitly address this.

The best thing is to have a summary section dedicated to this, it's ok if this info is redundant in other sections and would be great to make the redundancy explicit, eg: "as explained in section X, etc.".