Community mailing list archives
Re: The issue mountain on githubby
One feasible solution which I want to direct to Anthony, is the following:
GitHub server hooks would process issues and look for keywords in the issue title or body (which have to be documented prominently). When the script finds an issue, it applies corresponding labels automatically.
Some authorised community users could "tag" an issue in a comment, so the bot script would alter/close the issue. The script would check the list of authorised users against a normal text file within the repo.
Hacky, but rather easy and absolutely worthwhile.
Snap Nhomar,I deleted my part about the old drivers team as I felt like a launchpad fanboy. But even then there were hundreds of outstanding issues, but what it did was get better discussion about them.On Thu, Jul 30, 2015 at 10:42 AM, Nhomar Hernández <firstname.lastname@example.org> wrote:2015-07-28 19:02 GMT-05:00 Antony Lesuisse <email@example.com>:The solution is to create pull request telling the issue AND providing the fix. Or to quote linus 'Talk is cheap. Show me the code.' :) PLEASE dont create both an issue and a PR, if you have a patch only create a pr explaining the issue and providing the fix. It's explained here https://github.com/odoo/odoo/wiki/Contributing We mainly process PRs and moslty not issues (unless its a security problem). In 1 year we processed 2516 PRs and there are still currently 438 PR to process (please use the filter from the wiki to get the accurate number). https://github.com/odoo/odoo/wikiAnthony.I understand perfectly the point of have more priority over the issues (no brain reason here I understand).BUT.You can not have a public opensource project with almost 2000 open issues it sends (at least to pleople like me) 2 messages:1.- Community Management sucks.2.- Too complicated tool to solve issues.3.- Not organized people behind this tool.4.- This tool techinically sucks.This is mostly our complain then let me propose some constructive solutions:Opt 1.- Do again what we did in launchpad in the begining make a community "odoo-driver team" that only close label and clasify issues, this can be a selected team of 20 or 30 respected people on commuty which know that they can not push to odoo/odoo ever, it works really well in Launchpad.Opt 2.- Create a new repository odoo-issues and manage the code in odoo/odoo and manage issues in odoo-issues and left open the clasification.Opt 3.- You can dedicate a resource to label issues with a new clasification "Can be merged - Expected PR" and "Close Issues" ond/or mark as "Won't Fix".IMHO this 3 options (maybe combined) can help to close almost 2000 issues it is really desperating see that.Even the biggest tools in github do not have such number of issues.