Proposal for help by community (besides dev/money): Documentation

[demokrit]

Hi everyone,
I'm new to this group (at least in really trying to contribute) but i would like to summarize a proposal, mainly to all those who want to help but don't have dev skills or money. (I'll try to keep it short but it's a big topic, sry)

The documentation is IMO in a very bad shape (both the remaining one by canonical and the ubp parts) and one thing i think that really held back UT was that this has allways been that way. @ all people who have been involved in this, please don't take this too harshly, i fully understand that as developer there are more important things to do than documentation (and also there's allways too little time). However, since this is a 100% community driven project we need to improve this so porters/app devs/non devs may more easily contribute to the succeess of the whole group. ( I personally was trying to do a few things with my limited skills back in 2016 and didn't get far and a few friends of mine started to develop a few apps and were almost immediately frustrated with out-dated docu)
So long story short, documentation is the future(IMO ;-P)

To get going I would like to share my initial ideas on steps we have to take and hear your thoughts on this

Step 1: Analyse the situation
The current wiki is sorted into

• Install
• Developement
• Bug reporting
• links

This is a somewhat historical picture since it was very nice when only porting to new devices was done by ubp. I'd think something like the following would be more appropriate today:

• Install (keep this)
• User Contribution
  • Bug reporting
  • Translating
  • Documentation (Guidelines)
  • Donating (not shure if this is a must have, it's pretty straight forward how to donate ;))
• System porting & developement
  • Device Overview
  • Specific Device Pages
  • General Porting Information (just link to canonicals guide somewhere and only keep ubp stuff in this wiki)
  • Kernel Information (what patches/backports are needed for which features, e.g. lxc -> libertine, apparmor -> confinement, dunno -> miracast)
  • architecture armhf vs arm64 (aka why only M10 got snaps and 16.04 base)
  • ubuntu base (document what is different from the desktop 'mainline' ubuntu?)
• App Developement
  • Framework/APIs (not shure, this is still to be decided right?!)
• UBP Infrastructure
  • build system (how does this work, ...)
  • community organisation

Step 2: Tell people how they can help
This is the actual core of my proposal i think; There are a few things in that list that no one who isn't involved in really working on the code may answer. HOWEVER, there are many things that people like me, who can read a few things, use a search engine or just have a phone/tablet they want to see ported can do. So the important thing is to tell them(us) how and what to document. I have a few ideas that might be achievable without coding skills:

• Make a big table where all the hardware info is gathered of every device. With this i don't mean something like (2Gb RAM) but rather every chip inside as exact as possible ( e.g. for the bq aquaris: RAM = SKhynix H9TP65A8JDAC PRKGM 510A 2MYRV05bQ3 [at least that's written on the chip]) and check whether there are drivers in the mainline kernel (and IF, link to the specific patch and document the kernel version) This is something everyone might do who wants his/her device ported.For reference, something like the sunxi mainlining matrix for allwinner ARM SoCs combined with a more detailed version of the wikipedia comparison of smartphones

• Gather device specific Info for existing/wished for device in each specific sub page. For example is the storage on the device so scarce that something like the rootfs-modifier for the HTC Desire Z by w-flo is necessary? Often, this is rather recycling of info posted online for example on xda forums or on UT specific blogs. (e.g. for bq e4.5 one might find very usefull info @ sturmflut's blog which is now @ lieberbiber.de others might try to see if some ways of obtaining info is similar on their device.

• Also for any topic: go through the web and try to document common errors and how to solve them when porting or ways to debug and such stuff (e.g. watch marius gripsgard's talk @ ubucon 2016 and filter out usefull info for devs)

As I Said, these are only ideas and i would like to hear your thoughts. However I for one would like to contribute to this with all the (little) time i can spare. For starters, a quick documentation how to use the wiki would be nice. It's not too complex but is there a way that is not as chaotic as cloning the repo and editing it with an editor like atom/geany, whatever? (is there a gui like for dokuwikis or something?!). Maybe another "documentation" work group might be usefull?
Best regards