GitLink Maintainer Radar

简体中文

GitLink Maintainer Radar is a standalone competition repository for the GitLink intelligent-service open-source contribution challenge, subtask 3. It addresses a practical maintenance problem: teams operating several open-source repositories must inspect issues, pull requests, contributors, branches, documentation, and releases separately before they can decide what to handle first.

Open-source repository: https://www.gitlink.org.cn/saber1/gitlink-project-health-radar .

The workflow turns that fragmented evidence into project maintenance reports, issue-routing suggestions, PR quality gates, release-readiness checks, a cross-project attention order, and three data figures. It runs 16 distinct read-only gitlink-cli commands per project.

Problem-Solving Workflow

Project list
  -> repository baseline
  -> issue triage and maintainer candidates
  -> PR change-surface and review gate
  -> health and release-readiness checks
  -> cross-project attention order
  -> maintenance brief and action package
  -> optional writeback after human confirmation

The checked-in snapshot was produced from two public GitLink projects:

• mindspore-Ecosystem/mindspore, project ID 1410955, focused PR #9.
• opentiny/tiny-vue, project ID 1449224, focused PR #11.

Both pages returned HTTP 200 during verification. “Applied to a project” here means the workflow completed a public read-only analysis; it does not claim adoption by either project team.

Project	Health / risk	Repo report / risk	Focused PR / risk	Overall risk	Collection	Signal content
mindspore-Ecosystem/mindspore	61 / high	38 / critical	#9 / low	critical	16/16	14/16 populated, 2 valid-empty
opentiny/tiny-vue	61 / high	52 / high	#11 / low	high	16/16	14/16 populated, 2 valid-empty

The two valid-empty signals are zero public reviews and zero GitLink releases. They are successful observations, not missing collection. Overall risk is the more severe of the raw workflow +health and workflow +repo-report risks; focused-PR risk remains a separate change-level signal.

An evidence-consistency guard preserves raw CLI labels while checking them against direct change evidence. TinyVue PR #11 is still reported as raw low, but its 29 files, +1,284 lines, feature title, and five unchecked test items trigger a P1 manual-review gate, shown as low* in figures.

Evidence Figures

16-Command Chain

#	Command	Decision signal
1	repo +info	Repository identity and scale
2	repo +readme	README availability
3	repo +code-stats	Commit, author, and change volume
4	repo +contributors	Contributor evidence and maintainer candidates
5	branch +list	Branch activity
6	issue +list	Open issue queue
7	label +list	Label governance
8	pr +list	Open pull-request queue
9	pr +view	Focused PR details
10	pr +files	Changed files and line volume
11	pr +reviews	Review records
12	workflow +health	Rule-based health score
13	workflow +triage	Issue type, priority, and missing information
14	workflow +pr-summary	PR risk and test suggestions
15	workflow +repo-report	Consolidated repository governance score
16	release +list	Release cadence

Run

Requirements: Python 3.9+ and gitlink-cli. The Python workflow uses only the standard library.

cd D:\competition\gitlink-project-health-radar
$env:PYTHON="python"
.\scripts\run_demo.ps1 `
  -Mode cli `
  -CliBin "D:\path\to\gitlink-cli.exe" `
  -OutputDir examples\demo_outputs

Offline reproduction:

.\scripts\run_demo.ps1 -Mode fixture -Config examples\fixture_config.json

Verification:

python scripts\verify_submission.py
python -m unittest discover -s tests -p "test_*.py"

Start reviewing from the portfolio report and the 32-command log.

Safety and Truthfulness

• The default workflow is read-only.
• Responsibility fields are candidates derived from public contribution statistics, not actual assignments.
• A successful command is distinct from a non-empty signal; valid empty review and release lists remain explicit.
• TinyVue’s default branch is dev; the workflow obtains it from repo +info and runs repo +readme --ref dev, returning README.md (32,546 bytes).
• Raw workflow scores are preserved even when independent probes provide newer or more specific evidence; contradictory recommendations are filtered and the limitation is documented.
• Fixture exports redact email, token, invite-code, and secret fields.
• Remote issue +comment is only available with explicit --apply-publish --publish-issue-number <n> arguments.