Update gsoc-2025.md

Updated style and grammar

Author: Belosnegova

docs/topics/gsoc-2025.md

@@ -48,22 +48,22 @@ Thank you! We look forward to reading your applications!
 ### Build Server Protocol: add Kotlin support [Hard, 350 hrs]
 
 The Kotlin team wants to expand official Kotlin support not only for Gradle and Maven build systems,
-but any other build system as well and support them natively in JetBrains IDE with minimal effort.
-On the other hand, we also want to provide basic Kotlin support in non-JetBrains IDE –
-one part of such support is to be able to get Kotlin specific information from any build system supporting Kotlin.
+but any other build system as well and support them natively in JetBrains IDEs with minimal effort.
+On the other hand, we also want to provide basic Kotlin support in non-JetBrains IDEs –
+one part of such support is being able to get Kotlin-specific information from any build system supporting Kotlin.
 
 The solution to these requirements could be a [Build Server Protocol](https://build-server-protocol.github.io) (BSP)
-that provides an abstraction layer between build system and IDE.
+which provides an abstraction layer between the build system and IDE.
 
-The goal of this project would be implementing a prototype which uses the BSP protocol to get all required for 
-IDEA information from a user project to be able to work with Kotlin code in the project. 
-To limit the scope of this prototype – user project will be using Gradle to build itself.
+The goal of this project would be implementing a prototype which uses the BSP protocol to get all the required 
+information for IntelliJ IDEA from a user project so that it will be possible to work with Kotlin code in the project. 
+To limit the scope of this prototype, the user project will use Gradle to build itself automatically.
 
-**Skills required (preferred)**
+**Preferred skills**
 
-* Kotlin
-* Understanding how to write Gradle plugins
-* _Bonus_: understanding how to write IntelliJ IDEA plugins
+* Knowledge of Kotlin
+* Understanding of how to write Gradle plugins
+* _Bonus_: understanding of how to write plugins for IntelliJ IDEA
 
 **Possible mentors**
 
@@ -76,36 +76,36 @@ Yahor Berdnikau, Bálint Hegyi, and Reinhold Degenfellner
 
 * **Task #2**.
   Practice assignment:
-  create a Gradle plugin which exposes a specific task. This task should on the presence of 
-  Kotlin Gradle Plugin get all the Kotlin sources structure and output to the file. Having tests is a bonus
+  Create a Gradle plugin which exposes a specific task. This task should, in the presence of the Kotlin Gradle Plugin, retrieve all the Kotlin sources’ structures and output them.
+  Including tests would be a bonus.
 
 ### Support Android and iOS targets in Kotlin Multiplatform for an existing Google service [Medium, 175 hrs]
 
 This project aims to create an open-source Kotlin Multiplatform (KMP) library that supports an existing Google service 
-on at least Android and iOS. This project will showcase best practices in creating KMP libraries for existing services,
-with a focus on appropriate production implementation (for example, proper API key management, allowing user-managed API keys,
-client throttling).
+on at least Android and iOS. It will showcase best practices in creating KMP libraries for existing services,
+with a focus on appropriate production implementation (for example, proper API key management, user-managed API keys support, 
+and client throttling).
 
 **Expected outcomes**
 
 * A new Kotlin Multiplatform library with support for an existing Google service
 * Sample code and documentation
 
-**Skills required (preferred)**
+**Preferred skills**
 
 * Kotlin
 * Kotlin Multiplatform
 * Mobile development (Android and iOS)
 
-**Possible mentor**
+**Possible mentors**
 
 Matt Dyor, and the Google team
 
 ### Add Kotlin Multiplatform support in Bazel [Hard, 350 hrs]
 
 Bazel's support for Kotlin is evolving, but proper Kotlin Multiplatform (KMP) integration remains a challenge.
 This project aims to improve [Bazel's KMP support](https://github.com/bazelbuild/rules_kotlin/issues/567)
-by addressing dependency resolution issues, enhancing `rules_kotlin` and `rules_jvm_external` compatibility,
+by addressing dependency resolution issues, enhancing `rules_kotlin` and `rules_jvm_external` compatibility, 
 and enabling cross-platform builds.
 
 Key improvements will focus on handling platform-specific dependencies (expect/actual mechanisms), 
@@ -117,23 +117,22 @@ improving Gradle metadata support, and ensuring a smoother developer experience
 * Improved integration with `rules_kotlin` and `rules_jvm_external`
 * A working KMP build setup in Bazel for seamless multiplatform development
 
-**Skills required (preferred)**
+**Preferred skills**
 
 * Kotlin Multiplatform and Gradle
 * Bazel build system
 * Dependency resolution strategies
 
-**Possible mentor**
+**Possible mentors**
 
 Shauvik Roy Choudhary, and the Uber team
 
 ### Kotlin Language Server (LSP) [Hard, 350 hrs]
 
 The Language Server Protocol (LSP) is a widely adopted standard that enables code intelligence features such as autocompletion,
-go-to definition, and refactoring across different editors and IDEs. There is currently no official Kotlin LSP server.
-Uber has developed an internal Kotlin LSP, but a publicly maintained, community-driven implementation 
-can support broader use cases, including code migration, AI-powered code assistance, 
-and seamless integration into various development environments.
+go-to definition, and refactoring across different editors and IDEs. While there is currently no official Kotlin LSP server, 
+Uber has developed an internal Kotlin LSP. A publicly maintained, community-driven implementation can support broader use cases,
+including code migration, AI-powered code assistance, and seamless integration into various development environments.
 
 This project aims to develop a Kotlin LSP implementation, ensuring compatibility with key LSP features
 and broadening Kotlin's accessibility across development environments.
@@ -142,13 +141,13 @@ and broadening Kotlin's accessibility across development environments.
 
 Develop a Kotlin LSP implementation
 
-**Skills required (preferred)**
+**Preferred skills**
 
 * Kotlin
 * Language Server Protocol (LSP)
 * Plugin or extension development for IDEs
 
-**Possible mentor**
+**Possible mentors**
 
 Shauvik Roy Choudhary, and the Uber team
 
@@ -161,11 +160,10 @@ to a new Maven Central Instance, which has a very different API implementation a
 Developing a Gradle plugin that is compatible with the new Maven Central publication APIs would help
 the library authors building with Gradle to have a smooth experience with the new process.
 
-Currently, there are multiple implementations of Maven Central publishing plugins in Gradle,
-for example, the [Maven Publish Plugin](https://docs.gradle.org/current/userguide/publishing_maven.html)
+Currently, there are multiple implementations of Maven Central publishing plugins in Gradle, for example, the [Maven Publish Plugin](https://docs.gradle.org/current/userguide/publishing_maven.html)
 or the [New Maven Central Publishing](https://github.com/GradleUp/nmcp), which already tries to adopt the new APIs.
-A potential contributor, during the application or the community bonding phase, would need to review the implementations
-and suggest a plugin to be updated, or decide to build a new plugin or fork.
+During the application or the community bonding phase, a potential contributor would need to review the implementations
+and either suggest an existing plugin to update or decide to build a new plugin or fork.
 The deliverables would include either a new version of an existing plugin for Maven Central publishing or a new plugin for Gradle.
 We anticipate the implementation to be in Kotlin or Java and to have proper test coverage and documentation.
 Additional deliverables may include Kotlin DSL extensions to simplify the use of the plugins and
@@ -175,13 +173,13 @@ Additional deliverables may include Kotlin DSL extensions to simplify the use of
 
 * Updated Maven Central publishing plugin or a new plugin
 
-**Skills required (preferred)**
+**Preferred skills**
 
 * Kotlin
 * Gradle
 * Maven Repositories
 
-**Possible mentor**
+**Possible mentors**
 
 Oleg Nenashev, and the Gradle team
 
@@ -191,12 +189,12 @@ Gradle is working on [Isolated Projects](https://docs.gradle.org/current/usergui
 that greatly extends the configuration cache to further improve performance, particularly the performance of
 Android Studio and IntelliJ IDEA sync. From the developer experience standpoint, it is one of the most expected features in Gradle.
 
-One of the problems for Isolated projects is the lock contention in the Gradle core and plugins sometimes getting in the way of parallel execution.
+One of the problems for Isolated projects is the lock contention in the Gradle core, with plugins sometimes getting in the way of parallel execution.
 We would like to reduce the lock contention, especially in the key Gradle Build Tool plugins for Java, Kotlin, Android,
-and Kotlin Multiplatform ecosystems. Contributors are welcome to choose the deliverables, based on their interest and the desired project size.
+and Kotlin Multiplatform ecosystems. Contributors are welcome to choose the deliverables based on their interests and the desired project size.
 
-Potential deliverables include but not limited to:
-* Embed the [Configuration Cache Report](https://github.com/gradle/configuration-cache-report) tool into the Gradle Profiler (or implement a GitHub Action for it)
+Potential deliverables include but are not limited to:
+* Embed the [Configuration Cache Report](https://github.com/gradle/configuration-cache-report) tool into the Gradle Profiler (or "implement a GitHub Action for it")
 * Profile Gradle and a few popular Gradle plugins in various projects, with automation of the test suite on GHA
 * Determine potential areas and plugins where lock contention can be reduced, with or without Configuration Cache
 * While around, contribute to other areas of [Configuration Cache compatibility](https://github.com/gradle/gradle/issues/13490) in the target plugins
@@ -206,53 +204,53 @@ Potential deliverables include but not limited to:
 
 Implementing extensibility features in the Kotlin DSL for Gradle and improving support for common project integrations
 
-**Skills required (preferred)**
+**Preferred skills**
 
 * Kotlin
 * Gradle 
 * Java
 * Performance analysis
 * Profiling
 
-**Possible mentor**
+**Possible mentors**
 
 Oleg Nenashev, Laura Kassovic
 
 ### Gradle convention plugin for developing Jenkins plugins [Easy to Hard, 90 hrs to 350 hrs]
 
 There are more than 50 Jenkins plugins that are implemented with Gradle. 
 There is a [Gradle JPI plugin](https://github.com/jenkinsci/gradle-jpi-plugin),
-but it is not fully compliant with Jenkins hosting requirements, and needs an update.
+but it is not fully compliant with Jenkins hosting requirements and needs an update.
 In this project idea, the aim would be to recover the Gradle developer flow for Jenkins, reach feature parity with the
 Apache Maven flow ([Parent POM](https://github.com/jenkinsci/plugin-pom),
 [Plugin Compatibility Tester](https://github.com/jenkinsci/plugin-compat-tester),
 [Jenkins Bill of Materials](https://github.com/jenkinsci/bom), and others),
 and to improve the developer experience for those who develop Jenkins plugins with Gradle.
 
-Contributors are welcome to choose the deliverables, based on their interest and the desired project size.
+Contributors are welcome to choose the deliverables based on their interest and the desired project size.
 
-Potential deliverables include but not limited to:
+Potential deliverables include but are not limited to:
 * Refreshing the Gradle JPI plugin and making it compliant with hosting best practices
 * Migrating the Gradle JPI plugin codebase from Groovy to Kotlin
 * Implementing a new convention plugin for Jenkins Plugins that would cover the main features of Jenkins plugin Parent POM, with Kotlin and Kotlin DSL.
   This would include not just building the plugin, but also testing and static analysis according to Jenkins' best practices
-* Adopting the refreshed plugin and/or the convention plugin in the most popular Gradle plugin, including the Gradle Plugin itself
-* Integrating Gradle Plugins into Plugin Compatibility Tester and Bill of Materials
+* Adopting the refreshed plugin and/or the convention plugin in the most popular Gradle plugin, including the Gradle plugin itself
+* Integrating the Gradle plugin into the Plugin Compatibility Tester and Bill of Materials
 * Documenting the updated Gradle development flow for Jenkins plugins
 
 **Expected outcomes**
 
-Updated Gradle JPI Plugin AND/OR new convention plugin for Jenkins, published on Jenkins Update Center and Gradle Plugin Portal
+Updated Gradle JPI plugin and/or new convention plugin for Jenkins, published on Jenkins Update Center and the Gradle Plugin Portal
 
-**Skills required (preferred)**
+**Preferred skills**
 
 * Kotlin DSL
 * Kotlin
 * Gradle
 * Jenkins
 * Java
 
-**Possible mentor**
+**Possible mentors**
 
 Oleg Nenashev, Stefan Wolf
 
@@ -261,21 +259,21 @@ Oleg Nenashev, Stefan Wolf
 Many projects, including Gradle, have a lot of Kotlin DSL samples and code snippets (see the Gradle Docs for examples). 
 Testing them against multiple versions poses certain challenges because the snippets often represent incomplete code 
 for the sake of brevity. We would like to build a test framework that simplifies the verification of those samples 
-within a unit test framework (Kotest or JUnit 5) on GitHub Actions or Teamcity. Later we would be interested in
+within a unit test framework (Kotest or JUnit 5) on GitHub Actions or TeamCity. Later we would be interested in
 doing the same for [Declarative Gradle](https://declarative.gradle.org/) samples.
 
 **Expected outcomes**
 
 Implementing extensibility features in the Kotlin DSL for Gradle and improving support for common project integrations
 
-**Skills required (preferred)**
+**Preferred skills**
 
 * Kotlin
 * Gradle
 * Java
 * Static analysis
 
-**Possible mentor**
+**Possible mentors**
 
 Oleg Nenashev, Laura Kassovic
 
@@ -291,16 +289,16 @@ and external companies to integrate their workflows with JetBrains tools.
 **Expected outcomes**
 
 * Introduce Gradle Reporting to provide detailed, configurable verification task reports.
-* Utilize Gradle Worker API to enable parallel execution of the verifyPlugin task against multiple IntelliJ Platform versions, reducing the task execution time.
+* Utilize Gradle Worker API to enable parallel execution of the `verifyPlugin` task against multiple IntelliJ Platform versions, reducing the task execution time.
 * Explore additional Gradle enhancements to further improve plugin development workflows.
 
-**Skills required (preferred)**
+**Preferred skills**
 
 * Kotlin
 * Gradle
 * IntelliJ Platform
 
-**Possible mentor**
+**Possible mentors**
 
 Jakub Chrzanowski, JetBrains
 
@@ -310,17 +308,23 @@ OpenRewrite is a powerful framework for automating code migrations and refactori
 While OpenRewrite has strong support for Java, the Kotlin ecosystem would benefit from a more comprehensive
 set of OpenRewrite recipes to help developers seamlessly migrate their codebases.
 
+This project aims to expand the Kotlin OpenRewrite recipe collection by adding more 
+automated transformations, such as migrating Java-based AutoValue classes to idiomatic 
+Kotlin data classes, modernizing Kotlin code to follow best practices, and enabling more 
+seamless migrations across Kotlin versions. These recipes will help Kotlin developers 
+maintain clean, up-to-date, and idiomatic codebases with minimal manual effort.
+
 **Expected outcomes**
 
 * Development of new OpenRewrite recipes for Kotlin code migrations
 
-**Skills required (preferred)**
+**Preferred skills**
 
 * Kotlin
 * OpenRewrite framework
 * Java-to-Kotlin migration strategies
 
-**Possible mentor**
+**Possible mentors**
 
 Shauvik Roy Choudhary, and the Uber team
 
@@ -340,13 +344,13 @@ ensuring compatibility with widely used dependency management approaches.
 * Improved dependency resolution and usability for Bazel users
 * Documentation and examples for using BOM support in Bazel
 
-**Skills required (preferred)**
+**Preferred skills**
 
 * Starlark (Bazel's scripting language)
 * Bazel build system
 * Dependency resolution strategies
 
-**Possible mentor**
+**Possible mentors**
 
 Shauvik Roy Choudhary, and the Uber team
 
@@ -355,9 +359,9 @@ Shauvik Roy Choudhary, and the Uber team
 Gradle recently introduced a new [Problems API](https://docs.gradle.org/current/userguide/reporting_problems.html)
 that allows Gradle and third-party plugins to propagate issues and warnings in a unified way. 
 This API provides clean and actionable error reporting and more insights into the console output, dedicated HTML reports, 
-and connected observability tools. IDEs, such as IntelliJ IDEA or Android Studio, also have access to the details via Gradle's tool integration API, 
-and can show warnings right in the code editorI. Several core features and plugins have already adopted the Problems API: Java compilation, 
-dependency resolution errors, deprecation warnings, etc. We want the code quality plugins for Kotlin to adopt this API, too; it would greatly 
+and connected observability tools. IDEs such as IntelliJ IDEA or Android Studio can also access the details via Gradle's API integration tool, 
+and can show warnings right in the code editor. Several core features and plugins have already adopted the Problems API: Java compilation, 
+dependency resolution errors, deprecation warnings, etc. We want the code quality plugins for Kotlin to adopt this API, too; it would significantly 
 improve the developer experience for 100,000+ Kotlin developers using Gradle.
 
 In this project, we invite contributors to choose a number of Kotlin code quality plugins, such as Ktlint, Detekt, Diktat, ArchUnit, or Checkstyle 
@@ -367,7 +371,7 @@ for Kotlin, and integrate them with Problems API. You can also work on integrati
 
 * Implement Problems API integration in the mentioned plugins
 
-**Skills required (preferred)**
+**Preferred skills**
 
 * Kotlin
 * Gradle