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.