10 Jul
2024
10 Jul
'24
12:09 a.m.
On Mon, Jul 8, 2024 at 5:13 PM Rosy Schechter via groups.io
<rosy=ardc.net(a)groups.io> wrote:
I know this is an open-ended question to generate discussion, but (and
I'm just spitballing here) I'd think one could do it with some means
of hierarchy, implemented in the portal. A ticket should be
addressable to an individual for handling (e.g., a coordinator) but
there ought to be some method for "escalation" if it's determined that
the ticket falls outside of the purview of the coordinator (or if
they're just unresponsive or otherwise uncool about helping a user
out). Perhaps this could be tied to time (7 days with no response and
the ticket gets auto-reassigned to someone else) or explicitly set up
by the ticket assignee ("I'm going on vacation and will be out of town
for a month. Please contact $OTHERPERSON instead...").
I'm sympathetic to the privacy concerns.
I think he mentioned a replacement for AMPRGW infrastructure and
software is being considered; if he mentioned API-based access to the
portal, I'm afraid I missed it.
Absolutely. Another category is discovery around, "how does this
work?" This being an amateur radio community, people are naturally
curious about _how_ things work; when something behaves oddly, I can
see how folks want to have that discussion, but that's qualitatively
different than a bug report, or request for support.
That's wonderful to hear. Thanks!
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).
I'm happy to chime in, and glad that you find it helpful. Hopefully
others will do similarly.
- Dan C.
Hi Dan ++
Thanks for these thoughts; they are super helpful. Responding in line...
Thanks, Rosy.
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?
I like this framing :)
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.
These are definitely items we want to discuss with coordinators. We both
want to give folks such abilities but also ensure that they are being
responsive / not only giving allocations to their friends and no one
else. (This is something that's been brought to our attention a number
of times.) There are also some GDPR privacy concerns around PII that
have been brought up; not impossible to deal with but will require some
real thought and coordination.
The question I'm thus asking is: how can we make sure that coordinators
have agency while also ensuring fairness to users, as well as
sensitivity of data, etc.? 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.
As Chris mentioned, this is in the works :) 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.
I definitely see what you are saying here and agree that the tickets are
not a replacement for a public forum. I think the trick will be to find
the balance between, "This is a bug / admin function that doesn't need
everyone's attention" (ticket) vs. "I have a technical question that
I'd
like support from the community to address" (forum). It's about finding
the right pathway for each item, and what you're saying here gives me
some ideas for items we can implement. 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.
Agree. This is part of the plan. We'd like to kick it around a little
more internally before doing so, and also to make sure that we are ready
to handle feature requests / issues / pull requests etc. I fear that if
we don't do that in advance, we'll set ourselves up another
less-than-awesome rollout. I...don't think we need another one of those ;)
This item is also towards the top of the list for our forthcoming
Technical Department Manager. 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.
Yep.
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.
Chris already responded about this one, so I'll leave it.
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.
Thanks again so much, Dan. I appreciate and agree with much of your
feedback, and our aim is to implement much of it. It will take time and
some more people (we're working on it!), but I'm confident we'll get there.