[DISCUSS] Stop using Jira (since we aren't using it properly)

[Ash Berlin-Taylor <as...@firemirror.com>]

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.apache.org/jira/browse/AIRFLOW-6987 and https://issues.apache.org/jira/browse/AIRFLOW-2824 (I'm not trying to pick on anyone involved here, I just happened to notice this)
Additionally most of the committers follow a similar path of "work on feature, open Jira ticket just before creating PR".
I am proposing we migrate over to Github issues and drop the requirement to have a jira ticket for PRs.
The one downside is we might get people opening issues for as an "help, how do I do this" -- I think we can address that by having an issue template saying something like "DO NOT OPEN AN ISSUE ASKING FOR HELP - ask on users@ or join slack".
The only other thing Jira currently gives us is the ability mark tasks for "backporting" -- I think we can replace that with Github Milestones. Kaxil or I will happily update the scripts we use to build/check the status of releases.
Thoughts?
The only outstanding question is then what do we do about migrating the issue (do we copy issues across to Github?). Perhaps it might be a good opportunity for a clean slate.
-ash

Re: [DISCUSS] Stop using Jira (since we aren't using it properly)

[Kaxil Naik <ka...@gmail.com>]

VOTE and switch.

On Mon, Mar 16, 2020 at 2:06 PM Ash Berlin-Taylor <as...@apache.org> 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
> bothering with this" today.
> It seems like we have fairly broad agreement this time. AIP worth, or just
> a VOTE and switch over?
> -a
> On Mar 16 2020, at 2:02 pm, Tomasz Urbaszek <tu...@apache.org> wrote:
> > +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 spotted that Apache Superset is proposing SIP (Superset Improvement
> Proposals) on Github issues. T. On Mon, Mar 16, 2020 at 1:08 PM Kaxil Naik
> wrote: > > +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 issue when PR is merged. > > Regards, > Kaxil
> > > > > On Mon, Mar 16, 2020 at 12:04 PM Ash Berlin-Taylor wrote: > > > >
> Maybe we could have some clear guidelines on when the issues should be > >
> created - only when there is a problem so
> meone 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 submit a fix straight away: > >
> create an issue. > > -a > > On Mar 16 2020, at 12:02 pm, Jarek Potiuk > >
> wrote: > > > 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 "work" + "create" +" submit"
> sequence - without the unnecessary hassle. > > You can assign
> milestones/projects/label the same way on both. We actually > > found that
> even when we use them in some other projects - they become > > unnecessary.
> I think eventually there should be a way to convert an issue > > into PR
> :). Even if we want to use Github Projects eventually, we ca
> n add > > PRs to projects similarly as issues. 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. J.
> On Mon, > > Mar 16, 2020 at 12:46 PM Ash Berlin-Taylor wrote: > > 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 we can use Github issues for simple use, which
> > > is to report some > bugs/questions by users, who are not necessarily >
> > planning to create a PR > soon. > Yes, that was what I meant but I wasn't
> > > clear; I was just using "Github > Issues" as a collective product name,
> and > > not saying we need an issue for > every PR. > > -ash > > On Mar 16
> 2020, at > > 11:42 am, Sumi
> t Maheshwari > wrote: > > 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 we can use Github
> issues > > for simple use, which is to report some > > > bugs/questions by
> users, who are not necessarily planning to create a > > PR > soon. Also, if
> we go this route, then we can do the one time Jira > > cleanup > and port
> only valid issues in Github. On Mon, Mar 16, 2020 at > > 5:07 PM Ash >
> Berlin-Taylor wrote: > 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 ei
> ther way > > > > > > On 16 > > March 2020 at 12:33:27, Ash > Berlin-Taylor
> (ash@firemirror.com > (mailto: > > a > sh@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 creating new > > Jira > > tickets, rather
> than searching to see if there already exists a > > ticket for > > that
> feature. > > > For example: > ht > > tps://
> issues.apache.org/jira/browse/AIRFLOW-6987 and > > > >
> https://issues.apache.org/jira/browse/AIRFLOW-2824 (I'm not trying to > >
> > > pick on anyone involved here, I just happened to notice this) > > > > >
> > Additionally most of the committers follow a similar path of "work on > >
> > > feature, open Jira ticket just before creating PR". > > > I am
> proposing we > > > migrate over to Github issues and drop the > requirement
> to have a jira > > > ticket for PRs. > > > The one downside is we might get
> people opening
>  > > > issues for as an > "help, how do I do this" -- I think we can
> address that > > > by having an issue > template saying something like "DO
> NOT OPEN AN ISSUE > > > ASKING FOR HELP - ask > on user > s@ or join
> slack". > > > The only > > other thing Jira currently gives us is > the
> ability mark tasks > for > > "backporting" -- I think we can replace that >
> with Github Milestones. > > > Kaxil or I will happily update the scripts we
> use > to build/check the > > status > of releases. > > > Thoughts? > > >
> The only > outstandi > > ng question is then what do we do about migrating
> > the issue (do > we > > copy issues across to Github?). Perhaps it might
> be a good > opportunity > > > for a clean slate. > > > -ash > > > > > > > >
> > > > > -- Jarek Potiuk > > Polidea | Principal Software Engineer M: +48
> 660 796 129 <+48660796129> > > [image: Polidea] > > > >
>
>

Re: [DISCUSS] Stop using Jira (since we aren't using it properly)

[Jarek Potiuk <Ja...@polidea.com>]

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 least discuss it before we move 100s of issues
to Github without knowing what we are going to do with them.

Just another voice in the discussion: I just got this message from a user
(Slava) who tried to post to the mailing list but had trouble with mailer
only sending HTML (rejected by the discussion group) , and posted it to me
on Slack. I am forwarding it here - to add some thoughts. I do not
necessary think we should do it this way, but maybe this might be something
that we could start our discussion on

>>>>>>>>>>>> Quote from Slava follows

hi still can't send to the mailing list... I gave up as it's too much
trouble..
I'll share my thoughts about the Jira-Github thread.
I think that Airflow is trying to relay on automated process too much.
To me it sounds like at the end the github issues will be a mess just like
the Jira is.

Please see:
https://github.com/pandas-dev/pandas/issues

They have over 3000+ open issues yet it magnificently organised and well
understood by everyone.
no duplications, no hard time finding issues, labels are well used, each
issue is designated to a specific planed release so it's easy to know what
still needed to fix before releasing next version
What they do?

New issues has no label - This basically means "This issue needs triage".
This issues are being processed by authorised members of the community.

Process includes:
0. Making sure it's not duplicated/wrong etc..
1. adding labels
2. adding release milestone (including SomeDay or ContributorsWelcome)
3. adding comments or engage discussion on what is actually needed so that
the person who start working on the issue won't guess.
In airflow the approach is a bit different, it's more like "first open PR
then we'll discuss it".
it's always possible to know which issues haven't been reviewed yet -
simply see the issues without labels or milestone.

J,

On Fri, Mar 27, 2020 at 2:00 PM Ash Berlin-Taylor <as...@apache.org> wrote:

> 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 reports or feature requests (i.e. "how do I get X
> working", or "How do I best do X?") will likely be closed without a
> response.
> --
>
> So they if they read _at all_ they were told in advance that it would be
> closed without a response. You are right that we can at least repeat that
> message when closing anything with the "invalid" label.
>
> On Mar 27 2020, at 6:12 am, Jarek Potiuk <Ja...@polidea.com> wrote:
> > 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 agree between ourselves on how to do it. If we don't do it we
> might end up with a similar mess as we have in JIRA now - just using a
> different tool. For now, we have no rules defined nor best practices for
> how we are handling new issues, how we are labeling them etc. Just to give
> an example (note Ash - I am not criticizing, just showing an example that I
> think we can do better and that we have no common rules around how we deal
> with issues). There was this issue
> https://github.com/apache/airflow/issues/7890 which was closed as invalid
> without any explanation. I think it's not really a good idea. I believe we
> should always, as a rule, state why we are closing an issue even if it is
> invalid. The main reason is that if someone will have a similar issue they
> will be able to find it there or next time we can refer them to such closed
> issues. Issues in GitHub are indexed by Google and I often find solutions
> in already closed issues when there is an explanation - even for invalid
> ones. This is an invaluable source of information that results in many
> fewer issues being open - because people can find solutions before they
> open the issues. I think that was one of the problems with JIRA that it was
> difficult to find similar issues, but with Google indexing Github issues,
> it will happen automatically as long as we provide good explanations and
> answer issues promptly. I believe - reading Karolina's mail - that she is
> willing to help with establishing processes/practices (and I know from
> working with her that it's really helpful to organize it just a bit). At
> the same time we could split the JIRA issues between ourselves in a
> meaningful way and Karolina could help in managing the whole process. WDYT?
> Do you also think this might be a good idea to do it in this way? J. On
> Wed, Mar 25, 2020 at 1:15 PM Karolina Rosół wrote: > 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 explore how we can auto-label the issues > > based on
> subject/description (we could find a bot or extend our > > boring-cyborg
> and it should be rather easy). So whatever we can automate > > without
> adding too much overhead is good. > > As per automation it's always a good
> idea to automate and I'm happy to > explore the labeling subject. > > > We
> won't be able to enforce this but we can definitely encourage it - > > with
> a watchout that we have to be careful not to add unnecessary > friction in
> > > some cases if we make it into a rule. Again - adding PR to >
> CONTRIBUTING.rst > > might be a good idea :) > > Agree :-) > > > Fully
> agree. Though we have to remember that if we cannot automate and > >
> enforce something, we have no mechanisms to make people contributing do >
> it > > other than encouragement. Maybe someone would like to volunteer to
> take > > the role of some lightweight organising of those tickets and >
> prioritising them > > properly? I'd love that. > > I'd love that too and
> I'm willing to work such process and encourage > everyone > to participate.
> > > Karolina Rosół > Polidea | Project Manager > > M: +48 606 630 236 > E:
> karolina.rosol@polidea.com > > Check out our projects! > > Karolina Rosół
> > Polidea | Project Manager > > M: +48 606 630 236 > E:
> karolina.rosol@polidea.com > > Check out our projects! > > > > On Tue,
> Mar 17, 2020 at 7:29 PM Jarek Potiuk > wrote: > > > > 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 > > process in a way that will be maintainable in the future. We
> need > > lightweight approach to the issues/creating the right issue
> templates > > (bug/feature) > > that will help us to guide people to create
> issues and let us manage > them. > > > > Automation can help here.
> Auto-labelling and good templates might be > > a good start. We should
> explore how we can auto-label the issues > > based on subject/description
> (we could find a bot or extend our > > boring-cyborg and it should be
> rather easy). So whatever we can automate > > without adding too much
> overhead is good. > > > > > I do not know if there is a process for
> creating tasks but I assume it > > > looks like this: check keywords if
> such an issue/task exists and then > > > create ticket in Jira, if you need
> help ask on Slack or via devlist. > > > > I think not many people check for
> existing issues and with such > distributed > > environment and having
> people coming from many places/backgrounds/needs > > we won't be able to
> enforce it. However I think github already has > related > > issues
> feature: > https://github.blog/changelog/2018-12-12-related-issues-update/
> > > which should kick-in as soon as we have a big enough number of issues >
> > created. > > > > I think this is really good feature (providing it works
> this way)- and > we should > > promote it among the contributors and
> encourage following the > > "Related issues" advice. (I believe it is
> displayed as-you-type the > > subject of your issue). > > I think we can't
> do more than encouraging it though :). > > > > As longa as we describe it
> in our docs as "guideline" or even "rule" - > > we can use it to > > point
> it out always as we find out that it was not followed (and ask > > people
> to follow in the > > future). > > > > We even have the right places to add
> information about it: > > > > >
> https://github.com/apache/airflow/blob/master/CONTRIBUTING.rst#contribution-workflow-example
> > > >
> https://github.com/apache/airflow/blob/master/CONTRIBUTING.rst#how-to-communicate
> > > > > I think it would be great to add it (PR is welcome :)). Happy to >
> > review and contribute to it. > > > > > > > > Before starting a task, I
> was thinking about sending an email on > devlist to > > > everyone with
> questions like "I am starting to work on feature X for > the Y > > >
> service. Does anybody work on such a task?”, and attaching task >
> description. > > > > > > > We won't be able to enforce this but we can
> definitely encourage it - > > with a watchout that we have to be careful
> not to add unnecessary > friction in > > some cases if we make it into a
> rule. Again - adding PR to > CONTRIBUTING.rst > > might be a good idea :) -
> then we can always point people to it in > discussions. > > And even quite
> recently I took part in some reviews where people started > > working on
> the same issue, we found it out and they eventually joined > forces, > >
> cross-reviewed and made co-authored commits. I think it's sometimes ok - >
> some > > duplication is unavoidable and sometimes the cost of avoiding > >
> duplication might be > > bigger than the cost of duplication itself. But it
> would be great to > > encourage people to > > assign themselves to an issue
> when they start working on it (which will > be far > > easier if we switch
> to GitHub issues). > > > > > I am not sure if this is a good solution, but
> maybe it's better than > > > nothing. I don't know how many devs are
> reading this devlist. > > > > > > I am afraid that the same situation could
> be with GitHub. Maybe we > should > > > think about the flow of creating
> tickets and working with a new tool > > > (GitHub or whatever else). > > >
> > Fully agree. Though we have to remember that if we cannot automate and >
> > enforce something, we have no mechanisms to make people contributing do >
> it > > other than encouragement. Maybe someone would like to volunteer to
> take > > the role of some lightweight organising of those tickets and >
> prioritising them > > properly? I'd love that. But we have no formal
> management structure > (which > > is great) and it should - IMHO - follow
> the lines of encouragement and > best > > efforts to make it easy to follow
> rather than introduce some > > high-friction rules > > that everyone must
> follow. It's not easy (actually that's about as hard > a job as > > I can
> imagine) but if executed properly it might be great for the > community > >
> and super-rewarding. > > > > I even have such person in mind :)... Maybe
> she is reading that now .... > > -- > > > > Jarek Potiuk > > Polidea |
> Principal Software Engineer > > > > M: +48 660 796 129 > -- Jarek Potiuk
> Polidea | Principal Software Engineer M: +48 660 796 129 <+48660796129>
> [image: Polidea]
>
>

