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
