Visibility for infra has being suboptimal, that’s something I’m very conscious and I’ve been actively working on. So, this is a pretty dear subject to me
Prepare for a wall of text.
For the wiki what I’m actually trying to aim is for two wiki spaces: one public and one private.
https://wiki.openmrs.org/display/ISM/Home is the public one, I’ve spent quite a few time getting it clean and nice recently.
I’m cleaning JIRA project too, to make sure we can improve visibility of the project tasks pending or being worked on. I know that helpdesk doesn’t help with visibility, but I think in the future they can coexist.
Telegram is very verbose and it’s harder for those not following it closely, it’s hard to tell which bits and pieces of info would actually be useful for you.
I like talk/email for structured talks, it works well. I think it makes all sense to me to have infra category for our longer discussions. It’s a tool I believe it can play a pretty good role. I’m voting +1 for talk infra.
Security is a pretty complicated topic. There’s no black and white here, and I can guarantee you that no single person will ever get it all right. It’s a balance, about how much info you are handing vs the benefit of spreading it. For example, the benefit of making the outages registry public is so huge that I think it’s worth making public.
I’d think we should have both a public category (the Community one is fine), and a new one private. By private I never mean infra team only, that’s not enough. I think we need to grow the trust circle, I want to have infra team + leadership + maybe /dev/4-5? This ‘extended’ infra should have access to all JIRA tickets, both wikis and both talk categories.
An absolute non-comprehensive list of dangerous things we should not say in public repos:
- Versions of software we are running (including OS and other ‘patchable’ things)
- Network topology, providers, SSH or authentication config, firewall config/version
- Users (including bot accounts, access, and where to find credentials)
- Password and secret management
- Mentioning which groups of software are running on a single box ( bonus points for ldap and database locations)
- Backups location, policy, how to retrieve it
- How access is granted, to whom (targeting some specific users for access)
What we can do, I’d think, is that every topic we create on the private repo, we can always question if it should be public and move it.