This is an automated email from the ASF dual-hosted git repository.
wankun pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/griffin.git
The following commit(s) were added to refs/heads/master by this push:
new 6784dc0 [GRIFFIN-317] Define guidelines for Griffin Project
Improvement Proposals (GPIP)
6784dc0 is described below
commit 6784dc047c1a2904b4f752a6e9538194f67a1d5a
Author: chitralverma <[email protected]>
AuthorDate: Thu Jan 16 15:20:21 2020 +0800
[GRIFFIN-317] Define guidelines for Griffin Project Improvement Proposals
(GPIP)
**What changes were proposed in this pull request?**
Taking inspiration from Apache Spark, this ticket aims to define guidelines
for Griffin Project Improvement Proposals (GPIP).
The purpose of a GPIP is to inform and involve the user community in major
improvements to the Apache Griffin codebase throughout the development process,
to increase the likelihood that user needs are met.
A GPIP aims to discuss the design and implementation of major features and
changes in a collaborative manner. These major features must not be small/
incremental/ wide-scoped, as these features can be resolved by normal Jira
process.
**Does this PR introduce any user-facing change?**
No
**How was this patch tested?**
Not Applicable
Author: chitralverma <[email protected]>
Closes #563 from chitralverma/griffin-pip-template.
---
griffin-doc/dev/griffin-pip.md | 103 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 103 insertions(+)
diff --git a/griffin-doc/dev/griffin-pip.md b/griffin-doc/dev/griffin-pip.md
new file mode 100644
index 0000000..ce07e70
--- /dev/null
+++ b/griffin-doc/dev/griffin-pip.md
@@ -0,0 +1,103 @@
+<!--
+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.
+-->
+# Griffin Project Improvement Proposals (GPIP)
+
+Taking inspiration from [Apache Spark's improvement proposal
guide](https://spark.apache.org/improvement-proposals.html),
+> The purpose of a SPIP is to inform and involve the user community in major
improvements to the Spark codebase throughout
+> the development process, to increase the likelihood that user needs are met.
+
+### What is GPIP?
+> This guideline should be used for significant user-facing or cross-cutting
changes, not small incremental improvements.
+> When in doubt, if a committer thinks a change needs a proposal, it does.
+
+A GPIP is similar to a product requirement document commonly used in product
management that must do the following,
+ - A JIRA ticket labelled "GPIP" (prefix title with **[GPIP]**) proposing a
major improvement or change to Apache Griffin,
+ - The Template must follow the points defined
[below](#GPIP-document-template),
+ - Discussions on the JIRA ticket and
[[email protected]](mailto:[email protected]) list must be done to
evaluate
+ the proposal
+
+### Who can submit a GPIP?
+
+#### GPIP tasks by role
+
+| Role | GPIP Task |
+|:-------------|:-----------|
+| Member | Discuss the changes for which a GPIP can be submitted or they
can submit a GPIP directly |
+| Contributor | Other than Member tasks above, contributors can help with
discussions regarding the technical feasibility of a GPIP |
+| Committer | Other than Contributor tasks above, committers can help with
discussions regarding whether a GPIP aligns with long-term project goals, and
by shepherding GPIPs|
+
+Taking terms from the [Apache Spark's improvement proposal
guide](https://spark.apache.org/improvement-proposals.html),
+
+> ##### Proposal Author
+> Any community member who authors an improvement proposal and is committed to
pushing the
+>change through the entire process. SPIP authorship can be transferred.
+
+> ##### Proposal Shepherd
+> A PMC member who is committed to shepherding the proposed change throughout
the entire process.
+> Although the shepherd can delegate or work with other committers in the
development process,
+> the shepherd is ultimately responsible for the success or failure of the
proposal.
+
+### What is the process of proposing a GPIP?
+1. Anyone may submit a GPIP, i.e. raise the JIRA ticket, as per the [GPIP
tasks by role table](#gpip-tasks-by-role).
+When submitting a proposal, ensure that you are willing to help, at least with
discussion ([check GPIP author role](#proposal-author)).
+2. After a GPIP is submitted, the author should notify the community about the
same at [[email protected]](mailto:[email protected]).
+This will initiate discussions on the JIRA ticket.
+
+**Note:** If a GPIP is too small/ incremental/ wide-scoped and should have
been done through the normal JIRA process,
+ a committer should remove the GPIP label and notify the author.
+
+#### GPIP Document Template
+A GPIP document is a short document with a few questions, inspired by the
+ [Heilmeier Catechism](https://en.wikipedia.org/wiki/George_H._Heilmeier):
+
+>1. What are you trying to do? Articulate your objectives using absolutely no
jargon.
+>2. What problem is this proposal NOT designed to solve?
+>3. How is it done today, and what are the limits of current practice?
+>4. What is new in your approach and why do you think it will be successful?
+>5. Who cares? If you are successful, what difference will it make?
+>6. What are the risks?
+>7. How long will it take?
+>8. What are the mid-term and final “exams” to check for success?
+
+**Appendix A.** Proposed API Changes. An Optional section defining APIs
changes, if any. Backward and forward
+compatibility must be taken into account.
+
+**Appendix B.** Optional Design Sketch: How are the goals going to be
accomplished? Give sufficient technical detail to
+allow a contributor to judge whether it’s likely to be feasible. Note that
this is not a full design document.
+
+**Appendix C.** Optional Rejected Designs: What alternatives were considered?
Why were they rejected? If no alternatives
+ have been considered, the problem needs more thought.
+
+#### Notes regarding GPIP Discussions and process
+
+ - All discussions of a GPIP should take place publicly, preferably the
discussion should be on the JIRA ticket directly.
+ - Any discussions that happen offline should be made available online for the
community via meeting notes summarizing
+ the discussions.
+ - During these discussions, at least 1 shepherd should be identified among
PMC members.
+ - Once the discussion settles, the shepherd(s) should call for a vote on the
GPIP moving forward on the
+ [[email protected]](mailto:[email protected]) list. The vote
should be open for at least 72 hours and follows
+ the typical Apache vote process and passes upon consensus (at least 3 **+1**
votes from PMC members and no **-1** votes from PMC members).
+ - If a committer does not think a GPIP aligns with long-term project goals or
is not practical at the point of proposal
+ submission, the committer should explicitly vote **-1** for the GPIP and give
technical justifications for the same.
+ - The Community should be notified of the vote result at
[[email protected]](mailto:[email protected]) list.
+ - If no PMC members are committed to shepherding a GPIP within a month, the
GPIP is considered rejected.
+
+### What is the process of implementing a GPIP?
+Implementation should take place via the [standard
process](https://griffin.apache.org/docs/contribute.html) for code
+ changes. Changes that require GPIPs typically also require design documents
to be written and reviewed.
\ No newline at end of file
