This topic is for discussion about topics that would make the openSUSE Project more approachable and streamline operations in ways that help the community be more effective in their contributions.
Ideas related to project governance should be put in the appropriate discussion - this is to cover things that are not explicitly part of the overall governance structure.
I think it’s worth considering who uses or wants to use openSUSE software and projects, in order to understand how to make their lives easier.
Here is a table with two dimensions of knowledge that I think would be the most relevant measurements for people engaging with openSUSE.
It is important to recognise that knowledge in these dimensions are not a gradient, but rather a spectrum – individuals can have high levels of knowledge in some specific areas of a dimension, without being knowledgeable in others.
| Low Linux knowledge | High Linux knowledge | |
|---|---|---|
| Low openSUSE knowledge | Switching to Linux from Windows/macOS | Prospective contributor |
| High openSUSE knowledge | N/A | Contributor |
This dimension of knowledge refers to an individual’s understanding and familiarity with GNU + Linux systems.
For users, it refers to understanding and familiarity with things such as:
For contributors, knowledge is saturated around topics such as writing software and building packages.
This dimension of knowledge refers to an individual’s understanding and familiarity with the openSUSE project. It includes knowledge about:
Developing knowledge about the openSUSE project generally requires a requisite amount of understanding about Linux systems. Further, being a contributor to openSUSE requires a requisite amount of knowledge about the both the wider project, and knowledge in areas relevant to the contributions an individual would like to make.
I think there are three goals/ideals to work towards:
These are my first thoughts around this, let me know if you have anything you agree/disagree with here
This is a good write-up. I am curious if this is something we can expand on the Wiki and write some guides or documentation for people on these different levels of knowledge.
The goal is to keep the conversation at this stage in one place, so let’s discuss the ideas here and then, when we have a concrete proposal, we can move it to the wiki.
I agree that this is a great starting place.
What do you think we currently do? 
Are you suggesting that what aesara has outlined is what we do? If so, do you think we do it well, or is there room for improvement? If so, how do you think we could improve it?
This would be the problem. People don’t know how things work. It’s nice that you feel you have a firm grasp on it, but that’s not particularly useful to anybody else.
@aesara talks about general onboarding of contributors. Turning people new to Linux/openSUSE that are not very knowledgeable into contributors that are (more) knowledgeable about Linux/openSUSE. That is the path that people take. That is what we do in openSUSE.
What are you talking about? Who would “people” be? What are “things”? If you want to improve something you should be specific…
And you think we do it well? You think there’s no room for improvement?
That’s certainly an opinion. As someone who’s been here for a while, I’m sure your view that “things are just fine as they are” makes sense to you. I would suggest that looking at it through the lens of someone who wants to contribute but doesn’t know where to start might be a more useful view if we want to attract more contributors.
Unless, of course, you don’t think we need more contributors, either.
From context, it seems clear to me that “people” would be “potential contributors”.
Processes and procedures for how contributions are made and accepted in the project, not just from a code perspective, but everything else.
ie, what these discussions are talking about.
I don’t think it’s very productive to be asking for a problem restatement with every message posted.
I find that unless they’re paid to contribute, people usually only contribute to software they use. The entry point of contributions is when someone finds some sort of “deficiency” with the software they’re using, and wish to help to get rid of that deficiency.
There are a number of barriers that prevent the best outcome (the user contributing a fix), which I hope I’ve successfully outlined in the following flowchart:
People have been discussing whether posts like this, that “state the obvious” waste time. I feel that it’s important to establish ground truth and frameworks for thought, as new ideas are very easy to shoot down, and if criticism is unguided, discussions will devolve quickly.
In future I will discuss actual instances of issues I’ve identified with the openSUSE project. I felt that it was important to create these posts before writing those criticisms, as it sets a “barometer” to not only identify problems in the pipeline, but also measure how effective potential solutions can be.
I just realised that “available resources” has an objective component to it, but also a perceived component. It’s not “am I objectively capable of fixing this problem?”, but rather “how difficult to I perceive fixing this problem to be?”
That’s a good observation - and I think an important one to think about when it comes to determining how best to onboard those who want to contribute, but don’t know where or how to start. If a prospective contributor can’t easily find the information they need to get started, that raises the barrier to entry (perceptually or otherwise) and makes it less likely for them to step up.
It’s not a waste of time, at all, as far as I’m concerned, a lot of times we just take it as read that people have the same understanding of things that we do, when oftentimes it isn’t the case
Errata: reporting a bug isn’t promised and falls under the perview of “collecting feedback”, which is a nightmare in and of itself. Updated flowchart presented below:
I add: especially for users of other languages ​​and even more so for those who are not very experienced in handling software projects.
Even I don’t find it easy!
How about you resist the urge to try to assess my motive for asking questions or my opinions? You don’t know me, you don’t know my motives or opinions If something is unclear to you, just ask.
Let’s pretend you have… My motive of asking @aesara this question is that everybody here needs to understand that openSUSE consists of many different sub-communities. Each of those has their own rules of engagement, their own set of advantages and problems. If we want to improve those sub-communities, then generalization and abstraction is not the best approach. The opposite is: be specific as possible.
One suggestion I have is that the project should have at least enough contributors to keep up with maintaining the existing infrastructure, or the amount of existing infrastructure should be consolidated/reduced. I tend to believe that there currently aren’t enough contributors to cover everything; the openSUSE software portal, which I’ve been told is mostly abandoned, is the most visible example to me. There are also many matrix channels that are completely dead for months. I believe that abandoned infrastructure and abandoned online spaces give the impression that the project has lower activity, when in reality that’s not the case.
@cbmiller For Matrix, it’s likely the changes due to unwanted spam etc that it was changed, @crameleon would have more info on this…
I actually quite like the software portal, it’s a good place to find references for which software does or does not have a package without requiring a CLI tool, can also be faster than zypper, too.
The ability to easily search for packages should exist, although perhaps the functionality is duplicated in OBS and that OBS should be the focus instead…
