Improve development and release workflow

The development workflow can be updated to adress some current issues:

• update contributing process (PR to develop):

  • _add a contribution section to mention contributors: @kaemo @akruszewski I feel your name should be mentioned as your contribution grow more and more -> I have added a “hall of fame” badges with the number of commit of the most active people of the repo. Is it sataisfying? What other solutions would you prefer?
  • ~force the CI to fail under 100% test coverage: several recent PR have broken coverage (mainly #9 but I had spotted breaking the 100% coverage before)~ (EDIT 2020-09-26)For now, I don’t add the --cov-fail-under=100 flag to the “test” step in the build workflow because it will malke all CI fail until we add all the missing tests. I mark it as resolved and add it after the next release. I think that the codecov bot gives far enough information to take decision to merge A PR with the implications in mind.
  • update the coverage to a dedicated third party (codecov? I don’t have any preference here, an idea?) to identify more easily the coverage breaking PR.

• update release process both in the documentation and in the CI (PR to master from develop):

  • use an action to create a release in the github repo (if possible taking beeing fed automatically by the changelog, maybe create-release
  • fix the deployment to pypi and move to a public action (maybe gh-action-pypi-publish )
  • change the trigger of the worflow (closing a PR even if dismissed currently triggers the pipeline: it should only be triggered when a merge on master is completed).

Do you have any other suggestion @kaemo and @akruszewski ?

[Galileo-Galilei]

Let’s add this to the issues to adress when we’re having a call.

For the record, I think we should be pragmatic here and keep using github actions on the short term (I guess it will be easier/faster to add the actions I suggested to the existing github workflows rather to rewrite the CI even if it is not difficult, but please go ahead if you really want it 😉 ). CircleCI is definitely one of the most used, let’s keep it on the list of potential tools.

[Galileo-Galilei]

I suggest to remove the unecessarily compelx workflow of merging on develop and then on master. Since I don’t support 2 different versions at the same time, using only the master branch as the reference and release directly from it will make the CI simpler.