IRIX Network Forums
Wiki -- We don't have a lot of engagement - Printable Version

+- IRIX Network Forums (//forums.irixnet.org)
+-- Forum: Site-Related (//forums.irixnet.org/forum-39.html)
+--- Forum: Site Discussion (//forums.irixnet.org/forum-29.html)
+--- Thread: Wiki -- We don't have a lot of engagement (/thread-3142.html)


Wiki -- We don't have a lot of engagement - Raion - 09-28-2021

So I've been running the numbers and it appears while a lot of people are using the wiki, a lot of them aren't signing up for it or wanting to contribute.

I need to know what it is we're doing wrong that precludes users like yourself from wanting to engage.

The big one, I know, is you need separate accounts for everything. Currently, despite my best efforts that cannot be solved. Bridges are expensive, and they don't often work too well over networks or have the best security. They also by nature of their operation mean you need to lockstep software versions together. This is dangerous and unsafe.

I cannot currently fix the lack of SSO. It's just not possible. Other than that, what do we need to do? Let me highlight the history of the wiki and why we're currently using Tiki Groupware for it:

In 2017 I launched the wiki under Mediawiki, mostly as a clone of the Nekochan wiki.

In '18 it started breaking down, bad, because it wouldn't play nice with MariaDB, which we use instead of ORACLE MySQL for reasons I won't get into. Suffice to say, the differences between the two are purely political in nature, and that MariaDB is IMHO, a better product. However, many applications do not offer some level of compatibility. So we clearly had to move off Mediawiki. I switched us to Dokuwiki, porting our articles over by hand.

I moved it from Doku to Tiki due to dissatisfaction with the performance and flexibility, as well as user feedback. So Tiki it was. We're here now

What do I or the other staff need to do to get more user engagement? I know some articles are brief. I know some are stubby. We're still needing to flesh it out, but thus far only me and a few others have joined in it. Currently, I'd argue we have the best quality. Preterhuman's SGI section, while respectable, is mostly out of date, with articles that vary in quality and style and lots of nasty mistakes. I have done my best to create a decent manual of style that refers to the correct way to technical write as I was taught, and I have done 90% of the work.

RE: Wiki -- We don't have a lot of engagement - weblacky - 09-28-2021

OK, I didn't even remember there was a Wiki...so it starts from there, for me. I just went through it and asked myself, why I haven't used it and so forth. Combining your own thoughts from your posting into my thinking - I see a few items.

These are obviously my own opinion and perhaps not correct:

#1 - To me, Wikis are for finalized information, not for developing info or an evolving situation. Since I'm normally at the front of something developing, I wouldn't want to write something down, just to have to edit it later. I always assumed Wikis were the most up to date, final, statement about a topic. Basically full articles or instructions.

#2 - Index - having a good Index that's fluid to the user is very hard to get right, the first level of taxonomy seems okay, accept it's just ambiguous enough to not really know where you're going to go (is my issue hardware or OS?). I suggest that the Wiki MAY be improved by using a taxonomy that encourages goals/tasks instead of identification. I think the tutorial section was the best for me due to this thinking. My attention goes way up when I come across a posting with a actual objective or question, something that sounds immediately actionable. in the title. So maybe tutorials should be separate from definitions which should be separate from System/Station facts pages and not in a common taxonomy.

#3 - Standards and fact checking, normally there is a gatekeeper for this, it's not a great job unless you love writing. But the only way for articles to have a similar feel or level of compliance is for someone(s) to gatekeeper the posting and refine/fact check and authorize final appearance (posting) in the wiki. To add this it might be helpful to have a confirmation score from other users that have followed the steps and confirmed the tutorial worked (a from of communal fact checking).

#4 - Writing the actual information (article publishing). Tutorials make the most sense (outside of spec sheets for each station). Good technical writing does take effort, yes we can assume some level of experience here but not too much. If we want good technical articles you must forcibly create a foundation. By that I mean basic, fully fleshed out, articles that cover the basics - e.g. "Parallel SCSI standards, Operation, and Termination" and also things like "basic hard drive selection" and "Current SSD options for systems" and also perhaps items like "PS/2 scan code revisions - recommended peripherals for hassle free SGI usage". Once we have stuff like this, we can reference it, creating a web of incrementally more concise and precise statements for each article. We may have to even do a community payout to pay someone for working on some of this basic, core foundation, stuff. But once it's there, you can then build on it with articles about "how to safely disassemble an O2" and some shipping info that references that article instead of repeating it. Tangentially, you can then do software tutorials. For me, I'd love a good, exact rundown of modifications and settings I should immediately do after an Irix install for speed or bug fixing (like disabling ESP, configuring DNS, and such).

#5 - High standards means the ability to say "NO", I won't stop anyone from writing an article, but if it doesn't meet the bar, it's not in, sorry. I feel bad when someone has put in effort and that may dissuade them from trying again, but unless it's simple grammar and others can help comb that out, each article needs a point and cannot be a solution looking for a problem.

#6 - Feedback, each Wiki or article page NEEDS a community (have to have a login for Forum at least) feedback section. It will either CONFIRM the value or bring up a serious flaw that needs correction, then someone knows it needs correction. Any wiki posting with misinformation could do damage, we can you community feedback to perform self-correction (to an extent).

#7 - My last thought, to encourage people like myself to contribute to the Wiki directly, once a developing scenario has an answer and has closure (forum posting thread), The admins and the postings author, need to be able to transfer a copy of the entire thread (photos and links and all) into a new wiki page (ready to be named and possibly indexed into a hierarchy). While this won't guarantee a final article, it will create a sudo-article from the posting (copied), now instead of searching the forums, certain postings will be come single page tutorials and articles. If I had all the text from a posting (all of it) in a wiki page, already marked up with Photos inline with the text, well then I could simply snip out the useless conversation, create a minimized record of the discussion and its findings that would almost mimic a tutorial (we remove what didn't work, structure what did).

I guess what I mean it, it's MUCH easier for me to create a summary of a document, when have the document right there and can chop it up easily (condense it). If you asked me to separately summarize instructions for something over a 5 page thread post...I'd tell you that's too much work. If you gave me the entire post and I can cut and rewrite. I can get you something MUCH faster that reads LIKE a tutorial, but in the way we follow short postings with instructions through a single page. We keep in the comments about people discovering things and who tried this and such. But keep all the right answers and throw away what isn't needed to get the point. This may be seen as a quality slip, but at least the info GOT into the WiKi in a condensed manner, that's accurate. That's a win right there.

I also feel information gets buried under the postings, so this would be a great way of highlighting success stories via forums posts, instead of hoping everyone can search the right terms to find the gold in an old posting you cannot see on page 1. Without using "Stickies", I think successful/meaningful posts SHOULD be placed in the wiki and properly titled as information (just like the Irix Setup tutorial). If it's something people can follow, it's instructions, it just needs some weeds removed. That's easier then landscaping a new lawn.

If I had all the pictures and inline text from the posting I can hack it into a mini-article in a few minutes. I only need to cover what I said and did, if I have to gather all those photos and comments again, I'm likely not going to do it.


I hope this was the kind of feedback you were looking for. I'd love to see finalized tutorial info on the Wiki instead of searching in vain in the forums. We need that follow-through from discovery to publication. I hope my suggestions give you some ideas and how we could tackle that hurdle.

RE: Wiki -- We don't have a lot of engagement - Raion - 09-28-2021

Hey weblacky,

Thanks for the verbose feedback. I'll go through each number:

1. We only have a few stubs, fwiw. And a lot of that is due to poor documentation.

2. So you're saying the topic-based index is a bit unintuitive? I'm limited partially by the architecture of Tiki, so I can change categories around and such, but I can't really do a Wikipedia style page for it. Similarly, I don't really want to have pages crossing categories as that will increase possibilities of dead links.

I'm open to changing it, but we need more than just "It needs to be changed"

On this topic, I feel our linking system on the main site is pretty intuitive. Unless you have tunnel vision, there's a clear indication we have a wiki.

3. At least for tutorials I've written, I confirm they work. This is why I don't do for instance macOS or GNU/Linux tutorials. I don't write articles I cannot test. As for fact checking other articles, I do my best to cut through bullshit that exists out there.

4. With regards to more tutorials, I'll point out for most systems SCSI termination isn't even a major concern, and I've only seen one or two PS/2 items that don't work with machines here. Off the cuff, Indy, Indigo2 and Fuel are the only ones that really necessitate termination to be handled by the end user. Octane, Chimeras, etc don't even require it. Neither do O2s. I'm all for getting more articles, but we have to consider topicality, and I'm not paying someone for content milling. That would not really benefit our cause, I feel. What I see most from users is network questions and questions about monitors. It's basically impossible at this point to get a 100% accurate compendium of monitors, as the adapter in my experience has more to do with it than the monitor, and even minor revisions of monitors can have vastly differing results. If somebody wants to try I'm not opposed to it but it's definitely not something that I myself could tackle because it'll end up being a disjointed mess. I have way too much OCD for that to actually fly for me.

As for your last quip an article for that already exists. Check IRIX 101.

5. Do you have an example of any articles that are a solution looking for a problem?

6. My one counter to the suggestion would be that we already have a lot of underused sections and I'm not willing to add more to it. In the past people have requested sections only for them to go under utilized. Clogging the forum with posts for every article is not really feasible, but I do already have request threads and have requested feedback on big articles.

7. I don't really want people posting raw forum threads or posts into the wiki. Not only are the formatting differences vast between the two and can't really be converted one to one, but photo inlining and linking is entirely different between the two. When I ported Jacques' article on upgrading the O2, for instance I basically had to rewrite the entire article and photo links to actually look good and flow properly. You can also see on Preterhuman that they have many archived Nekochan threads, and just how messy and unprofessional looking it is to dump a metric ton of forum content in like that. That's part of the reason I disallow in the wiki style guide confusing constructions like pronoun usage/second person addressing, or vague references to things that don't include links or context.

I have been when I have time converting useful threads and responses into articles, but it's not exactly easy. Everything I've done on the wiki and silicon image by far is the most manual labor I've done. Ever copied nearly 3,000 images by hand off Archive.org? That's me.

I've tried to show people how to do this but some people seem to have a little bit of trouble comprehending the markup/markdown differences and don't seem to understand why second person constructions in technical writing is disallowed. As for why, it's because it creates ambiguity as to what the readers actually supposed to do and there are times where it results in awkward constructions. An article explains how to do something, it's not a place to dictate how to do something to the user like a YouTube video does.

RE: Wiki -- We don't have a lot of engagement - weblacky - 09-28-2021

Yo,
These responses are out of order, as I respond to severity and not the order of the topics (all of this is opinion with a few recommendations), but the topic responses should be clear to follow:

I thought I did give more than "it needs to be changed" by suggesting the root taxonny be changed to System Information/Specs, Tutorials, and Articles (perhaps also Software). Articles can cover info on specific perherials or add-on hardware. I don't think we need a dedicated hardware section as it's too ambiguous. If I wasn't clear, my fault, I was trying to show an image/approach, I didn't have a prefab solution out of the gate. Hopefully the above gives clarity.

The suggested (above) basic roots would replace the current root of "Emulation, Hardware, OS, Peripherals, Policies, Programming, Projects, Subsystems and Applications, Tutorials" (As one can see many of these are sub-topics of neighboring sections: e.g. Emulation, OS, Programming, Applications all fall under Software (Subsystems and Applications). Also Peripherals already falls under Hardware. So that's a starting place for my suggestion. We can compact but also change from identification-style index terms to terms that fit the user/views goal on the wiki. They are searching, maybe not browsing.

In regards to tunnel vision, absolutely! I don't pay any attention to tabs at the top of a page once I click forums...literally didn't even see the wiki tab because it's not a place I really ever went. So yeah, personal failing, but nonetheless true.

In regards to the suggested topics of the articles I mentioned, I think you may have a bit of a unconscious bias on this. While some people might be lucky, most aren't, most start out on Indigo, Indy, Indigo2 systems - as they are cheaper. I did, I didn't even get a system higher than Indigo2 for 4 years (O2 R5200) and then 7 years after the O2, I got Tezros. So starting out on an Octane, that's like having a sports car as your first car, most of us didn't get to learn on one, we had to start with an older/lesser model of car. With SGIs you get what you can, so the education needs of the older systems may perhaps impact a larger subset of collectors then you might think. it's still required knowledge for certain scenarios on newer SGIs as well.

We all love to talk about our higher-end systems. But I have those same older systems I got 20+ years ago and someday somelese will get to enjoy them too. So I think basic education on the technology and setup of the time is in fact more paramount as it's the foundation of later models. I do understand you personally not wanting to take that on, that's not my main point anyway. I'm merely suggesting a technical base of articles that "train-up" a user for handing SGIs, it's a harder technique but then it's a foundation that be utilized as a springboard. If we as a group decided on say 3-4 foundational topics as articles, we could attempt a communal editing/adding of content with a few people trying to tackle cohesion/voice after all the info is present.

In regards to the fact that you've had to do rewrites, that only proves my point, you have to have a gatekeeper and that's a huge funnel of work, consistent voice as well. Personally I find a lot of good info on the preterhuman wiki, info that I didn't see anywhere else once Neko went down. I'm glad it's there and I don't expect a college-level dissertation of each article (as long as the grammar and spelling are checked). And that's exactly what I'm suggesting. Get the info onto you platform first, then you can rewrite it to whatever/whenever. But if you create a barrier of writing standards, the info doesn't appear.

I do not mind the copies of Neko threads at all, yes - some need pruning to remove topics that don't go anywhere. But the core info is there and I can follow it...versus gone. I won't push the issue, but just restating, but I feel that being able to take a thread's raw text encoding, create some kind of basic translation/markup conversion application and dump a thread's text into a wiki page with basic markup already there (basically images and quotes) would allow you to radically accelerate the inflow of good, pertinent information, that at least has some structure already. It can then be chopped, altered, or even rewritten at the later date. But for now it's like cutting out a newspaper article and storing it in your personal binder. You can always do whatever with it later, but now it's saved, titled, organized for retrieval (based on value/topic). You could argue that search works the same, however there are times I search for something and cannot find it, due to the title and missing meta descriptions not having the terminology I would think to use in the posting. But with a saved thread as a article, that can be fixed with a title, summation, perhaps some tags? It's sectional, structured, actionable information that otherwise gets buried. The form does need work...but I think it would be less work then rewriting everything (assuming you had the basic translation markup system going for formatting and inline images).


If "Irix 101" was the article I wanted (I'll assume you are referring to "Irix Setup 101"- I just took a peek right now, didn't know it existed), it's poorly named and that's why I skipped it, not trying to be hurtful, just truthful. I'm looking at descriptive labels to infer what's inside a posting. At least forum postings have a thought or complete sentence to give you the impression of what might be in there. To me, 101 class means basic info (about Irix and installing Irix), I was looking or terms like "Next steps after installing Irix", "Securing Irix", or perhaps something like the terms used in the wiki, "Customizing Irix". Though I do no like that term as it's too broad (covers several sub-topics) and doesn't tell me what might be in there. I'm literally judging a book by its cover, help me do that accurately.

Auctionable terms, this is why some online resources are so good, I can map a goal that tracks onto a set of terms (search) and it all comes together. I've never used a library system search, never used a card index, and always (whenever I had to go to a library) asked where the section is with the topic I wanted, then manually browsed through whatever they had (discovering tangents along the way) in that area. Because I view searching as a bird-eye view of what's available (marking interesting things) then I can come back to them. Rarely online do search terms perfectly line up, so I've learned to get as close as I can to the section, then just do an audit to find what I need. Jargon does help, but does not 100% fix the situation either.

As for the topic of the solution looking for the problem. How about (off the top of my head, they are stupid, because they aren't really wanted) - Modding an O2 case to fit a mATX motherboard PC, making fish tank of out an Onyx, making sofa ends out of two crimsons, using an RGB fan with custom arduino lighting inside an Octane, etc....yes these are slanted, I'm sure someone can think of other topics that similarly go against our wishes and waste our time.

In regards to your training others, do you have a tutorial on the Wiki about formatting/markup or writing? I'd like to at least know the basics myself of what formatting is available and how to do that. I don't know right now.

Either way I hope these addressed the concerns you raised, yes, many are my personal problem, if you find others don't agree, feel free to take it as one person's view but not helpful for the majority. I'm used to being told by others that nobody thinks this way, but this is how I operate and gain skills. I'm big into preserving info, if you can find a good technique/shortcut to engage and start pulling in more information, I'm all for it.

It's just that to me, I grew up reading articles and forums postings, so titles that tantalize skills or info draw me in and allow me to easily decide if that's something I'm going to read or not (did the title grab you). I'll even say the idea of an article summation next to the title would be great as well, to let perspective readers know what yo expect from this article

On a closing note, I really like IrixNet, I spend nearly all my online day here, I love the hardware and repair topics and I'd love to see more. As we discover things, I'd love for those to be documented into Wiki pages. I think we can do that for milestone efforts, but for the small things, I think perhaps a looser definition of a wiki article may need to exist for smaller topics.

You've created a great site and fostered a great group of people, you have something special, we all only want to help improve it and add our piece. So please view this with that understanding.

RE: Wiki -- We don't have a lot of engagement - Raion - 09-29-2021

So I'm gonna give a brief reply that answers that one sticking question:

Yes, we do have a style guide: https://wiki.irixnet.org/Style-Guide

It's listed on the main page and includes system specific style points as well as a link to Tiki's excellent markdown articles. For examples of how I've used most of those, check out the Onyx article and view it's source code. You may need to create an account to do that.

I am willing to rename or possibly combine categories, but without discounting your suggestion of more of an hierarchical search tree, it would be confusing and for the wiki's size, rather unnecessary. If you take a wrong turn, you end up in a secondary level where you have to again select a category and that can get repetitive. Certainly useful if we have a lot more categories. I keep emulation apart from the others for instance because I feel that running tech support for emulation is a niche issue. The emulation is gonna not be perfect and have limitations that may not be experienced by a real machine, hence I think it's prudent, as we do here, to keep emulation related stuff in it's own section.

That being said, we can consider switching some out or even removing some stub articles like the one on Xsgi.

I don't want to wholesale import articles from Preterhuman, and I won't do that. As we have most of our systems covered, that's pretty manifestly unnecessary for that category. For other topics, most of them don't meet our quality standards. I've grabbed the ones and converted them that I think are the most viewed or pertinent, do you have suggestions of topics they have that we don't?

I'm aware that the hobby has changed and Octanes for a hundred bucks is not really common anymore, for that fuck eBay and I don't understand why so many people continue to give them business and buy into it. I have a list of eBay auctions in that category I keep eyes on, but it's only really good bargains.

But I've not seen SCSI termination come up that often. It does a few times a year and those get usually answered pretty easily, I think I did mention in either the Indy or Indigo2 article about the fact they use a different SCSI ID for the controller (I believe 0?) Than the standard calls for on other systems. If you have an idea for how you wanna flesh that article, make an account, I'll promote you to editor and you can scratchpad it out.

I think IRIX Setup 101 was a good name, or at least that's why I chose it. It covers too many topics to be generalized as customization or anything, and it is arranged in a logical fashion. I could change it to "IRIX Post Installation Setup 101" but I thought brevity is better. People today have attention spans that are shorter than a cigarette butt.

As far as a script to turn BB code into Tiki markdown goes, that's just not possible due to specificity. Tiki uses image justification that requires it to sit on one side or the other. There's no way to get that from an BB code tag and if you make a default assumption of left or right it will cause text scrunching or text wrapping issues since it inlines. The code and preformatted text blocks are VERY particular about escaped characters for tiki, and those aren't easily parsed out even with a perl or DOM text engine IME.

That being said, if we get a band of authors on the wiki besides me, maybe we can make a thread for copying the posts we think are worthy of their own articles into an article format. Then we can link the wiki back to the original conversation.