Proper protocol to fix issues with beagleboard.org website or software

Jason,
Just so I am clear on your preferred methods....how do I communicate to you
(or someone else) any ideas or suggestions or questions that I may have
about the current state of BeagleBone Black information on the internet? Do
I email you? Do I submit a form? Do I fix it myself? Do I compile a list
and hand it in monthly?

Best method is to:
a) publicly post issue to beagleboard@googlegroups.com -- providing
direct suggestions on what can be improved is very helpful, suggesting
specific text or code
b) if a git repo exists, file an issue report and reference the post
to the public group
c) submit a pull request via git or a patch via e-mail if you are able
to fix the issue
d) follow-up with e-mail to me directly, pointing to the post in the
public group
e) after 24 hours, feel free to call me

Here are two specific examples:

Example1
At this important "Software Support" page, which is navigated to from
"http://beagleboard.org/" -> Support -> Software Support:
:::Debian is not mentioned at all
:::Not all potential OS possibilities are touched on (I thought the
theoretical marketing list was quite long... shouldnt this be supported
here)?

Aha! I see that perhaps you maintain the list here, which is more
exhaustive. Why have two different pages trying to say the same thing, with
one of them being hopelessly out of date and incomplete? Maybe the first
one should just say "See your specific platform's wiki page" or something?
Then no one has to worry about maintaining the first one.

I believe information is somewhat more reliable when hosted at
http://beagleboard.org. I believe the
GitHub - beagleboard/bone101: Web-hosted documentation on BeagleBone enhanced with BoneScript and live-running tutorials project should be the upstream
for software documentation. Support BeagleBoard Foundation now on Amazon Smile - BeagleBoard should
mirror the documentation in that project. The fact that the
documentation in that project is shipped with the board and Diego is
working on making it more "forkable" should help get more people
involved and exposed to that information.

Example2
When I first started with the BBB last Fall 2013, I noticed probably 20+
instances of confusing and conflicting information very similar to Example1
above (I know things have been in a big state of flux in general). At the
time, I was not comfortable nor confident telling anyone about it for fear
that I was misunderstanding something....but now that I am more confident
and comfortable, I would like to take a more active role in either fixing or
reporting the problems/inconsistencies/confusion-points that I notice this
time around. I am about to embark on a flurry of tutorials and blog posts
AND starting a club in collaboration with the Guatemalan Professors from
Universidad Galileo. I am going to be looking at lots of the BBB resources
again with fresh eyes and I want to know how to handle things properly.

I feel if you can get it right in bone101 and in the SRM (the
definitive hardware guide), then people should be getting the right
information.

(PS- I dont care about the BBW nor the out-dated capes... I think they
should all be recycled or traded in so the rest of us can move foreward.
Why force cutting edge BBB developers to hang on to the old outdated
kernel?)

As a general philosophy, if it worked once, it shouldn't stop working.
We try to follow the Linux development model where possible where
essentially changes can get blackballed by leaving people behind in
terms of hardware. It can, however, be assumed that all users can be
asked to upgrade to a newer kernel to get support for whatever they
are doing. I think with the cape-universal approach we'll be able to
move to a newer kernel very soon.