airflow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aizhamal Nurmamat kyzy <aizha...@google.com.INVALID>
Subject Re: [Proposal] Component changes for Apache Airflow
Date Thu, 02 May 2019 23:03:42 GMT
+1 on Ash's points.

is it possible to disable labels to begin with?
> I see no great benefit in having components with labels.
> We can do just fine with only components.
>
I think we need to keep the labels for searchability and findability: eg.
user creates an issue with 'redshift' label within 'aws-operators', and we
want to allow everyone to look those issues up if they care only about
redshift. Also GSoC, GSoD, and other things that don't necessarily map to
components.

I also think that the "version" field should be mandatory.
> It's important to know against which airflow version the ticket is
> reported.
>
+1 here. Users must know the version when they file a bug, and if those
bugs get fixed with newer versions, it would allow us to go back and close
those issues more efficiently. Any other thoughts?

Best,
Aizhamal




>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Wednesday, May 1, 2019 12:17 PM, Ash Berlin-Taylor <ash@apache.org>
> wrote:
>
> > This sounds like a fantastic idea.
> >
> > I would add to the list:
> >
> > -   Remove labels that should be components (we have a gcp label and a
> gcp component for instance) - having duplication in them is confusing
> > -   Possibly use a label to indicate when an issue has already been
> triaged (to avoid duplicated effort)
> >
> >     We can delete components, but labels are Jira wide so apply across
> every ASF project so we can't do much about what appears in the
> auto-complete. This would be the place where a Triager's Guide would come
> in to play.
> >
> >     -ash
> >
> >
> > > On 1 May 2019, at 00:26, Aizhamal Nurmamat kyzy
> aizhamal@google.com.INVALID wrote:
> > > Hello everyone,
> > > I would like to propose a few changes for the Apache Airflow JIRA. The
> > > reason behind this proposal is that the set of components is
> disorganized,
> > > and it could use some improvements to track the status of the project
> and
> > > improve the Jira triage.
> > > I outlined all the proposed changes (and reasons behind) in this
> document
> > > [1]. Please take a look and comment if you have any suggestions. I also
> > > created a public dashboard to to be able to look into some statistics
> > > around JIRA issues [2].
> > > The high level overview of changes is:
> > >
> > > -
> > >
> > > Clean up components that are typos, duplicates or overly specific
> > >
> > > ------------------------------------------------------------------
> > >
> > > Make component a required field when filing an issue in JIRA
> > >
> > > -------------------------------------------------------------
> > >
> > > Give a component to all issues that don’t have one at the moment
> > >
> > > -----------------------------------------------------------------
> > >
> > > Ensure that no new components are created unless it’s discussed by the
> > > community
> > > For further details, please take a look at the doc[1], and share your
> > > thoughts on it.
> > > Thank you,
> > > Aizhamal
> > > [1]
> > >
> https://docs.google.com/document/d/1gticSJ7LgD15XHgQhEP78-Ky38Er_NnMlarIvSQ8NYM/edit?usp=sharing
> > > [2]
> > >
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12333933
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message