-- 

Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer

M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>

Re: [DISCUSS] Stop using Jira (since we aren't using it properly)

[Ash Berlin-Taylor <as...@apache.org>]

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 reports or feature requests (i.e. "how do I get X working", or "How do I best do X?") will likely be closed without a response.
--

So they if they read _at all_ they were told in advance that it would be closed without a response. You are right that we can at least repeat that message when closing anything with the "invalid" label.

On Mar 27 2020, at 6:12 am, Jarek Potiuk <Ja...@polidea.com> wrote:
> 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 agree between ourselves on how to do it. If we don't do it we might end up with a similar mess as we have in JIRA now - just using a different tool. For now, we have no rules defined nor best practices for how we are handling new issues, how we are labeling them etc. Just to give an example (note Ash - I am not criticizing, just showing an example that I think we can do better and that we have no common rules around how we deal with issues). There was this issue https://github.com/apache/airflow/issues/7890 which was closed as invalid without any explanation. I think it's not really a good idea. I believe we should always, as a rule, state why we are closing an issue even if it is invalid. The main reason is that if someone will have a similar issue they will be able to find it there or next time we can refer them to such closed issues. Issues in GitHub are indexed by Google and I often find solutions in already closed issues when there is an explanation - even for invalid ones. This is an invaluable source of information that results in many fewer issues being open - because people can find solutions before they open the issues. I think that was one of the problems with JIRA that it was difficult to find similar issues, but with Google indexing Github issues, it will happen automatically as long as we provide good explanations and answer issues promptly. I believe - reading Karolina's mail - that she is willing to help with establishing processes/practices (and I know from working with her that it's really helpful to organize it just a bit). At the same time we could split the JIRA issues between ourselves in a meaningful way and Karolina could help in managing the whole process. WDYT? Do you also think this might be a good idea to do it in this way? J. On Wed, Mar 25, 2020 at 1:15 PM Karolina Rosół wrote: > 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 explore how we can auto-label the issues > > based on subject/description (we could find a bot or extend our > > boring-cyborg and it should be rather easy). So whatever we can automate > > without adding too much overhead is good. > > As per automation it's always a good idea to automate and I'm happy to > explore the labeling subject. > > > We won't be able to enforce this but we can definitely encourage it - > > with a watchout that we have to be careful not to add unnecessary > friction in > > some cases if we make it into a rule. Again - adding PR to > CONTRIBUTING.rst > > might be a good idea :) > > Agree :-) > > > Fully agree. Though we have to remember that if we cannot automate and > > enforce something, we have no mechanisms to make people contributing do > it > > other than encouragement. Maybe someone would like to volunteer to take > > the role of some lightweight organising of those tickets and > prioritising them > > properly? I'd love that. > > I'd love that too and I'm willing to work such process and encourage > everyone > to participate. > > Karolina Rosół > Polidea | Project Manager > > M: +48 606 630 236 > E: karolina.rosol@polidea.com > > Check out our projects! > > Karolina Rosół > Polidea | Project Manager > > M: +48 606 630 236 > E: karolina.rosol@polidea.com > > Check out our projects! > > > > On Tue, Mar 17, 2020 at 7:29 PM Jarek Potiuk > wrote: > > > > 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 > > process in a way that will be maintainable in the future. We need > > lightweight approach to the issues/creating the right issue templates > > (bug/feature) > > that will help us to guide people to create issues and let us manage > them. > > > > Automation can help here. Auto-labelling and good templates might be > > a good start. We should explore how we can auto-label the issues > > based on subject/description (we could find a bot or extend our > > boring-cyborg and it should be rather easy). So whatever we can automate > > without adding too much overhead is good. > > > > > I do not know if there is a process for creating tasks but I assume it > > > looks like this: check keywords if such an issue/task exists and then > > > create ticket in Jira, if you need help ask on Slack or via devlist. > > > > I think not many people check for existing issues and with such > distributed > > environment and having people coming from many places/backgrounds/needs > > we won't be able to enforce it. However I think github already has > related > > issues feature: > https://github.blog/changelog/2018-12-12-related-issues-update/ > > which should kick-in as soon as we have a big enough number of issues > > created. > > > > I think this is really good feature (providing it works this way)- and > we should > > promote it among the contributors and encourage following the > > "Related issues" advice. (I believe it is displayed as-you-type the > > subject of your issue). > > I think we can't do more than encouraging it though :). > > > > As longa as we describe it in our docs as "guideline" or even "rule" - > > we can use it to > > point it out always as we find out that it was not followed (and ask > > people to follow in the > > future). > > > > We even have the right places to add information about it: > > > > > https://github.com/apache/airflow/blob/master/CONTRIBUTING.rst#contribution-workflow-example > > > https://github.com/apache/airflow/blob/master/CONTRIBUTING.rst#how-to-communicate > > > > I think it would be great to add it (PR is welcome :)). Happy to > > review and contribute to it. > > > > > > > > Before starting a task, I was thinking about sending an email on > devlist to > > > everyone with questions like "I am starting to work on feature X for > the Y > > > service. Does anybody work on such a task?”, and attaching task > description. > > > > > > > We won't be able to enforce this but we can definitely encourage it - > > with a watchout that we have to be careful not to add unnecessary > friction in > > some cases if we make it into a rule. Again - adding PR to > CONTRIBUTING.rst > > might be a good idea :) - then we can always point people to it in > discussions. > > And even quite recently I took part in some reviews where people started > > working on the same issue, we found it out and they eventually joined > forces, > > cross-reviewed and made co-authored commits. I think it's sometimes ok - > some > > duplication is unavoidable and sometimes the cost of avoiding > > duplication might be > > bigger than the cost of duplication itself. But it would be great to > > encourage people to > > assign themselves to an issue when they start working on it (which will > be far > > easier if we switch to GitHub issues). > > > > > I am not sure if this is a good solution, but maybe it's better than > > > nothing. I don't know how many devs are reading this devlist. > > > > > > I am afraid that the same situation could be with GitHub. Maybe we > should > > > think about the flow of creating tickets and working with a new tool > > > (GitHub or whatever else). > > > > Fully agree. Though we have to remember that if we cannot automate and > > enforce something, we have no mechanisms to make people contributing do > it > > other than encouragement. Maybe someone would like to volunteer to take > > the role of some lightweight organising of those tickets and > prioritising them > > properly? I'd love that. But we have no formal management structure > (which > > is great) and it should - IMHO - follow the lines of encouragement and > best > > efforts to make it easy to follow rather than introduce some > > high-friction rules > > that everyone must follow. It's not easy (actually that's about as hard > a job as > > I can imagine) but if executed properly it might be great for the > community > > and super-rewarding. > > > > I even have such person in mind :)... Maybe she is reading that now .... > > -- > > > > Jarek Potiuk > > Polidea | Principal Software Engineer > > > > M: +48 660 796 129 > -- Jarek Potiuk Polidea | Principal Software Engineer M: +48 660 796 129 <+48660796129> [image: Polidea]

