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.sha...@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 <jarek.pot...@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 <turbas...@apache.org> > wrote: > > > Yes, vote and switch. > > > > > > On Mon, Mar 16, 2020 at 3:06 PM Ash Berlin-Taylor <a...@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 <turbas...@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 > > > (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: > 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.slowikow...@polidea.com Unique Tech Check out our projects! <https://www.polidea.com/our-work>
