From 2757f8178f68c0a39fb06f9b63fab3f55a65d7c7 Mon Sep 17 00:00:00 2001 From: Carlos Ortiz Date: Sun, 16 Aug 2026 13:28:24 -0600 Subject: [PATCH] docs: add a contributor on-ramp pointing at the open issues MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The issue list is only an invitation if someone finds it. Adds a 'Where to start' section naming the three gaps that matter most for adoption (monotone constraints, stability monitoring, fair lending), the smaller entry points, and an explicit note that domain knowledge is as welcome as code — several issues need someone who has governed a scorecard in production more than someone who writes fast Python. --- CONTRIBUTING.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 7fe72f1..0e97b4f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -3,6 +3,33 @@ Thanks for your interest. CompileML aims for a small number of hard promises, each enforced by tests — contributions are judged against that bar. +## Where to start + +The [open issues](https://github.com/orgoca/CompileML/issues) are written to be +picked up: each one states the problem, why it matters in a regulated lending +context, a proposed approach, acceptance criteria, and the files involved. + +Three of them are, in my view, what stands between this being interesting +infrastructure and something a risk function could actually adopt: + +| | | +|---|---| +| [#8](https://github.com/orgoca/CompileML/issues/8) | **Monotone feature constraints.** Today the distilled whitebox cannot enforce them, so a compiled scorecard may show a bin where more delinquency scores *better*. That is a scorecard a committee rejects on sight. | +| [#9](https://github.com/orgoca/CompileML/issues/9) | **Stability monitoring (PSI/CSI/drift).** The validation framework checks an artifact at a point in time; model risk management is about what happens next. | +| [#10](https://github.com/orgoca/CompileML/issues/10) | **Fair lending.** Disparate impact testing, plus disparity decomposition over the exact attributions — something the reconciliation identity makes possible here in a way it is not elsewhere. | + +Smaller entry points: [#17](https://github.com/orgoca/CompileML/issues/17) +(FAQ: why not PMML/ONNX), [#18](https://github.com/orgoca/CompileML/issues/18) +(WOE compatibility docs), [#12](https://github.com/orgoca/CompileML/issues/12) +(retention by segment). + +Domain knowledge is as welcome as code. Several issues — segmented artifact +suites ([#13](https://github.com/orgoca/CompileML/issues/13)), informative +missingness ([#11](https://github.com/orgoca/CompileML/issues/11)) — need +someone who has governed a scorecard in production more than they need someone +who writes fast Python. Comment on the issue before opening a PR on those; the +design discussion is the work. + ## Ground rules 1. **The spec is the contract.** Runtime, exporters, and validators implement