Thanks @Dean! Here is a recap of the answers discussed during the contributor meetup today:
@sarina described that this is a security topic - we have a whitelist of accounts who are allowed to run the tests directly, to avoid allowing unintended executions of arbitrary code by the tests. Only allowing people we trust to run them removes attack vectors.
We wondered if it would be possible to more easily add people like @ghassan to such a list, but nobody in the meeting was sure of where or who controls this aspect of the tests. There seemed to be a general agreement that this would be a good thing, but someone would need to explore how this could be done and suggest an approach. @ghassan will post about it on the forums.
+1! Try the new version of the checkin tool if you haven’t already 
@kmccormick This is for you from @Dean ^ Kudos for the offer to help!
We quickly discussed collaborating on Kubernetes with @Felipe during the meeting, and we agreed that we’ll need to find an approach that can be managed at the community / Open edX project level, rather than a specific organisation. @Felipe has offered to develop a new approach on the forum thread. I remarked that we had already multiple implementations in the community, so it would be great if the solution was not to have to redevelop yet another reimplementation. Since we started discussing collaborating only after code had been written, we all got attached to a specific approach. It might be useful to pick different compatible parts from different contributors, to all have some ownership in the shared project, but keep only one approach that we all use and co-own together at the community level? CC @braden
@mgmdi The BTR meeting can be found in the shared working groups calendar:
@pdpinch is still blocked on this – but the next update from @feanil (cf below) proved useful, reminding us that @feanil you are probably a good person to help @pdpinch with this ^