+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 <[email protected]> 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 <[email protected]> > 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 ([email protected] > (mailto: > a > [email protected])) 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] > >
