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
