Merge pull request #27723 from backstage/rugvip/bep-update
beps: update BEP process to merge straight into implementable
This commit is contained in:
Patrik Oldsberg
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: BEP Title
|
||||
status: provisional
|
||||
status: implementable
|
||||
authors:
|
||||
- '@ghost'
|
||||
owners:
|
||||
@@ -13,16 +13,10 @@ creation-date: yyyy-mm-dd
|
||||
|
||||
<!--
|
||||
**Note:** When your BEP is complete, all these pre-existing comments should be removed
|
||||
|
||||
When editing BEPs, aim for tightly-scoped, single-topic PRs to keep discussions focused. If you disagree with what is already in a document, open a new PR with suggested changes.
|
||||
-->
|
||||
|
||||
# BEP: <!-- Your short, descriptive title -->
|
||||
|
||||
<!-- Before merging the initial BEP PR, create a feature issue and update the below link. You can wait with this step until the BEP is ready to be merged. -->
|
||||
|
||||
[**Discussion Issue**](https://github.com/backstage/backstage/issues/NNNNN)
|
||||
|
||||
- [Summary](#summary)
|
||||
- [Motivation](#motivation)
|
||||
- [Goals](#goals)
|
||||
|
||||
+15
-15
@@ -4,19 +4,18 @@ A Backstage Enhancement Proposal (BEP) is a way to propose, communicate and coor
|
||||
|
||||
## Quick start for the BEP process
|
||||
|
||||
1. Discuss the idea with the community and maintainers. Either here on GitHub, Discord, or during community sessions or SIG meetings.
|
||||
Make sure that others think the work is worth taking up and will help review the BEP and any code changes required.
|
||||
1. Discuss the idea with the community and maintainers. Either here on GitHub, Discord, or during community sessions or SIG meetings. Make sure that others think the work is worth taking up and will help review the BEP and any code changes required.
|
||||
1. Make a copy of the [BEP template](./NNNN-template/) directory as `beps/NNNN-short-descriptive-title`, where `NNNN` is the next available number padded with leading zeroes.
|
||||
1. Fill out as much of the YAML metadata as you can.
|
||||
1. Fill out the template as best you can.
|
||||
1. If you want the BEP to be owned by a particular project area, add an entry for the BEP folder to [CODEOWNERS](../.github/CODEOWNERS).
|
||||
1. Create a PR for the BEP. Title it "BEP: <title>". Aim to get the high level goals clarified and avoid getting hung up on specific details. The PR can be merged early and iterated on.
|
||||
1. Once the BEP is ready to be merged, create a [feature issue](https://github.com/backstage/backstage/issues/new?template=feature.yaml) titled "BEP: <title>". Use the summary of the BEP as description and link to the BEP PR in the context section. Once the PR is merged, the issue should be updated to link to the BEP folder instead. This issue will serve as a general discussion issue for the BEP.
|
||||
1. Once the initial BEP is merged you should keep iterating on it until it is ready to leave that `provisional` state. Leaving the `provisional` state is a decision made by the project area maintainers.
|
||||
1. Create a PR for the BEP. Title it "BEP: <title>". Aim to get the high level goals clarified and avoid getting hung up on specific details. The PR can be iterated on until the BEP is ready to be merged.
|
||||
1. The relevant maintainers will review the BEP and provide feedback. It can also be useful to join relevant SIG meetings to discuss the BEP, to help drive it forward faster.
|
||||
1. Let the maintainers know when you think the BEP is ready to be merged. At this point the BEP should be fully filled out and ready for implementation, along with a clear owner for the work.
|
||||
|
||||
Just because a BEP is merged does not mean it is complete or approved for implementation. Any BEP marked as `provisional` is a working document and subject to change.
|
||||
The merging of a BEP means that it is approved for implementation and has an owner that is responsible for said implementation. Up until that point, the author(s) of the BEP are responsible for driving the BEP forward.
|
||||
|
||||
The authors of the BEP are also responsible for driving the BEP forward all the way to implementation. The approval of a BEP is not a commitment to implement it.
|
||||
While the BEP PR is open the owner can open separate PRs to ship experimental features in support of the BEP to help drive the design forward, and these may be merged pending usual PR review. If the BEP is withdrawn or rejected these features should generally be removed.
|
||||
|
||||
## FAQs
|
||||
|
||||
@@ -38,7 +37,7 @@ No, except for plugins that implement core features of Backstage. The BEP proces
|
||||
|
||||
### Can I update an existing BEP?
|
||||
|
||||
Yes! As long as the BEP is still in the `provisional` state you should keep iterating on it. Please keep each PR focused on a single topic and avoid long-running and overly broad PRs.
|
||||
Yes! As long as the BEP is in the `implementable` state. Updates should however only be done based on new discoveries during the implementation phase. If you want to make a significant change to a BEP that has already been approved, you should open a new BEP to replace the old one.
|
||||
|
||||
### Can I update a BEP that was submitted by someone else?
|
||||
|
||||
@@ -48,6 +47,10 @@ Yes! BEPs are living documents and anyone can suggest changes to them. We encour
|
||||
|
||||
Architecture Decision Records (ADRs) are used to document decisions made for development within the Backstage project. They are not intended to be used for proposing new features or changes to Backstage.
|
||||
|
||||
### What's does it mean for a BEP to be in "provisional" state?
|
||||
|
||||
This is a state from an older version of the BEP process, and means that it has been approved as work to be done but the exact design is not yet agreed upon. BEPs in this state need to be moved to the `implementable` state before they can be implemented.
|
||||
|
||||
### My FAQ isn't answered here!
|
||||
|
||||
The BEP process is still evolving!
|
||||
@@ -72,13 +75,10 @@ At the start of each BEP is a YAML document that contains metadata about the BEP
|
||||
|
||||
The BEP Status is critical to clearly communicate the status of each BEP. Each BEP must have its status field set to one of the following values:
|
||||
|
||||
- `provisional`: The BEP has been proposed and is actively being defined. The BEP as been approved by the owning project area maintainers as work to be done.
|
||||
- `implementable`: The approvers have approved this BEP for implementation.
|
||||
- `implemented`: The BEP has been implemented and is no longer actively changed.
|
||||
- `deferred`: The BEP is proposed but not actively being worked on.
|
||||
- `rejected`: The approvers and authors have decided that this BEP is not moving forward.
|
||||
The BEP is kept around as a historical document.
|
||||
- `withdrawn`: The authors have withdrawn the BEP.
|
||||
- `implementable`: The BEP has been approved for implementation by the owning project area maintainers.
|
||||
- `implemented`: The BEP has been implemented.
|
||||
- `deferred`: The BEP was approved but is no longer being actively worked on. If anyone wishes to pick up the work they can move it back to the `implementable` state.
|
||||
- `rejected`: The approvers and authors have decided that this BEP is not moving forward. The BEP is kept around as a historical document.
|
||||
- `replaced`: The BEP has been replaced by a new BEP.
|
||||
|
||||
### Prior Art
|
||||
|
||||
Reference in New Issue
Block a user