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 <a...@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 <sumeet.ma...@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 (a...@firemirror.com > (mailto:a > s...@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/>
