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ół <karolina.ro...@polidea.com> 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 <jarek.pot...@polidea.com> > 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 <https://www.polidea.com/> | Principal Software Engineer M: +48 660 796 129 <+48660796129> [image: Polidea] <https://www.polidea.com/>
