Update src/index.qmd

src/index.qmd

@@ -49,6 +49,7 @@ As the size of my dataset grew, several consistent patterns emerged, both about
     Large contributions (500-2,476 LoC) in examples, integrations, new functionality are ideal for long-term impact on projects.
     
 2. **Documentation PRs merged 10x faster than code**: This metric shows that documentation is prioritized than code due to less complexity, but a high standard of work such as code examples, addition of docstrings to missing functions, etc. are expected as valid contributions.
+
 3. **Repeat repository engagement (11 repos) correlated with 3.2x faster merge times**: When contributions are targeted to a set of high-quality and community driven projects, relationship capital compounds faster than technical expertise.
 
 Across all open-source repositories, successful PRs consistently showed these traits:
@@ -66,56 +67,51 @@ Also, an important insight was observed:
 
 The following PRs represent different dimensions of software engineering: DevOps, API design, documentation enhancement and developer tooling:
 
-1. [Add Optuna + Transformers Integration Example (huggingface/cookbook)](https://github.com/huggingface/cookbook/pull/304){target="_blank"}
+1. Add Optuna + Transformers Integration Example (huggingface/cookbook)[^1]
 
 **Challenge:** Demonstrating hyperparameter optimization for transformer models with evaluation, observability and storage of trials.
 
 **Technical Solution:** 
-
 - Combined expertise in neural architecture search, training and automated ML. The tech stack used `W&B` for recording trials(`observability`), storage with `SQLite` and visualization with `Matplotlib`.
-- It was featured in Hugging Face  as an integration example.
+- It was featured in Hugging Face as an integration example.
 
 **Outcome:** Enabled practitioners to optimize model training 3-5x faster using Auto ML search strategies.
 
-2. [Modernize Python Tooling with pyproject.toml (skorch-dev/skorch)](https://github.com/skorch-dev/skorch/pull/1108){target="_blank"}
+2. Modernize Python Tooling with pyproject.toml (skorch-dev/skorch)[^2]
 
 **Challenge:** Skorch relied on legacy packaging (`setup.py`, `requirements.txt`, `.pylintrc`, `.coveragerc`, `MANIFEST.in`) causing maintenance burden and incompatibility with modern Python tooling.
 
 **Technical Solution:**
-
-- Consolidated 6 configuration files into single `pyproject.toml` based on [PEP 518](https://peps.python.org/pep-0518/), [PEP 621](https://peps.python.org/pep-0621/), [PEP 639](https://peps.python.org/pep-0639/). Migration of build system to modern setuptools declarative format was also performed. Also, updated `pytest`, `pylint`, `flake8`, `coverage` configurations to reflect modern tooling.
+- Consolidated 6 configuration files into single `pyproject.toml` based on PEP 518[^3], PEP 621[^4], PEP 639[^5]. Migration of build system to modern setuptools declarative format was also performed. Also, updated `pytest`, `pylint`, `flake8`, `coverage` configurations to reflect modern tooling.
 - Added PyPI classifiers for better package discoverability.
 
 **Outcome:** Simplified maintenance, improved `CI/CD` reliability, aligned with `Python ecosystem standards`.
 
-3. [Reduce CI Flakiness by Configuring HF Token and Caching (PrunaAI/pruna)](https://github.com/PrunaAI/pruna/pull/406){target="_blank"}
+3. Reduce CI Flakiness by Configuring HF Token and Caching (PrunaAI/pruna)[^6]
 
 **Challenge:** CI test runs failed due to Hugging Face API rate limits and memory-intensive dataset downloads causing non-deterministic test failures.
 
 **Technical Solution:**
-
 - Configured HF authentication tokens to increase rate limits from `anonymous` to `authenticated tier`. Implemented a `caching` strategy for datasets and models.
 - Added `pytest-rerunfailures` plugin with controlled `retry logic` and introduced `cache-cleanup` to handle transient failures and cleaned incomplete cache directories before test runs to prevent corruption.
 
 **Outcome:** Reduced `CI` flakiness from frequent failures to stable test runs, unblocking maintainers and improving development velocity.
 
-4.  [Add Interactive Demo Link to Fast LoRA Inference Blog Post (huggingface/blog)](https://github.com/huggingface/blog/pull/3044){target="_blank"}
+4. Add Interactive Demo Link to Fast LoRA Inference Blog Post (huggingface/blog)[^7]
 
 **Challenge:** The LoRA inference optimization blog post lacked an interactive component, limiting reader ability to experiment with the concepts.
 
 **Technical Approach:**
-
-- Created an interactive [Replicate](https://replicate.com/paragekbote/flux-fast-lora-hotswap){target="_blank"} deployment showcasing PEFT +BnB+ Diffusers integration with LoRA hotswapping.
+- Created an interactive Replicate[^8] deployment showcasing PEFT +BnB+ Diffusers integration with LoRA hotswapping.
 - Embedded the demo link directly in blog post for immediate experimentation and usage.
 
 **Outcome:** Readers can now test `LoRA inference optimizations` interactively, transforming passive reading into active learning. Interactive demos reduce the gap between reading and understanding by 5x.
 
-5. [Extend callback_on_step_end Support for AuraFlow and LuminaText2Img Pipelines (huggingface/diffusers)](https://github.com/huggingface/diffusers/pull/10746){target="_blank"}
+5. Extend callback_on_step_end Support for AuraFlow and LuminaText2Img Pipelines (huggingface/diffusers)[^9]
 
 **Challenge:** `AuraFlow` and `LuminaText2Img` pipelines lacked callback support present in other diffusion pipelines, breaking consistency for users.
 
 **Technical Depth:**
-
 - Extended callback mechanism to enable step-by-step intervention during inference. Maintained backward compatibility with existing pipeline implementations.
 - Aligned the implementation with established patterns from Stable Diffusion and SDXL pipelines.
 
@@ -129,13 +125,13 @@ When contributing to open-source projects works best when contributors follow co
 
 To begin, comment on existing issue with an approach that can help resolve the issue in reasonable time or create a new one in which your approach is outlined. Wait for maintainer signal and then open a PR.
 
-Note that if you propose breaking changes that affect the public API without discussion, it may take significant time for review or lead to **rejection of the PR** because the approach doesn’t align with the project direction.
+Note that if you propose breaking changes that affect the public API without discussion, it may take significant time for review or lead to **rejection of the PR** because the approach doesn't align with the project direction.
 
 2. **Use Programming Language Standards to Improve your Contributions**
 
-There are standards for every major programming language such as the **[PEP Index](https://peps.python.org/){target="_blank"} for Python, [Go Programming Language Specification](https://go.dev/ref/spec){target="_blank"} for Golang or the [RFC Series](https://www.rfc-editor.org/) for building public APIs**. Try to reference them in your GitHub issues, use methods from them in your PRs and since these standards are widely accepted and adopted by programmers, your contributions are more likely to be accepted sooner. 
+There are standards for every major programming language such as the PEP Index[^10] for Python, Go Programming Language Specification[^11] for Golang or the RFC Series[^12] for building public APIs. Try to reference them in your GitHub issues, use methods from them in your PRs and since these standards are widely accepted and adopted by programmers, your contributions are more likely to be accepted sooner. 
 
-Examples can be seen in this [**PR**](https://github.com/skorch-dev/skorch/pull/1108){target="_blank"} and this [**issue**](https://github.com/PrunaAI/pruna/issues/225){target="_blank"}.
+Examples can be seen in this PR[^13] and this issue[^14].
 
 3. **Treat the CI Green Light as Non-Negotiable Before Merging**
 
@@ -147,9 +143,9 @@ Never request a final review unless CI is fully green. CI ensures correctness, c
 
 4. **Follow the "One Thing Per PR" Discipline**
 
-Since maintainers often batch-review PRs, mixed-scope PRs get deferred because they're time-consuming to review and give feedback. Tend to avoid the **‘Fix bug X, refactor Y feature and update docs Z’** mindset, since these types of PRs may not get accepted.  Keep your commits atomic with clear description of changes within the PR. 
+Since maintainers often batch-review PRs, mixed-scope PRs get deferred because they're time-consuming to review and give feedback. Tend to avoid the **'Fix bug X, refactor Y feature and update docs Z'** mindset, since these types of PRs may not get accepted.  Keep your commits atomic with clear description of changes within the PR. 
 
-If we look at the **box plot showing the distribution of merge times**, we see a clear pattern: PRs that follow these practices consistently merge faster, while PRs having large, multi-scope or under-discussed contributions take significantly longer and sometimes become “stuck” for weeks or months.
+If we look at the **box plot showing the distribution of merge times**, we see a clear pattern: PRs that follow these practices consistently merge faster, while PRs having large, multi-scope or under-discussed contributions take significantly longer and sometimes become "stuck" for weeks or months.
 
 ![Boxplot for Response Times](images/response_time_boxplot.png)
 
@@ -159,7 +155,7 @@ Effective PR collaboration requires understanding the intent behind reviewer fee
 
 Accept the style/writing feedback without debate. **Style or formatting-related comments**, such as renaming variables to snake_case or adjusting docstrings should be accepted without debate. These suggestions are usually grounded in project-wide conventions and help maintain a consistent codebase. 
 
-For **technical feedback**, however, it’s important to engage thoughtfully. If a reviewer flags a potential bug or an unhandled edge case, ask clarifying questions to understand the scenario they are concerned about.
+For **technical feedback**, however, it's important to engage thoughtfully. If a reviewer flags a potential bug or an unhandled edge case, ask clarifying questions to understand the scenario they are concerned about.
 
 6. **The 48-Hour Response Commitment**
 
@@ -173,10 +169,30 @@ It is also worth noting that maintainers may occasionally miss a PR due to workl
 
 ## Reflections for Future Contributions {#reflections-for-future-contributions}
 
-The real lesson from 95 PRs isn’t about productivity, it's about understanding the needs of project maintainers, resolving long-standing issues that require attention and pursuing effective communication. At scale, open-source contribution becomes a feedback loop. You learn project-specific patterns. This leads to internalize quality signals and leads to increase in merged rates and iteration cycles decrease. It also leading to compounding of trust and access to interesting problems. 
+The real lesson from 95 PRs isn't about productivity, it's about understanding the needs of project maintainers, resolving long-standing issues that require attention and pursuing effective communication. At scale, open-source contribution becomes a feedback loop. You learn project-specific patterns. This leads to internalize quality signals and leads to increase in merged rates and iteration cycles decrease. It also leading to compounding of trust and access to interesting problems. 
 
 If I could summarize this case-study into one actionable insight:
 
 **Small and frequent contributions which are well tested to a focused set of projects compound faster than large, sporadic contributions to many projects.**
 
-The [scripts](https://github.com/ParagEkbote/ParagEkbote.github.io/tree/main/scripts){target="_blank"} used for data collection are available for reference and PR links are also included.
+The scripts[^15] used for data collection are available for reference and PR links are also included.
+
+---
+
+## References
+
+[^1]: https://github.com/huggingface/cookbook/pull/304
+[^2]: https://github.com/skorch-dev/skorch/pull/1108
+[^3]: https://peps.python.org/pep-0518/
+[^4]: https://peps.python.org/pep-0621/
+[^5]: https://peps.python.org/pep-0639/
+[^6]: https://github.com/PrunaAI/pruna/pull/406
+[^7]: https://github.com/huggingface/blog/pull/3044
+[^8]: https://replicate.com/paragekbote/flux-fast-lora-hotswap
+[^9]: https://github.com/huggingface/diffusers/pull/10746
+[^10]: https://peps.python.org/
+[^11]: https://go.dev/ref/spec
+[^12]: https://www.rfc-editor.org/
+[^13]: https://github.com/skorch-dev/skorch/pull/1108
+[^14]: https://github.com/PrunaAI/pruna/issues/225
+[^15]: https://github.com/ParagEkbote/ParagEkbote.github.io/tree/main/scripts