Proposal: Pull requests and sub-proposals

Status: Open.

Pull requests: None yet.

What changes

Proposals get two more fields next to the status:

• Pull requests: the links to the pull requests that implement the proposal, each shown with its state (open, merged or closed).
• Part of: optionally, a main proposal this one belongs to, used only when grouping helps (for example a large change built in several steps). A main proposal lists its parts automatically, each with its status.

Why

Proposals are becoming the place where every change to Agpedia that readers or contributors will notice is described, discussed and followed until it is live, software changes included; changes nobody can see, such as internal fixes, need none. A proposal is only finished when the change is live. Linking the pull requests shows readers where the work stands without leaving Agpedia, and every change gets a page that release notes on the blog can link to.

How it works

• Anyone who can edit the proposal can add a pull request link. The state of each pull request is checked automatically, so a merged pull request shows as merged.
• When all of a proposal's pull requests are merged and deployed, an admin moves it to Applied.
• Sub-proposals live at addresses under their main proposal, for example meta/proposals/wikidata/wikidata-id under meta/proposals/wikidata.
• The fields are general enough that other kinds of items, such as bug reports, can use them later.

Technical notes

Stored in the same properties.proposal field as the status: pullRequests (list of URLs on the Agpedia software repository) and parent (the slug of the main proposal). Pull request states come from the GitHub API, cached and refreshed periodically. The main proposal's list of parts is a query over pages whose parent points to it.