On Tue, Jul 2, 2024 at 12:38 PM Rosy Schechter via groups.io <rosy=ardc.net(a)groups.io> wrote: Might one offer a different viewpoint for consideration? Everything happens in some sort of context. In this case, the context is 44Net, how it works, and how that has changed given events in the last 5 or so years, particularly around communication. I think it's fair to say that administration under Brian Kantor was both collaborative, and what one might describe as, "light touch." Volunteer voices were valued, and administration was spread informally around a group of people; those who were interested in doing the work volunteered and did the work, and were welcomed in doing so. This system was not always perfect (for instance, some coordinators were inattentive, and one former coordinator had a criminal record that made me, at least, extremely uncomfortable whenever I had to interact with him [note: this is not trolling; this was a matter of public record that legitimately freaked me out]). In the old manner of doing things, the volunteer coordinators expended significant time, energy and in some cases money, to assist with the administration of the network. They developed relationships with users, and bore the brunt of handling day-to-day requests, etc. WB6CYT was the overall anchor holding this crew together, true, but much of the work was outsourced. After the sale of the /10 (FTR, a move I fully supported and continue to support), this seemed to change. ARDC became much more involved in the daily operation of the network. With the new portal, the role of the coordinators seems greatly reduced. Public requests for public technical discussion involving ARDC-administered software (like AMPRGW) largely goes unanswered, or given perfunctory responses to file a ticket, often with little follow-up. Frankly, it's hard not to feel ignored. One of the more vocal folks here has been a coordinator. Putting myself in the position of the coordinators, a way to look at this is that the work they had put in: building rapport with users, doing tech support, walking new folks through getting online, was simply discarded. Moreover, sincere offers to help with reducing the backlog of tickets have seemingly been ignored; recall that these folks have already spent considerable amounts of their own time and energy building relationships that could make this easy, and up until the introduction of the new portal, they were entrusted to do just that...why not take them up on something they've already shown aptitude and desire to do? Since we're talking about respectful communication, I can say that, if I were in that situation, I'd probably feel pretty disrespected: wouldn't you? None of this is to suggest that harassment or outright trolling is useful, or should be excused, let alone tolerated; I'm not a party to the off-list harassment that took place, so I cannot comment on that at all. Nor am I a coordinator and in fairness, I have no insight into what's going on other than what's been publicly shared on this list. But I do have my own experiences and observations to draw on, and taking a step back, what I observe has happened is that the context in which 44net operates has fundamentally changed, but that has not been clearly or sufficiently communicated to the existing stakeholders (and the coordinators and users _are_ stakeholders!). From my perspective, things have become less collaborative, less experimental, and frankly far less transparent; there seems to be more top-down administration, and a lot less room for volunteer contribution. Pointing out errors in documentation is all well and good, but ignores the considerable areas in which others might usefully contribute. It's fine for the context to change, of course, but if we want a healthy, vibrant community going forward, it is not ok for that to happen without open communication. And right now, communication from ARDC to the larger community does not feel very open. As a concrete example, that the rollout of the new portal has been rough has been acknowledged by all parties. But have there been any formal (or even informal!) "lessons learned" recorded in the wake of that? Will they be shared publicly? Is there anything actionable to come out of that? If ARDC were to embark on a similar software project tomorrow, what would be done differently? Would members of the community be invited to be more involved from the start? Would the resulting source code be open? Speaking as a professional software engineer, I can't help but feel if that there had been more engagement from the outset, many of the rougher edges in the portal launch could have been avoided, and --- I admit I'm purely speculating here --- perhaps the present sad situation would never have materialized as a result. Again, I'm not trying to defend harassment. But the road of respect goes both ways, and I respectfully wonder if ARDC has critically examined its own role here. In my opinion, it could start with more transparency and more communication and engagement with the community at large, and especially with the volunteers who have given much of themselves to the community and asked for little in return. Am I being unreasonable? - Dan C. (KZ2X) _______________________________________________ 44net mailing list -- 44net(a)mailman.ampr.org To unsubscribe send an email to 44net-leave(a)mailman.ampr.org

