docs(incubator): adopt ‘contribution’ terminology; refine proposal template (#67)

• docs(incubator): adopt ‘contribution’ terminology; refine proposal template

Rename donation/donor to contribution/contributing organization across all English content, following the terminology used by peer foundations (CNCF’s legal instrument is the Contribution Agreement; Apache’s is the Software Grant). ‘Contribution’ also matches our legal reality: the default SGA model is license-not-assignment, so the contributing organization keeps copyright — nothing is ‘donated’ in the property-transfer sense. Chinese text keeps 捐赠, which carries no such weight in domestic usage (consistent with OpenAtom).

Renames: Donation Proposal -> Contribution Proposal; Donor -> contributing organization; Donation scope -> Contribution scope; Quick Start for Donors -> Quick Start for Contributing Projects; Donation & Formal Acceptance Process -> Contribution & Formal Acceptance Process. The SGA (Software Grant Agreement) name is unchanged — ‘grant’ is the neutral legal term of art.

Also fold in four template refinements from comparing against the Apache Incubator podling proposal template:

• Project Description now asks for a single-sentence summary first, reusable in the acceptance announcement and project list
• New ‘Developer independence’ field: salaried-vs-independent developer ratio and the organization’s commitment if priorities shift (addresses the salaried-developer risk; feeds the reduced-single-party-dependence graduation dimension)
• Known risks now explicitly lists cryptographic functionality, so export-compliance surfaces at proposal time instead of during IP clearance
• Template note: write N/A where a field does not apply

• docs(incubator): contributing party as umbrella term; scope project contribution

Address review findings on the terminology rename:

1. ‘contributing organization’ silently excluded individual contributors from operative texts (COI recusal, SGA representations, checklist, runbooks, trademark return). Replace with the defined umbrella term ‘contributing party’ (organization or individual); ‘contributing organization’ remains only in organization-specific rules. COI recusal now also covers a TSC member who is the individual contributing party. The developer-independence prompt is conditioned on an organizational contributing party (N/A for individuals).
2. Bare ‘contribution matter/acceptance/process’ could be read as covering ordinary code contributions. Add a Terminology note to both READMEs defining ‘project contribution’ vs day-to-day contributions, and use ‘project contribution …’ phrasing in governance-sensitive passages.
3. Quick Start heading: ‘Quick Start: Contribute a Project’.
4. Acceptance runbook account wording: alliance service account as owner; retain/downgrade/remove existing organization and individual accounts per the approved migration plan.

• docs(incubator): cover individual contributing parties in three residual spots

• ip-checklist: SGA signed by the contributing party (by its authorized signatory where the party is a legal entity) — an individual signs directly and has no separate legal entity
• mentor-guide (EN/CN): the contributing party does not mentor its own project; for organizational parties, members of the organization or its affiliates do not serve — mirrors the COI rule and closes the self-mentoring gap for individuals
• README (EN/CN) graduation dimension 6: maintainership and critical project knowledge not concentrated in a single individual or organization — covers individually contributed projects and the single-maintainer bus factor generally

• docs(incubator): sync acceptance-runbook_CN account-migration wording

The Chinese runbook still prescribed downgrading/removing personal accounts by default, omitting existing organization accounts and the approved migration plan as the controlling basis. Align with the English rule: add the alliance service account as owner; retain, downgrade, or remove existing organization and individual accounts per the approved migration plan.