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
