[aprssig] APRS roadmap planning proposal

[Andrew Pavlin]

 Documented features scattered all around: that's for sure! I tried to implement every APRS 1.2 proposal that applied to a general APRS client, but I sure didn't do all of them.

Perhaps we should bring the I-gate interface requirements into the central protocol document as an addendum or appendix. It's been 10 years now, and I'm _still_ not sure whether I have my I-gate interface in my APRS client coded correctly, because the specs on aprs-is.net are not clear, complete, and specific, especially compared with what I actually see on the APRS-IS and what I see from the few transmit I-gates I'm spotted on RF. Not that I want to criticize the authors of APRS-IS; as has been noted earlier on this mailing list, it is HARD to write good documentation, and way too easy to assume that because "I" know it (speaking from the point-of-view of an riginal software author, [which I am, just not of APRS-IS]) that something is intuitively obvious to everyone else (but it isn't).
John, as an experienced software engineer (and documentation writer) in my own right, I would be happy to do a document review for you. I've been trained in the brutal school of military documentation review (from the unhappy side as a defense contractor writer), so I'm pretty good at it. Find all those t's that weren't crossed and i's that weren't dotted, etc. :-) Alternatively, if there are sections you'd like me to help with, I'd be happy to contribute chapters.

Andrew, KA2DDOauthor of YAAC (which has routine documentation file updates and reviews)

    On Sunday, February 13, 2022, 04:00:02 PM EST, John Langner WB2OSZ <wb2osz at comcast.net> wrote:  
 
 Scott Howard wrote:

>  Hello everyone,

> I'd like to take a stab at synthesizing discussions on the multiple
threads
> into actionable items, with the goal of coming up with the 3 month goal
> with > 50% likelihood of success as was suggested. Below is a summary of
> the conversations (IMO), and I think goal #1 below is reasonable to aim
for
> in 3 months.

> In order of apparent priorities:
> 1) Maintenance of APRS as written.
> 1.1) Take inventory of all the documents (1.0, 1.1, the proposed 1.2, all
> the other notes on aprs.org).    ...


Anyone who has tried to implement the protocol has found it difficult
because two decades of updates are scattered around rather than being
merged into the original protocol specification.

I'm already pretty far along on updating the protocol specification with 
the later notes.

I took a copy of the original 1.0 specification and have been merging in all

of the corrections, clarifications, and new features in the 1.1 addendum.
Most of it is pretty straightforward.

The 1.2 addendum is a little trickier because it is mostly proposals that
never went anywhere.  I think we should just include new features that have 
been widely implemented.

The problem with putting it on github or otherwise making it publicly
available
Is that the original document is copyright 2000 by the APRS Working Group.

If the original "APRS Working Group" is no longer interested in maintaining
the document, the new maintainers would need to obtain permission to 
distribute a modified copy of the copyrighted material.
 

73,
John WB2OSZ







_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20220213/851e2a63/attachment.html>