Re: [DISCUSS] Stop using Jira (since we aren't using it properly)

[Jarek Potiuk <Ja...@polidea.com>]

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 agree between ourselves on how to do it. If we
don't do it we might end up with a similar mess as we have in JIRA now -
just using a different tool.

For now, we have no rules defined nor best practices for how we are
handling new issues, how we are labeling them etc. Just to give an example
(note Ash - I am not criticizing, just showing an example that I think we
can do better and that we have no common rules around how we deal with
issues). There was this issue
https://github.com/apache/airflow/issues/7890 which
was closed as invalid without any explanation. I think it's not really a
good idea. I believe we should always, as a rule, state why we are closing
an issue even if it is invalid. The main reason is that if someone will
have a similar issue they will be able to find it there or next time we can
refer them to such closed issues. Issues in GitHub are indexed by Google
and I often find solutions in already closed issues when there is an
explanation - even for invalid ones. This is an invaluable source of
information that results in many fewer issues being open - because people
can find solutions before they open the issues. I think that was one of the
problems with JIRA that it was difficult to find similar issues, but with
Google indexing Github issues, it will happen automatically as long as we
provide good explanations and answer issues promptly.

I believe - reading Karolina's mail - that she is willing to help with
establishing processes/practices (and I know from working with her that
it's really helpful to organize it just a bit).

At the same time we could split the JIRA issues between ourselves in a
meaningful way and Karolina could help in managing the whole process.

WDYT? Do you also think this might be a good idea to do it in this way?

J.


On Wed, Mar 25, 2020 at 1:15 PM Karolina Rosół <ka...@polidea.com>
wrote:

> 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 explore how we can auto-label the issues
> > based on subject/description (we could find a bot or extend our
> > boring-cyborg and it should be rather easy). So whatever we can automate
> > without adding too much overhead is good.
>
> As per automation it's always a good idea to automate and I'm happy to
> explore the labeling subject.
>
> > We won't be able to enforce this but we can definitely encourage it -
> > with a watchout that we have to be careful not to add unnecessary
> friction in
> > some cases if we make it into a rule. Again - adding PR to
> CONTRIBUTING.rst
> > might be a good idea :)
>
> Agree :-)
>
> > Fully agree. Though we have to remember that if we cannot automate and
> > enforce something, we have no mechanisms to make people contributing do
> it
> > other than encouragement. Maybe someone would like to volunteer to take
> > the role of some lightweight organising of those tickets and
> prioritising them
> > properly? I'd love that.
>
> I'd love that too and I'm willing to work such process and encourage
> everyone
> to participate.
>
> Karolina Rosół
> Polidea | Project Manager
>
> M: +48 606 630 236
> E: karolina.rosol@polidea.com
>
> Check out our projects!
>
> Karolina Rosół
> Polidea | Project Manager
>
> M: +48 606 630 236
> E: karolina.rosol@polidea.com
>
> Check out our projects!
>
>
>
> On Tue, Mar 17, 2020 at 7:29 PM Jarek Potiuk <Ja...@polidea.com>
> wrote:
> >
> > 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
> > process in a way that will be maintainable in the future. We need
> > lightweight approach to the issues/creating the right issue templates
> > (bug/feature)
> > that will help us to guide people to create issues and let us manage
> them.
> >
> > Automation can help here. Auto-labelling and good templates might be
> > a good start. We should explore how we can auto-label the issues
> > based on subject/description (we could find a bot or extend our
> > boring-cyborg and it should be rather easy). So whatever we can automate
> > without adding too much overhead is good.
> >
> > > I do not know if there is a process for creating tasks but I assume it
> > > looks like this: check keywords if such an issue/task exists and then
> > > create ticket in Jira, if you need help ask on Slack or via devlist.
> >
> > I think not many people check for existing issues and with such
> distributed
> > environment and having people coming from many places/backgrounds/needs
> > we won't be able to enforce it. However I think github already has
> related
> > issues feature:
> https://github.blog/changelog/2018-12-12-related-issues-update/
> > which should kick-in as soon as we have a big enough number of issues
> > created.
> >
> > I think this is really good feature (providing it works this way)- and
> we should
> > promote it among the contributors and encourage following the
> > "Related issues" advice. (I believe it is displayed as-you-type the
> > subject of your issue).
> > I think we can't do more than encouraging it though :).
> >
> > As longa as we describe it in our docs as "guideline" or even "rule" -
> > we can use it to
> > point it out always as we find out that it was not followed (and ask
> > people to follow in the
> > future).
> >
> > We even have the right places to add information about it:
> >
> >
> https://github.com/apache/airflow/blob/master/CONTRIBUTING.rst#contribution-workflow-example
> >
> https://github.com/apache/airflow/blob/master/CONTRIBUTING.rst#how-to-communicate
> >
> > I think it would be great to add it (PR is welcome :)). Happy to
> > review and contribute to it.
> >
> > >
> > > Before starting a task, I was thinking about sending an email on
> devlist to
> > > everyone with questions like "I am starting to work on feature X for
> the Y
> > > service. Does anybody work on such a task?”, and attaching task
> description.
> > >
> >
> > We won't be able to enforce this but we can definitely encourage it -
> > with a watchout that we have to be careful not to add unnecessary
> friction in
> > some cases if we make it into a rule. Again - adding PR to
> CONTRIBUTING.rst
> > might be a good idea :) - then we can always point people to it in
> discussions.
> > And even quite recently I took part in some reviews where people started
> > working on the same issue, we found it out and they eventually joined
> forces,
> > cross-reviewed and made co-authored commits. I think it's sometimes ok -
> some
> > duplication is unavoidable and sometimes the cost of avoiding
> > duplication might be
> > bigger than the cost of duplication itself. But it would be great to
> > encourage people to
> > assign themselves to an issue when they start working on it (which will
> be far
> > easier if we switch to GitHub issues).
> >
> > > I am not sure if this is a good solution, but maybe it's better than
> > > nothing. I don't know how many devs are reading this devlist.
> > >
> > > I am afraid that the same situation could be with GitHub. Maybe we
> should
> > > think about the flow of creating tickets and working with a new tool
> > > (GitHub or whatever else).
> >
> > Fully agree. Though we have to remember that if we cannot automate and
> > enforce something, we have no mechanisms to make people contributing do
> it
> > other than encouragement. Maybe someone would like to volunteer to take
> > the role of some lightweight organising of those tickets and
> prioritising them
> > properly? I'd love that. But we have no formal management structure
> (which
> > is great) and it should - IMHO - follow the lines of encouragement and
> best
> > efforts to make it easy to follow rather than introduce some
> > high-friction rules
> > that everyone must follow. It's not easy (actually that's about as hard
> a job as
> > I can imagine) but if executed properly it might be great for the
> community
> > and super-rewarding.
> >
> > I even have such person in mind :)... Maybe she is reading that now ....
> > --
> >
> > Jarek Potiuk
> > Polidea | Principal Software Engineer
> >
> > M: +48 660 796 129
>


-- 

Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer

M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>

Re: [DISCUSS] Stop using Jira (since we aren't using it properly)

[Karolina Rosół <ka...@polidea.com>]

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 explore how we can auto-label the issues
> based on subject/description (we could find a bot or extend our
> boring-cyborg and it should be rather easy). So whatever we can automate
> without adding too much overhead is good.

As per automation it's always a good idea to automate and I'm happy to
explore the labeling subject.

> We won't be able to enforce this but we can definitely encourage it -
> with a watchout that we have to be careful not to add unnecessary friction in
> some cases if we make it into a rule. Again - adding PR to CONTRIBUTING.rst
> might be a good idea :)

Agree :-)

> Fully agree. Though we have to remember that if we cannot automate and
> enforce something, we have no mechanisms to make people contributing do it
> other than encouragement. Maybe someone would like to volunteer to take
> the role of some lightweight organising of those tickets and prioritising them
> properly? I'd love that.

I'd love that too and I'm willing to work such process and encourage everyone
to participate.

Karolina Rosół
Polidea | Project Manager

M: +48 606 630 236
E: karolina.rosol@polidea.com

Check out our projects!

Karolina Rosół
Polidea | Project Manager

M: +48 606 630 236
E: karolina.rosol@polidea.com

Check out our projects!



On Tue, Mar 17, 2020 at 7:29 PM Jarek Potiuk <Ja...@polidea.com> wrote:
>
> 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
> process in a way that will be maintainable in the future. We need
> lightweight approach to the issues/creating the right issue templates
> (bug/feature)
> that will help us to guide people to create issues and let us manage them.
>
> Automation can help here. Auto-labelling and good templates might be
> a good start. We should explore how we can auto-label the issues
> based on subject/description (we could find a bot or extend our
> boring-cyborg and it should be rather easy). So whatever we can automate
> without adding too much overhead is good.
>
> > I do not know if there is a process for creating tasks but I assume it
> > looks like this: check keywords if such an issue/task exists and then
> > create ticket in Jira, if you need help ask on Slack or via devlist.
>
> I think not many people check for existing issues and with such distributed
> environment and having people coming from many places/backgrounds/needs
> we won't be able to enforce it. However I think github already has related
> issues feature: https://github.blog/changelog/2018-12-12-related-issues-update/
> which should kick-in as soon as we have a big enough number of issues
> created.
>
> I think this is really good feature (providing it works this way)- and we should
> promote it among the contributors and encourage following the
> "Related issues" advice. (I believe it is displayed as-you-type the
> subject of your issue).
> I think we can't do more than encouraging it though :).
>
> As longa as we describe it in our docs as "guideline" or even "rule" -
> we can use it to
> point it out always as we find out that it was not followed (and ask
> people to follow in the
> future).
>
> We even have the right places to add information about it:
>
> https://github.com/apache/airflow/blob/master/CONTRIBUTING.rst#contribution-workflow-example
> https://github.com/apache/airflow/blob/master/CONTRIBUTING.rst#how-to-communicate
>
> I think it would be great to add it (PR is welcome :)). Happy to
> review and contribute to it.
>
> >
> > Before starting a task, I was thinking about sending an email on devlist to
> > everyone with questions like "I am starting to work on feature X for the Y
> > service. Does anybody work on such a task?”, and attaching task description.
> >
>
> We won't be able to enforce this but we can definitely encourage it -
> with a watchout that we have to be careful not to add unnecessary friction in
> some cases if we make it into a rule. Again - adding PR to CONTRIBUTING.rst
> might be a good idea :) - then we can always point people to it in discussions.
> And even quite recently I took part in some reviews where people started
> working on the same issue, we found it out and they eventually joined forces,
> cross-reviewed and made co-authored commits. I think it's sometimes ok - some
> duplication is unavoidable and sometimes the cost of avoiding
> duplication might be
> bigger than the cost of duplication itself. But it would be great to
> encourage people to
> assign themselves to an issue when they start working on it (which will be far
> easier if we switch to GitHub issues).
>
> > I am not sure if this is a good solution, but maybe it's better than
> > nothing. I don't know how many devs are reading this devlist.
> >
> > I am afraid that the same situation could be with GitHub. Maybe we should
> > think about the flow of creating tickets and working with a new tool
> > (GitHub or whatever else).
>
> Fully agree. Though we have to remember that if we cannot automate and
> enforce something, we have no mechanisms to make people contributing do it
> other than encouragement. Maybe someone would like to volunteer to take
> the role of some lightweight organising of those tickets and prioritising them
> properly? I'd love that. But we have no formal management structure (which
> is great) and it should - IMHO - follow the lines of encouragement and best
> efforts to make it easy to follow rather than introduce some
> high-friction rules
> that everyone must follow. It's not easy (actually that's about as hard a job as
> I can imagine) but if executed properly it might be great for the community
> and super-rewarding.
>
> I even have such person in mind :)... Maybe she is reading that now ....
> --
>
> Jarek Potiuk
> Polidea | Principal Software Engineer
>
> M: +48 660 796 129

