Improve contribution experience

[zhukovgreen]

ref OAMG-3458

This epic introduces several improvements in the contribution experience. The following areas will be affected:

Running linters

• use pre-commit hooks as a way to run linters use pre-commit hooks as a way to run linters #561
• use flake8 as the only code linting provider use flake8 as the only code linting provider #562
• run linters only for python3 (experiment) run linters only for python3 (experiment) #563
• add interrogate docstrings plugin for pre-commit

More autoformatting and more strict code format linter (i.e. automatic import sorting and code formatting etc.)

• use isort pre-commit (https://github.com/timothycrosley/isort) as a sorting tool of imports use isort pre-commit (https://github.com/timothycrosley/isort) as a sorting tool of imports #564
• use black pre-commit (https://github.com/psf/black) as an autoformatting tool use black pre-commit (https://github.com/psf/black) as an autoformatting tool #565

Automatic security vulnerabilities detection

• use bandit security linter (https://github.com/PyCQA/bandit) use bandit security linter #574

Updating dependencies

• use poetry instead of requirements.txt use poetry instead of requirements.txt #566
• migrate all configs to pyproject.toml migrate all configs to pyproject.toml #567
• use Dependabot bot (https://dependabot.com/) to update our dependencies use Dependabot bot (https://dependabot.com/) to update our dependencies #568

Reporting code coverage

• use codecov.io (https://codecov.io) for automation in reporting test coverage use codecov.io (https://codecov.io) for automation in reporting test coverage #569
• find and implement a convenient way to get comprehensive coverage report locally via cli find and implement a convenient way to get comprehensive coverage report locally via cli #570

Create templates for new issues and merge requests

• create templates for new issues create templates for new issues #571
• create templates for new merge requests create templates for new merge requests #572

Ensuring the improvements will have a persistent character

Set up a practice where each month we'll create an MR from the branch chore/monthly-maintenance/{month}-{year} which includes:

• bumping versions of hooks in the pre-commit config file
• updates to configs
• possible fixes in linting related problems within our codebase
• adding new features to improve contribution experience (i.e. new bots, automation, ci etc.)
• Automate monthly-maintenance process Automate monthly-maintenance process #573

After successful implementation of tasks in this epic repeat this to other OAMG repos

• Improve contribution experience in https://github.com/oamg/leapp
• Improve contribution experience in https://github.com/oamg/convert2rhel

[pirat89]

Discussed in the past, we do not want to have tamplates for PRs. Only reason why we have tamplates for issues is to ensure that people deliver all needed information for us (or at least as much as possible for the report) so we do not have to ask for it every time. But it can be discussed again, whether we find a good reason to have it.

Btw, for new issues we have already template: https://github.com/oamg/leapp-repository/issues/new?labels=bug&template=bug_report.md

[zhukovgreen]

@pirat89 Petr, please give a me link to the context behind "discussed in the past". Doing merge requests review I see a lot of advantages to have a MR template.

I also familiar with the bug report template, however, I hope, we'll have not only bug report issues, but also feature proposals etc.

[pirat89]

@zhukovgreen Outcome of the discussion was, that we want the template just for the stuff to make it clear that people will give us needed information, to ensure that we will be able to reproduce the problem and see how to fix it and in the end safe time for everyone. In case of PRs and features, it seems just as bureaucracy and it's kind of impossible to create template, that will not look like that for every case. In many cases, people (me including) will do just Ctrl+A -> Delete or use the blank format. As well, in many cases, the short description (or let's say free form) is better then description satisfying templates. Similar in case of features. If we create templates, we will need to be clear that people do not have to use it - and in such a case I believe they will not use it in most cases, so it's question whether it worths to spend time on it.

But as I wrote, we can open the discussion (ML could be good place) to discuss that, whether there is enough pros to do it.

[pirat89]

To make it clear, I have been that time propagator of templates in our projects at least to make for people an option, how to fill description for RFE and PR if they do not want to use the free form. But I have to agreed that it really was not worthy to create the other two templates.

[GAZDOWN]

@pirat89 I actually see a great benefit of having a template for PR. strictly speaking, having stuff in unified form each time I open a new PR description as reviewer will save some time which will eventually turn into significant amount given how many reviews we do. Another point of view here is from contributor side - I will have a guidance of what should I provide as information. Not everybody knows what to provide or speaks well enough english to provide well formatted description, etc. This way we can always catch the point of PR by providing simple means in the template. And yes, it may seem to be a bureaucratic at first glance, but the template is a format suggestion, not mandatory thing and we should encourage people to use it instead of going the obvious way Ctrl + A then delete.