Yeah. It's just normal that people do not read instructions. But the more we repeat the message in various places, the more people will notice. It's just a matter of being persistent and patient.
How about the other part about lightweight process? Anyone has opinion on that? I think we should at least discuss it before we move 100s of issues to Github without knowing what we are going to do with them. Just another voice in the discussion: I just got this message from a user (Slava) who tried to post to the mailing list but had trouble with mailer only sending HTML (rejected by the discussion group) , and posted it to me on Slack. I am forwarding it here - to add some thoughts. I do not necessary think we should do it this way, but maybe this might be something that we could start our discussion on >>>>>>>>>>>> Quote from Slava follows hi still can't send to the mailing list... I gave up as it's too much trouble.. I'll share my thoughts about the Jira-Github thread. I think that Airflow is trying to relay on automated process too much. To me it sounds like at the end the github issues will be a mess just like the Jira is. Please see: https://github.com/pandas-dev/pandas/issues They have over 3000+ open issues yet it magnificently organised and well understood by everyone. no duplications, no hard time finding issues, labels are well used, each issue is designated to a specific planed release so it's easy to know what still needed to fix before releasing next version What they do? New issues has no label - This basically means "This issue needs triage". This issues are being processed by authorised members of the community. Process includes: 0. Making sure it's not duplicated/wrong etc.. 1. adding labels 2. adding release milestone (including SomeDay or ContributorsWelcome) 3. adding comments or engage discussion on what is actually needed so that the person who start working on the issue won't guess. In airflow the approach is a bit different, it's more like "first open PR then we'll discuss it". it's always possible to know which issues haven't been reviewed yet - simply see the issues without labels or milestone. J, On Fri, Mar 27, 2020 at 2:00 PM Ash Berlin-Taylor <a...@apache.org> wrote: > 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] > > -- Jarek Potiuk Polidea <https://www.polidea.com/> | Principal Software Engineer M: +48 660 796 129 <+48660796129> [image: Polidea] <https://www.polidea.com/>
