Lowering contribution barrier

[Becheler]

Story

A newcomer or a researcher asking "how do I add an algorithm to BGL?" has no documented answer in this repo.

The entrance bar is already high: BGL's design is heavily generic (algorithms are coded against concepts, not concrete graph types), the historical documentation is sparse, and the contribution process is undocumented. The generic design is a core constraint we can't remove, but we can remove some of the process friction and pain points.

Concretely, the repo has:

• No top-level CONTRIBUTING.md
• No .github/CONTRIBUTING.md
• No PR or issue templates
• No contribution guidance on the docs site
• No modern tutorial on how to step by step design/implement an algorithm a la BGL

A newcomer falls back to generic Boost-wide resources (the boostorg wiki, the Boost mailing list, the general boost+git workflow), none of which is BGL-specific.

Researchers come with additional context and frictions: they are not developers, their job is to submit papers, not to figure out b2, cmake, generic C++ and Boost idioms. BGL needs researchers and researchers need BGL. A process must exist for researchers and developers to communicate.

Dream solution

Meet newcomers and researchers where their incentives already are.

• A lightweight algorithm proposal template (so the entry cost is hours, not weeks)
• An extended set of graph generators with real and synthetic datasets to validate, reproduce and review algorithms with concrete benchmarks
• A pairing system matching researchers with C++ contributors per PR (so Boost conventions become someone else's problem, handled in review).
• Academic credit via JOSS, which turns a merged contribution into a citable artifact (the thing researchers actually need)

Starting point

• Julia package registration
• JOSS, Journal of Open Source Software
• A user looking for benchmark datasets for BGL

Intermediary objective

Identify highest friction points to new contributions and draft possible solutions. Any idea is welcome, or pick one:

• Proposal template: sketch a one-pager (algorithm name, key paper + DOI, worst-case complexity, reference dataset, API sketch in BGL terms, proposed reviewer etc ) that could later be converted as an issue template.
• Graph generators & datasets: Consider switching to Graph generators for benchmarking and testing #480 to inventory what BGL ships, list what's missing (common synthetic models, standard real datasets), identify no-goes (maybe getting the entire facebook graph is not BGL responsibility)
• Pairing system: draft how could a pair form and what the risks are: who proposes the match, what maintainer commits to, what happens when it stalls.
• JOSS path: JOSS reviews standalone packages, not patches into existing libraries, so a direct submission may not fit. Worth checking before promising researchers a citation. Alternatives: SoftwareX (more permissive), or a Zenodo DOI per merged algorithm (citable artifact, no journal needed).