Task | Identify structure of wiki | reqruiting / assessing

[bongowongo]

imho the pages that are maintained by the workgroup must still be editable by other people as well. The workgroup must make sure to do follow-up editing to make sure, the changes that occurred to a page are ok.

So the wikigroup should review the changes afterwards, and make clear the rules how to edit a page.

[Marie.O]

Yes. That way you keep the initial reason for a wiki (community edits) alive and kicking while at the same time making sure things stay in order.

[nzlneil]

To assist the work group and allow them to keep an eye on the wiki pages, can a daily summary of updated pages be emailed to the people that are maintaining that group of pages with a list of pages that need a review? Once reviewed, the page can be approved, updated to correct format, or rolled back. This way users can update pages to correct and expand the page live, while the work group has the ability to review the changes to ensure that they conform.

Thinking out loud, could the email have an embedded a web page with the list of updated wiki pages in the body that gets it's information from a automatically updated page on the wiki, listing the page, and the status of that page. That way the reader can see at a glance if one of the other work group team has already reviewed the page, of if they need to review the page.

Email Body e.g.

Page       Status
zwave      Approved.
x10         Awaiting Review.
Telecom   Rolled back.

[Marie.O]

every user of the wiki can ask to get notified of changes in a page.

[purps]

This is a first hack at the first and second levels of the new wiki. The third level would mainly be the articles themselves. I dug all over the wiki hardware and tutorials. I think most of the articles can fit into the following structure...



LMCE Installation Instructions (with pictures/videos)

LMCE Operation Instructions (with pictures/videos)

Core/Hybrid
 -Built systems (Dianemo, etc)
 -motherboards
 -video cards
 -TV capture
 -video capture
 -serial cards
 -network cards
 -sound cards
 -Raid

Media Directors
 - Built systems
 - Motherboards

Network
 -modems
 -routers
 -NAS

Control
 -Remotes
 -Orbiters (laptops, smart phones, VOIP phones, webpads)
 -Bluetooth
 -RS232
 -USB
 -IR

Media
 -Displays
 -DVD
 -MythTV
 -satellite boxes
 -cable boxes
 -Amps/Receivers
 -squeezbox

Automation (lights, climate, irrigation)
 -Aeon labs
 -Insteon
 -Zwave
 -X10
 -One-wire

Security
 -web cams
 -alarms

Telecom
 -Analog Telephone Adapters
 -VOIP phones

Scenarios/Events

User pages

Wiki Tutorial (Adding and Administering Content)

Well having spent some time looking through the various pages at trying to put myself in the shoes of the new user, I am coming around to this method of organisation. I still believe it is important to identify the information as "approved" or "hack" etc, but this could be achieved using page "flags".

I think the "flag" system needs further discussion. At this moment in time I'm thinking three (SIMPLE) "flag" fields. One for the relevant version (710, 810 etc), one for the page status (eg reviewed, approved as per your suggestion nzlneil) and one for page type (instructional, overview, hack).

I would be interested in your views. One thing I will say - I think there need to be the bare MINIMUM of options for each of these fields, enough to cover the various situations, but not so many it becomes difficult to decide what option to choose.

Remember a draft version of what could be displayed is here http://wiki.linuxmce.org/index.php/Draft_Page_Status feel free to add your own ideas or just mention them here.

I assume these "flags" would only be editable by the wiki staff?

[twodogs]

one for page type (instructional, overview, hack).

I would be interested in your views. One thing I will say - I think there need to be the bare MINIMUM of options for each of these fields

Agree that wiki contributors should have simple options from which to choose. Agree that hacks should be identified, but that doesn't necessarily mean we need another field. When we consider that a small percentage of wiki articles are hacks, and that hacks will be contributed by advanced users, then we might not want to make every Joebag'o'donuts wiki contributor fill out an extra field. Maybe we have two types of wiki templates - one for regular contributors, and one for hacks. The hack template could have a standard disclaimer at the top, be a different color, have different fonts, etc.

