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 <jarek.pot...@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.ro...@polidea.com > > Check out our projects! > > Karolina Rosół > > Polidea | Project Manager > > M: +48 606 630 236 > E: > karolina.ro...@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]
