Marked in my calendar On Tue, Nov 3, 2020 at 3:33 AM Vikram Koka <[email protected]> wrote:
> Hi all, > > I wanted to invite you to a follow-up call on the Airflow issue triage > process. > > *Date*: November 5th > *Time*: 8.30--9.30 AM Pacific / 4.30 - 5.30 PM GMT > *Zoom link*: > https://astronomer.zoom.us/j/96659511795?pwd=MVd2VjVKVEdtRG5vTGN3VXNXZEJPdz09 > <https://www.google.com/url?q=https://astronomer.zoom.us/j/96659511795?pwd%3DMVd2VjVKVEdtRG5vTGN3VXNXZEJPdz09&sa=D&source=calendar&ust=1603062773118000&usg=AOvVaw3NILdQFS5CXdYmOD1HuvpK> > > Agenda for today's call: > > - Follow-up feedback from decisions of last call > - Learnings from issues currently being processed > - Discuss triage party > > > Best regards, > > Vikram > > > > > On Tue, Oct 27, 2020 at 1:07 PM Jarek Potiuk <[email protected]> > wrote: > >> Thanks Vikram! >> >> I will try to join the next meeting and see if I can help with anything >> (providing that the CI and providers will not be eating all of my time. >> >> J. >> >> On Tue, Oct 27, 2020 at 4:51 AM Vikram Koka <[email protected]> wrote: >> >>> Hi all, >>> >>> I have updated our meeting notes document to summarize the discussion >>> from our call last week. Sorry that it took so long. >>> Thank you all who joined the call. >>> >>> To all those who attended, can you please double-check and add if I >>> missed anything? >>> To all those who didn't join, if you disagree to anything covered, >>> please voice your opinion. >>> Also, please let me know if you want to include anything in Next call's >>> Agenda. >>> *Key Decisions:* >>> >>> - >>> >>> Labels >>> - >>> >>> Purpose: Labels should be non-temporal in nature and should >>> indicate the following two elements: >>> - >>> >>> “Kind” should indicate “what kind of issue it is” i.e. “bug”, >>> “feature”, “doc change”, “performance improvement” >>> - >>> >>> “Area” should indicate the area of the code: Scheduler, >>> Webserver, etc. One use of the “Area” is to say who/which group of >>> people >>> should review the PR. For example, Daniel filters by “area/kubernetes” >>> which makes it easier to find it. >>> >>> >>> >>> - >>> >>> Products should be folded into “area”. So, “area/helm-chart” >>> - >>> >>> “Need” which is a temporary state for an issue, before the above >>> two labels are assigned. Primarily, until one or more committers can >>> weigh >>> in, though some may need discussion on the mailing list. >>> - >>> >>> What should they be: An initial non-exhaustive list of all the >>> labels is below. >>> - >>> >>> kind/bug, kind/feature, kind/documentation, kind/performance >>> - >>> >>> kind/enhancement: this is an improvement to an existing feature. >>> This is somewhat subjective vs. a new feature, but this is useful to >>> generate a change log as part of a release. >>> >>> >>> >>> - >>> >>> area/webserver, area/scheduler, area/executor, area/providers >>> (area/providers/google, area/providers/amazon, area/providers/azure, >>> area/providers/other) >>> - >>> >>> Currently, we also have area/providers/apache, but that should be >>> replaced by area/providers/other >>> - >>> >>> area/webserver - includes User Interface (and UX) >>> - >>> >>> area/docker-image >>> - >>> >>> area/kubernetes - can be used along with other areas, to reflect >>> that this touches kubernetes. For example, an issue could have both: >>> area/executor and area/kubernetes >>> - >>> >>> area/breeze >>> - >>> >>> area/helm-chart >>> - >>> >>> area/core - covers anything else >>> - >>> >>> Others to be deprecated include: area/logging which would now be >>> included in area/core >>> >>> >>> >>> - >>> >>> need/discussion: some method to get discussion from committers, >>> but is not specifically an issue for a particular area. >>> - >>> >>> Example: Issue opened regarding “deprecating mssql hook”. >>> https://github.com/apache/airflow/issues/8458 Should we still do >>> this or not? Not necessarily, something that needs to be on the dev >>> mailing >>> list. >>> - >>> >>> >>> - >>> >>> need/triage: default starting point for an issue. >>> - >>> >>> “Need” labels are intended to be temporary, until they can be >>> processed. These should not be long lived. Only needed until one or >>> more >>> committers can weigh in. >>> >>> >>> >>> - >>> >>> What labels should not be touched because of release management: >>> “pinned” - only relevant for PRs, not for issues. >>> - >>> >>> Labels for community development: Good-first-issue, hacktoberfest >>> - >>> >>> >>> - >>> >>> Epic? - Let’s use milestones or projects for Epics. Let’s not >>> clutter up the label list with temporary labels for AIPs or Epics. >>> >>> >>> >>> - >>> >>> How / when assigned: >>> - >>> >>> Automatically any new issue will be added a “need/triage” label. >>> And then when one of “us” is going over the new issues, the labels >>> from >>> this document will be added/applied. >>> >>> >>> >>> - >>> >>> Milestones >>> - >>> >>> Purpose: Temporal in nature. Useful for release management >>> purposes. Will generally be used to represent releases (targets) >>> - >>> >>> Examples: What issues do we want to get into a particular >>> release? Or, what releases do we want to backport issues to? >>> - >>> >>> Feature releases - may need a milestone such as 2.1 >>> - >>> >>> Patch releases - may be more Kanban style, but may have a >>> milestone as well such as 2.0.1 >>> - >>> >>> Milestone on a PR implies: This PR should be merged into that >>> particular release >>> - >>> >>> Milestone on an Issue: Target issue resolution for that release. >>> - >>> >>> What should they be: >>> - >>> >>> Right now, useful milestones: 2.0beta1, 2.0beta2, 2.0rc1, 1.10.13 >>> (critical bug fixes only) >>> - >>> >>> Providers will be independently versioned and be in small >>> releases - so potentially can just use kanban style. >>> >>> >>> >>> - >>> >>> Priority >>> - >>> >>> Purpose: Yes, let’s use priorities. >>> - >>> >>> What should they be: Google vs. Kubernetes vs. other. >>> - >>> >>> Let’s use Kubernetes style priorities, as opposed to the Google >>> style priorities, since they are easier to understand for most people. >>> - >>> >>> This is primarily for prioritization and release management. >>> >>> >>> *Next steps:* >>> >>> - >>> >>> Update google doc - Vikram >>> - >>> >>> Send to dev list - Vikram >>> - >>> >>> Follow-up call next Tuesday? - Vikram to schedule >>> - >>> >>> Investigate applying these by next call - Paola >>> - >>> >>> Discuss Tooling in the next call. Triage party proposed by Kamil. >>> >>> >>> >>> *Doc links*: >>> *Meeting notes*: >>> https://docs.google.com/document/d/1Fx46SoOnNLiqZKtrC-tOHj3zFlZfQwWuR2LRFXJnWqw/ >>> *Original doc*: >>> https://docs.google.com/document/d/1jqmXO6mGZzHkhuvISedQVnhyc37V_iz00hokdMuoFaI/ >>> >>> Best regards, >>> >>> Vikram >>> >>> >>> >>> >> >> -- >> >> Jarek Potiuk >> Polidea <https://www.polidea.com/> | Principal Software Engineer >> >> M: +48 660 796 129 <+48660796129> >> [image: Polidea] <https://www.polidea.com/> >> >> -- Jarek Potiuk Polidea <https://www.polidea.com/> | Principal Software Engineer M: +48 660 796 129 <+48660796129> [image: Polidea] <https://www.polidea.com/>
