Spaces:

AINovice2005
/

case-study

Sleeping

App Files Files Community

AINovice2005 commited on Dec 8, 2025

Commit

1a93aeb

verified ·

1 Parent(s): 411d311

update paths.

Browse files

Files changed (1) hide show

src/index.qmd +5 -5

src/index.qmd CHANGED Viewed

@@ -18,7 +18,7 @@ To understand contribution patterns, I converted raw GitHub activity into struct
 One of the first patterns comes from the **monthly PR volume**, which provides a high-level view of project activity over time. The visualization below shows how merged PRs fluctuate month-to-month, highlighting periods of higher contributor engagement (such as November 2024 and April 2025) and quieter phases (such as August 2024 or September 2025). These variations help understand review load, maintainer bandwidth and seasonal contribution patterns before diving into more granular metrics.
-![Temporal Trends of PR Contributions](src/images/temporal_trend_graph.png)
 Before diving into patterns, let's establish what the key metrics actually measure:
@@ -40,7 +40,7 @@ This distribution highlights a consistent pattern across open-source ecosystems:
 To understand when contributors (including myself) tended to open PRs, I also generated a day-of-week × hour-of-day activity heatmap. The pattern shows that most PRs were created during weekday afternoons and early evenings, aligning with typical contributor availability and maintainer review windows.
-![Activity Heatmap of PR Creation](src/images/activity_heatmap.png)
 As the size of my dataset grew, several consistent patterns emerged, both about my contribution style and about how maintainers respond. The top 3 insights were seen as follows:
@@ -139,7 +139,7 @@ Examples can be seen in this [**PR**](https://github.com/skorch-dev/skorch/pull/
 3. **Treat the CI Green Light as Non-Negotiable Before Merging**
-![The CI Green Light](src/images/green_light_ci.png)
 Before committing your changes, it is important to execute linting and tests on the changed files to reduce the CI failure rate. CI also helps maintainers **reduce bugs and maintain consistency** in the codebase and if CI is difficult to restore to green, request to get pointers to fix the CI before merging the PR.
@@ -151,7 +151,7 @@ Since maintainers often batch-review PRs, mixed-scope PRs get deferred because t
 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](src/images/response_time_boxplot.png)
 5. **The "Praise Specifics, Accept Generics" Mindset**
@@ -167,7 +167,7 @@ A consistent pattern observed across projects is that **timely responses from co
 Across the data, **PRs with a response time under 48 hours merged 4.2 days faster** than PRs where contributors responded after 72 hours. Staying engaged within the first two days keeps your PR visible and signals intent.
-![Bar Chart of Merge Timing](src/images/merge_time_graph.png)
 It is also worth noting that maintainers may occasionally miss a PR due to workload or notification overload. A polite follow-up, usually after a few days is not only appropriate but often necessary to bring the PR back into the review cycle.

 One of the first patterns comes from the **monthly PR volume**, which provides a high-level view of project activity over time. The visualization below shows how merged PRs fluctuate month-to-month, highlighting periods of higher contributor engagement (such as November 2024 and April 2025) and quieter phases (such as August 2024 or September 2025). These variations help understand review load, maintainer bandwidth and seasonal contribution patterns before diving into more granular metrics.
+![Temporal Trends of PR Contributions](images/temporal_trend_graph.png)
 Before diving into patterns, let's establish what the key metrics actually measure:
 To understand when contributors (including myself) tended to open PRs, I also generated a day-of-week × hour-of-day activity heatmap. The pattern shows that most PRs were created during weekday afternoons and early evenings, aligning with typical contributor availability and maintainer review windows.
+![Activity Heatmap of PR Creation](images/activity_heatmap.png)
 As the size of my dataset grew, several consistent patterns emerged, both about my contribution style and about how maintainers respond. The top 3 insights were seen as follows:
 3. **Treat the CI Green Light as Non-Negotiable Before Merging**
+![The CI Green Light](images/green_light_ci.png)
 Before committing your changes, it is important to execute linting and tests on the changed files to reduce the CI failure rate. CI also helps maintainers **reduce bugs and maintain consistency** in the codebase and if CI is difficult to restore to green, request to get pointers to fix the CI before merging 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.
+![Boxplot for Response Times](images/response_time_boxplot.png)
 5. **The "Praise Specifics, Accept Generics" Mindset**
 Across the data, **PRs with a response time under 48 hours merged 4.2 days faster** than PRs where contributors responded after 72 hours. Staying engaged within the first two days keeps your PR visible and signals intent.
+![Bar Chart of Merge Timing](images/merge_time_graph.png)
 It is also worth noting that maintainers may occasionally miss a PR due to workload or notification overload. A polite follow-up, usually after a few days is not only appropriate but often necessary to bring the PR back into the review cycle.