a new rule was invented on the spot as to why that could not be granted.

Responding briefly because today is a holiday in the U.S., but I don’t want to leave this conversation about transparency unaddressed until next week. I’m sharing some thoughts here on the subject of transparency, as well as next steps for how we might address some of the concerns shared in this thread and beyond. Sincere thank you Dan and others for voicing your thoughts and opinions here. These points in particular I take to heart:

<quote> I agree that we could do a better job with being transparent. A clear learning from the most recent launch was that involving some of you in testing the portal prior to launch would have been helpful, as well as opening up discussions around any potential shifts in policies. There are certainly more lessons learned, and in the coming weeks - following a request from some of y'all – I’ll post a more comprehensive list. (Some staff members are in and out of town for the next couple of weeks, and I want to make sure to review with everyone prior to sharing, so thanks for your patience there.) On a related note, please understand that any lack of communication or greater engagement on our part has more to do with capacity (or lack thereof) than anything else. One of the key functions of our upcoming Technical Department Manager hire will be to interface with this community on a more regular basis.

Even with such a hire, though, one thing is also true that is worth mentioning: there is no possible way to replace Brian Kantor. Inevitably, when someone exits an organization, something shifts. When someone enters, there is also a shift. And when Brian and ARDC’s board decided to sell part of the address space, there was a major shift there too. From the perspective of those of you who have been around for 10 years or more, I can see how these shifts have felt quite stark. Additionally, Brian used to run everything. When he passed away suddenly, he left no playbook. Given that, I am interested in learning from you how he engaged with you so that we can do a better job, to the best of our ability. Clearly newsletters and sharing announcements with the list isn’t cutting it. What specific and actionable steps can we take to better address your concerns?

In addition to getting your feedback here, we’ll be talking about this a bit at the next Regional Coordinators’ meeting (July 27). We aim to hold these meetings regularly (at least every 1-3 months, depending on everyone's availability). Ok, this is a much longer email than I intended, but it’s as they say - if I had more time, I would write a shorter letter. Nevertheless, the point I’m trying to get across – which I hope is received – is that we are willing to learn from our mistakes and to do things better. We are all, in fact, on the same team – growing pains and all. For those in the US, I wish you a happy Independence Day. For everyone else, I hope you have a good weekend, and I look forward to picking up the conversation next week. 73, Rosy Rosy Schechter - KJ7RYV Executive Director Amateur Radio Digital Communications (ARDC) ardc.net -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#320): https://ardc.groups.io/g/44net/message/320 Mute This Topic: https://groups.io/mt/107043561/481017 Group Owner: 44net+owner(a)ardc.groups.io Unsubscribe: https://ardc.groups.io/g/44net/leave/13272901/481017/1172239927/xyzzy [crossd(a)gmail.com] -=-=-=-=-=-=-=-=-=-=-=-

Hi Dan, Just to correct a misconception: Plans are not underway to deprecate the IPIP mesh tunnel infrastructure. Yes, ARDC are developing POPs that utilise VPN technology, and if all goes well I am sure that some users of the IPIP tunnels will likely migrate to the POPs, also newcomers to 44Net will find the POPs a much easier on-ramp than the IPIP system, so IPIP use may well reduce over time. To re-iterate ARDC have no plans to deprecate the IPIP infrastructure, ARDC will continue to support its use for as long as the membership is using it.

Not that I am aware of.

Hi Dan, I said we are hoping to deprecate the gateway server and then I went on to explain that it would be replaced, not turned down.

Not only is the server very old, but the code it is running has bugs (as you pointed out). I would like to see it replaced with more modern hardware running updated software that is easier to maintain and update. However, this is not a priority at the moment, so very unlikely to be worked on in the short to medium term.

73, Chris - G1FEF

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.

If it helps, there is a bit of a middle ground where a project can be opened up for inspection, but with a disclaimer that it's not ready for external support or handling PRs, etc. We do this at my job for a number of things (one of our core values is transparency and commitment to open source dovetails with that; we try to open up as much as we can, from our OS implementation to our firmware).