You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airflow.apache.org by Vikram Koka <vi...@astronomer.io> on 2020/10/27 03:51:09 UTC
[Meeting Notes] Airflow issue triage process - Call #1 - Oct 20 2020
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
Re: [Meeting Notes] Airflow issue triage process - Call #1 - Oct 20 2020
Posted by Jarek Potiuk <Ja...@polidea.com>.
Marked in my calendar
On Tue, Nov 3, 2020 at 3:33 AM Vikram Koka <vi...@astronomer.io> 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 <Ja...@polidea.com>
> 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 <vi...@astronomer.io> 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/>
Re: [Meeting Notes] Airflow issue triage process - Call #1 - Oct 20 2020
Posted by Vikram Koka <vi...@astronomer.io>.
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 <Ja...@polidea.com>
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 <vi...@astronomer.io> 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/>
>
>
Re: [Meeting Notes] Airflow issue triage process - Call #1 - Oct 20 2020
Posted by Jarek Potiuk <Ja...@polidea.com>.
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 <vi...@astronomer.io> 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/>