Also not sure we need to differentiate "instructional" from "overview".  The top level of each category would actually be the overview, then the instructional wiki articles would be in the second and third levels. For instance, when a newbie wants to install LMCE, said newbie clicks on "LMCE Installation Instructions" where he immediately sees something very much like the current "Quick Start Guide". http://wiki.linuxmce.org/index.php/QuickStart_Guide Much of this overview-type content would come from what is now the LMCE Manual. Only the administrators could modify it. If someone thought that the overview was inadequate, then they could submit their ideas to the chapter lead (or whatever we call them) instead of writing a wiki article. The second level of "LMCE Installation" would probably have a category called "Video Setup" among others. This would also have some video overview content along with access to third level articles like "black screen", "fonts too small" and such.

If the newbie is having a hard time getting his telecom gear to work during installation, he might decide to get really smart on the subject and could click entirely out of the "installation" chapter and into the "Telecom" chapter where there would be a good overview of the way telecom works in LMCE. With all his detailed questions answered, he could then return to the "LMCE Installation" chapter.

The overall concept is that we combine everything into a single source. Right now, if I want to learn about a subject I have to read the manual, then read the tutorials, then visit the hardware page, then read the forums, etc. And after doing all that, I do a Google search and find even more stuff! What I'm suggesting is one way to end all of that. All how-to content would fit into a 3-level wiki structure.
Here is a possible way forward, subject to the approval of Bongo and crowd.

• Create the new wiki structure/framework (programming skills required)
• Identify the chapter leads (maybe one or two chapters per volunteer)
• Have each chapter lead fill out his chapter by cut/paste from existing content. The first level would come mainly from the manual. Second and third levels would mostly be wiki articles. This would be more of a sorting effort instead of a huge rewrite (which could take forever).
• Release the new wiki. Beers for everyone. There would not be much new content, but at least people could finally find what they are looking for (our biggest problem).
• Improve/Maintain. Once we have everything properly sorted and organized, we will discover many areas for improvements. This is where we can draft rewrites. The chapter leads can start tracking down the experts and asking for updates (making every effort to avoid bugging the devs).

edit: Actually, I suspect that once we start sorting we might find that the second wiki level will be mostly or all overview, and only the third level will have user-submitted articles.

[purps]

Also not sure we need to differentiate "instructional" from "overview".  The top level of each category would actually be the overview, then the instructional wiki articles would be in the second and third levels.

What I meant by the "overview" page type is that it is informative i.e. it explains how the system works or just gives information generally. If you look at my draft page status page, so far I have...
-This page is for information
-This page is an instruction
-This page is a hack

I think that there is a place for this system, as it identifies what you are looking at exactly. I did think about these three terms in great detail to begin with, and now that I have thought about it some more, I will stand by them. I think that every page you find will fall into one or more of these categories and it immediately tells a new user what they can expect if they continue reading.

With regards to the other flags, would an "Approved" and "Awaiting review" suffice? And for the version, see my draft page, I think something like that is what we want.

Would the user be able to edit these flags, or would the wiki bods do all of this when they review the page? I'm leaning more towards the latter at the moment.

[twodogs]

I had not seen your draft page in a while. I vote for the second status box with the yes/no format. As for the type of page, I assume the template would have the three options with instructions to remove two? Seems pretty easy to me.

[purps]

That sounds good, then the options are in front of you to see, and you get rid of the ones that DON'T apply.

I've just had a little fiddle (ahem) during my lunch break, see what you think http://wiki.linuxmce.org/index.php/Draft_Page_Status

[twodogs]

Format looks good to me. However, the "awaiting review" and "confirmed" box brings up a potential problem. Do we have enough people, with enough skill, who are not devs, and who are willing to review all the wiki pages? I doubt that all of our "chapter lead" will have enough system knowledge to approve articles. Perhaps the best way to answer this is to give it a shot and see if the box gets filled out?

[purps]

Format looks good to me. However, the "awaiting review" and "confirmed" box brings up a potential issue. Do we have enough people, with enough skill, who are not devs, and who are willing to review all the wiki pages? I think I could volunteer for a chapter or two, if that meant organizing and clarifying the content. I don't think I'm enough of an expert on the system to approve articles.

I would hope so! Looking at the list of people that volunteered, I'm sure we could work it out amongst us. And if not, we can ask on IRC, here, or try it out ourselves. I imagine it would be a slog to begin with, but once it's all done, I would have thought that this would be relatively easy to keep on top of.

