[aprssig] Information organization

[Scott Howard]

On Thu, Feb 17, 2022 at 1:25 PM Steve Dimse <steve at dimse.com> wrote:
>
> If you want to prepare for that time when we do start moving forward and
you can offer your services to the APRS group I think that is great, but I
think it is not yet time for public protocol documentation.
>

Maybe I wasn't clear, but this isn't about making any type of protocol
document nor proposals on how to change the protocol. From my previous
roadmap email, this was #1 (taking inventory). The text is actually about
the high level organization of what APRS is. It is just an initial effort
of trying to figure out what is even out there. If you read it, I don't
even write what the protocol is but hyperlink to all the relevant pages on
the aprs.org website. (I do put a couple individual "bits" of information
about specific bits that are buried on aprs.org but important if you are
starting from scratch, just to be helpful). Any details of the protocol are
intentionally vague for the very reasons you pointed out (I just say, "see
this link, it's in this document, etc.")

The first step to anything will be taking an inventory of what already
exists, regardless of which way people decide to go forward. So if this is
useful, great. If it's not useful, then don't use it. If this ends up only
being for my own benefit, I'm happy - and I'm happy to share as well if it
helps anyone.

There is also an immediate need for people like me that are working on
developing hardware and embedded firmware that are struggling to even
figure out what we're supposed to do. Over the past two years, I've figured
it out - but it wasn't easy. A perfect example is the "New n-N Paradigm"
page (http://aprs.org/fix14439.html) where you're hit with a massive wall
of text, and nowhere on that page does it even tell you what the New n-N
Paradigm even is. There are a couple of other examples like that where I've
had to search a ton of documentation, old TNC firmware documentation, or
find nearly hidden links on aprs.org to get started. So that too is not
written like a protocol document but more as "here's where the info is. But
for my own sanity, here's a summary just so I can keep track of what's
going on." I also included things that are important for people like me but
buried in the site. You can ignore those pieces if you'd like.

> We have two proposals for groups that will assume managing the spec. One
is a resurrection of the APRS Working Group in the control of a handful of
software authors, the other a group that represents all stakeholders. How
the integration of the spec, new and old info on aprs.org, and new
additions will be handled depends on which group moves forward. Those
infrastructure decisions ought tp be made by the people that have to live
with them.

I agree with this, which is why I'm not writing it like a protocol document
and instead writing it like an inventory of concepts. I agree that we
should be thinking high-level, both organizationally and technically. That
is what the document is attempting.

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20220217/4d132a2b/attachment.html>