Yeah. It's just normal that people do not read instructions. But the more
we repeat the message in various places, the more people will notice. It's
just a matter of being persistent and patient.
How about the other part about lightweight process? Anyone has opinion on
that? I think we should at l
The issue template for "Question or Support request" says this:
--
**Do not use issues for support requests or general help queries**
Please ask on one of our mailing lists, or in our Slack channel. See the "Ask a
question" section of http://airflow.apache.org/community/
Issues which are not bug
I saw that some individual issues are being migrated but we have not agreed
first of all how we are handling the migration, how we split the work and
most of all - how we are handling the issues afterwards.
I think we have a unique chance to work out, document and follow a
lightweight process and
Hi guys,
> I think the problem here is not the tool like Jira but the way we are using
> it.
I fully agree with Michał that there should be some rules / guidelines
agreed among community to follow.
> Automation can help here. Auto-labelling and good templates might be
> a good start. We should e
Thanks for that Michał I think those are very good points. And I would love what
others think about it. Here are my thoughts.
> I think the problem here is not the tool like Jira but the way we are using
> it.
Agreed. Good point. I think we have a chance to make a fresh start and
design the
proce
sues from my work computer!
>
> Damian
>
> -Original Message-
> From: Jarek Potiuk
> Sent: Monday, March 16, 2020 10:25
> To: dev@airflow.apache.org
> Subject: Re: [DISCUSS] Stop using Jira (since we aren't using it properly)
>
> Yep. Vote and switch :)
>
tiuk
Sent: Monday, March 16, 2020 10:25
To: dev@airflow.apache.org
Subject: Re: [DISCUSS] Stop using Jira (since we aren't using it properly)
Yep. Vote and switch :)
On Mon, Mar 16, 2020 at 3:12 PM Tomasz Urbaszek
wrote:
> Yes, vote and switch.
>
>
> On Mon, Mar 16, 2020 at 3:
Yep. Vote and switch :)
On Mon, Mar 16, 2020 at 3:12 PM Tomasz Urbaszek
wrote:
> Yes, vote and switch.
>
>
> On Mon, Mar 16, 2020 at 3:06 PM Ash Berlin-Taylor wrote:
>
> > Yeah, Superset is using GIthub Issues instead of Jira.
> >
> > This is probably the third or fourth time the Github/Jira su
Yes, vote and switch.
On Mon, Mar 16, 2020 at 3:06 PM Ash Berlin-Taylor wrote:
> Yeah, Superset is using GIthub Issues instead of Jira.
>
> This is probably the third or fourth time the Github/Jira subject has been
> brought up, something just finally pushed me over the edge of "why are we
> bo
VOTE and switch.
On Mon, Mar 16, 2020 at 2:06 PM Ash Berlin-Taylor wrote:
> Yeah, Superset is using GIthub Issues instead of Jira.
>
> This is probably the third or fourth time the Github/Jira subject has been
> brought up, something just finally pushed me over the edge of "why are we
> botherin
Yeah, Superset is using GIthub Issues instead of Jira.
This is probably the third or fourth time the Github/Jira subject has been
brought up, something just finally pushed me over the edge of "why are we
bothering with this" today.
It seems like we have fairly broad agreement this time. AIP wort
+1 for Github issues. Github allows creating issue template (feature,
bug, custom) so this should help. And I have a feeling that GH issues
are indexed better than JIRA tickets.
JIRA gives the possibility to interlink between ASF projects but I
don't think is something important for us.
I've also
+1
One other problem it would help us solve is *closing issues where the PR is
merged*. This is one of the pain-points for us, some of the JIRA issues are
open even though the PR is merged.
With Github issues, if there is a PR solving an existing issue just adding
"fixes #20" would close that iss
And for the clean state -> I am rather for a "brute" approach. I.e. review
them and only move those that people reviewing them find necessary to keep.
Mark the others as stale, add comment "we are closing them in a week -
please create a github issue if you want to keep it" and close the
remaining
> Maybe we could have some clear guidelines on when the issues should be
> created - only when there is a problem someone wants to report and we have no
> code for it yet.
Yes, exactly. If you want to submit a fix directly: great, open a PR; if you
want to report it but arent able/willing to su
I am all for it. We can easily rely just on PR# to uniquely identify commit
rather than Github issue id - and remove the requirement to have an issue
altogether? The issue can be added optionally but it should not be a
requirement.
I think PRs and Issues are pretty equivalent when you follow the "
> I'm totally in favor of not using Jira, as they are serving hardly any
> purpose other than just a useless step before creating a PR. However, I don't
> think to make a GitHub issue mandatory is also a good step, as eventually,
> it'll meet the same fate of being opened just before opening a P
I'm totally in favor of not using Jira, as they are serving hardly any
purpose other than just a useless step before creating a PR. However, I
don't think to make a GitHub issue mandatory is also a good step, as
eventually, it'll meet the same fate of being opened just before opening a
PR.
So IMO
Yeah, Github issues are far from perfect, it's mainly just I feel we have a lot
of "busy-work" in our process that is no longer really serving much benefit to
us as a community.
-a
On Mar 16 2020, at 11:35 am, Bolke de Bruin wrote:
> Honestly, I think both suck. So I can go either way
>
>
> On
Honestly, I think both suck. So I can go either way
On 16 March 2020 at 12:33:27, Ash Berlin-Taylor (a...@firemirror.com) wrote:
The subject pretty much says it all.
We aren't using Jira very well in most cases, and the requirement for a
Jira ticket for a code change leads to people just creati
The subject pretty much says it all.
We aren't using Jira very well in most cases, and the requirement for a Jira
ticket for a code change leads to people just creating new Jira tickets, rather
than searching to see if there already exists a ticket for that feature.
For example: https://issues.a
21 matches
Mail list logo
