[CONTRIBUTORS][PIPELINE] Prepare ENTITY for GSoC, Outreachy and structured mentorship programs

[blackmore-technology-group]

Goal

Build a long-horizon contributor pipeline so ENTITY can attract developers for 8–22 week projects, not only one-off issues.

This is community/mentorship preparation and must remain separate from release remediation.

Google Summer of Code

Google's published general timing places mentoring-organization applications in January/February, with contributor proposals in March/April and coding beginning around late May/June. The 2027 dates have not yet been published.

Preparation before the next organization application window:

1. maintain a clearly active public repository and release history;
2. publish a dedicated GSoC-ideas/mentorship ideas page with small, medium and large project scopes;
3. identify at least two reliable human mentors/backups;
4. document contributor communication channels and expected response times;
5. create prerequisite starter tasks so applicants demonstrate setup and judgment before proposing larger projects;
6. make project outcomes independently testable rather than subjective;
7. avoid assigning release-critical authority/signing operations to first-time contributors;
8. preserve the distinction between BTG-controlled implementation work and independent qualification.

Candidate GSoC-scale projects:

• native verifier/SDK packaging and registry distribution across one language ecosystem;
• protocol/schema developer tooling and diagnostics;
• cross-platform conformance runner UX;
• independent test-vector generator/fuzzer with fail-closed oracle boundaries;
• documentation/schema browser and conformance explorer;
• reproducibility/evidence dashboard driven only by public artifacts.

Outreachy

The December 2026 mentoring-community/project deadline was 25 September 2026, so ENTITY missed the current cohort by two days. Do not attempt a late submission.

Prepare for the next Outreachy community call, which typically opens in early January for the mid-year cohort.

Requirements to prepare:

• newcomer-safe project scope;
• mentor capacity for frequent review;
• contribution-period starter tasks;
• explicit code of conduct and communication expectations;
• documented development environment;
• sponsor/funding plan if required by the cohort;
• project work that can be evaluated without exposing credentials or production sovereignty state.

Foundation mentorship routes

Linux Foundation LFX mentorship currently operates through participating LF projects (including LF Decentralized Trust and OpenSSF). ENTITY is not assumed eligible merely because it is open source. Treat LFX as a possible future route only if ENTITY becomes part of, or collaborates through, an eligible foundation project.

University / capstone route

Create a reusable academic project brief suitable for software-engineering, security, distributed-systems, digital-identity and formal-methods courses. Prefer projects with:

• a sealed public input corpus;
• deterministic acceptance tests;
• no access to BTG private infrastructure;
• publishable negative as well as positive results;
• a clean authorship boundary for student work.

Success measures

• accepted mentoring-organization/community application;
• number of qualified applicants who complete prerequisite tasks;
• retained contributors after the structured program ends;
• independently authored repositories/tools;
• merged work with reproducible evidence;
• no weakening of release/security boundaries.

Coordination

• [OUTREACH] Share ENTITY v3.4.3 external verification challenge with relevant developer communities #56 developer-acquisition tracker
• [OUTREACH][PHASE 2] Conferences, standards communities and optional contributor bounties #73 conferences/standards/bounty expansion
• [DISTRIBUTION][HELP WANTED] Make ENTITY language baselines registry-discoverable without changing protocol semantics #71 registry distribution
• [DISCOVERY] Enable Zenodo DOI archival and research-software indexing for ENTITY releases #72 DOI/research discovery
• ENTITY v3.4.3 external verification challenge — reproduce it, break it, or implement one part independently #55 external verification umbrella

Do not modify or retag historical releases through this workstream.