Re: [DISCUSS] Stop using Jira (since we aren't using it properly)

[Jarek Potiuk <Ja...@polidea.com>]

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
process in a way that will be maintainable in the future. We need
lightweight approach to the issues/creating the right issue templates
(bug/feature)
that will help us to guide people to create issues and let us manage them.

Automation can help here. Auto-labelling and good templates might be
a good start. We should explore how we can auto-label the issues
based on subject/description (we could find a bot or extend our
boring-cyborg and it should be rather easy). So whatever we can automate
without adding too much overhead is good.

> I do not know if there is a process for creating tasks but I assume it
> looks like this: check keywords if such an issue/task exists and then
> create ticket in Jira, if you need help ask on Slack or via devlist.

I think not many people check for existing issues and with such distributed
environment and having people coming from many places/backgrounds/needs
we won't be able to enforce it. However I think github already has related
issues feature: https://github.blog/changelog/2018-12-12-related-issues-update/
which should kick-in as soon as we have a big enough number of issues
created.

I think this is really good feature (providing it works this way)- and we should
promote it among the contributors and encourage following the
"Related issues" advice. (I believe it is displayed as-you-type the
subject of your issue).
I think we can't do more than encouraging it though :).

As longa as we describe it in our docs as "guideline" or even "rule" -
we can use it to
point it out always as we find out that it was not followed (and ask
people to follow in the
future).

We even have the right places to add information about it:

https://github.com/apache/airflow/blob/master/CONTRIBUTING.rst#contribution-workflow-example
https://github.com/apache/airflow/blob/master/CONTRIBUTING.rst#how-to-communicate

I think it would be great to add it (PR is welcome :)). Happy to
review and contribute to it.

>
> Before starting a task, I was thinking about sending an email on devlist to
> everyone with questions like "I am starting to work on feature X for the Y
> service. Does anybody work on such a task?”, and attaching task description.
>

We won't be able to enforce this but we can definitely encourage it -
with a watchout that we have to be careful not to add unnecessary friction in
some cases if we make it into a rule. Again - adding PR to CONTRIBUTING.rst
might be a good idea :) - then we can always point people to it in discussions.
And even quite recently I took part in some reviews where people started
working on the same issue, we found it out and they eventually joined forces,
cross-reviewed and made co-authored commits. I think it's sometimes ok - some
duplication is unavoidable and sometimes the cost of avoiding
duplication might be
bigger than the cost of duplication itself. But it would be great to
encourage people to
assign themselves to an issue when they start working on it (which will be far
easier if we switch to GitHub issues).

> I am not sure if this is a good solution, but maybe it's better than
> nothing. I don't know how many devs are reading this devlist.
>
> I am afraid that the same situation could be with GitHub. Maybe we should
> think about the flow of creating tickets and working with a new tool
> (GitHub or whatever else).

Fully agree. Though we have to remember that if we cannot automate and
enforce something, we have no mechanisms to make people contributing do it
other than encouragement. Maybe someone would like to volunteer to take
the role of some lightweight organising of those tickets and prioritising them
properly? I'd love that. But we have no formal management structure (which
is great) and it should - IMHO - follow the lines of encouragement and best
efforts to make it easy to follow rather than introduce some
high-friction rules
that everyone must follow. It's not easy (actually that's about as hard a job as
I can imagine) but if executed properly it might be great for the community
and super-rewarding.

I even have such person in mind :)... Maybe she is reading that now ....
--

Jarek Potiuk
Polidea | Principal Software Engineer

M: +48 660 796 129

