Pyra Wiki Scope

[Wally]

I think it's probably a good idea to start working on what we require for the Pyra Wiki.

Things along the lines of:

Wiki Software

Structure / Categories

Templates for new pages 

Documentation initiation (lorem ipsum for now) for all hardware / software.

Rules for what can be put on wiki (I think we should keep any software that's not built into the OS outside of the wiki)


At the moment it's in my backlog on my Kanban board at home but once I have something to go off I might start a new kanban board just for the wiki as it's quite a big project.

I'm happy to host a temporary mediawiki here at youbroke.it/wiki as i'm not really using it for anything.


My goal is to make the Pyra the best niche product out there with the best documentation for users so we don't have to spend hours aimlessly answering questions.

 

[ekianjo]

My goal is to make the Pyra the best niche product out there with the best documentation for users so we don't have to spend hours aimlessly answering questions.

Then it would be a good idea to think about how to make the wiki MUCH more visible, because even now there's a ton of info on the wiki but many people ask questions on the boards without looking at the Wiki at all. 

A wiki that's "invisible" is unfortunately pretty useless. 

This being said, I clearly support your initiative. I just think we need to make the wiki way more prominent. 

 

[Majin Wamu]

Yes this sounds like an excellent idea! If you want some extra help, I can hopefully assist you in anyway possible.

 

[EvilDragon]

That's exactly the reason I want to combine everything into the main page, with the same login data.

 

[levi]

I'm not sure about the rule of excluding non-OS software, specifically for the case of compatablity lists. Those have worked quite well in the past for emulators like PPSSPP and the likes.

 

[Wally]

I'm not sure about the rule of excluding non-OS software, specifically for the case of compatablity lists. Those have worked quite well in the past for emulators like PPSSPP and the likes.

Compatibility lists are an exception. I just mean general application pages which are never maintained.

Which this gives me an idea of repo integration If repo integration works and apps are placed into Applications > Specific category with appropriate formatting, screenshot and update information. That would be awesome.

 

[comradekingu]

With the mediawiki 1.22 stable i think we can see the vision of what it was supposed to be.

Other than that, i think it works well enough, with room for improvement on things that would have been different if done from scratch.

I think on the OP timeline the craig situation should be stated once and for all or link to openpandora ltd. for _every_ question relating to that.

For a dragonbox wiki: (what i thought of so far)

Team - same as on OP, but more pictures and better structure.

Quickstart

Manual -  metapage with info assembled from other pages. (Hw and SW) For example assembly/disassembly from repairs. Screenshots of every installed app.

Timeline - double duty of notable events and planned events, current progress. Some history.

Environmental: metapage with recycling info and source of material from all pages.

/Software

Debian (default)- The parts that are custom to the pyradebistro. Fontchoice, dpi, list of installed programs

Slackware -

Gentoo -

        /inhouse apps

wbviewer,

repo-client

C4a, 

       /emus

/Hardware

Audio - port schematics, info, mic, speakers

Battery - mAh, weight, environmental info.  Charging

Bluetooth - Info, using internal bt app

Case - info, 3dprint files, mods

CPU  -  info and how to overclock

Display - Screen, tv out, rotation,

GPU -   Info and how to overclock

Keyboard - layout, keymapping

LEDs         - how to manage blinkenlights

Nubs        - info, 3dprint files

Modem     -  3g radio info and how to set up mobile internets

RAM        - info, how to overclock.

Repairs   -  Disassembly, 3d files, flaws/damages and how to correct them

Storage - nand and SD card info

USB         -  info

WiFi -      Driver, info.Display - Screen, tv out,

/Guides:  (Only notaz quality development/advanced pages.) Dont duplicate anything thats already fine on the pandorawiki.

Overclocking: metapage with included info from GPU and CPU and RAM

List of redirects:

Charging → Battery#charging.

Memory   → ram or storage?

Only software projects integral to the project. Projects help the community, and the community help projects along by allowing them easy access to the wiki.

Use other resources if they are at all available, and help those. Only inhouse on wiki.

 

[Esn]

I'm not sure about the rule of excluding non-OS software, specifically for the case of compatablity lists. Those have worked quite well in the past for emulators like PPSSPP and the likes.

 Compatibility lists are an exception. I just mean general application pages which are never maintained.

What if certain applications need certain tweaks to get working properly on the system? A wiki is the perfect place to store long-term information like that. Maybe the rule should be "only make application pages if they're not just duplicating the info already available on the repo, but actually contain something useful".
Or maybe every application uploaded to the Repo should have a wiki article made for it automatically, with a bot that will automatically update info in the infobox as the file on the repo gets updated. That might even be a better solution - it will be easy for people to add any potential important info that way (the bot would only care about article name, categories and infobox). There are many such bots that do similar things on Wikipedia (particularly for the smaller languages), making stub-articles that editors will then hopefully fill out. Or it could be a catastrophic failure, of course.

 

[x1212]

Would it be possible/practical to have separate wikis on several topics? I remember, that there was some trouble with the Slackware pages when the wiki got restructured.

So maybe we could have a wiki for developers, one for users and one for hardware-hackers/modders.

 

[Wally]

Would it be possible/practical to have separate wikis on several topics? I remember, that there was some trouble with the Slackware pages when the wiki got restructured.

So maybe we could have a wiki for developers, one for users and one for hardware-hackers/modders.

Unlike the Pandora Wiki which had no structure. I'm hoping this one will have structure hence not being a problem. It'll get too confusing otherwise.

 

[Binky]

For a dragonbox wiki: (what i thought of so far)

Team

Quickstart

Manual - metapage with info assembled from other pages.

Debian -

Timeline

Audio - port schematics, info, mic, speakers

Case - info, 3dprint files, mods

Storage - nand and SD card info

Display - Screen, tv out, rotation,

WiFi -      Driver, info.

Bluetooth - Info, using internal bt app

Keyboard - layout, keymapping

Nubs        - info, 3dprint files

USB         - info

Repairs   -  3d files, flaws/damages and how to correct them

Guides:  (Only notaz quality development/advanced pages.) Charging Overclocking

Only software projects integral to the project. Projects help the community, and the community help projects along by allowing them easy access to the wiki.

Use other resources if they are at all available, and help those. Only inhouse on wiki.

That seems fairly fragmented, as well as having too many top-level categories:

I suggest:

About:

• Team
• History
• Community
• Goals

User guides:

• Quickstart
• How to use various peripherals (including official dragonbox and assorted 3rd party ones)
• Software tips and tweaks
• How do I <make something do something>
• Troubleshooting

Technical reference:

• Detailed descriptions of hardware
• Hardware hacking guide
• Documentation for Pyra-specific libs
• Known faults
• Downloads of firmware source, hardware designs

 

[x1212]

That seems fairly fragmented, as well as having too many top-level categories:

I suggest:

About:

• Team
• History
• Community
• Goals

User guides:

• Quickstart
• How to use various peripherals (including official dragonbox and assorted 3rd party ones)
• Software tips and tweaks
• How do I <make something do something>
• Troubleshooting

Technical reference:

• Detailed descriptions of hardware
• Hardware hacking guide
• Documentation for Pyra-specific libs
• Known faults
• Downloads of firmware source, hardware designs

This looks like a good structure.

I'd add a dedicated dev-section though to make it easier for new users to become devs/porters themselves ...

maybe something like:

Software Development:

• Toolchains (native and cross-toolchains)
• Pyra specific behaviours/pitfalls (stuff like that egl-crash on pandora or gles behaviour that's not documented in the specifications)
• Optimization (Neon/DSP, or that 2d-Accelerator-thing on the OMAP5)
• Step by step tutorials
• non-native development (stuff like Java/Mono or those game-creation-kits)
• OS development

 

[comradekingu]

I didnt mean categories, those i mentioned were actual pages. Will keep adding to it as i think of more things and more suggestions come in.

Easy to type, one word, self-explanatory.

 

[Dresha]

I think one wiki integrated in the page correctly and good structured would be better then actual wikis for each section.

 

[LEOXD]

On MediaWiki, you can have categories, namespaces (, normal pages) and subpages.

Namespaces should not be used for specific stuff, but only for the highest level possible. In each case they should not be used for languages (like the pandorawiki currently does). 

Possible namespaces could be:

• Pyra (for "official" stuff like the about page)
• Portal
• Guide (or maybe howto)
• Reference
• [plus the default stuff]

Subpages (or maybe subdomains, like Wikipedia does; but that would scatter the whole thing maybe too much) should be used for translations and other specifications

categories are used to group topics (duh). They may overlap with namespaces and subpages, but not necessarily. In general, it's nice to put translations in their own categories, and what distro is used in their own category. 

a possible page structure would look like this:

Pyra:About/de, in the categories: de, official/de

Guide:How to install software/Debian/ja, in the categories: ja, Guide/ja, Debian/ja

The categories themselves are of course categorized as well:

Categoryfficial/de in the main categories: official, de

Category:de in the main category: translation

The sidebar should not contain links to categories, but either links to actual pages or portals that are ordered by topic (and not alphabet, like categories do). 

Also, the wiki should probably use the vector skin over monobook; and the webdesigners should make the theme fit to the other pages (you can do that in the mediawiki:common.css and mediawiki:common.js) 

A common problem when putting all languages in one wiki is that you are basically always only one click away from reading english again. It is possible to prevent this to some extend by using stuff like Autotranslate and LangSwitch, but I'm not familiar with this stuff. 

 

[Granitehead]

I would suggest using a multiple language set up like wikipedia, so multiple wiki systems, one for each language, linked with those language links (fairly easy to set up in LocalSettings.php or however it's called again). It's been a while since I looked at MediaWiki (to my shame, I'm supposed to look after the German Pandora wiki), but I'm pretty sure you can set it up so you actually only have one install which is run with different settings, and you can have one a generic settings file (for stuff shared between all languages, extensions and so on) which you import from the language specific settings files.

Edit: Oh and an anti spam plugin is a must from the get go. It's a fucking PAIN (it deserves to be capitalized) to clean up the mess spam bots leave.

 

[Wally]

One thing I had noticed with the Pandora Wiki was that other languages were not maintained and everything was inconsistent.

To be quite honest I think English and German are probably the only two languages we should support given that most of our audience is from either an English or German speaking background. I dunno what other people think and we can't discriminate if others want to offer a language and is happy to translate the major articles.

To save having several domain names for the pyra wiki I think this is a good idea

Spam Filters are also a great idea but honestly I think locking down the Wiki so that only registered users can edit the articles with random capcha is a better idea. 

 

[Granitehead]

I think locking down the Wiki so that only registered users can edit the articles

I just took that as a given. And then try to prevent bots from registering, it's annoying to have to solve a captcha for every edit, so I would prefer a solution which tries to keep bots completely out of the system so legit users are only annoyed once.

There is for example a plugin which lets you specify custom questions and answers to ask at the registration page, that's pretty neat in my opinion. Have the question link to some longer resource where you can find the answer if you read it, but which is too long for a bot to find the answer on.

 

[LEOXD]

Spam Filters are also a great idea but honestly I think locking down the Wiki so that only registered users can edit the articles with random capcha is a better idea.

the pandorawiki already uses ConfirmEdit (captcha), SimpleAntiSpam (an invisible field, if a bot does anything with it, it will give an error), and SpamBlacklist (blacklist for URLs). 

Other extensions: AbuseFilter (automatic responses [reverts] to stuff), AntiSpoof (prevents spoofy usernames), StupidProxyBlocker (blocks open proxies), AntiBot (only a framework).

There is also a script that allows Admins to revert all changes made by a specific user. 

IMHO there is no need to lock down the wiki entirely. 

 

[Wally]

It's not locking down the wiki entirely.. It's locking it down to prevent guest editing.

I don't want to have volunteers waste time cleaning up spam or posts made by defunct members who have a vendetta against us (CCF, Franko and possibly craig haters (Even though Craig isn't even involved in the pyra project).