Task | Identify structure of wiki | reqruiting / assessing

[purps]

re: hacks

The problem with hacks is that they can get outdated very quickly and are usually not maintained. Also hacks in the forum are not in the wiki.
I see that they are very usefull, but on the other hand very confusing. I remember in my newbie days following wiki-hack page that was outdated and didn't work. It should not happen.

The reason I suggest it is because I would follow a wiki page and not know that it was a hack in the first place!! Then you find that it has bollocksed something up, you ask for help, and you're told "this is what happens when you try to hack the system!".

I appreciate they go out of date quickly, but surely that's part of what a "hack" is? I assume that on the main page we would have a little key explaining all these terms, and you would explain that any page displaying the "hack flag" may or may not ruin your life.

On the page itself, perhaps we are talking about 3 columns here; 1. for the LMCE version, 2. for the type of page (instruction, overview, hack) and 3. for the "bongo stamp of approval" or similar.

[twodogs]

Pedantic point 1: TV capture, what about the homerun? It should go under network with "NAS" for example, but then you want to keep TV hardware together.
Pedantic point 2: Do you think there is a blur between "automation" and "security"?


Generally speaking, personally I was keen to separate the "information" from the "hacks", and with your structure they will all be lumped in together. I think the "hacks" do have a place contrary to what some may think, but it should be made clear that they ARE hacks.

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. It is a little difficult to find a perfect structure for this wiki, but it will be orders of magnitude better than the maze we now have (where it is easy to get lost). 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. For example, if someone looks for Homerun under "NAS", it takes only two clicks to either find it, or discover that it is not there. So they look at the index and know that it is probably under "Media->TV Capture". We would no longer have the hidden doors, secret passages, and one-way corridors that we currently have in the wiki.

I'm not sure exactly what you mean by hacks, or how many of them we have (an example might help me). Maybe hacks belong in the forum. Maybe they belong in the wiki mixed in with everything else, but are identified as hacks by font, page color, or some such.

Maybe automation and security should be lumped to begin with. If the category gets too big, we can split them out. But you're probably correct - not too many articles on security right now.

[purps]

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. It is a little difficult to find a perfect structure for this wiki, but it will be orders of magnitude better than the maze we now have (where it is easy to get lost). 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. For example, if someone looks for Homerun under "NAS", it takes only two clicks to either find it, or discover that it is not there. So they look at the index and know that it is probably under "Media->TV Capture". We would no longer have the hidden doors, secret passages, and one-way corridors that we currently have in the wiki.

I'm not sure exactly what you mean by hacks, or how many of them we have (an example might help me). Maybe hacks belong in the forum. Maybe they belong in the wiki mixed in with everything else, but are identified as hacks by font, page color, or some such.

Maybe automation and security should be lumped to begin with. If the category gets too big, we can split them out. But you're probably correct - not too many articles on security right now.

Yes good points. They could indeed exist in two places, but it would be better not to. I suppose there won't be too many examples of this, so it could just go in both, then you find what you are looking for regardless of how you go about looking for it.

Regarding hacks, the first example that springs to mind is the HTTPS wiki page, which is now properly implemented http://wiki.linuxmce.org/index.php/HTTPS. Another would be the wiimote page http://wiki.linuxmce.org/index.php/Wiimote. Basically, if it isn't supported out of the box without some serious fettling, it's a hack as far as I am concerned, and this should be indicated so that people don't blame the system if it goes wrong.

I'm going to start another thread regarding page/version info, I would welcome your input.

[davegravy]

This may be heresy, but keep in mind that I know very little about these systems:

Are there systems (other than wiki) that are better suited to LinuxMCE? I feel like what we need is a highly structured database-type organization of information, with a highly flexible front-end.

I'm brainstorming on the fly here, so bear with me.

It would be great if, for example, one could filter the list of receivers to show only those which are...

a) compatible, and
b) have ruby codes supporting discrete power on/off commands

...rather than having to click through each receiver, one at a time, and do this manually.

Or, it would be great if a user could identify themselves (set a preference somehow) as an 810 user, and automatically have articles/links to 710,1010, etc material filtered out.

Maybe what I'm describing is a custom web-documentation application? which would be too much work?

[nzlneil]

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".

Yes good points. They could indeed exist in two places, but it would be better not to. I suppose there won't be too many examples of this, so it could just go in both, then you find what you are looking for regardless of how you go about looking for it.

Reading through this, it seems to me that we should have some sort of page tags to assist with grouping them together. This will allow for having one page that could be part of several systems.
e.g. "Some Brands Security System Model XYZ" could have the following tags (these are just some possible random ones off the top of my head, and are in no order)

• Security
  
• Video Monitoring
  
• Remote Access
  
• Lighting Control
  
• Hardware
  
• "Brand Name"
  
• Serial Interface
  
• Cellular Notifications
  
• Hack
  
• 8.10rc
  

[twodogs]

We are beginning to gather a variety of different ideas - exactly as a brainstorming session should do. However, my thoughts are beginning to turn toward the practical. I'd like to know who is actually going to program the framework of our new wiki. What is his/her opinion of the technical difficulty of doing some of what we propose?

[purps]

I'll try and mock something up this lunch time using collapsible tables, but dunno how that will look. Will look into other methods also for making it look more like the link you posted, twodogs.

I'm assuming it doesn't have to be a user-friendly method, as every page will go through a review process before it going into the main wiki? If so, that's another thing we need to think about - will the "approved" wiki pages be locked, so that new pages have to be created in a holding area or whatever before they are reviewed and introduced into the real thing?

[bongowongo]

The holding pages, you can use the draft_pageX formula.
I think it is good if we can summarize this weekend, what ideas to go for and which on not.

[purps]

Once the new structure goes live, would it be possible to have any new pages automatically prefixed with "draft"? Because people won't necessarily know our methods, and might go ploughing in without following the right procedure.

[purps]

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

[bongowongo]

Once the new structure goes live, would it be possible to have any new pages automatically prefixed with "draft"? Because people won't necessarily know our methods, and might go ploughing in without following the right procedure.

We can lock certain pages maybe?

[twodogs]

I'm assuming it doesn't have to be a user-friendly method, as every page will go through a review process before it going into the main wiki? If so, that's another thing we need to think about - will the "approved" wiki pages be locked, so that new pages have to be created in a holding area or whatever before they are reviewed and introduced into the real thing?

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.

[Techstyle]

Been away for a few days, these are all good ideas:

I like the identification of hacks - but also would like a definition of 'hacks' as some newbie might not know what the pitfalls are with doing this.

We had talked previously about putting a tag in the wiki page that said the page was approved by the wiki team. Surely anything not approved by the wiki team falls into the early discussed draft group?

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.

[bongowongo]

Every page will make will first be a draft
e.g. draft_zwave
When it is finalized it will replace the page zwave, and the draft_zwave will become absolete and deleted.
Then the new zwave wiki page will be in a catagory approved/maintained by wiki workgroup.

My proposal is that for some key wiki pages not everybody can edit it anymore and should go through the wiki workgroup.
 
Hacks will need to get a disclaimer.

Everything not having a catagory is just not updated / visited / maintained by the wiki workgroup.

[Marie.O]

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.