Re: [DISCUSS] Stop using Jira (since we aren't using it properly)

[Michał Słowikowski <mi...@polidea.com>]

Hi guys,

I am new here, and usually I try to create tickets on Jira before starting
to work on a task.
I think the problem here is not the tool like Jira but the way we are using
it.

I do not know if there is a process for creating tasks but I assume it
looks like this: check keywords if such an issue/task exists and then
create ticket in Jira, if you need help ask on Slack or via devlist.

Before starting a task, I was thinking about sending an email on devlist to
everyone with questions like "I am starting to work on feature X for the Y
service. Does anybody work on such a task?”, and attaching task description.

I am not sure if this is a good solution, but maybe it's better than
nothing. I don't know how many devs are reading this devlist.

I have been working with Jira (which I like) for a long time already but I
have noticed that such a big community like Airflow has problem with
tickets because there is no person who would manage the tickets for whom
Jira would be the only place of the truth. For me such a place is GitHub
and I assume that a lot of you have your own projects on GitHub, too.

It is hard to keep Jira clean and tidy because we are all working on very
different fields.

I am afraid that the same situation could be with GitHub. Maybe we should
think about the flow of creating tickets and working with a new tool
(GitHub or whatever else).

Best regards
Michał

On Mon, Mar 16, 2020 at 4:28 PM Shaw, Damian P. <
damian.shaw.2@credit-suisse.com> wrote:

> I would just like to add some extra positive thoughts for this.
>
> Firstly as a newcomer JIRA is  confusing, even coming from a word that
> does use JIRA internally it's not what you see for most open source
> projects so it's far more familiar to use GitHub issues. (actually as a
> side note one negative is you may see an increase of "issues" that are
> actually support questions, I know this happens a lot on Jira, I don't know
> if you've considered standard or automatic handling)
>
> Secondly coming from a big enterprise company I often find Apache is
> blocking our connection and I can almost never load Airflow's JIRA. Because
> we are tens of thousands of users all behind 1 IP it seems that Apache
> automatically blocks us often. So it will be nice to actually be able to
> read issues from my work computer!
>
> Damian
>
> -----Original Message-----
> From: Jarek Potiuk <Ja...@polidea.com>
> 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 <tu...@apache.org>
> wrote:
>
> > Yes, vote and switch.
> >
> >
> > On Mon, Mar 16, 2020 at 3:06 PM Ash Berlin-Taylor <as...@apache.org>
> 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 bothering with this" today.
> > > It seems like we have fairly broad agreement this time. AIP worth,
> > > or
> > just
> > > a VOTE and switch over?
> > > -a
> > > On Mar 16 2020, at 2:02 pm, Tomasz Urbaszek <tu...@apache.org>
> > wrote:
> > > > +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 spotted that Apache Superset is proposing SIP (Superset
> > > Improvement
> > > Proposals) on Github issues. T. On Mon, Mar 16, 2020 at 1:08 PM
> > > Kaxil
> > Naik
> > > wrote: > > +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 issue
> > > when PR is merged. > > Regards, >
> > Kaxil
> > > > > > > On Mon, Mar 16, 2020 at 12:04 PM Ash Berlin-Taylor wrote: >
> > > > > > > > > >
> > > Maybe we could have some clear guidelines on when the issues should
> > > be >
> > >
> > > created - only when there is a problem so meone 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 submit a fix straight away:
> > > >
> > > create an issue. > > -a > > On Mar 16 2020, at 12:02 pm, Jarek
> > > Potiuk > >
> > > wrote: > > > 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
> "work" + "create" +"
> > submit"
> > > sequence - without the unnecessary hassle. > > You can assign
> > > milestones/projects/label the same way on both. We actually > >
> > > found
> > that
> > > even when we use them in some other projects - they become > >
> > unnecessary.
> > > I think eventually there should be a way to convert an issue > >
> > > into PR :). Even if we want to use Github Projects eventually, we ca
> > > n add > > PRs to projects similarly as issues. 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.
> > J.
> > > On Mon, > > Mar 16, 2020 at 12:46 PM Ash Berlin-Taylor wrote: > >
> > > 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 we can use Github issues for
> > > simple use,
> > which
> > > > > is to report some > bugs/questions by users, who are not
> > > > > necessarily
> > >
> > > > planning to create a PR > soon. > Yes, that was what I meant but I
> > wasn't
> > > > > clear; I was just using "Github > Issues" as a collective
> > > > > product
> > name,
> > > and > > not saying we need an issue for > every PR. > > -ash > > On
> > > Mar
> > 16
> > > 2020, at > > 11:42 am, Sumi
> > > t Maheshwari > wrote: > > 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 we can use
> > > > > Github
> > > issues > > for simple use, which is to report some > > >
> > > bugs/questions
> > by
> > > users, who are not necessarily planning to create a > > PR > soon.
> > > Also,
> > if
> > > we go this route, then we can do the one time Jira > > cleanup > and
> > > port only valid issues in Github. On Mon, Mar 16, 2020 at > > 5:07
> > > PM Ash > Berlin-Taylor wrote: > 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 ei
> > > ther way > > > > > > On 16 > > March 2020 at 12:33:27, Ash >
> > Berlin-Taylor
> > > (ash@firemirror.com > (mailto: > > a > sh@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 creating new > > Jira > >
> > > tickets,
> > rather
> > > than searching to see if there already exists a > > ticket for > >
> > > that feature. > > > For example: > ht > > tps://
> > > issues.apache.org/jira/browse/AIRFLOW-6987 and > > > >
> > > https://issues.apache.org/jira/browse/AIRFLOW-2824 (I'm not trying
> > > to >
> > >
> > > > > pick on anyone involved here, I just happened to notice this) >
> > > > > > >
> > > >
> > > > Additionally most of the committers follow a similar path of "work
> > > > on
> > > >
> > > > > feature, open Jira ticket just before creating PR". > > > I am
> > > proposing we > > > migrate over to Github issues and drop the >
> > requirement
> > > to have a jira > > > ticket for PRs. > > > The one downside is we
> > > might
> > get
> > > people opening
> > >  > > > issues for as an > "help, how do I do this" -- I think we can
> > > address that > > > by having an issue > template saying something
> > > like
> > "DO
> > > NOT OPEN AN ISSUE > > > ASKING FOR HELP - ask > on user > s@ or join
> > > slack". > > > The only > > other thing Jira currently gives us is >
> > > the ability mark tasks > for > > "backporting" -- I think we can
> > > replace
> > that >
> > > with Github Milestones. > > > Kaxil or I will happily update the
> > > scripts
> > we
> > > use > to build/check the > > status > of releases. > > > Thoughts? >
> > > > > The only > outstandi > > ng question is then what do we do about
> > migrating
> > > > the issue (do > we > > copy issues across to Github?). Perhaps it
> > > > might
> > > be a good > opportunity > > > for a clean slate. > > > -ash > > > >
> > > > >
> > > >
> > > > > > > -- Jarek Potiuk > > Polidea | Principal Software Engineer M:
> > > > > > > +48
> > > 660 796 129 <+48660796129> > > [image: Polidea] > > > >
> > >
> > >
> >
>
>
> --
>
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
>
> M: +48 660 796 129 <+48660796129>
> [image: Polidea] <https://www.polidea.com/>
>
>
>
> ===============================================================================
>
> Please access the attached hyperlink for an important electronic
> communications disclaimer:
> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
> ===============================================================================
>
>


-- 

Michał Słowikowski
Polidea <https://www.polidea.com/> | Junior Software Engineer

E: michal.slowikowski@polidea.com

Unique Tech
Check out our projects! <https://www.polidea.com/our-work>

RE: [DISCUSS] Stop using Jira (since we aren't using it properly)

["Shaw, Damian P. " <da...@credit-suisse.com>]

I would just like to add some extra positive thoughts for this. 

Firstly as a newcomer JIRA is  confusing, even coming from a word that does use JIRA internally it's not what you see for most open source projects so it's far more familiar to use GitHub issues. (actually as a side note one negative is you may see an increase of "issues" that are actually support questions, I know this happens a lot on Jira, I don't know if you've considered standard or automatic handling)

Secondly coming from a big enterprise company I often find Apache is blocking our connection and I can almost never load Airflow's JIRA. Because we are tens of thousands of users all behind 1 IP it seems that Apache automatically blocks us often. So it will be nice to actually be able to read issues from my work computer!

Damian

-----Original Message-----
From: Jarek Potiuk <Ja...@polidea.com> 
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 <tu...@apache.org>
wrote:

> Yes, vote and switch.
>
>
> On Mon, Mar 16, 2020 at 3:06 PM Ash Berlin-Taylor <as...@apache.org> 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 bothering with this" today.
> > It seems like we have fairly broad agreement this time. AIP worth, 
> > or
> just
> > a VOTE and switch over?
> > -a
> > On Mar 16 2020, at 2:02 pm, Tomasz Urbaszek <tu...@apache.org>
> wrote:
> > > +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 spotted that Apache Superset is proposing SIP (Superset 
> > Improvement
> > Proposals) on Github issues. T. On Mon, Mar 16, 2020 at 1:08 PM 
> > Kaxil
> Naik
> > wrote: > > +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 issue 
> > when PR is merged. > > Regards, >
> Kaxil
> > > > > > On Mon, Mar 16, 2020 at 12:04 PM Ash Berlin-Taylor wrote: > 
> > > > > > > > >
> > Maybe we could have some clear guidelines on when the issues should 
> > be >
> >
> > created - only when there is a problem so meone 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 submit a fix straight away:
> > >
> > create an issue. > > -a > > On Mar 16 2020, at 12:02 pm, Jarek 
> > Potiuk > >
> > wrote: > > > 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 "work" + "create" +"
> submit"
> > sequence - without the unnecessary hassle. > > You can assign 
> > milestones/projects/label the same way on both. We actually > > 
> > found
> that
> > even when we use them in some other projects - they become > >
> unnecessary.
> > I think eventually there should be a way to convert an issue > > 
> > into PR :). Even if we want to use Github Projects eventually, we ca 
> > n add > > PRs to projects similarly as issues. 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.
> J.
> > On Mon, > > Mar 16, 2020 at 12:46 PM Ash Berlin-Taylor wrote: > > 
> > 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 we can use Github issues for 
> > simple use,
> which
> > > > is to report some > bugs/questions by users, who are not 
> > > > necessarily
> >
> > > planning to create a PR > soon. > Yes, that was what I meant but I
> wasn't
> > > > clear; I was just using "Github > Issues" as a collective 
> > > > product
> name,
> > and > > not saying we need an issue for > every PR. > > -ash > > On 
> > Mar
> 16
> > 2020, at > > 11:42 am, Sumi
> > t Maheshwari > wrote: > > 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 we can use 
> > > > Github
> > issues > > for simple use, which is to report some > > > 
> > bugs/questions
> by
> > users, who are not necessarily planning to create a > > PR > soon. 
> > Also,
> if
> > we go this route, then we can do the one time Jira > > cleanup > and 
> > port only valid issues in Github. On Mon, Mar 16, 2020 at > > 5:07 
> > PM Ash > Berlin-Taylor wrote: > 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 ei
> > ther way > > > > > > On 16 > > March 2020 at 12:33:27, Ash >
> Berlin-Taylor
> > (ash@firemirror.com > (mailto: > > a > sh@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 creating new > > Jira > > 
> > tickets,
> rather
> > than searching to see if there already exists a > > ticket for > > 
> > that feature. > > > For example: > ht > > tps://
> > issues.apache.org/jira/browse/AIRFLOW-6987 and > > > >
> > https://issues.apache.org/jira/browse/AIRFLOW-2824 (I'm not trying 
> > to >
> >
> > > > pick on anyone involved here, I just happened to notice this) > 
> > > > > >
> > >
> > > Additionally most of the committers follow a similar path of "work 
> > > on
> > >
> > > > feature, open Jira ticket just before creating PR". > > > I am
> > proposing we > > > migrate over to Github issues and drop the >
> requirement
> > to have a jira > > > ticket for PRs. > > > The one downside is we 
> > might
> get
> > people opening
> >  > > > issues for as an > "help, how do I do this" -- I think we can 
> > address that > > > by having an issue > template saying something 
> > like
> "DO
> > NOT OPEN AN ISSUE > > > ASKING FOR HELP - ask > on user > s@ or join 
> > slack". > > > The only > > other thing Jira currently gives us is > 
> > the ability mark tasks > for > > "backporting" -- I think we can 
> > replace
> that >
> > with Github Milestones. > > > Kaxil or I will happily update the 
> > scripts
> we
> > use > to build/check the > > status > of releases. > > > Thoughts? > 
> > > > The only > outstandi > > ng question is then what do we do about
> migrating
> > > the issue (do > we > > copy issues across to Github?). Perhaps it 
> > > might
> > be a good > opportunity > > > for a clean slate. > > > -ash > > > > 
> > > >
> > >
> > > > > > -- Jarek Potiuk > > Polidea | Principal Software Engineer M: 
> > > > > > +48
> > 660 796 129 <+48660796129> > > [image: Polidea] > > > >
> >
> >
>


-- 

Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer

M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>



=============================================================================== 
Please access the attached hyperlink for an important electronic communications disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
=============================================================================== 

Re: [DISCUSS] Stop using Jira (since we aren't using it properly)

[Jarek Potiuk <Ja...@polidea.com>]

Yep. Vote and switch :)

On Mon, Mar 16, 2020 at 3:12 PM Tomasz Urbaszek <tu...@apache.org>
wrote:

> Yes, vote and switch.
>
>
> On Mon, Mar 16, 2020 at 3:06 PM Ash Berlin-Taylor <as...@apache.org> 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
> > bothering with this" today.
> > It seems like we have fairly broad agreement this time. AIP worth, or
> just
> > a VOTE and switch over?
> > -a
> > On Mar 16 2020, at 2:02 pm, Tomasz Urbaszek <tu...@apache.org>
> wrote:
> > > +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 spotted that Apache Superset is proposing SIP (Superset Improvement
> > Proposals) on Github issues. T. On Mon, Mar 16, 2020 at 1:08 PM Kaxil
> Naik
> > wrote: > > +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 issue when PR is merged. > > Regards, >
> Kaxil
> > > > > > On Mon, Mar 16, 2020 at 12:04 PM Ash Berlin-Taylor wrote: > > > >
> > Maybe we could have some clear guidelines on when the issues should be >
> >
> > created - only when there is a problem so
> > meone 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 submit a fix straight away:
> > >
> > create an issue. > > -a > > On Mar 16 2020, at 12:02 pm, Jarek Potiuk > >
> > wrote: > > > 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 "work" + "create" +"
> submit"
> > sequence - without the unnecessary hassle. > > You can assign
> > milestones/projects/label the same way on both. We actually > > found
> that
> > even when we use them in some other projects - they become > >
> unnecessary.
> > I think eventually there should be a way to convert an issue > > into PR
> > :). Even if we want to use Github Projects eventually, we ca
> > n add > > PRs to projects similarly as issues. 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.
> J.
> > On Mon, > > Mar 16, 2020 at 12:46 PM Ash Berlin-Taylor wrote: > > 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 we can use Github issues for simple use,
> which
> > > > is to report some > bugs/questions by users, who are not necessarily
> >
> > > planning to create a PR > soon. > Yes, that was what I meant but I
> wasn't
> > > > clear; I was just using "Github > Issues" as a collective product
> name,
> > and > > not saying we need an issue for > every PR. > > -ash > > On Mar
> 16
> > 2020, at > > 11:42 am, Sumi
> > t Maheshwari > wrote: > > 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 we can use Github
> > issues > > for simple use, which is to report some > > > bugs/questions
> by
> > users, who are not necessarily planning to create a > > PR > soon. Also,
> if
> > we go this route, then we can do the one time Jira > > cleanup > and port
> > only valid issues in Github. On Mon, Mar 16, 2020 at > > 5:07 PM Ash >
> > Berlin-Taylor wrote: > 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 ei
> > ther way > > > > > > On 16 > > March 2020 at 12:33:27, Ash >
> Berlin-Taylor
> > (ash@firemirror.com > (mailto: > > a > sh@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 creating new > > Jira > > tickets,
> rather
> > than searching to see if there already exists a > > ticket for > > that
> > feature. > > > For example: > ht > > tps://
> > issues.apache.org/jira/browse/AIRFLOW-6987 and > > > >
> > https://issues.apache.org/jira/browse/AIRFLOW-2824 (I'm not trying to >
> >
> > > > pick on anyone involved here, I just happened to notice this) > > >
> > >
> > > Additionally most of the committers follow a similar path of "work on
> > >
> > > > feature, open Jira ticket just before creating PR". > > > I am
> > proposing we > > > migrate over to Github issues and drop the >
> requirement
> > to have a jira > > > ticket for PRs. > > > The one downside is we might
> get
> > people opening
> >  > > > issues for as an > "help, how do I do this" -- I think we can
> > address that > > > by having an issue > template saying something like
> "DO
> > NOT OPEN AN ISSUE > > > ASKING FOR HELP - ask > on user > s@ or join
> > slack". > > > The only > > other thing Jira currently gives us is > the
> > ability mark tasks > for > > "backporting" -- I think we can replace
> that >
> > with Github Milestones. > > > Kaxil or I will happily update the scripts
> we
> > use > to build/check the > > status > of releases. > > > Thoughts? > > >
> > The only > outstandi > > ng question is then what do we do about
> migrating
> > > the issue (do > we > > copy issues across to Github?). Perhaps it might
> > be a good > opportunity > > > for a clean slate. > > > -ash > > > > > >
> > >
> > > > > > -- Jarek Potiuk > > Polidea | Principal Software Engineer M: +48
> > 660 796 129 <+48660796129> > > [image: Polidea] > > > >
> >
> >
>


-- 

Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer

M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>

Re: [DISCUSS] Stop using Jira (since we aren't using it properly)

[Tomasz Urbaszek <tu...@apache.org>]

Yes, vote and switch.


On Mon, Mar 16, 2020 at 3:06 PM Ash Berlin-Taylor <as...@apache.org> 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
> bothering with this" today.
> It seems like we have fairly broad agreement this time. AIP worth, or just
> a VOTE and switch over?
> -a
> On Mar 16 2020, at 2:02 pm, Tomasz Urbaszek <tu...@apache.org> wrote:
> > +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 spotted that Apache Superset is proposing SIP (Superset Improvement
> Proposals) on Github issues. T. On Mon, Mar 16, 2020 at 1:08 PM Kaxil Naik
> wrote: > > +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 issue when PR is merged. > > Regards, > Kaxil
> > > > > On Mon, Mar 16, 2020 at 12:04 PM Ash Berlin-Taylor wrote: > > > >
> Maybe we could have some clear guidelines on when the issues should be > >
> created - only when there is a problem so
> meone 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 submit a fix straight away: > >
> create an issue. > > -a > > On Mar 16 2020, at 12:02 pm, Jarek Potiuk > >
> wrote: > > > 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 "work" + "create" +" submit"
> sequence - without the unnecessary hassle. > > You can assign
> milestones/projects/label the same way on both. We actually > > found that
> even when we use them in some other projects - they become > > unnecessary.
> I think eventually there should be a way to convert an issue > > into PR
> :). Even if we want to use Github Projects eventually, we ca
> n add > > PRs to projects similarly as issues. 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. J.
> On Mon, > > Mar 16, 2020 at 12:46 PM Ash Berlin-Taylor wrote: > > 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 we can use Github issues for simple use, which
> > > is to report some > bugs/questions by users, who are not necessarily >
> > planning to create a PR > soon. > Yes, that was what I meant but I wasn't
> > > clear; I was just using "Github > Issues" as a collective product name,
> and > > not saying we need an issue for > every PR. > > -ash > > On Mar 16
> 2020, at > > 11:42 am, Sumi
> t Maheshwari > wrote: > > 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 we can use Github
> issues > > for simple use, which is to report some > > > bugs/questions by
> users, who are not necessarily planning to create a > > PR > soon. Also, if
> we go this route, then we can do the one time Jira > > cleanup > and port
> only valid issues in Github. On Mon, Mar 16, 2020 at > > 5:07 PM Ash >
> Berlin-Taylor wrote: > 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 ei
> ther way > > > > > > On 16 > > March 2020 at 12:33:27, Ash > Berlin-Taylor
> (ash@firemirror.com > (mailto: > > a > sh@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 creating new > > Jira > > tickets, rather
> than searching to see if there already exists a > > ticket for > > that
> feature. > > > For example: > ht > > tps://
> issues.apache.org/jira/browse/AIRFLOW-6987 and > > > >
> https://issues.apache.org/jira/browse/AIRFLOW-2824 (I'm not trying to > >
> > > pick on anyone involved here, I just happened to notice this) > > > > >
> > Additionally most of the committers follow a similar path of "work on > >
> > > feature, open Jira ticket just before creating PR". > > > I am
> proposing we > > > migrate over to Github issues and drop the > requirement
> to have a jira > > > ticket for PRs. > > > The one downside is we might get
> people opening
>  > > > issues for as an > "help, how do I do this" -- I think we can
> address that > > > by having an issue > template saying something like "DO
> NOT OPEN AN ISSUE > > > ASKING FOR HELP - ask > on user > s@ or join
> slack". > > > The only > > other thing Jira currently gives us is > the
> ability mark tasks > for > > "backporting" -- I think we can replace that >
> with Github Milestones. > > > Kaxil or I will happily update the scripts we
> use > to build/check the > > status > of releases. > > > Thoughts? > > >
> The only > outstandi > > ng question is then what do we do about migrating
> > the issue (do > we > > copy issues across to Github?). Perhaps it might
> be a good > opportunity > > > for a clean slate. > > > -ash > > > > > > > >
> > > > > -- Jarek Potiuk > > Polidea | Principal Software Engineer M: +48
> 660 796 129 <+48660796129> > > [image: Polidea] > > > >
>
>

Re: [DISCUSS] Stop using Jira (since we aren't using it properly)

[Ash Berlin-Taylor <as...@apache.org>]

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 worth, or just a VOTE and switch over?
-a
On Mar 16 2020, at 2:02 pm, Tomasz Urbaszek <tu...@apache.org> wrote:
> +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 spotted that Apache Superset is proposing SIP (Superset Improvement Proposals) on Github issues. T. On Mon, Mar 16, 2020 at 1:08 PM Kaxil Naik wrote: > > +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 issue when PR is merged. > > Regards, > Kaxil > > > > On Mon, Mar 16, 2020 at 12:04 PM Ash Berlin-Taylor wrote: > > > > Maybe we could have some clear guidelines on when the issues should be > > created - only when there is a problem so
meone 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 submit a fix straight away: > > create an issue. > > -a > > On Mar 16 2020, at 12:02 pm, Jarek Potiuk > > wrote: > > > 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 "work" + "create" +" submit" sequence - without the unnecessary hassle. > > You can assign milestones/projects/label the same way on both. We actually > > found that even when we use them in some other projects - they become > > unnecessary. I think eventually there should be a way to convert an issue > > into PR :). Even if we want to use Github Projects eventually, we ca
n add > > PRs to projects similarly as issues. 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. J. On Mon, > > Mar 16, 2020 at 12:46 PM Ash Berlin-Taylor wrote: > > 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 we can use Github issues for simple use, which > > is to report some > bugs/questions by users, who are not necessarily > > planning to create a PR > soon. > Yes, that was what I meant but I wasn't > > clear; I was just using "Github > Issues" as a collective product name, and > > not saying we need an issue for > every PR. > > -ash > > On Mar 16 2020, at > > 11:42 am, Sumi
t Maheshwari > wrote: > > 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 we can use Github issues > > for simple use, which is to report some > > > bugs/questions by users, who are not necessarily planning to create a > > PR > soon. Also, if we go this route, then we can do the one time Jira > > cleanup > and port only valid issues in Github. On Mon, Mar 16, 2020 at > > 5:07 PM Ash > Berlin-Taylor wrote: > 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 ei
ther way > > > > > > On 16 > > March 2020 at 12:33:27, Ash > Berlin-Taylor (ash@firemirror.com > (mailto: > > a > sh@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 creating new > > Jira > > tickets, rather than searching to see if there already exists a > > ticket for > > that feature. > > > For example: > ht > > tps://issues.apache.org/jira/browse/AIRFLOW-6987 and > > > > https://issues.apache.org/jira/browse/AIRFLOW-2824 (I'm not trying to > > > > pick on anyone involved here, I just happened to notice this) > > > > > > Additionally most of the committers follow a similar path of "work on > > > > feature, open Jira ticket just before creating PR". > > > I am proposing we > > > migrate over to Github issues and drop the > requirement to have a jira > > > ticket for PRs. > > > The one downside is we might get people opening
 > > > issues for as an > "help, how do I do this" -- I think we can address that > > > by having an issue > template saying something like "DO NOT OPEN AN ISSUE > > > ASKING FOR HELP - ask > on user > s@ or join slack". > > > The only > > other thing Jira currently gives us is > the ability mark tasks > for > > "backporting" -- I think we can replace that > with Github Milestones. > > > Kaxil or I will happily update the scripts we use > to build/check the > > status > of releases. > > > Thoughts? > > > The only > outstandi > > ng question is then what do we do about migrating > the issue (do > we > > copy issues across to Github?). Perhaps it might be a good > opportunity > > > for a clean slate. > > > -ash > > > > > > > > > > > > -- Jarek Potiuk > > Polidea | Principal Software Engineer M: +48 660 796 129 <+48660796129> > > [image: Polidea] > > > >

Re: [DISCUSS] Stop using Jira (since we aren't using it properly)

[Tomasz Urbaszek <tu...@apache.org>]

+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 spotted that Apache Superset is proposing SIP (Superset
Improvement Proposals) on Github issues.

T.


On Mon, Mar 16, 2020 at 1:08 PM Kaxil Naik <ka...@gmail.com> wrote:
>
> +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 issue when PR is merged.
>
> Regards,
> Kaxil
>
>
>
> On Mon, Mar 16, 2020 at 12:04 PM Ash Berlin-Taylor <as...@apache.org> wrote:
>
> > > 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 submit a fix straight away:
> > create an issue.
> > -a
> > On Mar 16 2020, at 12:02 pm, Jarek Potiuk <Ja...@polidea.com>
> > wrote:
> > > 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 "work" + "create" +" submit" sequence - without the unnecessary hassle.
> > You can assign milestones/projects/label the same way on both. We actually
> > found that even when we use them in some other projects - they become
> > unnecessary. I think eventually there should be a way to convert an issue
> > into PR :). Even if we want to use Github Projects eventually, we can add
> > PRs to projects similarly as issues. 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. J. On Mon,
> > Mar 16, 2020 at 12:46 PM Ash Berlin-Taylor wrote: > > 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 we can use Github issues for simple use, which
> > is to report some > bugs/questions by users, who are not necessarily
> > planning to create a PR > soon. > Yes, that was what I meant but I wasn't
> > clear; I was just using "Github > Issues" as a collective product name, and
> > not saying we need an issue for > every PR. > > -ash > > On Mar 16 2020, at
> > 11:42 am, Sumit Maheshwari > wrote: > > 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 we can use Github issues
> > for simple use, which is to report some
> >  > bugs/questions by users, who are not necessarily planning to create a
> > PR > soon. Also, if we go this route, then we can do the one time Jira
> > cleanup > and port only valid issues in Github. On Mon, Mar 16, 2020 at
> > 5:07 PM Ash > Berlin-Taylor wrote: > 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 16
> > March 2020 at 12:33:27, Ash > Berlin-Taylor (ash@firemirror.com > (mailto:
> > a > sh@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 creating new
> > Jira > > tickets, rather than searching to see if there already exists a
> > ticket for > > that feature. > > > For example: > ht
> > tps://issues.apache.org/jira/browse/AIRFLOW-6987 and > >
> > https://issues.apache.org/jira/browse/AIRFLOW-2824 (I'm not trying to > >
> > pick on anyone involved here, I just happened to notice this) > > > >
> > Additionally most of the committers follow a similar path of "work on > >
> > feature, open Jira ticket just before creating PR". > > > I am proposing we
> > > migrate over to Github issues and drop the > requirement to have a jira >
> > ticket for PRs. > > > The one downside is we might get people opening >
> > issues for as an > "help, how do I do this" -- I think we can address that
> > > by having an issue > template saying something like "DO NOT OPEN AN ISSUE
> > > ASKING FOR HELP - ask > on user > s@ or join slack". > > > The only
> > other thing Jira currently gives us is > the ability mark tasks > for
> > "backporting" -- I think we can replace that > with Github Milestones. >
> > Kaxil or I will happily update the scripts we use > to build/check the
> > status > of releases. > > > Thoughts? > > > The only > outstandi
> > ng question is then what do we do about migrating > the issue (do > we
> > copy issues across to Github?). Perhaps it might be a good > opportunity >
> > for a clean slate. > > > -ash > > > > > > > > > > > > -- Jarek Potiuk
> > Polidea | Principal Software Engineer M: +48 660 796 129 <+48660796129>
> > [image: Polidea]
> >
> >

Re: [DISCUSS] Stop using Jira (since we aren't using it properly)

[Kaxil Naik <ka...@gmail.com>]

+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 issue when PR is merged.

Regards,
Kaxil



On Mon, Mar 16, 2020 at 12:04 PM Ash Berlin-Taylor <as...@apache.org> wrote:

> > 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 submit a fix straight away:
> create an issue.
> -a
> On Mar 16 2020, at 12:02 pm, Jarek Potiuk <Ja...@polidea.com>
> wrote:
> > 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 "work" + "create" +" submit" sequence - without the unnecessary hassle.
> You can assign milestones/projects/label the same way on both. We actually
> found that even when we use them in some other projects - they become
> unnecessary. I think eventually there should be a way to convert an issue
> into PR :). Even if we want to use Github Projects eventually, we can add
> PRs to projects similarly as issues. 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. J. On Mon,
> Mar 16, 2020 at 12:46 PM Ash Berlin-Taylor wrote: > > 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 we can use Github issues for simple use, which
> is to report some > bugs/questions by users, who are not necessarily
> planning to create a PR > soon. > Yes, that was what I meant but I wasn't
> clear; I was just using "Github > Issues" as a collective product name, and
> not saying we need an issue for > every PR. > > -ash > > On Mar 16 2020, at
> 11:42 am, Sumit Maheshwari > wrote: > > 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 we can use Github issues
> for simple use, which is to report some
>  > bugs/questions by users, who are not necessarily planning to create a
> PR > soon. Also, if we go this route, then we can do the one time Jira
> cleanup > and port only valid issues in Github. On Mon, Mar 16, 2020 at
> 5:07 PM Ash > Berlin-Taylor wrote: > 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 16
> March 2020 at 12:33:27, Ash > Berlin-Taylor (ash@firemirror.com > (mailto:
> a > sh@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 creating new
> Jira > > tickets, rather than searching to see if there already exists a
> ticket for > > that feature. > > > For example: > ht
> tps://issues.apache.org/jira/browse/AIRFLOW-6987 and > >
> https://issues.apache.org/jira/browse/AIRFLOW-2824 (I'm not trying to > >
> pick on anyone involved here, I just happened to notice this) > > > >
> Additionally most of the committers follow a similar path of "work on > >
> feature, open Jira ticket just before creating PR". > > > I am proposing we
> > migrate over to Github issues and drop the > requirement to have a jira >
> ticket for PRs. > > > The one downside is we might get people opening >
> issues for as an > "help, how do I do this" -- I think we can address that
> > by having an issue > template saying something like "DO NOT OPEN AN ISSUE
> > ASKING FOR HELP - ask > on user > s@ or join slack". > > > The only
> other thing Jira currently gives us is > the ability mark tasks > for
> "backporting" -- I think we can replace that > with Github Milestones. >
> Kaxil or I will happily update the scripts we use > to build/check the
> status > of releases. > > > Thoughts? > > > The only > outstandi
> ng question is then what do we do about migrating > the issue (do > we
> copy issues across to Github?). Perhaps it might be a good > opportunity >
> for a clean slate. > > > -ash > > > > > > > > > > > > -- Jarek Potiuk
> Polidea | Principal Software Engineer M: +48 660 796 129 <+48660796129>
> [image: Polidea]
>
>

Re: [DISCUSS] Stop using Jira (since we aren't using it properly)

[Ash Berlin-Taylor <as...@apache.org>]

> 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 submit a fix straight away: create an issue.
-a
On Mar 16 2020, at 12:02 pm, Jarek Potiuk <Ja...@polidea.com> wrote:
> 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 "work" + "create" +" submit" sequence - without the unnecessary hassle. You can assign milestones/projects/label the same way on both. We actually found that even when we use them in some other projects - they become unnecessary. I think eventually there should be a way to convert an issue into PR :). Even if we want to use Github Projects eventually, we can add PRs to projects similarly as issues. 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. J. On Mon, Mar 16, 2020 at 12:46 PM Ash Berlin-Taylor wrote: > > 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 we can use Github issues for simple use, which is to report some > bugs/questions by users, who are not necessarily planning to create a PR > soon. > Yes, that was what I meant but I wasn't clear; I was just using "Github > Issues" as a collective product name, and not saying we need an issue for > every PR. > > -ash > > On Mar 16 2020, at 11:42 am, Sumit Maheshwari > wrote: > > 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 we can use Github issues for simple use, which is to report some
 > bugs/questions by users, who are not necessarily planning to create a PR > soon. Also, if we go this route, then we can do the one time Jira cleanup > and port only valid issues in Github. On Mon, Mar 16, 2020 at 5:07 PM Ash > Berlin-Taylor wrote: > 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 16 March 2020 at 12:33:27, Ash > Berlin-Taylor (ash@firemirror.com > (mailto:a > sh@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 creating new Jira > > tickets, rather than searching to see if there already exists a ticket for > > that feature. > > > For example: > ht
tps://issues.apache.org/jira/browse/AIRFLOW-6987 and > > https://issues.apache.org/jira/browse/AIRFLOW-2824 (I'm not trying to > > pick on anyone involved here, I just happened to notice this) > > > > Additionally most of the committers follow a similar path of "work on > > feature, open Jira ticket just before creating PR". > > > I am proposing we > migrate over to Github issues and drop the > requirement to have a jira > ticket for PRs. > > > The one downside is we might get people opening > issues for as an > "help, how do I do this" -- I think we can address that > by having an issue > template saying something like "DO NOT OPEN AN ISSUE > ASKING FOR HELP - ask > on user > s@ or join slack". > > > The only other thing Jira currently gives us is > the ability mark tasks > for "backporting" -- I think we can replace that > with Github Milestones. > Kaxil or I will happily update the scripts we use > to build/check the status > of releases. > > > Thoughts? > > > The only > outstandi
ng question is then what do we do about migrating > the issue (do > we copy issues across to Github?). Perhaps it might be a good > opportunity > for a clean slate. > > > -ash > > > > > > > > > > > > -- Jarek Potiuk Polidea | Principal Software Engineer M: +48 660 796 129 <+48660796129> [image: Polidea]

Re: [DISCUSS] Stop using Jira (since we aren't using it properly)

[Jarek Potiuk <Ja...@polidea.com>]

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 ones a week later. They will still be there (but closed) and we
can always ressurrect them as needed.

I think we can do it at any time (maybe after or at 1.10.10 release).

J.

On Mon, Mar 16, 2020 at 1:02 PM Jarek Potiuk <Ja...@polidea.com>
wrote:

> 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 "work" +
> "create" +" submit" sequence - without the unnecessary hassle. You can
> assign milestones/projects/label the same way on both. We actually found
> that even when we use them in some other projects - they become
> unnecessary. I think eventually there should be a way to convert an issue
> into PR :). Even if we want to use Github Projects eventually, we can add
> PRs to projects similarly as issues.
>
> 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.
>
> J.
>
>
> On Mon, Mar 16, 2020 at 12:46 PM Ash Berlin-Taylor <as...@apache.org> wrote:
>
>> > 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 we can use Github issues for simple use, which is to report some
>> bugs/questions by users, who are not necessarily planning to create a PR
>> soon.
>> Yes, that was what I meant but I wasn't clear; I was just using "Github
>> Issues" as a collective product name, and not saying we need an issue for
>> every PR.
>>
>> -ash
>>
>> On Mar 16 2020, at 11:42 am, Sumit Maheshwari <su...@gmail.com>
>> wrote:
>> > 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 we can use Github issues for simple use, which is to report some
>> bugs/questions by users, who are not necessarily planning to create a PR
>> soon. Also, if we go this route, then we can do the one time Jira cleanup
>> and port only valid issues in Github. On Mon, Mar 16, 2020 at 5:07 PM Ash
>> Berlin-Taylor wrote: > 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 16 March 2020 at 12:33:27, Ash
>> Berlin-Taylor (ash@firemirror.com > (mailto:a
>> sh@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 creating new Jira >
>> tickets, rather than searching to see if there already exists a ticket for
>> > that feature. > > > For example:
>> https://issues.apache.org/jira/browse/AIRFLOW-6987 and >
>> https://issues.apache.org/jira/browse/AIRFLOW-2824 (I'm not trying to >
>> pick on anyone involved here, I just happened to notice this) > > >
>> Additionally most of the committers follow a similar path of "work on >
>> feature, open Jira ticket just before creating PR". > > > I am proposing we
>> migrate over to Github issues and drop the > requirement to have a jira
>> ticket for PRs. > > > The one downside is we might get people opening
>> issues for as an > "help, how do I do this" -- I think we can address that
>> by having an issue > template saying something like "DO NOT OPEN AN ISSUE
>> ASKING FOR HELP - ask > on user
>> s@ or join slack". > > > The only other thing Jira currently gives us is
>> the ability mark tasks > for "backporting" -- I think we can replace that
>> with Github Milestones. > Kaxil or I will happily update the scripts we use
>> to build/check the status > of releases. > > > Thoughts? > > > The only
>> outstanding question is then what do we do about migrating > the issue (do
>> we copy issues across to Github?). Perhaps it might be a good > opportunity
>> for a clean slate. > > > -ash > > > > > > > > > >
>>
>>
>
> --
>
> 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: [DISCUSS] Stop using Jira (since we aren't using it properly)

[Jarek Potiuk <Ja...@polidea.com>]

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 "work" +
"create" +" submit" sequence - without the unnecessary hassle. You can
assign milestones/projects/label the same way on both. We actually found
that even when we use them in some other projects - they become
unnecessary. I think eventually there should be a way to convert an issue
into PR :). Even if we want to use Github Projects eventually, we can add
PRs to projects similarly as issues.

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.

J.


On Mon, Mar 16, 2020 at 12:46 PM Ash Berlin-Taylor <as...@apache.org> wrote:

> > 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 we can use Github issues for simple use, which is to report some
> bugs/questions by users, who are not necessarily planning to create a PR
> soon.
> Yes, that was what I meant but I wasn't clear; I was just using "Github
> Issues" as a collective product name, and not saying we need an issue for
> every PR.
>
> -ash
>
> On Mar 16 2020, at 11:42 am, Sumit Maheshwari <su...@gmail.com>
> wrote:
> > 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 we can use Github issues for simple use, which is to report some
> bugs/questions by users, who are not necessarily planning to create a PR
> soon. Also, if we go this route, then we can do the one time Jira cleanup
> and port only valid issues in Github. On Mon, Mar 16, 2020 at 5:07 PM Ash
> Berlin-Taylor wrote: > 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 16 March 2020 at 12:33:27, Ash
> Berlin-Taylor (ash@firemirror.com > (mailto:a
> sh@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 creating new Jira >
> tickets, rather than searching to see if there already exists a ticket for
> > that feature. > > > For example:
> https://issues.apache.org/jira/browse/AIRFLOW-6987 and >
> https://issues.apache.org/jira/browse/AIRFLOW-2824 (I'm not trying to >
> pick on anyone involved here, I just happened to notice this) > > >
> Additionally most of the committers follow a similar path of "work on >
> feature, open Jira ticket just before creating PR". > > > I am proposing we
> migrate over to Github issues and drop the > requirement to have a jira
> ticket for PRs. > > > The one downside is we might get people opening
> issues for as an > "help, how do I do this" -- I think we can address that
> by having an issue > template saying something like "DO NOT OPEN AN ISSUE
> ASKING FOR HELP - ask > on user
> s@ or join slack". > > > The only other thing Jira currently gives us is
> the ability mark tasks > for "backporting" -- I think we can replace that
> with Github Milestones. > Kaxil or I will happily update the scripts we use
> to build/check the status > of releases. > > > Thoughts? > > > The only
> outstanding question is then what do we do about migrating > the issue (do
> we copy issues across to Github?). Perhaps it might be a good > opportunity
> for a clean slate. > > > -ash > > > > > > > > > >
>
>

-- 

Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer

M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>

Re: [DISCUSS] Stop using Jira (since we aren't using it properly)

[Ash Berlin-Taylor <as...@apache.org>]

> 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 we can use Github issues for simple use, which is to report some bugs/questions by users, who are not necessarily planning to create a PR soon.
Yes, that was what I meant but I wasn't clear; I was just using "Github Issues" as a collective product name, and not saying we need an issue for every PR.

-ash

On Mar 16 2020, at 11:42 am, Sumit Maheshwari <su...@gmail.com> wrote:
> 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 we can use Github issues for simple use, which is to report some bugs/questions by users, who are not necessarily planning to create a PR soon. Also, if we go this route, then we can do the one time Jira cleanup and port only valid issues in Github. On Mon, Mar 16, 2020 at 5:07 PM Ash Berlin-Taylor wrote: > 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 16 March 2020 at 12:33:27, Ash Berlin-Taylor (ash@firemirror.com > (mailto:a
sh@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 creating new Jira > tickets, rather than searching to see if there already exists a ticket for > that feature. > > > For example: https://issues.apache.org/jira/browse/AIRFLOW-6987 and > https://issues.apache.org/jira/browse/AIRFLOW-2824 (I'm not trying to > pick on anyone involved here, I just happened to notice this) > > > Additionally most of the committers follow a similar path of "work on > feature, open Jira ticket just before creating PR". > > > I am proposing we migrate over to Github issues and drop the > requirement to have a jira ticket for PRs. > > > The one downside is we might get people opening issues for as an > "help, how do I do this" -- I think we can address that by having an issue > template saying something like "DO NOT OPEN AN ISSUE ASKING FOR HELP - ask > on user
s@ or join slack". > > > The only other thing Jira currently gives us is the ability mark tasks > for "backporting" -- I think we can replace that with Github Milestones. > Kaxil or I will happily update the scripts we use to build/check the status > of releases. > > > Thoughts? > > > The only outstanding question is then what do we do about migrating > the issue (do we copy issues across to Github?). Perhaps it might be a good > opportunity for a clean slate. > > > -ash > > > > > > > > > >

Re: [DISCUSS] Stop using Jira (since we aren't using it properly)

[Sumit Maheshwari <su...@gmail.com>]

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 we can use Github issues for simple use, which is to report some
bugs/questions by users, who are not necessarily planning to create a PR
soon.

Also, if we go this route, then we can do the one time Jira cleanup and
port only valid issues in Github.

On Mon, Mar 16, 2020 at 5:07 PM Ash Berlin-Taylor <as...@firemirror.com>
wrote:

> 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 <bd...@gmail.com> wrote:
> > Honestly, I think both suck. So I can go either way
> >
> >
> > On 16 March 2020 at 12:33:27, Ash Berlin-Taylor (ash@firemirror.com
> (mailto:ash@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 creating new Jira
> tickets, rather than searching to see if there already exists a ticket for
> that feature.
> > > For example: https://issues.apache.org/jira/browse/AIRFLOW-6987 and
> https://issues.apache.org/jira/browse/AIRFLOW-2824 (I'm not trying to
> pick on anyone involved here, I just happened to notice this)
> > > Additionally most of the committers follow a similar path of "work on
> feature, open Jira ticket just before creating PR".
> > > I am proposing we migrate over to Github issues and drop the
> requirement to have a jira ticket for PRs.
> > > The one downside is we might get people opening issues for as an
> "help, how do I do this" -- I think we can address that by having an issue
> template saying something like "DO NOT OPEN AN ISSUE ASKING FOR HELP - ask
> on users@ or join slack".
> > > The only other thing Jira currently gives us is the ability mark tasks
> for "backporting" -- I think we can replace that with Github Milestones.
> Kaxil or I will happily update the scripts we use to build/check the status
> of releases.
> > > Thoughts?
> > > The only outstanding question is then what do we do about migrating
> the issue (do we copy issues across to Github?). Perhaps it might be a good
> opportunity for a clean slate.
> > > -ash
> > >
> > >
> >
>
>

Re: [DISCUSS] Stop using Jira (since we aren't using it properly)

[Ash Berlin-Taylor <as...@firemirror.com>]

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 <bd...@gmail.com> wrote:
> Honestly, I think both suck. So I can go either way
>
>
> On 16 March 2020 at 12:33:27, Ash Berlin-Taylor (ash@firemirror.com (mailto:ash@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 creating new Jira tickets, rather than searching to see if there already exists a ticket for that feature.
> > For example: https://issues.apache.org/jira/browse/AIRFLOW-6987 and https://issues.apache.org/jira/browse/AIRFLOW-2824 (I'm not trying to pick on anyone involved here, I just happened to notice this)
> > Additionally most of the committers follow a similar path of "work on feature, open Jira ticket just before creating PR".
> > I am proposing we migrate over to Github issues and drop the requirement to have a jira ticket for PRs.
> > The one downside is we might get people opening issues for as an "help, how do I do this" -- I think we can address that by having an issue template saying something like "DO NOT OPEN AN ISSUE ASKING FOR HELP - ask on users@ or join slack".
> > The only other thing Jira currently gives us is the ability mark tasks for "backporting" -- I think we can replace that with Github Milestones. Kaxil or I will happily update the scripts we use to build/check the status of releases.
> > Thoughts?
> > The only outstanding question is then what do we do about migrating the issue (do we copy issues across to Github?). Perhaps it might be a good opportunity for a clean slate.
> > -ash
> >
> >
>

Re: [DISCUSS] Stop using Jira (since we aren't using it properly)

[Bolke de Bruin <bd...@gmail.com>]

Honestly, I think both suck. So I can go either way


On 16 March 2020 at 12:33:27, Ash Berlin-Taylor (ash@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 creating new Jira
tickets, rather than searching to see if there already exists a ticket for
that feature.
For example: https://issues.apache.org/jira/browse/AIRFLOW-6987 and
https://issues.apache.org/jira/browse/AIRFLOW-2824 (I'm not trying to pick
on anyone involved here, I just happened to notice this)
Additionally most of the committers follow a similar path of "work on
feature, open Jira ticket just before creating PR".
I am proposing we migrate over to Github issues and drop the requirement to
have a jira ticket for PRs.
The one downside is we might get people opening issues for as an "help, how
do I do this" -- I think we can address that by having an issue template
saying something like "DO NOT OPEN AN ISSUE ASKING FOR HELP - ask on users@
or join slack".
The only other thing Jira currently gives us is the ability mark tasks for
"backporting" -- I think we can replace that with Github Milestones. Kaxil
or I will happily update the scripts we use to build/check the status of
releases.
Thoughts?
The only outstanding question is then what do we do about migrating the
issue (do we copy issues across to Github?). Perhaps it might be a good
opportunity for a clean slate.
-ash