maplibre / maplibre/maplibre.github.io

Acknowledge individual donors (OpenCollective + GitHub Sponsors) on the website

Open
#638 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement wontfix
Dominant language
MDX
Stars
23
Forks
47
Avg merge
1h 12m
Merged PRs (30d)
41

Description

Background

MapLibre receives individual donations via OpenCollective and GitHub Sponsors. Currently these donors are not acknowledged anywhere on the website, even though organizational sponsors are featured prominently. A draft implementation (PR #613) was explored but closed pending clearer requirements and a better design.

Open Questions

These need to be resolved before implementation:

  1. Consent / opt-in: Do donors need to explicitly opt in to being listed? OpenCollective and GitHub Sponsors both show donor names publicly by default, but appearing on the MapLibre website may feel meaningfully different. We need a clear stance — e.g., "public donors are assumed to consent" vs. "an explicit opt-in mechanism is required."

  2. Placement: Where should the donor list live? The /sponsors page is the natural home, but placement matters — the draft PR inserted the section between the Individual Donations CTAs and the In-Kind Donations section, which disrupted the page flow. Should it appear at the bottom of /sponsors? On project pages (GL JS, Native) as well? Somewhere else entirely?

  3. Minimum threshold: What donation amount qualifies for listing? (The draft used >$10 USD total on OpenCollective to filter prank/test entries — is this appropriate?)

Requirements

Data Sources
  • OpenCollective: BACKER members via public REST API (/members/all.json)
  • GitHub Sponsors: Organization.sponsors via GitHub GraphQL API, authenticated with GITHUB_TOKEN (available automatically in GitHub Actions)
  • Data fetched at build time — no client-side API calls (consistent with existing GitHub stats pattern)
  • Fail gracefully (empty list) if either API is unavailable
Filtering & Sorting
  • Exclude entries below the agreed minimum threshold
  • Deduplicate by name across both sources
  • Sort by total amount donated (descending), then by recency
Display
  • Name only — no avatars, logos, or donation amounts
  • Section renders nothing (no empty shell) when the donor list is empty
  • Include a brief thank-you line and CTA links to both donation platforms
Design Constraints
  • Must be visually muted and secondary — clearly not an interactive element
  • Do not use blue rounded rectangles or button styling — those are reserved for CTAs
  • Should be compact and unobtrusive — a flowing inline list or small text list, not a badge/card grid
  • Must not interrupt the primary flow of the page it appears on

Acceptance Criteria

  • Consent/opt-in policy is defined and documented
  • Placement is decided and does not disrupt page flow
  • Minimum donation threshold is agreed upon
  • Donor list section is visually distinct from interactive UI elements
  • Build succeeds gracefully when APIs are unreachable (empty list, no build failure)
  • GITHUB_TOKEN requirement is documented for contributors running local builds
  • Design reviewed and approved before merge

References

  • PR #613 (closed): draft implementation with screenshots showing design issues

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the closed PR #613 and the existing /sponsors page flow. Resolve the consent policy, placement, and minimum threshold before implementation; done requires design approval, documented GITHUB_TOKEN usage, graceful empty results when APIs fail, and a reviewed donor section that does not disrupt the page.

Written by the indexing model from the issue text.

Assessment

Tech stack
github, github-actions
Domain
build-system, content, web-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.