# GSOC 2026 Proposal draft

**URL:** https://talk.openelis-global.org/t/gsoc-2026-proposal-draft/2162
**Category:** GSOC
**Created:** [March 19, 2026, 12:03pm UTC](https://talk.openelis-global.org/t/gsoc-2026-proposal-draft/2162 "2026-03-19T12:03:17Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![chinerdene](https://avatars.discourse-cdn.com/v4/letter/c/43a26b/32.png) [@chinerdene](https://talk.openelis-global.org/u/chinerdene)
#### Post date: [March 19, 2026, 12:03pm UTC](https://talk.openelis-global.org/t/gsoc-2026-proposal-draft/2162/1 "2026-03-19T12:03:17Z")

</div>

## Problem Statement

The project faces a growing operational challenge: the small core development team manages client-facing work via Jira, while a global community of contributors submits issues and pull requests through GitHub. This creates two gaps:

1. \*\*Triage gap:\*\* Community GitHub issues and core-team Jira tickets are loosely connected. Duplicates, related work, and priority alignment between the two systems require significant manual effort.

2. \*\*Review gap:\*\* The volume of incoming PRs — across the main repo and 8+ submodules (plugins, analyzer bridge, HAPI FHIR starter, data export, Liquibase tools, etc.) — exceeds the core team’s capacity to review thoroughly. PRs can sit unreviewed, or get merged without sufficient quality validation against the project’s constitutional principles.

## Proposed Work

Build an MVP that takes the existing local AI commands and project knowledge, and scales them into an automated, CI-integrated pipeline. The project has three main work streams:

1. \*\*Goal:\*\* When a PR is opened or updated, automatically run project-specific quality checks and post structured feedback — without a core team member having to manually invoke anything.

Concrete work:

- Create GitHub Actions workflows that trigger on PR events (`opened`, `synchronize`, `ready_for_review`)

- Adapt the existing `/audit-branch` command’s detection rules (Tier 1 mechanical + Tier 2 heuristic) into CI-runnable checks that post inline PR comments

- Implement \*\*hard-stop checks\*\* (blocking merge on CRITICAL findings like merge conflicts, i18n duplicate keys, constitutional architecture violations like `@Transactional` on controllers) and \*\*soft advisory checks\*\* (code quality suggestions posted as non-blocking review comments)

- Explore integrating with GitHub’s native \*\*Copilot Code Review\*\* (now running on an agentic architecture as of March 2026, with static analysis integration supporting CodeQL and ESLint) alongside project-specific custom checks

- Evaluate tools like \*\*CodeRabbit\*\* for deeper context-aware review, potentially running alongside Copilot for complementary coverage

### 2. Cross-Platform Issue Triage & Linking

\*\*Goal:\*\* Help bridge the gap between community GitHub issues and core-team Jira tickets, reducing manual triage overhead.

Concrete work:

- Build an AI-assisted triage workflow (GitHub Action or bot) that classifies new GitHub issues by category (bug, feature request, question, duplicate) and priority

- Explore automated linking between GitHub issues and related Jira tickets using the Jira and GitHub APIs

- Investigate leveraging \*\*GitHub’s Agentic Workflows\*\* (in technical preview as of February 2026, supporting plain-Markdown workflow definitions for AI-driven repository tasks) for intelligent issue routing

- Generate periodic triage reports summarizing open issues, stale PRs, and alignment gaps between GitHub and Jira backlogs

### 3. CI Integration & Developer Feedback Loop

\*\*Goal:\*\* Make the automated checks useful and non-annoying — contributors should get fast, actionable feedback that helps them improve their PRs.

Concrete work:

- Design the feedback format: structured PR comments with severity levels, specific file:line references, and suggested fixes (following the pattern established by `/audit-branch`'s report format)

- Implement configurable severity thresholds per check (repo-level configuration, not hardcoded)

- Create a feedback dashboard or summary comment on each PR showing check status

- Ensure the pipeline works across the main repo and key submodules (especially `openelisglobal-plugins` and `openelis-analyzer-bridge`)
