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