Create OWNERS.md

[hennevogel]

This is my proposal how we could handle governance of the openSUSE Github Organization in a more structured way. Let me know what you think @openSUSE/org-maintainer

[hennevogel]

This is inspired loosely by the kubernetes membership documentation.

[hennevogel]

This is the list of people that would drop out because of inactivity:

• @ajaeger
• @aspiers
• @coolo
• @cornelius
• @danimo
• @digitaltom
• @DimStar77
• @dmacvicar
• @flavio
• @jdsn
• @jsegitz
• @kkaempf
• @kobliha
• @lnussel
• @lrupp
• @olafhering
• @sysrich
• @wfeldt

[aspiers]

I am still using Tumbleweed on several machines but admittedly not contributing to openSUSE in any significant way at the moment so am happy to relinquish this role if that makes sense.

[simotek]

In general I think this is a good move and a positive step forward, thanks for working on it.

One question though is what happens if we get to the point of only having a handful of semi active owners with none of them having the time to nominate someone new? As a board we have recently dealt with a similar issue within the membership officials.

I guess as a last final option, the board as the administrators of the openSUSE trademark could approach github directly to add people, but it would really be nice to have a fallback process that doesn't require that. Even if it is something along the lines of "If removing inactive members would result in having X or less administrators, then new administrators must be appointed before the old ones are removed." Where X is a number like 4 or 5 etc.

Maybe its also worth nominating a time of year or a who and when the active membership list will be looked at, just so we don't end up with the case where everyone is presuming that someone else will do it. Also for the sake of the board / security team that should be providing some level of oversight at the end of the day it would be nice to easily be able to see that A. this process has been done sometime in the last 12 months, or B. This hasn't been done and then request that someone do it.

Thanks again for your work on this.

Simon

[ajaeger]

This is the list of people that would drop out
* @ajaeger

I'm fine with the proposal and the implication to be removed as I indeed did not do much work here in the last years.

[ajaeger]

LGTM, thanks Henne!

[jsegitz]

I had the role to be able to get security reports for all repositories. I don't use that information anymore, so feel free to lower my access level. Very good idea btw

[dirkmueller]

can we measure "extended period"? is it a year?

[hennevogel]

See below how we can measure it...

[dirkmueller]

Really like the idea, thansk a lot @hennevogel some inline comments, generally LGTM

[hennevogel]

One question though is what happens if we get to the point of only having a handful of semi active owners with none of them having the time to nominate someone new?

How about we cross that bridge if we come to it?

Maybe its also worth nominating a time of year or a who and when the active membership list will be looked at, just so we don't end up with the case where everyone is presuming that someone else will do it.

Looking at the audit log can be automated in a scheduled github action or even with webhooks. Should be done continuously, not once a year.

Also for the sake of the board / security team that should be providing some level of oversight at the end of the day it would be nice to easily be able to see that A. this process has been done sometime in the last 12 months, or B. This hasn't been done and then request that someone do it.

Neither the security team nor the board has oversight over anything except the things the board and the security team do...

[simotek]

One question though is what happens if we get to the point of only having a handful of semi active owners with none of them having the time to nominate someone new?

How about we cross that bridge if we come to it?

Maybe its also worth nominating a time of year or a who and when the active membership list will be looked at, just so we don't end up with the case where everyone is presuming that someone else will do it.

Looking at the audit log can be automated in a scheduled github action or even with webhooks. Should be done continuously, not once a year.

Also for the sake of the board / security team that should be providing some level of oversight at the end of the day it would be nice to easily be able to see that A. this process has been done sometime in the last 12 months, or B. This hasn't been done and then request that someone do it.

Neither the security team nor the board has oversight over anything except the things the board and the security team do...

At the end of the day as the people appointed to look after the openSUSE Trademark the board does wind up having some level of responsibility, especially in the case where we receive a formal complaint about the actions of a github administrator. But also as the people who have been given permission to administer the trademarks it always comes back to us when the administrators of platform XYZ can no longer be contacted and the project needs to add new ones. Normally this process is long tedious and annoying hence my preference to design a system where its least likely to be required.

From a security perspective inactive maintainers increase the possible supply chain attack surface even if only slightly which is presumably one reason you are looking at this initiative, which is why I'd expect they would care these days at the same time being automated would solve all those fears I imagine and does seem like the best way forward (As long as it can't accidentally remove everyone).

[cboltz]

That looks like slightly broken english.

... all member_s_ of of the organization_'_s projects would sound better (assuming that's what you mean)

[cboltz]

Nitpick: that should be propose your own removal (remove the)

[lnussel]

the audit log seems to miss events that transfer ownership of repos into the organization. For example both disk-encryption-tool and sdbootutil were created less than 12 months ago and then transferred by me into openSUSE but I don't see an event. Similarly transactional-update-notifier by Richard. I still have a mail from Feb 10 notifying me about the transfer but don't see an event in the log.

[hennevogel]

And that is relevant how? Every member can transfer repos into the org AFAIK.

[aplanas]

I think that could be related with the activity monitor? Those two users are marked as inactive, but those projects are where those two users are active.

[flavio]

I'm fine being dropped out

[lrupp]

While I'm fine with being dropped ou (as sometimes it helps decision making if someone gives you a kick) - I just want to raise a question:

I stepped down as openSUSE member quite some time ago. But I still helped - from time to time (~ once a quarter) - with some Github questions or patch submissions. According to your document, this will not be possible any longer.

So why is an openSUSE membership a hard requirement?

Should an openSUSE membership also be required for other teams as well (like for the openSUSE heroes)?

As openSUSE membership applications include a "proof of work" for openSUSE - aren't you opening an interesting circle and limitation here, by asking to be an openSUSE member to work - while memberships are just given to those who work?

[hennevogel]

I stepped down as openSUSE member quite some time ago. But I still helped - from time to time (~ once a quarter) - with some Github questions or patch submissions. According to your document, this will not be possible any longer.

I'm not sure what exactly about "github questions" or "patch submissions" would require you to be a github organization owner? Is there something specific you have in mind?

So why is an openSUSE membership a hard requirement?

My thinking was that, because you are supposed to help and mentor the people of all of the projects in the openSUSE github organization, you should have explicitly "signed" the openSUSE guiding principles somehow.

As openSUSE membership applications include a "proof of work" for openSUSE - aren't you opening an interesting circle and limitation here, by asking to be an openSUSE member to work - while memberships are just given to those who work?

Only if your only "proof of work" for openSUSE is supposed to be github organization ownership work. I doubt this is something that would ever happen...