Hey Dominique, thanks for reminding me about Teams, that's a good entry point. Is there a simple and reliable way of having an estimate of how many people are actively contributing to these teams (not gonna email them all...)?

On 1/19/21 2:37 PM, Simon Lees wrote:

On 1/18/21 8:58 PM, Adrien Glauser wrote:

...

Hey Dominique, thanks for reminding me about Teams, that's a good entry point. Is there a simple and reliable way of having an estimate of how many people are actively contributing to these teams (not gonna email them all...)?

I think really though this is asking the wrong question. The much more useful question is, "what is a good way to contact these teams" is it via mailing list? Discord, IRC or something else? or in some cases should you contact an individual.

I'll answer on behalf of the Xfce team that it's easy to reach us. We have a dedicated ML, Telegram group, Matrix and Discord channels. We document it in our wiki page [1], if you scroll down to the section "Communicate" and can also see who the team members are. [1] https://en.opensuse.org/Portal:Xfce -- Maurizio Galli Xfce Team https://en.opensuse.org/Portal:Xfce

Wrong and correct questions I am interested in an estimate of the number of people active because it might help me determine how I should speak to them when advocating the programmatic solution hinted at in the above discussion. When you know how many people are working on task t, it gives you a clue (not decisive, but a clue nonetheless) as to whether these people are working over- or under capacity. This makes a difference to the value-proposition of a programmatic solution.

(To be sure, the programmatic solution I have in mind applies a maintainer-based model across the entire board of oS activities, with maintainers reporting on the health and needs of their group and activities. Decentralized, non-hierarchical, bottom-up, centered on people, distributing the burden of producing reliable information about your activities evenly across maintainers)

Resurect the portal If can give me a list of data collected from "portals", that would help me.

