Description
The README mentions:
All content must start with a
Content Proposal
. This will be in the form of a GitHub issue using theContent Proposal
issue template.
and it differentiates from requests as it seems to expect a [requested]
issue before that:
Look through the requested issues and find something that you feel uniquely capable of writing
This also seems to be strengthened by the Content Proposal
issue template which expects a Request Issue
.
However, it seems that the [approved]
label is typically put on accepted content requests (at least after this repo was opened for Community Contributions).
Furthermore, both #45 and #49 didn't seem to need a proposal issue, the request (followed by the future author being assigned to it) seemed to be sufficient.
Therefore, I propose to remove the distinction between content proposals. I would suggest to:
- Add an issue template for requests (or remove the
Request Issue
field from theContent Proposal
template). - Create a Pull Request template from the current
Content Proposal
template since it makes sense for PRs to mention the request issue (and all other fields from there). - Clean up the tags so only the tags actually being used are listed. For example, I haven't seen any usage of the
[in progress]
label. - Adapt the README to reflect this workflow.