Improve the PyPI project page for first-time users

[zasexton]

Problem

The svv project page on PyPI provides a short research motivation and a basic installation command, but it does not give first-time users enough information to understand the package's capabilities, choose an installation option, or complete an initial workflow.

The current description:

• emphasizes the motivating research problem without an equally concise statement of what users can accomplish;
• does not provide a scannable list of major capabilities such as domain preparation, constrained tree growth, connected forests, visualization, geometry export, and hemodynamic model export;
• has no runnable example, expected result, or representative image of generated output;
• describes multi-fidelity simulation without distinguishing the bundled 0-D solver from separately installed 1-D and 3-D solvers;
• exposes the accel and accelerated extras in PyPI metadata without explaining their purpose in the description;
• includes only a few links in the description and publishes no structured project links for PyPI's sidebar;
• contains redundant or unclear badges and a malformed PyPI-version badge link using https:://;
• states Python 3.9–3.12 in the installation guidance while the package classifiers include Python 3.13; and
• links from the PyPI description back to the same PyPI page instead of using that space for documentation or support resources.

These gaps make it harder for prospective users to evaluate the package and increase the distance between installation and a successful first result. They also leave important compatibility and solver-boundary details distributed across the documentation instead of summarizing them where package discovery occurs.

Solution

Revise README.md, which supplies the published long description, and complete the associated package metadata so the PyPI page presents a concise path from discovery to first use.

The revised description should:

• open with a direct, user-centered summary of vascular-network generation and downstream geometry or simulation workflows;
• follow the summary with four to six concrete capability bullets covering domains, trees, forests, visualization, exports, and supported simulation workflows;
• retain the standard installation command and briefly explain the default installation and the optional svv[accel] installation;
• state which native tools and solvers are included in official wheels and which solvers require separate installation;
• include a compact, tested quick-start example derived from the existing cube workflow, together with an expected textual result and one representative static image;
• link to the full installation guide, quick start, API reference, source repository, issue tracker, releases or changelog, and citation information;
• add structured project_urls metadata so the most important destinations appear in PyPI's Project links section;
• create a dedicated GitHub team named svv-pypi-maintainers, initially containing Zachary Sexton (@zasexton) and Dave Parker (@ktbolt), and use its active human membership as the source of truth for a Maintainers section in the PyPI description;
• update the published Maintainers section automatically when membership in svv-pypi-maintainers changes, without deriving package maintainership from broad organization-level repository access;
• generate a Contributors section from the repository's commit history, normalize and deduplicate contributor identities, and apply human-only filtering so automated and service accounts receive no contributor recognition;
• publish MIT through the standards-compliant SPDX License-Expression core metadata field, declare the applicable license file through License-File metadata, and include that file in both source and wheel distributions;
• reduce the badge row to signals that help users evaluate or use the package, with valid and canonical targets for every retained badge;
• use consistent product naming, PyPI capitalization, Python support ranges, and platform claims across the description, package metadata, and installation documentation; and
• keep detailed troubleshooting and platform-specific cluster guidance in the documentation, with concise links from the PyPI page.

The work should be considered complete when:

• a new visitor can identify the package's primary inputs, workflows, and outputs from the opening section;
• both installation variants and the bundled-versus-external solver boundary are explicitly documented;
• the quick-start example is exercised against a supported installation and its stated result is accurate;
• PyPI displays structured links for documentation, source, issues, releases, and citation information;
• the Maintainers section matches the current human membership of svv-pypi-maintainers, including Zachary Sexton and Dave Parker at initial publication;
• the Contributors section is generated from repository history, presents each human contributor once, and excludes accounts used by bots or other automation;
• attribution generation is deterministic and does not replace a valid published list with an empty or partial list when its GitHub data source is unavailable;
• PyPI displays License expression: MIT instead of relying only on the legacy free-form license field;
• the authoritative license file is declared in package metadata and is present in both the built source distribution and wheel;
• every link and badge target resolves correctly, including removal of the malformed https::// target;
• the supported Python range agrees across the README, classifiers, package metadata, and installation guide;
• the built distribution passes a PyPI-description rendering check, such as python -m twine check dist/*; and
• the rendered page is reviewed on TestPyPI or an equivalent local rendering before publication.

Additional context

setup.py currently reads README.md verbatim and publishes it as Markdown through long_description, so improving the README will improve both the repository landing page and the PyPI description without maintaining duplicate content.

Effective administrator access to the repository is inherited broadly through the SimVascular organization and is not a package-specific indication of maintainership. A dedicated svv-pypi-maintainers team provides a narrower, auditable list that can be managed in GitHub and synchronized without granting or modifying PyPI account permissions automatically.

Repository history includes commits from automated accounts, and account type alone is not sufficient to identify every service account. Contributor generation should therefore combine available account metadata with explicit bot and service-account filtering, while preserving a reviewable override mechanism for ambiguous identities.

setup.py currently sets license='MIT', which PyPI renders as the legacy License field rather than a License expression. MANIFEST.in also requests a root-level LICENSE file, but that file is not currently present. The implementation should add the authoritative license text, declare it through current package metadata, and verify its inclusion in every distribution format.

The existing documentation already contains most of the needed source material:

• installation and accelerator choices: https://simvascular.github.io/svVascularize/install.html
• tested tree and forest workflows: https://simvascular.github.io/svVascularize/quickstart.html
• API reference: https://simvascular.github.io/svVascularize/api/index_api.html
• current PyPI page: https://pypi.org/project/svv/
• citation DOI: https://doi.org/10.5281/zenodo.15151168

This request concerns documentation and distribution metadata. It should not change numerical behavior, supported public interfaces, or simulation results.

Code of Conduct

• I agree to follow this project's Code of Conduct and Contributing Guidelines