This is an automated email from the ASF dual-hosted git repository.
tison pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/pulsar.git
The following commit(s) were added to refs/heads/master by this push:
new 77f00413fff [improve][misc] Change PIP issue template (#19832)
77f00413fff is described below
commit 77f00413fffe2132c7bc9b1af740b57e221df6d3
Author: Asaf Mesika <asaf.mes...@gmail.com>
AuthorDate: Fri Apr 28 04:53:11 2023 +0300
[improve][misc] Change PIP issue template (#19832)
---
.github/ISSUE_TEMPLATE/pip.md | 167 +++++++++++++++++++++++++++++++++++++++++
.github/ISSUE_TEMPLATE/pip.yml | 82 --------------------
2 files changed, 167 insertions(+), 82 deletions(-)
diff --git a/.github/ISSUE_TEMPLATE/pip.md b/.github/ISSUE_TEMPLATE/pip.md
new file mode 100644
index 00000000000..520826f8b1c
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/pip.md
@@ -0,0 +1,167 @@
+---
+name: PIP
+about: Submit a Pulsar Improvement Proposal (PIP)
+title: 'PIP-XYZ: '
+labels: PIP
+---
+
+<!--
+RULES
+* Never place a link to an external site like Google Doc. The proposal should
be in this issue entirely.
+* Use a spelling and grammar checker tools if available for you (there are
plenty of free ones)
+
+PROPOSAL HEALTH CHECK
+I can read the design document and understand the problem statement and what
you plan to change *without* resorting to a couple of hours of code reading
just to start having a high level understanding of the change.
+-->
+
+# Background knowledge
+
+<!--
+Describes all the knowledge you need to know in order to understand all the
other sections in this PIP
+
+* Give a high level explanation on all concepts you will be using throughout
this document. For example, if you want to talk about Persistent Subscriptions,
explain briefly (1 paragraph) what this is. If you're going to talk about
Transaction Buffer, explain briefly what this is.
+ If you're going to change something specific, then go into more detail about
it and how it works.
+* Provide links where possible if a person wants to dig deeper into the
background information.
+
+DON'T
+* Do not include links *instead* explanation. Do provide links for further
explanation.
+
+EXAMPLES
+* See [PIP-248](https://github.com/apache/pulsar/issues/19601), Background
section to get an understanding on how you add the background knowledge needed.
+ (They also included the motivation there, but ignore it as we place that in
Motivation section explicitly)
+-->
+
+# Motivation
+
+<!--
+Describe the problem this proposal is trying to solve.
+
+* Explain what is the problem you're trying to solve - current situation.
+* This section is the "Why" of your proposal.
+-->
+
+# Goals
+
+## In Scope
+
+<!--
+What this PIP intend to achieve once It's integrated into Pulsar.
+Why does it benefit Pulsar
+-->
+
+## Out of Scope
+
+<!--
+Describe what you have decided to keep out of scope, perhaps left for a
different PIP/s.
+-->
+
+
+# High Level Design
+
+<!--
+Describe the design of your solution in *high level*.
+Describe the solution end to end, from a birds-eye view.
+Don't go into implementation details in this section.
+
+I should be able to finish reading from beginning of the PIP to here
(including) and understand the feature and
+how you intend to solve it, end to end.
+
+DON'T
+* Avoid code snippets, unless it's essential to explain your intent.
+-->
+
+# Detailed Design
+
+## Design & Implementation Details
+
+<!--
+This is the section where you dive into the details. It can be:
+* Concrete class names and their roles and responsibility, including methods
+* Code snippets of existing code
+* interface names and its methods,
+* ...
+-->
+
+## Public-facing Changes
+
+<!--
+Describe the additions you plan to make for each public facing component.
+Remove the sections you are not changing.
+Clearly mark any changes which are BREAKING backward compatability.
+-->
+
+### Public API
+<!--
+When adding a new endpoint to the REST API, please make sure to document the
following:
+
+* path
+* query parameters
+* HTTP body parameters, usually as JSON
+* Response codes, and for each what they mean.
+ For each response code, please include a detailed description of the
response body JSON, specifying each field and what it means
+ This is the place to document the errors.
+-->
+
+### Binary protocol
+
+### Configuration
+
+### CLI
+
+### Metrics
+
+<!--
+For each metric provide:
+* Full name
+* Description
+* Attributes (labels)
+* Unit
+-->
+
+
+# Monitoring
+
+<!--
+Describe how the changes you make in this proposal should be monitored.
+Don't describe the detailed metrics - they should be at "Public-facing
Changes" / "Metrics" section
+Describe how the user will use the metrics to monitor the feature: Which
alerts they should set up, which thresholds, ...
+-->
+
+# Security Considerations
+<!--
+A detailed description of the security details that ought to be considered for
the PIP. This is most relevant for any new HTTP endpoints, new Pulsar Protocol
Commands, and new security features. The goal is to describe details like which
role will have permission to perform an action.
+
+An important aspect to consider is also multi-tenancy: Does the feature I'm
adding have the permissions / roles set in such a way that prevent one tenant
accessing another tenant's data/configuration? For example, the Admin API to
read a specific message for a topic only allows a client to read messages for
the target topic. However, that was not always the case. CVE-2021-41571
(https://github.com/apache/pulsar/wiki/CVE-2021-41571) resulted because the API
was incorrectly written and did [...]
+
+If there is uncertainty for this section, please submit the PIP and request
for feedback on the mailing list.
+-->
+
+# Backward & Forward Compatability
+
+## Revert
+
+<!--
+Describe a cookbook detailing the steps required to revert pulsar to previous
version *without* this feature.
+-->
+
+## Upgrade
+
+<!--
+Specify the list of instructions, if there are such, needed to perform
before/after upgrading to Pulsar version containing this feature
+-->
+
+# Alternatives
+
+<!--
+If there are alternatives that were already considered by the authors or,
after the discussion, by the community, and were rejected, please list them
here along with the reason why they were rejected.
+-->
+
+# General Notes
+
+# Links
+
+<!--
+Updated afterwards
+-->
+* Mailing List discussion thread:
+* Mailing List voting thread:
diff --git a/.github/ISSUE_TEMPLATE/pip.yml b/.github/ISSUE_TEMPLATE/pip.yml
deleted file mode 100644
index d494d699472..00000000000
--- a/.github/ISSUE_TEMPLATE/pip.yml
+++ /dev/null
@@ -1,82 +0,0 @@
-# Licensed to the Apache Software Foundation (ASF) under one
-# or more contributor license agreements. See the NOTICE file
-# distributed with this work for additional information
-# regarding copyright ownership. The ASF licenses this file
-# to you under the Apache License, Version 2.0 (the
-# "License"); you may not use this file except in compliance
-# with the License. You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing,
-# software distributed under the License is distributed on an
-# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-# KIND, either express or implied. See the License for the
-# specific language governing permissions and limitations
-# under the License.
-
-name: PIP
-title: "PIP-XYZ: "
-description: Submit a Pulsar Improvement Proposal (PIP)
-labels: [ "PIP" ]
-body:
- - type: markdown
- attributes:
- value: |
- Thank you very much for submitting a Pulsar Improvement Proposal
(PIP)! Here are instructions for creating a PIP using this issue template.
-
- Please send a note to the d...@pulsar.apache.org mailing list to start
the discussion, using subject prefix `[DISCUSS] PIP-XYZ`. To determine the
appropriate PIP number XYZ, inspect the [mailing
list](https://lists.apache.org/list.html?d...@pulsar.apache.org) for the most
recent PIP. Add 1 to that PIP's number to get your PIP's number.
-
- Based on the discussion and feedback, some changes might be applied by
the author(s) to the text of the proposal.
-
- Once some consensus is reached, there will be a vote to formally
approve the proposal. The vote will be held on the d...@pulsar.apache.org
mailing list. Everyone is welcome to vote on the proposal, though it will
considered to be binding only the vote of PMC members. It will be required to
have a lazy majority of at least 3 binding +1s votes. The vote should stay open
for at least 48 hours.
-
- When the vote is closed, if the outcome is positive, the state of the
proposal is updated and the Pull Requests associated with this proposal can
start to get merged into the master branch.
- - type: textarea
- attributes:
- label: Motivation
- description: |
- Explain why this change is needed, what benefits it would bring to
Apache Pulsar and what problem it's trying to solve.
- validations:
- required: true
- - type: textarea
- attributes:
- label: Goal
- description: |
- Define the scope of this proposal. Given the motivation stated above,
what are the problems that this proposal is addressing and what other items
will be considering out of scope, perhaps to be left to a different PIP.
- validations:
- required: true
- - type: textarea
- attributes:
- label: API Changes
- description: |
- Illustrate all the proposed changes to the API or wire protocol, with
examples of all the newly added classes/methods, including Javadoc.
- - type: textarea
- attributes:
- label: Implementation
- description: |
- This should be a detailed description of all the changes that are
expected to be made. It should be detailed enough that any developer that is
familiar with Pulsar internals would be able to understand all the parts of the
code changes for this proposal.
-
- This should also serve as documentation for any person that is trying
to understand or debug the behavior of a certain feature.
- validations:
- required: true
- - type: textarea
- attributes:
- label: Security Considerations
- description: |
- A detailed description of the security details that ought to be
considered for the PIP. This is most relevant for any new HTTP endpoints, new
Pulsar Protocol Commands, and new security features. The goal is to describe
details like which role will have permission to perform an action.
-
- If there is uncertainty for this section, please submit the PIP and
request for feedback on the mailing list.
- validations:
- required: true
- - type: textarea
- attributes:
- label: Alternatives
- description: |
- If there are alternatives that were already considered by the authors
or, after the discussion, by the community, and were rejected, please list them
here along with the reason why they were rejected.
- - type: textarea
- attributes:
- label: Anything else?
- - type: markdown
- attributes:
- value: "Thanks for completing our form!"
