The goal of this project is to combat the fragmentation between teams, groups and services in openSUSE.
It seems to us that openSUSE has many niche places that don't talk to each other that much, let alone report their activities to hubs accessible to outsiders or potentially interested contributors.
Also, events and activities are not always visible and more often than not, people would find out about a community event or an outage when it's too late.
We suspect that this kind of fragmentation and opacity makes it more difficult than necessary for new users to onboard the openSUSE Project and for users to enjoy it as much as it deserves.
Our hope is that in so doing we will also help strengthen the bounds between people, teams and communities.
Cross-platform (Matrix, Telegram) moderation (depends on: https://github.com/openSUSE/defrag-api/projects/2#card-64817715)
Please see deploying.md for information on how to deploy the project.
Even though this is not required, in my experience working in peers (2 people working together on different parts of the same thing) works well. This can spare you a lot of time if the other person is more familiar with the code base. The better your Issue, the more likely someone will be willing to work with you.
Important to keep in mind:
loop.run_in_executor(None, ...)
trick to support sync libraries. pytest
for it, unless your function is consumed by another function which is introduced in the same Pull Request and which does have a corresponding unittest. (Later we will need to have 1 unittest for each function though.)pipenv
, virtualenv
, venv
, etc. See this page for ideas.Architecture
Handling logic