Welcome! Documentation editors play a key role in the DIY Drones community. Our ongoing discussions and efforts for the Ardupilot.com sites can be found here at the APM Wiki Editors Discussion Group. The best way to get involved in documentation is to pay the Editors Discuss group a visit, request to join the group, and start participating!
If you'd like edit permission on the Ardupilot.com manual sites, to fix or add something, please join the group above. We'll send you an introductory email with information about how to get started editing the APM Wikis.
This group here on DIY Drones has mostly just an organization role; it's a way for people who would like to join the documentation team to register their interest, and to show them the correct steps in getting started.
Comments
One of the early posts by Gary was in support of pdf-based "Manuals". I strongly support this idea as a way of reducing the incredible clutter of huge "My experience was...and how can I fix it" threads. Manuals (or perhaps chapters within a manual) addressing specific areas such as "How To Get Started", "Construction", "Tuning", "Learning To Fly", etc, etc, can be much more efficient than a search box, google, and a wiki when you are looking for guidance in a particular area. In addition, such a manual-based system can be easily downloaded and viewed locally.
I also support the idea that the manual development be conducted by a (mostly) separate group. I would be glad to participate in this group; does anyone know who might be its official Editor?
To All, re Jethro's how to share information question, here is a good contact spot as well as our built in DIY Drones Mail Box. Additionally, we can exchange Emails by directly referencing the members box above right and should do so for actual documentation transfer.
Also, I think you can all publish directly to the Wiki and you should probably feel free to do so, you can edit existing pages or just put it on a "New" page and link it at the bottom of the Left column index page (edit the index).
If you need help, ask me, it's mostly simplified HTML and I picked up what does and does not work by looking at the existing Wiki code and by trial and error.
Look at my Table of Contents and a few other pages in edit mode for examples.
In any case, happy to help in any way I can.
Hi Stephen(s)
I firmly believe that PDF documentation should be in addition to the Wiki, the Wiki provides a common interface and the main problem with the Wiki is that at this point it has seriously lacked direction and central control in its scatter shot publishing's (myself included).
I think it is great that they are getting an editorial director who can captain this ship.
To continue that analogy, the Wiki has gotten so big and so complex that it is pretty well adrift. I do think that the Annotated table of Contents I just added will help, but it is a band aid on a terminally ill patient. (Analogy switch!)
I do think that a library of PDF Manuals that essentially parrot the information on the Wiki for each significant release and can be appropriately archived as such is a great idea.
In addition I think supplemental PDF specific airframe tuning and construction articles can also be useful (such as I have already added a few of to the Wiki.)
A version specific downloadable manual should be useful both for reference and as a user guide.
Because of the size, quite possibly PDF chapters or sections should be individually downloadable tied together by Version reference.
Personally I would like to see the Wiki be of sufficient stature that the PDF manuals could simply be constructed by cut and paste then we could minimize duplication of effort, but it does mean we need to improve the quality of the Wiki (A LOT!)
And Jethro, Paintbox is a cute little program and that you are producing that quality of illustration with it is awesome You have an excellent grasp of what can be used to make essential concepts pictorially and brilliantly clear. I do not think anyone would object to adding your illustration style to the Wiki or our documentation. Youve got the picture is worth a thousand words thing down. We will still use 2D and 3D cad, but 3D CAD is ponderous at the best of times and 2D Cad has nothing on your illustrations.
I envision the PDF as being locked to a specific Version and only updated to correct errors. The next version gets is own PDF. This way the newbie doesn't have to figure out if the feature or issue he is looking for is for which version. Or even for the Arduplane.
Hiring an Editorial Director is a big step in the right direction.
Jethro, sharing your ideas on the documentation using this forum is likely the best method. Your illustrations are very well done; I'd suggest you include a descriptive title be included with each illustration. It helps the viewer understand the intent.
Stephen Mann, I agree with your comments. We need to develop a wiki format which addresses documentation differences due to APM harware versions.
Is anyone aware of another product support wiki which addresses this issue? We might get some ideas....
Gary McCray, I agree with your comments. I'm not sure it's possible for the developers to provide ' up front information'.
It seems to me the developers/Editorial Director need to deal with documentation for new features & hardware. I think our assistance should focus on revising documention of the current APM. What do you think?
A comprehensive .PDF document sounds like a good idea. I have some questions.... Would this document be a User Guide or a Reference Manual? Would it be in addition to the wiki or in place of it?
Would it be general in nature or specific (with need to update it frequently)?
Your thoughts please
FYI - the download of PaintBox from Softpedia triggered a Malware Alert from MalwareBytes.
The FileCluster server did not trigger the alert.
Thanks Gary,
I use paintbox for my illustrations. An important part of the 'look' of the Wiki is continuity, be it style of writing or style of illustration. The 'images' so far used in the wiki are 3D renderings of the case and board. These images are far clearer than what anyone can do with paintbox and it would be good to keep in line with that convention, something I learned after drawing the below images.
I think that we need more of a 1-2-3 format in the wiki. Unfortunately in it's current state important sections I feel are slightly bjuried, there is a bit of a lack of 'continuity'.
It is important to gear the wiki for people with no prior experience in any of this.
Here is just a rough thought on how to give people an idea of what is required of them on the software side of things I am still a little unclear as to how we are supposed to share ideas on the documentation, if someone could help me with this that would be great!
Stephen: I agree. That's why we're hiring a Editorial Director.
The problem I have with Wikis is that without an executive editor they encourage disorder. The current line of Wikis is full of a lot of good information. But there is little if any demarcation between versions which adds to the confusion for the newbie who is not nor does not want to be a developer or compile their own version of Arducopter.
Hi documentation guys, I've already made several additions to and edits of the Wiki and I think we have a serious need to upgrade and improve it so that it is current and perhaps more transparently makes available the information the users need.
To that end I have sent the following out on the Developers discussion group.
I'd like to add one more thought, if the Wiki could be updated in a bit more timely and useful manner to reflect the changes we are introducing, it would save a lot of effort in people needing to go to the forum in the first place.