Hi everyone! I’m an associate Android engineer and...

# gsoc

[Vanessa Johnson]

Hi everyone! I’m an associate Android engineer and have experience in both kotlin and Gradle. I’m interested in on working on Clean and actionable reporting for Gradle code quality plugins for Kotlin. I’ve recently been learning about making custom plugins and am excited to dig into this opportunity. I was thinking about focusing on detekt and Ktlint so would that be considered a sufficient project for the hour range? Or should 1 be the focus since this would be the first time I’m working with Problems API? Also are there specific features or integrations within these plugins that are already in mind to prioritize? Should I be focusing on these GitHub repos as well?: https://github.com/detekt/detekt and https://github.com/pinterest/ktlint

[Vanessa Johnson]

Cc: @Oleg Nenashev @Balint Hegyi @Reinhold Degenfellner

[Oleg Nenashev]

Hi! Thanks for the interest! I think ktlint and detekt might be sufficient. It depends on the integration depth, but this is something that can be approached iteratively.

Also are there specific features or integrations within these plugins that are already in mind to prioritize?

Ideally, we could start from streaming the discovered issues to problems API, firstly for projects being scanned and, later, for Gradle scripts themselves. It is trivial to do that after the completion of the scan by processing the report, but runtime reporting might be also interesting for bigger projects and IDE integrations

[Oleg Nenashev]

Should I be focusing on these GitHub repos as well?

These repos are for the projects themselves. There are Gradle plugin repos:
• https://github.com/JLLeitschuh/ktlint-gradle
• https://github.com/detekt/detekt/tree/main/detekt-gradle-plugin - inside the repo you referenced
I can imagine some patches to the main tool libraries for better error propagation

[Rishav Kumar]

Would runtime reporting be expected as part of the GSoC project, or is it more of a future improvement?

[Oleg Nenashev]

Not expected IMHO.

[Oleg Nenashev]

Someone can propose it in the project proposal if they feel it is feasible, but it really depends on the project size

[Vanessa Johnson]

When submitting a proposal, if the project is sized at small, if the aim of the project is achieved, can I be resized to be medium or would it still be considered small and with the time left it would be what additions could be added?

[Oleg Nenashev]

GSoC normally does not resize projects. That said, any project can continue upon completion, if both contributor and the mentors agree

[Vanessa Johnson]

Thanks!

[Vanessa Johnson]

Hi, I submitted my proposal and any early possible feedback would be appreciated! Thanks in advance.

[Oleg Nenashev]

Normally I recommend sending a draft in a commentable Google Doc as the first step

[Vanessa Johnson]

Should I re-upload a commendable Google Doc instead?

[Oleg Nenashev]

Whatever works best for you

[Oleg Nenashev]

Normally potential contributors send it separately from the application forms, though it is indeed gradually changes. More and more people use the submission form right away

[Vanessa Johnson]

Well, it is fine to keep it as is? Can I receive feedback without re-uploading?

[Oleg Nenashev]

At the moment, I do not have access to the 2025 proposals on the org page

[Vanessa Johnson]

Ahh I see. So should I send it to you over DM?

[Oleg Nenashev]

I am looking into fixing the access. My preference is that the proposals are shared publicly in the respective Slack channels. #*problems-api* on the Gradle Communuity Slack in this case

[Vanessa Johnson]

Ok thanks, will do that