Not actionable information for me, unfortunately. If there is no simple an reliable way of discovering how many people do what in the oS community, the best I can do is simply put my faith in the survey (https://en.opensuse.org/End-of-year-surveys/2020/Graphs#Contributors). I wish we had a simple way of verifying these numbers and to map them into actual subprojects, --- in particular to leaves in my gitmind chart. Perhaps an oS census? ;P

Am January 20, 2021 11:03:08 AM UTC schrieb Adrien Glauser :

If there is no simple an reliable way of discovering how many people do what in the oS community,

GDPR anyone? I'm very happy that there is "no simple way" to get public information about what I'm doing where and when. I'm doing stuff in different openSUSE areas, enough to convince the membership committee to accept my application as member in the past. But I have no interest to tell anybody in the world what I'm doing or where are my personal areas of interest just to provide statistics. Statistics that are outdated when created and can be misused in any form (as statistics always tend to get misused). What about just listing teams/projects of openSUSE and leave it to the people, if they want to get publicly connected to them? Note: I see writing and using tools that analyze existing data for different use cases (if a listed member is still active in any form - for example) without pre-approval from the affected users also as critical. But it looks like I'm alone with my doubts, so feel free to ignore me. Regards, Lars

In fact when I started this topic I had in mind something like a mindmap-like representation of the different activities and groups in terms of the "is a part of" or "is an instance of", hopefully leading to a concrete list of people. (The mind map was soon added in my first or second reply above.) The goal was to help newcomers and potential contributors grasp visually what the openSUSE was made of. But all along I started from the presupposition that most people on this ML knew what most of the most active contributors in openSUSE were doing. But this presuppostion was wrong; seeing from the answers, there is no common knowledge about what most active people do. When a key presupposition like that is flouted, better let the topic die, because it's beyond repair. I'll try to find a more ingenuous way of extracting this information for newcomers and potential contributors -- it's no big deal!

On Mon, 2021-01-18 at 10:58 +0000, Adrien Glauser wrote:

If anyone is interested in helping me, I am adding a link to collaborate on a mindmap for the purpose of turning the structure that emerges from https://en.opensuse.org/Portal:Teams into a structure that more adequately captures reality:

https://gitmind.com/app/join/c991489249 Code：4657

The goal is to have all nodes terminate in leaves that are a list of "last people publicly known to do actual work there". People can of course have their name occur at multiple leaves.

Without going into the details, but looking at the right side - 'new struture': Maybe I'm a bit silly, but what is the difference between 'Factory (below OBS)' and 'Tumbleweed (below distribution)' ? As it stands now, Factory and Tumbleweed 'are the same thing' -with a time gap: It's called Factory (like openSUSE:Factory) where we build the distro, then hand it out to QA - once QA passed it, the SAME thing is called 'Tumbleweed, the rolling distro that you can install' Cheers, Dominique

On Mon, 2021-01-18 at 12:16 +0000, Adrien Glauser wrote:

I am assuming that there is a difference between (a) the set of people working to produce Tumbleweed builds -- through the Factory -> openQA pipeline -- and (b) the set of people maintaining OBS and openQA in general (i.e. the public tools).

I've amended the map to better reflect this distinction.

Hi Adrien, Some feedback on the "New Structure" 1. Both openQA and OBS are openSUSE Sub Projects and part of the openSUSE Project, not seperate as currently mapped. 2. Kubic is not mentioned and should be marked as a derivative of MicroOS. (If we want to be really nitpicky, the kubic-project is a subproject of openSUSE that produces both MicroOS and Kubic, but I concur that modelling to the distributions might make more sense than modelling to the organisational reality..even though that's the whole point of this exercise, isn't it?) 3. MicroOS is derived from the Factory process just like Tumbleweed 4. Tumbleweed/Factory release management is missing entirely - this is not the same as openQA & Snapshots Review 5. Staging Management is missing entirely for both Leap and Factory/Tumbleweed - though could be argued to be part of release mangement 6. Leap uses openQA and has reviewers also.. 7. There is no mention of several other openSUSE Sub Projects including YaST, Kiwi and Uyuni 8. There is no mention of Translations 9. There is no mention of the Membership Officials, an absoultely key part of our governance model 10. There is no mention of our Maintenance and Security Teams 11. There seems to be a suspicious lack of all of our more developer centric teams from this list (eg. Kernel, Language teams, Virtualision) 12. All of the packaging & desktop environment teams seem to be ommitted.. And I'm probably missing some more things also. While I understand the potential benefit of this documentation exercise, I would like to express a few notes of caution A. Ommitting people from this document is a surefire way to upset people. I understand though that no document put together by one person is going to get it right first time, just hope that everyone is utterly clear this needs to be a living document that will almost certainly always be out of date. B. Given the openSUSE Project's ethos of "Those who do, decide" [1], is documenting the current structure actually the best way of addressing concerns regarding visibility? I can make a new team for a new initiative today, any team can decide to cease work quietly or noisily tomorrow. Plus not all of our current teams are necessarily open to anyone to just roll up and join, some teams are more open than others, and that's fine. I would postulate that if we want to improve visibility we need to improve things to make it easier for contributors (not just teams, but those working individually) to speak up about what they're doing and when/where/in what way they need help. C. How do you intend to present this finished document in a way that doesn't start locking mindsets on a track that you must be part of a team before being able to contribute to openSUSE? We're an open community, and teams are *part* of that story, sure, but not the entry point to joining the community. [1] https://rootco.de/2016-04-03-opensuse-and-you/ -- Richard Brown Linux Distribution Engineer - Future Technology Team    Phone +4991174053-361 SUSE Software Solutions Germany GmbH,  Maxfeldstr. 5,  D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer

On Mon, 2021-01-18 at 15:07 +0000, Adrien Glauser wrote:

Hey Richard, thanks for your insightful comments.

Fixed: 1-12 except for 10.

...

10. There is no mention of our Maintenance and Security Teams

Where would you put those?

I wouldn't, I don't think any org chart design aptly models the work that they, or many others do. For the Maintenance team you'd need to put them somewhere with lines to packages, kernel, desktop environment, Leap, package review, release management, staging management, OBS, and openQA, and translations For the security team you'd need all the same lines, plus lines to Tumbleweed/Factory, Kubic, MicroOS Looking at your current version, you state the goal is to eventually include all names of individuals So I have a premptive question - where would you put me? I contribute to release/staging management in Factory, and MicroOS, and Kubic In the past I used to also contribute to openQA and GNOME, and the membership officials, and the wiki, and translations..just how many lines to individuals are you going to have when you start adding everyones names to this chart? And there's people with a far more diverse bredth of contributions than me.. are you sure this Project is going to be a good way of modelling who we have doing what? Also, looking at the current revision, I see some more issues 1- "language teams and translations" - by "language teams" I meant python, golang, etc (language integration on the old version)...so they're misplaced for sure. Plus our translation teams primarily translate the distribution. If you look at https://l10n.opensuse.org/ you'll see that 'content' is a small subset of what they do. 2- "membership" - our membership only have a role in our governance, why are you treating them seperately from the Board or election committee? 3- Why do you continue to treat openQA as if it's chained after OBS? Both projects are not hard-coupled together in any way, manner or form. 4- What are "public OBS tools" and "public openQA instances"? There are build.opensuse.org and openqa.opensuse.org, but those are covered by "oS OBS tools" and "oS openQA instance" surely? 5. Aren't "oS OBS tools" and "oS openQA instance" infrastructure? 6. Why have "builds", Tumbleweed/Factory, MicroOS, Kubic, etc all derive from "os OBS tools" (the tool they use) but not have "translations" derive from a "weblate" bullet or the "election commitee" derive from the "election platform" bullet? There seems to be a mixup between organisational relationships and tool relationships..and I don't think tool relationships have a place in an organisation chart..

...

While I understand the potential benefit of this documentation exercise, I would like to express a few notes of caution

...

Does this really improve visibilty? Is it the best way? How do you avoid locking mindset?

It's one way, it's quite cheap, is easy to comprehend, and I am just getting warmed up -- a programmatic solution using a maintainer- centric workflow might be next on the line. I agree that only a programmatic solution will stand the test of time in view of how things are bound to evolve. Also I don't mind locking mindsets, as long as mindsets have the opportunity of frequently locking onto the next snapshot in the evolution of the entire map (which requires a programmatic solution).

A programmatic solution for a very human issue? Interesting How are you going to get human buy-in to that programmatic solution? And what if the humans don't conform to your self-declared programatic solution? Remember we're all volunteers here..impliment something programmatically that disrupts, upsets, or otherwise doesn't gel with the way the humans of the Project want to work, and we might find ourselves with less humans in the Project..

On Mon 2021-01-18, Richard Brown wrote:

7. There is no mention of several other openSUSE Sub Projects including YaST, Kiwi and Uyuni

I checked in with the Uyuni folks last year, and they did not see Uyuni as an openSUSE (sub)project and, at that point, did not want to change that. That can evolve, of course, but maybe something like affilated projects makes sense?

I can make a new team for a new initiative today, any team can decide to cease work quietly or noisily tomorrow.

That's a good point. And..

Plus not all of our current teams are necessarily open to anyone to just roll up and join, some teams are more open than others, and that's fine.

...in some cases it even requires an election or nomination by the board to join a team. ;-) I believe there's, very roughly, three flavors of team: 1. Those required by our "constitution" (election rules,...) - board, election officials, membership officials 2. Those the project remotely similar to as we know it cannot really do without - heroes, marketing, Linux release engineering,... 3. Many, many others, as Richard pointed out.

