Skip to content

Is the proposal issue necessary or not? #58

Open
@danthe1st

Description

@danthe1st

The README mentions:

All content must start with a Content Proposal. This will be in the form of a GitHub issue using the Content 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 the Content 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.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions