Your question is actually a combination of several other questions that have already been answered on this site. I'll outline the steps and issues here for general process, but link to relevant questions for specific tools. As you tagged it QGIS, that's what I'll describe though the same process would apply to any GIS package.
The first step is to prepare your data. The order of your values can matter depending on the tool used. gpx is generally lon, lat, name, comment. While it can handle more than that, some tools seem to fail with more than just four attributes. In this case it won't matter, as you can tell QGIS which column is which. However you do need to save your spreadsheet as a CSV (comma separated value) file - ArcGIS can read Excel (with caveats), but I don't know QGIS can.
CSVs are fairly universal when it comes to bringing data in (along with other delimited text formats). Because of that, you may be able to stop there unless you're distributing to sofware that doesn't have this ability (or to assign coordinate systems, etc). Also, for the record gpx files are text based, and therefore not much different than a delimited text file beyond the format (xml vs plaintext). There are tools out there that convert a csv to a gpx (for example POI Manager), but they may or may not allow for specifying a coordinate system since gpx is supposed to be WGS84 (see below).
The next step is getting it into QGIS (that link is pretty much a tutorial for this whole process) using Add Delimited Text Layer, which will let you specify which columns are lat/lon among other things. All of your other fields should become attributes of your new point shapes.
Now you should have points in a map, but they're not set to a specific coordinate system. Also, they're just displayed - they're not saved as points. You can right click on the layer and say Save As and the suggestion would be to ESRI shapefile. This is an almost universally accepted geometry format. As part of the save process, you can set the coordinate system to NAD83 of whatever variant you're using (more on that in a second). Once again, you may be able to stop here, assuming the software you're distributing to can read a shapefile.
The last step is the gpx conversion, for which there is a QGIS plugin, but it has limitations or issues. Some people have trouble with getting attributes to write correctly. And this is also where we come to the issues with use of gpx in the first place. While it may be fairly universal, it's actually a more restricted format than CSV or shapefile. For starters, any included data (like times) is expected to be in specific formats.
For example the definition of a gpx states that coordinates should be in WGS84. You're in NAD83, which means you would need to reproject the data (or the export/save should let you as part of that). The reason I asked if you needed the accuracy is because the difference between the original NAD83 and WGS84 systems should be virtually indistinguishable with the accuracy of most consumer grade GPS units - which is what gpx is aimed at. Later iterations of either may increase the difference and you don't specify, but with the originals you're talking less than 2m (at least in the US). Depending on how your coordinates were obtained you may already be outside that level of accuracy. What you've posted above only goes to the meter.
Regardless, to distribute in closest accuracy to what was collected you would want to preserve that and let your recipient reproject as needed. I think a shapefile would be your best bet, as you can easily preserve all attributes or add more, don't need to reproject (and the projection is defined in the data, which it wouldn't be with a CSV), and there is no implication that data is in one specific format if you haven't made sure to conform to the gpx specification. But again, it depends on your intended use/purpose.