I would postulate that if we want to improve visibility we need to improve things to make it easier for contributors (not just teams, but those working individually) to speak up about what they're doing and when/where/in what way they need help.

Yes. And it would also be lovely for teams to share a bit about themselves regularly (not necessarily often, regularly), similar to the above. Gerald

Am Mittwoch, 20. Januar 2021, 00:42:33 CET schrieb Gerald Pfeifer:

On Mon 2021-01-18, Dominique Leuenberger / DimStar wrote:

...

Without going into the details, but looking at the right side - 'new struture': Maybe I'm a bit silly, but what is the difference between 'Factory (below OBS)' and 'Tumbleweed (below distribution)' ?

As it stands now, Factory and Tumbleweed 'are the same thing' -with a time gap:

It's called Factory (like openSUSE:Factory) where we build the distro, then hand it out to QA - once QA passed it, the SAME thing is called 'Tumbleweed, the rolling distro that you can install'

At the risk of being yelled at and/or starting the mother of all threads:

How about "merging" Factory and Tumbleweed and only use one name?

We don't have Squaric and Kubic or other such pairs elsewhere, do we?

For those on this list it's probably not an issue; for someone not so closely involved it can be a bit, umm, confusing.

...but we are not promoting Factory somewhere to the world. We use it more internally to denote 'this is the bleeding untested stuff'. Does Kubic not follow Tumbelweed development? Ah, so 'no' in my opinion Cheers Axel

On Wed 2021-01-20, Richard Brown wrote:

...

...

How about "merging" Factory and Tumbleweed and only use one name? Also we may not have 'Squaric and Kubic' paired but Kubic, MicroOS, Tumbleweed and SUSE SLE are all paired/derived from Factory.

Indeed, that's the key point I recalled after hitting send. Suggestion retracted. We just need to be careful communicating with users, especially new ones, to focus on the projects they are using, not the underlying stream that Factory is Gerald