> 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 <jarek.pot...@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 (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]

Reply via email to