Standardize GSoC ideas page formatting (#1179)

* Standardize GSoC ideas page formatting

Signed-off-by: Ali Ok <aliok@redhat.com>

* Update 2024.md

Signed-off-by: Ali Ok <aliok@redhat.com>

---------

Signed-off-by: Ali Ok <aliok@redhat.com>

programs/summerofcode/2024.md

@@ -38,7 +38,7 @@ You can find the project ideas from previous year [here](./2023.md).
 - Description: Falco is a real-time security tool designed to detect abnormal behaviours and security-related runtime events in Linux systems and the cloud. The _event-generator_ is an utility within the Falco ecosystem that helps testing Falco’s detection capabilities. The tool also has benchmark capabilities that represent a building block of the Falco performance testing practices. However, the project received less attention than required in the past few years and would require some care and renovation. This Google Summer of Code project proposes upgrading the _event-generator_ to improve its testing and benchmarking capabilities, its reliability, and its consistency, and developing new Continuous Integration pipelines based on it. The end goal is to evolve the _event-generator_ and make it the standard tool for systematically assessing the correctness and performance of Falco’s threat detection capabilities at every release and development cycle
 - Expected Outcome: The project will result in an extended version of the _event-generator_ tool that reliably generates a consistent number of events per second and stresses the most common detection scenarios of Falco. This enhanced utility will be integrated into Falco’s Continuous Integration (CI) pipeline, allowing for efficient systematic monitoring of performance regressions while ensuring alignment with past benchmarking results. Eventually, this could originate new performance optimizations in Falco itself. A stretch goal for the mentee would be to become an official maintainer of the _event-generator_ project and/or of other repositories of the Falco ecosystem
 - Recommended Skills: Go programming language, familiarity with continuous integration, understanding of performance benchmarking concepts
-- Expected project size: Large
+- Expected project size: Large (350 hour project)
 - Mentor(s):
   - Jason Dellaluce (@jasondellaluce, jasondellaluce@gmail.com) - primary
   - Aldo Lacuku (@alacuku, aldo@lacuku.eu)
@@ -53,7 +53,7 @@ You can find the project ideas from previous year [here](./2023.md).
   - Support deploying Jaeger v2 via Kubernetes Operator, Helm chart, and brew.
   - Documentation on the website.
 - Recommended Skills: Go, Kubernetes, scripting, CI/CD
-- Expected project size: large (~350 hour projects)
+- Expected project size: Large (350 hour project)
 - Mentor(s):
   - Yuri Shkuro (@yurishkuro, github@ysh.us) - primary
   - Jonah Kowall (@jkowall, jkowall@kowall.net)
@@ -71,7 +71,7 @@ You can find the project ideas from previous year [here](./2023.md).
   - Bot is able to track the status of GitHub issues with labels
   - Introduce documentation about how to use and configure the bot
 - Recommended Skills: GitHub API, TypeScript/Golang, Webhooks
-- Expected project size: Large
+- Expected project size: Large (350 hour project)
 - Mentor(s):
   - Ondrej Dubaj (@odubajDT, ondrej.dubaj@dynatrace.com) - primary
   - Florian Bacher (@bacherfl, florian.bacher@dynatrace.com)
@@ -84,7 +84,7 @@ You can find the project ideas from previous year [here](./2023.md).
 - Description: Wasm aka WebAssembly provides a portable binary-code format that is ideal to write small functions. However, current support for Wasm in Knative Functions is limited and slow. This project will improve this support.
 - Expected Outcome: Contribute Wasm support to Knative functions, documentation, sample code etc. Ideal outcome would be running Wasm code via Knative Functions in a convenient way. However, there are some unknowns. Other possible outcome could be identifying the roadblocks and possible improvements
 - Recommended Skills: basic programming skills, use IDE and debugger, some experience with Kubernetes
-- Expected project size: medium (~175 hour project)
+- Expected project size: Medium (175 hour project)
 - Mentor(s):
   - Aleksander Slominski @aslom (aslomins AT redhat DOT com)  - primary
   - Matthias Wessendorf @matzew (matzew AT redhat DOT com)
@@ -103,7 +103,7 @@ You can find the project ideas from previous year [here](./2023.md).
   - Handle Recommendation of Policies based on `karmor recommend`
   - Integrate KubeArmor Visibility Dashboards based on Grafana with Rancher Preset Grafana Dashboards
 - Recommended Skills: Rancher, Grafana stack, Javascript
-- Expected project size: Large
+- Expected project size: Large (350 hour project)
 - Mentor(s):
   - Barun Acharya (@daemon1024, barun1024@gmail.com) - primary
   - Prashant Mishra (@primalpimmy, prashant20.pm@gmail.com)
@@ -116,28 +116,26 @@ You can find the project ideas from previous year [here](./2023.md).
 ##### New Plugin to Scaffold a Helm Chart for Easier Distribution
 
 - **Description**: [Kubebuilder](https://github.com/kubernetes-sigs/kubebuilder) is a tool that helps the community develop Native Solutions for Kubernetes. Moreover, the tool is implemented using a [plugin ecosystem](https://book.kubebuilder.io/plugins/plugins), which allows users to opt-in for certain options and features. Recently, there has been a strong demand within the community for a feature that packages the Solution done with Kubebuilder in a Helm Chart, as it is a common method for distributing projects, and many infrastructure solutions like Terraform integrate well with Helm. Therefore, the goal of this project is to create a new plugin, such as; `package-helm.kubebuilder.io/v1beta1`, which will enable users to opt-in for its usage either when they create the project or by modifying it with the Kubebuilder CLI (i.e., `kubebuilder init|edit --plugins=package-helm.kubebuilder.io/v1beta1`). This plugin will be responsible for scaffolding all files required to help users distribute their solution via Helm.
-- **Expected Outcome**: An initial beta version of the plugin that scaffolds a Helm Chart to distribute the project.
-- **Recommended Skills**: Go, Helm, Kubernetes
-- **Expected Project Size**: Large (~350-hour project)
-- **Mentor(s)**: For GSoC, it is **required** to have at least 2 mentors, with 1 being the primary mentor.
+- Expected Outcome: An initial beta version of the plugin that scaffolds a Helm Chart to distribute the project.
+- Recommended Skills: Go, Helm, Kubernetes
+- Expected Project Size: Large (350 hour project)
+- Mentor(s):
   - Camila Macedo (@camilamacedo86, camilamacedo86@email.com) - Primary
   - Varsha (@varshaprasad96, vnarsing@redhat.com)
-- **Upstream Issue (URL)**: WIP: PR for the design proposal: https://github.com/kubernetes-sigs/kubebuilder/pull/3632
+- Upstream Issue (URL): WIP: PR for the design proposal: https://github.com/kubernetes-sigs/kubebuilder/pull/3632
 
 #### Kubernetes Gateway API
 
 ##### Design and develop notification mechanism for ingress2gateway.
 
 - Description: [Gateway API](https://gateway-api.sigs.k8s.io/) is the new generation of Kubernetes Networking APIs. Ingress2gateway is a tool to help users migrate and convert Ingress, and implementation-specific configurations to Gateway API. As we add more conversion logic, and onboard more implementations (essentially Ingress and Gateway controllers like Istio, Kong, etc.), logs become insufficient to report conversion results, warnings and crucial messages regarding the conversion. To improve the tool usability, we need to enable users to know exactly the original resource/s -> new resource/s mapping, PLUS what the tool couldn't convert so they could make the final touches before applying the new resources to the cluster.
-
   A few of the notification types we'll need to support:
   - Overview of original resources and the equivalent resources to which they have been converted
   - Warnings about partial conversions (partial fields within a resource)
   - Warnings about fields/logics not supported in Gateway API
-
 - Expected Outcome: A new notification mechanism to notify users conversion results, warnings and crucial messages regarding their conversion has been added and is being used across implementations supported by the tool.
 - Recommended Skills: Go, Kubernetes
-- Expected project size: medium
+- Expected project size: Medium (175 hour project)
 - Mentor(s):
   - (Lior Lieberman, @LiorLieberman)
   - (Mattia Lavacca, @mlavacca)
@@ -154,7 +152,7 @@ You can find the project ideas from previous year [here](./2023.md).
   - All test results, including coverage statistics, vulnerabilities, and crash reports, are visible and manageable through the ClusterFuzz Dashboard.
   - Documentation on how to maintain and extend the fuzzing tests as the project evolves.
 - Recommended Skills: Golang, Kubernetes
-- Expected project size: Large
+- Expected project size: Large (350 hour project)
 - Mentors(s):
   - Saranya Jena (@Saranya-jena, saranya.jena@harness.io) - primary
   - Karthik S (@ksatchit, karthik.s@harness.io)
@@ -167,7 +165,7 @@ You can find the project ideas from previous year [here](./2023.md).
 - Description: The OpenAPI specifications for Kubernetes provides taxonomy, but augmenting a graph data model with formalized ontologies enables any number of capabilities, one of the more straightforward is the inferencing requisite for natural language processing, and consequently, a human-centric query / response interaction becomes becomes possible. More importantly, more advanced systems can be built when a graph data model of connected systems is upgraded to be a knowledge semantic graph.
 - Expected Outcome: YAML-formatted definition
 - Recommended Skills: DevOps, Kubernetes Administration, Light familiarity with all of the CNCF projects and a desire to study each project and their operators/resources.
-- Expected project size: Large
+- Expected project size: Large (350 hour project)
 - Mentor(s):
   - Lee Calcote (@leecalcote, leecalcote@gmail.com) - primary
   - Uzair Shaikh (@muzairs15, muzair.shaikh810@gmail.com)
@@ -180,7 +178,7 @@ You can find the project ideas from previous year [here](./2023.md).
 - Description: Created Timestamp was added to Prometheus protobuf format and storage in 2023 GSoC in the summer. The important follow up was to add optional created timestamp feature to Prometheus or OpenMetrics Text formats, similar to https://github.com/prometheus/proposals/pull/32. This project will involve proposal and implementation of the design that would be accepted by Prometheus community. The change has to be carefully designed as the scrape text formats are the most commonly used "APIs" for pulling (scraping) metrics in the CNCF generally. NOTE: No need to carefully prepare de#front, we will do the proper design together.
 - Expected Outcome: Prometheus or OpenMetrics Text format have support for created timestamp (for OpenMetrics it means replacing the current design that inolves extra series, which can be problematic) e.g. in metadata or similar to exemplar.
 - Recommended Skills: HTTP, Go, defining stable APIs
-- Expected project size: medium
+- Expected project size: Medium (175 hour project)
 - Mentor(s):
   - Bartek Plotka (@bwplotka, bwplotka@gmail.com) - primary
   - Arthur Silva Sens (@arthurSens, arthursens2005@gmail.com)
@@ -192,11 +190,12 @@ You can find the project ideas from previous year [here](./2023.md).
 - Description: Prometheus, like many other Go projects, still use "gogo" (https://github.com/gogo/protobuf) implementation of the protobuf generator, which was deprecated a while ago. Since then protobuf projects moved forward with the new API version and various amazing protobuf plugins in the community like "vtproto" (https://github.com/planetscale/vtprotobuf) from Vitess. In Prometheus we use protobuf mainly for remote writing, as well as protobuf scraping protocols. In both cases the efficiency of the solution is critical. This is why gogo implementation was popular--it allowed a certain "nullable" option, that reduced amount of pointers in generated structures and instead preferred allocating bigger amount of memory at once (e.g. `[]*CustomType` was in gogo `[]CustomType`). Long story short, moving Prometheus out of gogo protobuf to native Go protobuf with vtproto has to happen due to lack of support for gogo for new protobuf API iterations. However, it not only requires code changes, but also carefully benchmarking and optimizing for different generated message structures (allocating smaller objects, but more of them). If you want to dive into amazing world of coding optimizations and benchmarks -- this project is for you! NOTE: No need to carefully prepare de#front, we will do the proper design together.
 - Expected Outcome: Prometheus project does not depend on gogo protobuf and its performance (e.g. scraping and remote write) is not worse than what we have now with gogo.
 - Recommended Skills: Go, protobuf, benchmarking
-- Expected project size: medium
+- Expected project size: Medium (175 hour project)
 - Mentor(s):
   - Callum Styan (@cstyan, callumstyan@gmail.com) - primary
   - Max Amin (@macxamin, maxamin25@gmail.com)
-  - Bartek Plotka (@bwplotka, bwplotka@gmail.com) Daniel Hrabovcak @TheSpiritXIII (thespiritxiii@gmail.com)
+  - Bartek Plotka (@bwplotka, bwplotka@gmail.com)
+  - Daniel Hrabovcak @TheSpiritXIII (thespiritxiii@gmail.com)
 - Upstream Issue (URL): https://github.com/prometheus/prometheus/issues/11908
 
 #### Service Mesh Performance
@@ -209,7 +208,7 @@ You can find the project ideas from previous year [here](./2023.md).
 - 2. Syntax Highlighting and Auto-completion: The plugin can fetch SMP Model definitions such as cloud-native components and their relationships. This information can be used to provide syntax highlighting and auto-completion for these definitions in the JSON files, making it easier for developers to write error-free code.
 - 3. Validation and Reference: For Meshery MeshModel definitions such as cloud-native components and their relationships, the plugin can use the CUE language to provide validation for the CUE input and preview the rendering result. The plugin can also fetch the SMP Model schemas and display them in the IDE for reference.
 - Recommended Skills: Cuelang
-- Expected project size: Large
+- Expected project size: Large (350 hour project)
 - Mentor(s):
   - Lee Calcote (@leecalcote, leecalcote@gmail.com) - primary
   - Xin Huang (@gyohuangxin, xin1.huang@intel.com)
@@ -227,7 +226,7 @@ You can find the project ideas from previous year [here](./2023.md).
   - Documentation on the coredump format, including how to encode process, module, and instance information.
   - Tutorials, examples, and demonstration of post-mortem debugging using the implemented coredump feature.
 - Recommended Skills: WebAssembly, C++, Debugger
-- Expected project size: Large
+- Expected project size: Large (350 hour project)
 - Mentor(s):
   - Hung-Ying Tai (@hydai, hydai@secondstate.io) - primary
   - Shen-Ta Hsieh (@ibmibmibm, beststeve@secondstate.io)
@@ -242,7 +241,7 @@ You can find the project ideas from previous year [here](./2023.md).
   - Implement the fine-tuning functions inside WASI-NN PyTorch plugin.
   - Documentation, examples, tutorials, and demonstration are required.
 - Recommended Skills: C++, WebAssembly, PyTorch
-- Expected project size: Large
+- Expected project size: Large (350 hour project)
 - Mentor(s):
   - Michael Yuan (@juntao, michael@secondstate.io) - primary
   - Hung-Ying Tai (@hydai, hydai@secondstate.io)
@@ -257,7 +256,7 @@ You can find the project ideas from previous year [here](./2023.md).
   - Implement the fine-tuning functions inside [WASI-NN ggml plugin](https://github.com/WasmEdge/WasmEdge/blob/master/plugins/wasi_nn/ggml.h).
   - Documentation, examples, tutorials, and demonstration are required.
 - Recommended Skills: C++, WebAssembly, LLM fine-tuning
-- Expected project size: Large
+- Expected project size: Large (350 hour project)
 - Mentor(s):
   - Michael Yuan (@juntao, michael@secondstate.io) - primary
   - Hung-Ying Tai (@hydai, hydai@secondstate.io)