[aprssig] APRS tocalls.txt - practical steps

[Scott Howard]

On Fri, Feb 11, 2022 at 11:16 AM Randy Hall <aa6rh at socorad.io> wrote:
>
> From a semi-outsider perspective, here are my observations:
>
> I've seen plenty of hams try to organize around different projects after the founder leaves/retires/SK's. My biggest problem, and my biggest concern, is gatekeeping by anyone who comes along after.
> [...]
> If the community cannot rally around those basic concepts, then this is a dark time indeed for APRS, as it will not survive, nor will it evolve in a healthy manner. It will fracture and be diminished.

I'd like to echo Randy's comments. I come at this from the perspective
of open-source software project management and maintenance. The most
successful projects have the type of structure Randy indicates. The
projects that "die" have a strong top-down gatekeeper approach. The
maintainers' role is to serve the needs of the community; it really is
a service role. I also agree with Steve's comment that whatever is set
up actually represents the overall desires of the community. We might
not all agree on everything, but we'd agree that the protocol
maintenance system is in our best interest. In my opinion, the
structure should be:

- Acknowledged by some respected HAM group (e.g., TAPR)
- Has representation or at least communication with current
stakeholders (major software tools, hardware vendors, open-source
projects using APRS). This mailing list might suffice.
- A community conduct guide (for contributors and maintainers, as
Randy outlined)
- Articulated goals and scope (where does specification maintenance
end, and when does user application development start?)
- documented procedures for contributing to maintenance or becoming a maintainer
- clear organization of information (Is the goal simply a single
protocol document? Or is it maintenance of tocalls.txt and list of
applications/hardware as well? Are they the same group or different
groups? What about next gen APR -- will it be AX.25, just at higher
data rates and frequencies, or some completely new thing? Should that
new thing have its own governance, or be a part of APRS?)
- be maintained transparently, under open-source licenses. Here, I'm
discussing the protocol specification, not necessarily any particular
software. Software can be proprietary, but the protocol documents
should be open-source, in my opinion.

Coming from the open source world, I'm not too worried about a
fractured protocol maintenance because if the above steps are
followed, future software and hardware would support the "main" group.
If a second group surplants the "main" group, well maybe they are
better representing the community. However, I've never seen that
happen to any protocol specification project since you need so much
buy in to even get started.

I have experience with open source governance, so I'd be happy to
volunteer to help set that up here. I also developed some APRS
compatible (although not used on the APRS network to avoid spam)
software tools, so I'm familiar with the technology.

-Scott