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/> > >
