I am entering this here as at least a place to start this discussion. The work of doing these changes is likely across several people.
The purpose this issue is:
Then I reckon you can make individual tickets or whatever in other places, and link to this issue as the authorization to proceed with the change?
I don't know this if this is something we've done formally before, and I would be surprised if there was an existing or up-to-date process for making these changes it has only happened a few times. When Ralph left the Board, he still had most of his original permissions from before there ever was a Board. When Fabian left, I presume he did the work of removing himself from the few places. Most likely someone leaving the Board would primarily need to be removed from private mailing lists and aliases, chat channels, this git repo, and shared documents.
There are now two of us who have left the Board and have a number of permissions.
I suspect Carl Trieloff (ctrieloff) is less complicated than me. Likely his fall mostly within this list:
For me, I can think of these additional complications:
I can add to this issue as new things occur to me.
I would question whether certain ones of these should be tied to Board membership. In particular, admin on bugs.centos.org and wiki.centos.org, commit on the website, and admin on the IRC network, should be based on volunteer willingness and trustworthiness. The former of those is, of course, your call, but the latter remains.
Clearly the board mailing list, private board tickets, and confidential shared docs, are on the Board-only list. That said, we should continue to strive to make things private only if there's legitimate reason for them to be private, and default to public everywhere else.
I would question whether certain ones of these should be tied to Board membership. In particular, admin on bugs.centos.org and wiki.centos.org, commit on the website, and admin on the IRC network, should be based on volunteer willingness and trustworthiness. The former of those is, of course, your call, but the latter remains. Clearly the board mailing list, private board tickets, and confidential shared docs, are on the Board-only list. That said, we should continue to strive to make things private only if there's legitimate reason for them to be private, and default to public everywhere else.
I appreciate that, thanks. And it's worth my considering more deeply the accesses I have and my volunteer efforts here. Part of what leaves me a bit unsettled is the origin of a few of my accesses. We gave me full admin on a few items as we prepared for the January 2014 launch, before I could go through a normal process of e.g. being an exemplary bug squasher or wiki maintainer.
So in my mind these subset of things were not earned through normal activities, and represent a bit of an anti-pattern that I'd like to see us shed over time.
What is the path forward here? Who itemizes what you do have access to and should be revoked? Who determines when this ticket is complete? Who is going to write policy for what Board members get access to, and what is revoked when they step down?
As an incoming Board member, it would definitely be useful to have some kind of onboarding doc listing resources I should have access to / documents I should read / etc (and in turn, this could help with offboarding too when folks leave). I can help write one up, but I don't know what should actually go in it.
First of all, congratulations! And thank you for taking on the mantle at this pivotal time in the project's life. Much luck, and call upon me whenever you need.
For this, I would he happy to expand on what I wrote in the description above, with whatever reasoning I know/can recall.
Someone ultimately is going to need to use the blueprint to make changes to accounts and an SOP for the onboarding. Is that being captured for your onboarding so far?
I have started this file - https://git.centos.org/centos/board/blob/master/f/directors/onboarding - and will further update from Karsten's comments in this thread. Possibly not the best place to capture it, but we can move it when we have a better place.
Resolved on mailing list: Review contents of current GDrive. Anything which is approved/public should be put in this git repo. Anything which is still under debate or being drafted should use hackmd.io (or other collaborative tool which doesn't require Google accounts).
This has been turned into separate tickets over on https://pagure.io/centos-infra/issues
Closing.
Metadata Update from @rbowen: - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.