Thanks everyone for the valuable inputs. As I can see, all of us agree that we need some sort of guidelines.
As Sid suggested, I created PR: https://github.com/apache/ozone/pull/5372 updating contribution and pull request template. Please take a look and provide feedback. @ayushtkn, as you said, closing tickets (not having much details) is a community decision. We can come back to it later once we have guidelines in place. @weichiu, It is a good idea to create something like OIP (Ozone improvement proposal) but I think we are far from there. I'll suggest starting with a simple guideline (as I mentioned above) first and over time iteratively improving it to reach OIP. Thanks, Hemant On Thu, Sep 21, 2023 at 2:37 PM Wei-Chiu Chuang <weic...@apache.org> wrote: > Might be irrelevant but I just want to point out that other open source > projects have more stringent requirements when it comes to filing a jira. > > Infact, Kafka has KIP (Kafka Improvement Proposal) Yunikorn has YIP > (Yunikorn Improvement Proposal) and the proposers need to have sufficient > support (which means much more communication) before moving forward with > the development. Not saying we need to have an OIP, but having that extra > level of communication and consensus seems healthy. > > On Thu, Sep 21, 2023 at 9:54 AM Hemant Kumar <hem...@apache.org> wrote: > > > Hi Ozone Community, > > As we discussed in the last ozone community meeting about Ozone jiras and > > PRs not having enough information/details. Which makes it harder to > > understand when people outside the project look at them. Hence to make it > > better, I'm proposing the following guideline. > > Please take a look and let me know your thoughts. Once we are in > agreement, > > I'll add them to Ozone onboarding wiki. > > > > *Jira description guideline:* > > * Title: Title should be a one liner stating the problem. > > * Description: > > * What is the problem? Is it a feature, improvement or bug? Add as > > many details as possible and related design doc and discussion. > > * For new features, add as many details as possible. If it is part of > > the big feature, attach parent jira. > > * For improvement, add the value it will bring. Is it an > optimization, > > code simplification or something else? > > * For bugs, add steps to reproduce it. Where the root cause is > unknown > > and needs investigation, it would be great to update the jira description > > or add the summary once the root cause is identified. > > * Jira examples: > > * https://issues.apache.org/jira/browse/HDDS-9272 > > * https://issues.apache.org/jira/browse/HDDS-9322 > > * https://issues.apache.org/jira/browse/HDDS-9291 > > * https://issues.apache.org/jira/browse/HDDS-8940 > > * https://issues.apache.org/jira/browse/HDDS-9282 > > > > *PR description guideline:* > > * Title: Title should provide a one sentence overview of the purpose of > the > > PR. > > * Description: > > * What changes are proposed in the PR? and Why? > > * Provide as much context and rationale for the pull request as > > possible. It could be copy-paste from the jira's description if the jira > is > > well defined. > > * If it is complex code, describe the approach used to solve the > issue. > > If possible attach design doc, issue investigation, github discussion, > etc. > > * Testing: > > * How is the code tested? > > * Attach CD/CI run on the personal git repo. > > > > * PR examples: > > * https://github.com/apache/ozone/pull/3980 > > * https://github.com/apache/ozone/pull/5265 > > * https://github.com/apache/ozone/pull/4701 > > * https://github.com/apache/ozone/pull/5283 > > * https://github.com/apache/ozone/pull/5300 > > * https://github.com/apache/ozone/pull/5301 > > > > Thanks, > > Hemant > > >