This is being done because Projects v1 requires repo write access, a serious limitation for letting people use it. Projects v2 isn't a great option because it lacks event support. Labels are pretty stable in GitHub, so this switches to that. Note this assumes we're fine renaming "decision: accepted" -> "proposal accepted", etc. There are two reasons for this: 1) To make it clear that this is a proposal-specific label, versus something like an issue for leads label. 2) Removing the colon because it was causing trouble with yaml syntax. This also adds the "proposal draft" label, mainly to complete the taxonomy. I was considering whether this should be a proposal itself, but it feels like maybe it's not necessary because it's a fairly low-key infrastructure change, and I'm not sure how much people were relying on the project board anyways. I tested this in a personal repo, basically just poking at https://github.com/jonmeow/test/pull/2
3.1 KiB
TODO
Table of contents
TODO: Initial proposal setup
TIP: Run
./new_proposal.py "TITLE"to do new proposal setup.
- Copy this template to
new.md, and create a commit. - Create a GitHub pull request, to get a pull request number.
- Add the
proposal draftlabel to the pull request.
- Add the
- Rename
new.mdto/proposals/p####.md, where####should be the pull request number. - Update the title of the proposal (the
TODOon line 1). - Update the link to the pull request (the
####on line 11). - Delete this section.
TODOs indicate where content should be updated for a proposal. See Carbon Governance and Evolution for more details.
Problem
TODO: What problem are you trying to solve? How important is that problem? Who is impacted by it?
Background
TODO: Is there any background that readers should consider to fully understand this problem and your approach to solving it?
Proposal
TODO: Briefly and at a high level, how do you propose to solve the problem? Why will that in fact solve it?
Details
TODO: Fully explain the details of the proposed solution.
Rationale
TODO: How does this proposal effectively advance Carbon's goals? Rather than
re-stating the full motivation, this should connect that motivation back to
Carbon's stated goals and principles. This may evolve during review. Use links
to appropriate sections of /docs/project/goals.md,
and/or to documents in /docs/project/principles.
For example:
- Community and culture
- Language tools and ecosystem
- Performance-critical software
- Software and language evolution
- Code that is easy to read, understand, and write
- Practical safety and testing mechanisms
- Fast and scalable development
- Modern OS platforms, hardware architectures, and environments
- Interoperability with and migration from existing C++ code
Alternatives considered
TODO: What alternative solutions have you considered?