Hey everyone, I'm Joshua, a software developer fr...
# gsoc
j
Hey everyone, I'm Joshua, a software developer from Nigeria, and I'm quite new to open source. I'm interested in participating in this year's GSoC, specifically with Clean and Actionable Reporting for Gradle Code Quality Plugins for Kotlin. I have some questions I was hoping to get some clarifications on: • There are quite a number of plugins to choose from, and I don’t think it would be possible to integrate all of them within the timeframe. Are there specific plugins I should prioritize for any reason due to their impact or importance, or do I have the freedom to choose whichever ones I feel most drawn to? • My approach is to work on the plugins one at a time to maintain full focus. Here’s the flow I have in mind for each: a. Analyse the current reporting strategy of the plugin. b. Discuss with maintainers to understand how best to map issues to the Problems API (Error, Warning, etc.) and the best way to approach the integration. c. Implement the integration with the Problems API. d. Write unit tests to ensure maximum test coverage. e. Thorough testing (CLI, HTML reports, IDE integration). Does this flow make sense, or should I consider any adjustments? Also, would it be okay to share my proposal for review? @Oleg Nenashev @Balint Hegyi
Also If there's anyone interested in this project Please let's connect
o
Thank you for the proposal, I will do my best to review it today
j
Thanks @Oleg Nenashev Looking forward to your comments
o
Are there specific plugins I should prioritize for any reason due to their impact or importance, or do I have the freedom to choose whichever ones I feel most drawn to?
There are no specific plugins. You are welcome to choose the plugins as you like, and justify this selection as you see it (e.g. community value, personal expertise or interests - all counts)
My approach is to work on the plugins one at a time to maintain full focus.
Sounds about right. I can imagine creating some shared API in a separate plugin / library, but otherwise it is a good approach to limit Work-in-progress scope
. Here’s the flow I have in mind for each:
LGTM in principle My common recommendation is doing isolated incremental changes. E.g. if you have a feature that can be delivered independently, I would recommend to do that and include tests and documentation in the same pull request. Such smaller isolated changes help to deliver fastr
Also, would it be okay to share my proposal for review?
Sure!
j
Thanks @Oleg Nenashev Will share my proposal draft once it is ready
🙌 1