[44net] Re: [ARDC:44Net] a communication about communications

On Thu, Jul 4, 2024 at 3:45 PM Rosy Schechter via groups.io <rosy=ardc.net(a)groups.io> wrote: Happy to do it. As you noted, it was a holiday, so please excuse the delayed response. That's fair. As you said, there's no replacing Brian. Things change and the context shifts; in that spirit, I wonder if the most useful questions are less about how he did things and more about how to build the community we'd all like going forward? It's difficult to make concrete suggestions from my perspective: I'm not a coordinator, just one random person. Moreover, the portal probably isn't going to support some of these things, and will require development effort to implement properly. Regardless, if someone put the question to me, here are a few things I'd throw out there: 1. Let the coordinators take on ownership of tickets for users and allocations that fall under their purview. Let them take care of validating those users for whom they have prior relationships, for example. 2. Provide some sort of "batch mode" capability for coordinators to make updates on behalf of users. Consider DNS for example: I like the new system of being able to modify my own records, but I've been a (near) daily user of the Internet for other 30 years and have been running machines on the network for nearly as long. Some folks aren't going to be comfortable making updates and are going to lean on their coordinators to help guide them through the process. The current process, while nice, is also rather labor intensive, in that each record has to be added manually through the user interface. 3. Provide some sort of programmatic API for the portal. A batch interface would be a strict improvement over what's there now; I imagine that it would be even nicer if someone could just run a script. 4. Have technical discussions out in the open. The ticket system is all well-and-good, but I pointed out an issue with reverse DNS queries being (presumably) eaten by AMPRGW back in early May. I put some effort into writing up a summary, complete with my experimental method and observations. I was asked to file a ticket; I did, and tried to link to the discussion on the list for context; I was asked to put that data into a ticket, but the ticket system really isn't built for that: the textual input fields lack the space and formatting abilities to incorporate what I'd already written. I ended up putting it all into a text file and attacking it to the ticket, but it's not clear to me that that was ever read. It ended up being an enormously frustrating experience, and while I'm quite certain it was not intentional, frankly it all felt extremely disrespectful of the time I put into the matter. Similarly, I tried to figure out why AMPRGW stopped passing traffic when a router reboots; my investigations suggested that this is due to AMPRGW seeing ICMP unreachable messages for the endpoint during the reboot blackout window. I asked publically for confirmation of this _so that I could update the wiki with that information_; after a few days, I was again asked to file a ticket. Eventually I kinda-sorta got confirmation, but it was painful. The bottom line is that an ersatz ticketing system is not a substitute for a public forum for open discussion of technical matters. 5. In the spirit of openness, release the portal software as open source, putting it on the ARDC git server. Since much of the above hinges on (presumably) enhancements to the portal, it seems like it might be helpful to leverage the community in making those enhancements, which can't reasonably be done _unless_ the software is open. Indeed, I can't think of a good reason not to do this; to forestall what I suspect would be an objection, security is not a good reason: "security through obscurity" is a well-known anti-pattern in the software world and rarely works. It's much better when software is open for inspection and improvement by all. 6. Much of the current state of affairs comes from the rocky rollout of the portal. There's little we can do about this now, but a publically accessible post-mortem (preferably following the "blameless" format) about the launch: what went well, what went poorly, lessons learned and what could be done in the future to mitigate pain points, would be very well received, I imagine. 7. I know that plans are underway to deprecate the tunnel infrastructure and replace it with a set of VPNs that are independently peered with the Internet at large (at least, as I understand it). I think it would be helpful to publicly commit to a transition plan for this, including a public test period, a defined set of go/no-go criteria, and a plan for a rollback if it doesn't go well. In general, commit to involving the community early for any large-scale infrastructure projects ARDC takes on in the future. Anyway, these are the things I sort of thought of off the top of my head. In fairness, I recognize some are easier than others, and I hope other folks will chime in with thoughts as well. - Dan C. (KZ2X)