Besides, it's not just the technical stuff - it's the language and general "feel" of the pages that we'll also be moderating in order to keep everything consistent. It's all very well supplying a "this is how it should be done" page, but people aren't going to read all that when doing their wiki page. If they do, great, but I would have thought that mostly people will just want to scribble stuff down and leave the tarting up to us lot.

[nzlneil]

Looking at the draft page, I can see that there could be some confusion in pages where the page has both "This page is a hack" and "The content of this article is approved."

From a users POV, does this mean that the information on the page is an approved hack?

Thinking of the bigger picture, what actual purpose is a hack page for? I can only see 2 reasons for a hack page.

• To work around something that does not operate as expected (i.e. a bug).
• To get the system to do something that it does not currently (i.e. a feature request and how to implement it.)

If a user is documenting how they got a piece of hardware to talk to the software, or documenting how they implemented a feature, I think marking the page as a "hack" does not sound right. Maybe marking it as a "Contributed How To" would be a better option.

[purps]

Yes, I hear what you are saying. Perhaps "approved" is the wrong choice of word. Maybe just "reviewed" and "not reviewed". I will try to address this possible confusion in the explanation as well.

And yes, perhaps "hack" is the wrong choice of word as well, it is a word that we chuck around amongst ourselves, but isn't necessarily "new user friendly". Maybe the word "workaround" would be more appropriate. I think your two explanations for what a hack/workaround is is bang on, I will incorporate this also into the explanation.

Whilst I don't want to make it sound like a negative thing, I do think it is important to convey to somebody reading the wiki that it is not in the spirit of things as it were; referring to your first point (fixing a bug), they should be filing a ticket or fixing it properly with the developers, not just fettling their own installation. Referring to your second point (implementing a feature), the same thing applies, they should be working with somebody to get the feature included properly.

[purps]

OK I change the reviewed/not reviewed part, I think that looks better now.

I haven't changed the hack part yet, I am in two minds about this now. I would be interested in some other opinions!

[mcefan]

Lets pretend that I insisted that the Homerun should go under TV, and you insisted that it appear under NAS We could put it in both places, just as current wiki articles can be set up to appear in "tutorials" and "hardware". But I suggest we avoid duplication if possible. ... If we have a 3-level structure, and if the index is always present at the left of the screen, then it is almost impossible to get lost.

There is a reason why shopping sites keep track of what you click on and make suggestions on what you should look at next, or what other people did following what you just did: thinking flows by association.
An article should be in as may categories at necessary.

If I just completed my install, it's just natural for me to wonder "what else" I should install before leaving the installation phase.

http://en.wikipedia.org/wiki/MediaWiki:Sidebar - how do we get those sexy little arrows in the side bar like that?

By installing the extension. Please note that extensions are version specific.

Somewhere on the front page of the wiki, we should have a link called "Wiki Tutorial - Adding and Administering Content"

- In the "Adding Content" subheading, we would provide detailed instructions on how to create the perfect wiki article. We would have a link to the template everyone should use. We would give the authors the benefit of the doubt that they followed the rules, so there would be no holding area - a submitted article would immediately go up on the site.

- In the "Administering Content" subheading, we would have a table showing who is responsible for administering each major wiki chapter. Their first job would be move existing relevant articles into their chapter of the wiki. Administrators would periodically look at their wiki chapters for new content to make sure people are following the rules. If they found a problem they could fix it on the spot, get the author to fix it, or remove the article. If a particular chapter seems incomplete, an energetic administrator could go to the forums and request articles.

I added a few pages that that address some of the above needs. Please see the section title "Ongoing" on my user page: http://wiki.linuxmce.org/index.php/User:Mcefan#Ongoing

I do like the user identified when it comes to seeing if a particular page works. That way I can track the user down for more info if needed.

Make the "discussion" tab of a page the standard communication medium for pages maybe?

To assist the work group and allow them to keep an eye on the wiki pages, can a daily summary of updated pages be emailed to the people that are maintaining that group of pages with a list of pages that need a review?

That is the function of the "recent changes" special page: http://wiki.linuxmce.org/index.php/Special:RecentChanges
It can be filtered, but it's still labor intensive though, not automated.