Knowledge Base changes

From MozillaZine Knowledge Base
Jump to navigationJump to search

This page has been created for several reasons.

  • It would be nice to have a place where new editors can introduce themselves and meet existing editors.
  • It would be good to allow new editors to safely propose content changes (minor or major) prior to implementing them.
  • It would be good to have a central location to discuss the style, content and organisation of this Knowledge Base. (Some of the ideas in Talk:Knowledge Base can be migrated here, leaving that page solely for discussion of the front page article itself.
  • This page was an attempt to address incidents that have occured on the KB where some groups of editors have been unaware of major changes being made by other groups of editors.

This page is the primary place to announce new suggestions. Whenever possible, issues should be discussed in a more appropriate place, such as the discussion page of the article or category that the suggestion affects.

Once suggestions are resolved, they are moved to Knowledge Base changes/Archive.

Welcome to new editors

Hello! Great to have you here. Please add a comment here :-)

  • Hello Knowledge Base! FJ reporting to duty! *bows at all* FatJohn 11:30, 3 January 2006 (UTC)
  • I guess I'm new, I am "name already taken" from the forums, hello to everyone! --Lethargy 21:34, 10 May 2006 (UTC)



Knowledge Base changes

A discussion by interested parties regarding the MozillaZine Knowledge Base, in the context of planning for improved Mozilla end-user support, is taking place. Details at http://groups.google.com/group/mozilla.support.planning <snip> Forum discussion of end user support, including the KB, here. Alice 12:34, 8 May 2007 (UTC)

Update: Minutes of the end-user support meetings were posted to the mozilla.support.planning newsgroup, along with an announcement linking to drafts of a Firefox Support Overview and Support Product Requirements Document. Proposals related to the KB include one log-in for forums and knowledge base management, account levels (admin, senior moderator, moderator, senior editor, editor, volunteer) as well as analysis and metrics to include top viewed articles (problems). Division of articles into "How To’s" (tutorials or best practices initially populated with content from “Firefox Help”) and "Troubleshooting" (“support” that helps users solve problems) was proposed, with the troubleshooting section being initially populated with MozillaZine Knowledge Base content that will be organized in a tagging structure that incorporated most frequently accessed questions. Creation of KB style guides and editorial approval processes for content and style were also proposed. See http://wiki.mozilla.org/Support:PRD#Knowledge_base_requirements for details. Alice 10:57, 18 May 2007 (UTC)

Resolving logjams

We seem to be doing a good job of avoiding editing wars but not having a process to resolve logjams prevents us from improving some articles quality. The proposed dispute resolution process is not the right vehicle to do that since its basically a way to deal with people behaving badly. Nobody is behaving badly with a logjam, they're just not making any progress and there is no obvious way to resolve the issue.

A good example is Plain text e-mail - Thunderbird, written by Guanxi . It basically redefines plain text messages as non-MIME ASCII messages, which doesn't meet the needs of most of our users. Rod Whiteley wrote Mail content types which overlaps some of that article, and has more of a end user focus. There seem to be two process problems:

  1. We don't have any recourse if a author strongly disagrees with feedback in the talk pages without running the risk of editing wars and/or needless aggravation.
  1. The two authors agree it would make sense to merge the two articles but can't agree on a process to do that.
Note: The talk page for mail content types has most of the discussion about merging the articles and issues with the plain text article. I'm clearly biased, but that helps make my point. I originally gave up trying to get Guanxi to make some changes when it just seemed to pointlessly aggravate him, over a year ago.

If we can find a good way to resolve logjams (that doesn't run roughshod over peoples feelings or get abused to force one point of view) that might make it easier to make some progress on quality control and user feedback issues. Suggestions? Tanstaafl 09:57, 9 May 2007 (UTC)

You said that, The proposed dispute resolution process is not the right vehicle to do that since its basically a way to deal with people behaving badly. I never thought of it that way. I said here that, Such a mediation request could also be looked at as a request for "quality review" of the article, since after all, what we really want is for the article to be well written, understandable by the intended reader and technically accurate. The same conflict resolution process applies.
You also said, The two authors agree it would make sense to merge the two articles but can't agree on a process to do that. In this specific case where two articles overlap, if I were mediating the dispute I would suggest that the overlapping content be removed from the more recent article (Mail content types created by Rod Whiteley on 28 January 2007) and added to the original article (Plain text e-mail - Thunderbird first edited by Guanxi 2 February 2005). If the more recent article contains enough information to justify a new article it could be rewritten with just the new content; alternately, the two articles could be fully merged into the original article, whatever works best. A draft of the merged article could be worked out on the original article's discussion page or either user's page, whichever works for both parties, similar to the way the Error loading websites article was merged on my user page for proposed articles, as discussed in Talk:Error_loading_websites. Alice 18:21, 9 May 2007 (UTC)

Without having any guidelines or someone in charge, the way to resolve these issues is through compromise and majority rule. I'm sure you've already tried compromise, so all that's left is majority rule. Majority rule is more palatable the more people concur. I'll read up on the subject and throw in my opinion to see if that helps to resolve things.--Np 19:58, 9 May 2007 (UTC)

The point I was trying to make about the dispute resolution process was that if the authors were behaving badly you can force them to let somebody mediate the dispute etc. or suffer the consequences. However, nobody is behaving badly, and if they're not interested in the dispute being mediated (which carries a certain stigma , is a unpleasant process, and assumes there is a neutral mediator available they both can agree on) or can't agree on a compromise then we need other mechanisms. That seems to leave either organized social pressure or some form of majority rule. Tanstaafl 22:11, 9 May 2007 (UTC)

I see your point, you want a quality review process, as you said,... not having a process to resolve logjams prevents us from improving some articles quality. You don't necessarily want social pressure or majority rule unless the individuals exerting the pressure are known to have the technical expertise in the subject area. Ideally, you would have a quality control committee that will review an article, find deficiencies (factual, in-house style, etc) and then make a decision that includes references to back up disputed information. The reviewer(s) can either fix the article or issue a recommendation for a rewrite that carries weight. Hopefully, if or when Mozilla takes over the KB such a process can be put into effect. Alice 22:44, 9 May 2007 (UTC)
If user A and user B don't want the dispute mediated, then tough on them, they can fight continue to fight each other until one gives up. If people don't want to get the dispute resolved, I don't really care to force a resolution on them. If user C came along and said "hey, I agree with user A, I'm going to go through the process to get the changes done", then we go through the process and whatever is decided, user A and user B have to live with.--Np 15:48, 10 May 2007 (UTC)
While a "quality control committee" might make sense for Mozilla (who have more resources, direct access to the developers, and are a corporation) I'm leery of a bureaucratic approach. It centralizes power, and imposes their judgment (even down to small details) on what a good article is. Given our current situation I think a more appropriate approach might be one focused on breaking up logjams by forcing a resolution of the key issues (rather than trying to improve everything in the article) or bringing attention and resources on articles that either need significant rework (based on evaluating user or editors feedback) or updating (due to changes in the application) and then get out of the way and let the author(s) do their stuff. If something like that works then later on we can always try ratcheting it up another notch. We might eventually wind up with a "quality control committee" thats reviews articles and makes detailed judgments about how to improve them, or we might not.
Continuing Np's example, I'm user C. I see a logjam that serious enough that I want somebody to force a resolution, one way or another. Hopefully logjams will be much rarer than articles that need significant rework/updating, so I could identify a potential logjam using this page (which gets more scrutiny). While we might not have experts in that area we do have experienced editors with the right general background. I would hope that if we get a large enough group to deal with the problem that people aren't worried about bias, retribution (if you don't agree with me I'll get my friends to nominate lots of your articles) or lack of specific expertise. We'd need some sort of screening to push back on frivolous or inappropriate requests, some way to form the group when needed, a simple process to make a decision, and the ability to appeal to the sysops if you think the process was abused. Another issue would be how does the group discuss what to do without interference from the authors. Most of the tools for blocking and protecting a page seem too coarse. Tanstaafl 00:16, 11 May 2007 (UTC)
A fairly good criteria to weed out frivolous requests would be to simply see if there was any discussion about the problem on the talk page. That way, if someone wanted to get "retribution" by nominating a lot of someone's articles, they would have to write and defend critiques of each and every article, which is actually a good thing.--Np 14:57, 14 May 2007 (UTC)

Article review process

Tanstaafl, you said, While a "quality control committee" might make sense for Mozilla (who have more resources, direct access to the developers, and are a corporation) I'm leery of a bureaucratic approach. It centralizes power, and imposes their judgment (even down to small details) on what a good article is. I suppose you're right, an "arbitration by committee" approach might be better when "people are behaving badly", as the final step in the dispute resolution process. Still, I'm in favor of a structured quality review process, as I've said before, not only to systematically review articles when major changes occur, such as happened when Firefox 2 came out, but to see if the quality of all articles can be improved. My thinking was that a Quality Control committee would ideally have members that are technical experts in Mozilla applications but, as you said, While we might not have experts in that area we do have experienced editors with the right general background. I see your point how nominations of articles for quality review by a QC committee might be used as a threat by editors with "friends on the committee". Instead of a "commitee", we could use an open forum, such as we use when articles are nominated for deletion. I guess we could tag the article with a "Request for comments" template (from the wikipedia article: An RfC on article content is for helping to develop consensus or for gaining an outside perspective to help settle a deadlocked disagreement or make a better decision) as I mentioned here:

Correct me if I'm wrong but right now, articles are only updated or reviewed if someone comes across it and notices something amiss, or if it comes up in the recent changes list. That's why I mentioned a feedback process for non-editors, so that errors or problems get noticed. On way that articles get reviewed as a part of a group effort right now is if someone nominates it for deletion. I would at least like to see a system set up so that articles can be nominated for quality review. Nominating an article for quality review or requesting comments from other editors about article content could also be part of a dispute resolution process in the case of conflicting opinions about what information should be included or removed from an article or how the article content should be organized.

The downside of that approach would be that each "voter" might not have the same level of expertise as the persons who wrote the article, compared to review by a committee of experts. I'm just trying to come up with a process that everyone can respect as fair. We don't need to alienate editors, goodness knows we need all the help here we can get. Alice 13:36, 11 May 2007 (UTC)

A "quality control committee" approach seems to tacitly assume the "real" problem is authors making poor decisions (lack of technical expertise, poor writing skills, lack of feedback, poor process control, don't know how to properly analyze user feedback etc.). I don't think we're that successful yet, we're still being held back by lack of resources and not being able to make good use of those we have.
The request for comment tag approach is interesting. However, I think it suffers from the same problem we have with the update tag and whatever the tag is for saying that a article doesn't meet Wikipedia quality standards. In practice, somebody needs to look at the article to notice the tag.
While it would be great to have a system of feedback from ordinary users (other than the discussion page) I think we can do a lot without it. How about something as simple as a page devoted to nominating articles that need rework or updating? Anybody adding an article to that list would add a short paragraph specifying why you're listing it and maybe give it a severity rating. There would be no guarantee that when you nominate an article that whoever fixed it really did what you wanted, but it could be a quick and easy way to bring attention and resources to bear.
I'm aware of a couple of Thunderbird articles that need updating but I keep procrastinating since they're not about something I'm interested in and would also require me to do an hour or so of research. Its so much more tempting to write a new article or do a quick fix on an existing article instead. However, if I added them to the list somebody else who felt differently might do the work. I assume I'm not the only one in that situation. It might also help if somebody tried to organize a review of all of a applications articles after a major upgrade. Its a lot easier to ask somebody to read an article and make a note of any problems (they don't have to be problems due to the update) if they're not on the hook for making any of the changes.
I suspect this approach would work best for out of date or broken pages, logjams, or ineffective pages than identifying how to improve so-so pages. But it would be a start, and a lot easier to implement. Tanstaafl 00:34, 12 May 2007 (UTC)
How about something as simple as a page devoted to nominating articles that need rework or updating? That's kind of what I had in mind, a "Pages that need revision" (or whatever you want to call it) page, in addition to the article tag asking for comments that links there, just the way we do it for Pages voted for deletion. Discussion could be kept on the "Pages that need revision" page and, once a certain time period has elapsed to allow for comments, either the person initiating the request or another interested editor can go ahead and update the article. Any comments would then be copied to that article's Talk page before clearing the discussion. Alice 01:08, 12 May 2007 (UTC)
It sounds like I was reading something into "quality control committee" that you didn't intend. Sorry about that. A couple of questions.
OK but before we get too far on this, I just want to say that I never thought that any "articles needing revision" list or waiting period is needed for anyone wanting to do a major article revision. When I see something that needs fixing, I just go ahead and do it and document it on the discussion page if it may be controversial. I just figured someone who noticed a problem with a page might prefer bringing it to everyone's attention if he wanted more input before revising it or if he was too busy or did't want to do the revision himself. (There was also some talk on the mozilla.support.planning newsgroup about getting an inventory of KB articles, including those that needed fixing, so I thought maybe our own list would be helpful!) Alice 21:11, 13 May 2007 (UTC)
  • Why do you prefer to have the discussion in the "Pages that need revision" page rather than the articles discussion page? I had been thinking of deliberately keeping a short list in that page to make it easier to scan for articles that a person might be interested in helping out on. Either approach would work, I just want to understand your thinking.
    • On where to discuss proposed revisions, I was simply trying to keep the analogy going with the "Pages voted for deletion" approach. Just a short paragraph outlining what needs revision with a link to the particular article's own discussion page would be fine. Alice 21:11, 13 May 2007 (UTC)
  • I can see the benefit of waiting for comments when trying to improve a ineffective page or when there are conflicting opinions. Are you suggesting we should do that too when an article is out of date or is just a stub?
    • I would prefer this to be a separate page for articles that have quality issues or need major revision, and tag them with a "request for comments" template (and possibly a "needs revision" category?) so we can keep track, then wait a reasonable time before someone that wants to fix the article goes ahead with the revision. This isn't "asking for permission", it's gathering input so that the article can be improved. Articles that need to be cleaned up for style and formatting or those that need some updating but don't need major revision wouldn't get a "request for comments" tag, just the "cleanup"or "update" tags and categories we already use. Stub articles should already be tagged as stubs and don't need to be listed here either. Maybe a "stub category" can be used as a way to keep track of stubs (if that is what we want to do) and if no one expands them they can be nominated for deletion (that's what Stub articles says). Alice 21:11, 13 May 2007 (UTC)
  • Based on the quote for a "Request for comments" template I assume that covers logjams too. Are you suggesting that I could nominate the plain text article, wait a week for comments and then just do what I think is right (merge the two articles etc.) as long as there is a token appearance of a consensus? That doesn't seem right. Could you elaborate on how you think a decision should be made? Please include the possibility that one of the authors doesn't notice (for whatever reason) that their article has that template.
    • That's exactly what I'm suggesting, just ask for comments, then do what you think is right. If you indicate that you propose merging the articles and if no one responds to a request for comments, I see no reason why you or any author couldn't just go ahead and merge the articles or make other changes. Alice 21:11, 13 May 2007 (UTC)
  • You'd prefer just one template? An alternative would be one for updates, one for articles that somebody thinks are substandard but there is no "real" conflict (a good example would be somebody just wrote a stub), and those where there definitely are conflicting opinions.
    • Just one "request for comments" template (which possibly adds it to a category list) that states that someone is requesting or proposing major revision of the article, with a link to the "Articles needing revison" page. We already have "cleanup" "update" and "stub" templates. I would rather keep this list for articles that need major revision with an eye on improving quality. Alice 21:11, 13 May 2007 (UTC)
  • What guidelines would you suggest on whether a "request for comment" is appropiate? Tanstaafl 11:59, 12 May 2007 (UTC)
    • I don't think we need any guidelines, do we? We're just asking for comments about an article that someone feels needs revision. We could maybe just add a short description of the new template in the Rules/Templates article. Alice 21:11, 13 May 2007 (UTC)
We have cleanup, update, and stub templates but they don't seem to be widely used and unless you browse the article there doesn't appear to be a convenient way to find them (there is no page listed in http://kb.mozillazine.org/Special:Specialpages for example). I think a lot of this discussion has been because I keep trying to mingle making it easy to find articles that need work with the rfc template, which is what you're proposing for article reviews.
We have Category:Articles to clean up and Category:Articles to update (adding either of these templates to an article also places the article in the associated category) so those category pages can be used to find those articles. I don't see a category for stub articles, though. Alice 22:16, 14 May 2007 (UTC)
One of your answers states the rfc template is meant for gathering information, and not getting permission to do something that another author objects to. That would make the article review process very simple. However, another answer states that logjams are part of article reviews. The two answers contradict each other. From my viewpoint I have the information necessary to merge the plain text and mime content types articles. So I'd have no need to add a rfc template though I could do so. But I don't think its appropriate for me to do that unless there is a clear consensus. That the reason why I asked the question about guidelines.
We can use a "request for comments" template for a number of purposes, including gathering input from other editors to settle disputes among active editors, "kick-starting" a logjam and eliciting ideas to improve articles that are perceived to have quality issues. Wikipedia uses separate processes such as "Peer review" and "Pages needing attention" for different situations but I think we can use one simple "Request for comments" (or whateer you want to call it) category since we're a small group. Alice 22:51, 14 May 2007 (UTC)
I suggest we
  • Create Cleanup, Update, Stub, and Request for comments categories.
  • Don't create a "Articles needing revision" page since if somebody wants to be notified when somebody is requesting comments they can just navigate to "Request for comments" category and click on Watch.
  • Create a "rfc" template, mention it in http://kb.mozillazine.org/Rules/Templates, and also state which templates have categories.
  • Add a paragraph to http://kb.mozillazine.org/Rules about article review.
  • Plan on all of the article review taking place in the articles discussion pages.
  • Deal with the issue of logjams in the logjam discussion. Tanstaafl 10:44, 14 May 2007 (UTC)
I agree with all of the above, except as I mentioned, we already have categories for Category:Articles to clean up and Category:Articles to update. Alice 22:16, 14 May 2007 (UTC)
I just wanted to add that your idea to not create a separate "Articles needing revision" page to keep track of articles, and instead, to use a "Request for comments" category page, makes sense. When we do create the "Request for Comments" category, it might be a good idea to add a paragraph to the category page, along the lines of explaining that these articles need input from other editors to settle disputes or resolve logjams about article content and to gather ideas to improve article quality, just to clarify what the category includes. Alice 22:33, 14 May 2007 (UTC)

I see that a new Category:Request for comments has been created. Is a template also in the works, similar to Template:Cleanup? I would suggest something like this:

(Looking at how the "Cleanup" template is made, I guess you would also add [[Category:Request for comments |{{PAGENAME}}]] to the template to automatically add the category). Alice 20:56, 17 May 2007 (UTC)

I created the Request for comments template and modified the Stub template. I just need to update http://kb.mozillazine.org/Rules/Templates . Tanstaafl 11:09, 18 May 2007 (UTC)

Screenshots - confusion?

I'm worried about us posting screenshots of dialogs to describe how to do something and some poor granny trying to actually click on buttons in the screenshot. What can we do about this?--Np 16:59, 18 May 2007 (UTC)

I don't think there is much we can do to prevent people from making silly mistakes, except maybe to add something like "Sample image: do not click" to each screenshot ..... it's funny, because I've tried using scroll bars on screenshots myself, on occasion :-D Alice 19:44, 18 May 2007 (UTC)

Application specific articles

I've noticed a recent trend towards having more articles be application specific. My first impression is that this seems to be due to

  • Recent awareness that you can include screen shots in the article. Creating_a_new_Firefox_profile_on_Windows and Corrupt_localstore.rdf for example are articles that at one time would have at least been written to cover both Firefox and SeaMonkey, and might have also covered Thunderbird.
  • Frustration over the density and problems in navigating an article that cover many applications, such as Profile_folder
  • Mozilla's plans to create their own knowledge base, using migrated Firefox articles from mozillaZine.

I've frequently pushed for Thunderbird specific versions of some articles, including one for Profile_folder but I have mixed feelings about this trend. There are some cases where it makes a lot of sense to address multiple applications in one article. I'm also concerned over what effect this has on whether editors who tend to focus on browser specific articles will continue working on the mozillaZine knowledge base after Mozilla creates their own for just Firefox. Thoughts?

As an aside, does anybody object to my creating a calendar category? Tanstaafl 22:28, 18 May 2007 (UTC)

I can see advantages in combined application articles such as Profile Folder. One reason being, the same files may be used in different application profiles (in some cases they can be copied over directly, as with mimeTypes.rdf and bookmarks.html). Firefox users are in the majority, though, and it's hard for editors who don't have experience with Mozilla Suite or SeaMonkey to include it in articles. I use SeaMonkey about as often as I use Firefox (and I still have Mozilla Suite installed as well) so I try to include SeaMonkey where possible, such as in plugin articles. In the case of Changing media handling behaviour I've included screenshots for both Firefox and SeaMonkey. Regarding Mozilla's plans to create their own knowledge base, using migrated Firefox articles from mozillaZine, when that happens and if my contributions are no longer needed for Firefox articles because Mozilla folks have taken them over and restrict new articles to selected editors, I can always go over to SeaMonkey and start fixing up that KB a bit. Alice 00:39, 19 May 2007 (UTC)
I think combined application articles are good when the info provided only differs slightly, for example by a single menu sequence. In profile folder, about half the article doesn't apply to any given user. Creating a new Firefox profile on Windows was created not to avoid mentioning SeaMonkey, but to avoid the "but if"s, "except if"s , and "you can also"s that plague the profile manager article.--Np 01:41, 19 May 2007 (UTC)

"What's stopping you" feedback

I made a post on the forums and the support planning newsgroup asking why people who have the knowledge don't contribute to the KB. I'm going to post here the results, and we can discuss what can be done about it.--Np 16:41, 5 June 2007 (UTC)

Don't have an account [1][2]

We should turn user account back on. We had turned it off a while ago because of bot spam. Now that we run MediaWiki 1.6, we can use ConfirmEdit to stop bots with captchas.--Np 16:41, 5 June 2007 (UTC)

I filled in for you for a while as the contact point to get accounts and have watched the log file to see how often they contributed. My impression is they typically made a few minor edits and then disappear. I'm not as comfortable as you are that the capthca will do a decent job. So I don't buy the argument that the hassle of having to send a email message is causing a major problem, especially since there is a disproportionate amount of contributions from a few editors. I've also had to jump through similar hoops to join many forums. I'm far more concerned about what discourages a editor from contributing more often, or writing an article. Tanstaafl 21:25, 5 June 2007 (UTC)
I'm not as comfortable as you are that the capthca will do a decent job. A decent job of doing what? I don't think we want to limit who can edit the articles. That's actually the impression that we're putting out there by requiring an e-mail. I've had quite a few people mail me their requests with credentials, as if trying to prove that they're worthy. The current system:
  • Wastes my time
  • Wastes the users' time writing me an e-mail and waiting for my response
  • Possibly dissuades new editors (because they think they need credentials)
  • Possibly dissuades users from posting comments on articles
The only downside I can see to going to the captcha would be we wouldn't prevent the clueless who try to edit the pref articles and the like. That wasn't that big of a problem before we disabled creation, though.--Np 23:09, 5 June 2007 (UTC)
"A decent job of doing what? " - A decent job of preventing spammers from vandalizing our articles. I've read several articles about how how spammers get around image based captchas, it appears to mainly be a question of is it worth their effort. This article is just one example of the ingenuity that some sites need to deal with. I would feel much more comfortable if you had some data from other wiki's about that captcha's effectiveness rather than just speculation that we need this to get more editors.
I averaged one account request every two days. Our welcome mat isn't out, I suggest we change the text at http://kb.mozillazine.org/MediaWiki:Loginprompt and the thread in the mozillaZine site discussion post to make it explicit that anybody can have an account, while discussing this issue. Tanstaafl 00:22, 6 June 2007 (UTC)
Yes, spammers can get around captchas. They can get around pretty much anything. It's a case of how hard they're willing to try. I'm thinking that the spam we were getting was spambots set up to do that to any MediaWiki installation, not specifically us. We could set up the captcha system, and if it works, good, and if it doesn't, then we can go back to what we use today.--Np 01:53, 6 June 2007 (UTC)
I've edited the login screen, but I can't edit the sticky because it's locked.--Np 03:52, 6 June 2007 (UTC)
I edited it for you, using the same sentence you used in the login screen. If you want something different, send me a private message when you want it unlocked, and then again when you want it locked. Tanstaafl 06:09, 6 June 2007 (UTC)

Don't know how to write articles[3][4]

Perhaps we should add a basic intro on how to do it? I know we have all the rules and style guidelines and stuff, but I think we need something aimed at new users to encourage them to do it. Perhaps we can create some sort of comprehensive "Here's how to work the KB" with appropriate levels of detail that includes many of the articles in Category:MozillaZine Knowledge Base organization.--Np 16:41, 5 June 2007 (UTC)

That seems like a good idea. Tanstaafl 21:25, 5 June 2007 (UTC)
We could improve MozillaZine Knowledge Base:About. It seems to have the beginnings of what I'm talking about. We could also make it more prominent, like putting it on the registration page.--Np 23:14, 5 June 2007 (UTC)
Sounds good. I'd also suggest something like a link to a guide for new editors that actually points to that article in the paragraph at the top of Knowledge_Base. Having a link labeled "About" is too easily ignored. Tanstaafl 00:36, 6 June 2007 (UTC)

I've made changes to that page. Let me know what you think.--Np 17:14, 6 June 2007 (UTC)

Looks good, useful. Some minor comments:
  • Its a Discussion link, not a button.
  • It says to "press the Signature button on top of the text box (the second one from the right)". It took me a while to figure out you meant the next to the last of the blue icons above the edit window, "text box" didn't mean anything to me until after I had figured out which icon you meant. I don't know whether "text box" is a better or worse description than "edit window", but I had nothing to give me the right context. I don't know whether I mis-interpreted a "signature button" as meaning a standalone button (not a button in the toolbar), and whether I got that "the second one from the right" was talking about the signature button instead of which text box. All I know is that for a good while I just didn't get it. In fact I initially started to write a comment that I never heard of a signature button and couldn't find it (I always type ~~~~ and usually use just the two leftmost buttons/icons).
  • You might suggest that one way to learn how to do things is to look at the source of another article. I never read the article on tables for example, I just copied and pasted a table from another article and modified it.
  • I suggest "Making big changes" be rewritten to lower the bar for what should be mentioned in Knowledge Base changes to be anything that effects other editors or might cause arguments, such as adding a new category. The example of a "a new categorization system" implies it would be okay if I decided on my own to move everything in the Preferences category into lots of child categories.
If I have any further comments I'll make them in the articles talk page. Tanstaafl 03:12, 7 June 2007 (UTC)
I've made changes to address all your comments, thanks.--Np 08:15, 7 June 2007 (UTC)

A further theme seems to be that users don't want to do something wrong so they don't do anything at all. We should explicitly encourage users to post content even if it's not formatted properly or categorized correctly. As long as the content is accurate, I'd rather have it poorly formatted than not posted at all.--Np 19:59, 5 June 2007 (UTC)

I think we try to do that. Part of the problem might be the wiki itself. I remember when I first started editing articles how cautious I was because there was no place to get advice and I didn't want to embarrass myself with repeated failed attempts to do certain things showing up in the log. It also wasn't initially clear to me how you created a new article, or where it should be stored. I remember looking in the Wikipedia help and getting frustrated due to information overload, and it assuming you knew too much. I wasn't even aware that the Mediawiki help might be a slightly better resource. Perhaps we should consider something like the sticky Moderation / Spam / Registration / Login Activation Requests thread as a place to ask for help/advice? It might be less threatening than asking in a dedicated article. It would also have more visibility. Tanstaafl 21:25, 5 June 2007 (UTC)
Yes, kind of like a "KB Embassy" on the forums. We could include links to the intro and accept requests for (changes to) articles.--Np 23:14, 5 June 2007 (UTC)
[5]--Np 08:15, 7 June 2007 (UTC)

The interface sucks[6][7][8]

Maybe look into getting a new skin?--Np 16:41, 5 June 2007 (UTC)

No one talks about it[9]

See "Not seen as important".--Np 16:41, 5 June 2007 (UTC)

Don't think changes would be accepted[10]

Possibly related to not having an account, not knowing what to do, and "previous altercations".--Np 16:41, 5 June 2007 (UTC)

Previous altercations between members make it look unwelcoming[11][12]

Should we really be discussing changes to articles anywhere other than on the KB itself?--Np 16:41, 5 June 2007 (UTC)

Yes. I've found it very useful to occasionally create threads seeking input for new articles that I'm going to write, or to ask for help getting the info needed to update an article. For whatever reason, many of the most frequent posters in the forum don't want to be editors but are very willing to help this way, especially if its on a topic they might have strong opinions on. For example, Keep_it_working_(Thunderbird) . On the other hand, I agree we shouldn't wash our dirty laundry in public. Tanstaafl 21:25, 5 June 2007 (UTC)

"Attitudes towards volunteers"[13][14]

Not sure what this means, considering AFAIK all KB editors are volunteers. There seems to be some animosity between the different support channels and towards Mozilla itself. Not sure any changes to the KB would help this.--Np 16:41, 5 June 2007 (UTC)

Poor organization[15]

This is more likely "Don't think changes would be accepted".--Np 16:41, 5 June 2007 (UTC)

Not seen as important[16][17]

It's certainly important from Mozilla's perspective. Possibly not important to certain support channels because they have other methods of posting content (sticky threads, external websites, etc.) Should we make an effort to identify and migrate this external content?--Np 16:41, 5 June 2007 (UTC)

What external content are you talking about? My impression is that we try (perhaps not successfully) to port any information about profile folders and FAQs such as http://ilias.ca/netscape/profilefaq/ , and link to any tutorials we find.
I interpret Nitin's comment as mainly saying we're not that useful because we're not the first support link, we force users to deal with information about multiple applications, and its too hard to find information. I have low expectations about most new users looking for answers in the knowledge base, especially when Mozilla starts their own knowledge base. What I think is more realistic is to make it a good tool for frequent posters in the forum to use as canned answers when helping somebody, and to make it useful for advanced users.
I'm not saying we shouldn't try to make it more useful for new users, I just believe due to human nature and factors outside our control we're going to have limited success getting new users to look and find answers in the knowledge base. We've learned the hard way that many new users ignore a prominent sticky thread about their problem, and the knowledge base isn't organized like a traditional FAQ, so getting a new user to search categories for answers (especially when some have problems keeping straight the name of the application) can be a stretch. Tanstaafl 21:25, 5 June 2007 (UTC)
I agree with your assessment of Nitin's comments. I think his point of view is limited to what he sees in the forum. Other sources than the forum use the KB. Mozilla's support site already features KB content prominently. And as you said, it's useful for helpers to look up information. If someone only sees the forum and the KB, then having content in stickies is just as good or even better than having content in the KB. Looking at the whole picture, though, it isn't. We need to encourage having the content in the KB, and having stickies in the forums just be links to that content.--Np 23:22, 5 June 2007 (UTC)
There's two issues here - one is importing useful external content, the other is encouraging the makers of that content to bring it to the KB themselves.--Np 08:24, 7 June 2007 (UTC)

Don't want contributions edited mercilessly[18]

Not sure we can do much about this one...--Np 08:24, 7 June 2007 (UTC)

Lack of guidelines[19]

Need elaboration.--Np 08:24, 7 June 2007 (UTC)

Do not contribute directly, provide feedback via other channels[20]

We should encourage this, like in the "KB Embassy" idea above. What would work for other channels?--Np 08:24, 7 June 2007 (UTC)

Think it's already being covered adequately[21]

"The KB is too technical"

One of the complaints I've heard many times about KB content is that it's too technical and complex. I think we should flesh out some guidelines regarding how technical we can be in the articles. The goal here is not to remove technical information, but to make it so non-technical users can read the KB without having to understand the technical bits. Some ideas:

  • Don't assume that everyone knows how to do semi-complex tasks, such as setting a preference in about:config or finding the profile folder. When we need to tell people to do these things, either include step-by-step instructions on how to do them if it's short (setting a pref) or link to an article that explains it (finding the profile folder).
  • Where multiple ways of doing something exist, present the easiest first. Present others if they have some sort of advantage over the easiest way. If certain options have no advantage over other options already presented, do not include them. Some examples:
    • To kill a zombie process, the easiest thing to do is to restart the computer. Using the Task Manager requires more skill, but is quicker for those who already know how to use it.
    • To set a pref, the easiest thing to do is use the UI if it exists. Next easiest is about:config, then editing user.js. Does user.js have any advantage?
  • Where multiple options are given, present the information based on the type of person who would choose that option. Everyone knows how to restart their computer, so don't explain it. Everyone who would pick to use Task Manager instead already knows how Task Manager works.
  • Where a technical process exists for doing something and a non-technical process doesn't, mark the process is "Technical" or "Advanced".
  • Any choices we need the user to make that end with different results should include the pros and cons as it relates to the user. We don't need to give the pros and cons of restarting versus Task Manager because those give the same result. We do need to give the pros and cons of FooPlugin 2.1 versus FooPlugin 3.0, should we provide users the option.
  • Keep technical "background" or "overview" information to a minimum, or keep it in a separate section labeled as "Technical" or "Advanced".

--Np 20:45, 11 June 2007 (UTC)

Nice ideas. Can you show us the format you wish to use when marking something technical or advanced?
I don't have any set format in mind. In a few of my recent edits, I just put (Advanced) in the section name.--Np 02:45, 12 June 2007 (UTC)
I have to say, though, that I like overviews, especially for troubleshooting. Sometimes a little understanding is worth much more than someone blindly following the wrong procedure. I agree, though, that an overview should be brief and nontechnical if possible. --AnotherGuest. 22:18, 11 June 2007 (UTC)
I agree in general, but disagree with two recommendations. While we need to do a better job of deciding when and where to present technical information, not every article is written for the same audience. We need to be careful not to overreact to the real problems a non-technical user has in an article such as backing up your profile (where we push solutions that require you to find where your profile is, rather than recommending Mozbackup as the first choice) by dumbing down articles such as session logging. --Tanstaafl 23:51, 11 June 2007 (UTC) [signature added by AnotherGuest. -- I think I got this right -- this article is getting shuffled]
It could say:
  • Here (link) is where your profile is. Keep a copy in a safe place.
or...
  • Use the Mozbackup extension.
I don't like the idea of recommending extensions for what can be done without -- especially as the first or only alternative. We don't want people to be dependent on third-party software, especially if they have a problem installing extensions, or they have to run in safe mode, etc. The other software could also develop a problem. If users are intimidated by the first alternative, they can choose to install the extension.--AnotherGuest. 19:12, 12 June 2007 (UTC)
Not having to be dependent on third party software is a valid reason to include information on how to do it manually, but I don't like the concept of "If users are intimidated by the first alternative, they can choose (the other)." If people are intimidated by the first option, they might stop reading the article completely, or post in the forums that they can't understand what it's saying, or try to do it anyway and get it wrong.--Np 19:33, 12 June 2007 (UTC)
Users should know how to copy a directory, although some will fail at ANY task. Pictures help. Nevertheless, which way do you want to do it wrong? Give them something they might get wrong, or give them something else that they might get wrong, and that might fail for another reason? Or just reverse the two alternatives?
Truth be told, almost everything in the KB is too advanced for many users, and we risk overusing the label. Is everything that's off the menu to be labeled as "advanced"? Maybe backing up a profile is advanced.--AnotherGuest. 20:45, 12 June 2007 (UTC)


That's kind of what I was saying "present the information based on the type of person who would choose that option". I was applying it to options, but the same concept should be applied to articles. Non-technical users may want to back up their profile, but they're not likely to have even heard "session logging" and so are unlikely to even reach that article. A session logging article could still have an easy to understand intro and a notice that it's an advanced topic.--Np 02:45, 12 June 2007 (UTC)
It does have a easy to understand intro, and a notice that its an advanced topic. The very first sentence is "This article is about troubleshooting techniques for advanced users who are investigating problems with servers." It then goes on to explain when this is useful. I looking for some re-assurance that the current Session_logging_for_mail/news article is not an issue. That tells me that we both mean the same thing when talking about present the information based on the type of person who would choose that option. Tanstaafl 08:36, 12 June 2007 (UTC)
I've been trying to avoid talking about specific articles... I have no problem with the current Session_logging_for_mail/news article. The first sentence tells me exactly what I'm in for, and the subject is not something that can likely be simplified. The only change I would suggest would be to provide a link in the intro for people who are looking for general troubleshooting information, like "My Thunderbird can't connect to the server!", to read should they mistakenly think this is the article for them.--Np 19:33, 12 June 2007 (UTC)
Part of my concern is that most guidelines are actually treated as hard and fast rules. I'm sure whoever drove the statement that pathnames should be in <tt> tags meant well, but if you try to make a document more readable by omitting them when it doesn't make sense some grammar nazi edits them. Thats the least of our problems, but its that type of reaction that worries me when certain statements are made.
I think my suggestions give a fair bit of leeway. In any case, if a valid reason is given on why to ignore one of the suggestions, that's fine. But in a dispute, reasons have to be given why these things should be ignored, otherwise there's no point in having suggestions at all.--Np 02:45, 12 June 2007 (UTC)
I try to advocate using the GUI, then about:config/config editor, and only then modifying prefs.js. I don't agree with some articles bias towards modifying user.js rather than prefs.js. All of the supposed advantages are frequently irrelevant since that type of person shouldn't be modifying a config file in the first place. If they are modifying a config file, the last thing you want to do is make the situation more complex by adding yet another file whose whole purpose is to modify prefs.js for you. My experience is that unless you're in an environment where somebody else deploys your profile you're better off not having a user.js.
However, I don't think we should ignore prefs.js/users.js. Depending upon what you're doing sometimes it much easier/safer to modify related preferences in prefs.js than to use about:config/config editor. Especially if you're troubleshooting a problem or making wholesale changes to multiple accounts. Tanstaafl 23:51, 11 June 2007 (UTC)
You're explaining an advantage setting prefs.js/user.js has over about:config. If it's a valid statement, I see no reason why it couldn't be included. But the focus of the article would be more on UI or about:config. For such a common thing like setting prefs, we could figure out some format that works for most cases.--Np 02:45, 12 June 2007 (UTC)
You misunderstand my intent. I think we agree that the normal focus should be on using the GUI / about:config. I was replying to your speculation about does user.js have any advantage, and also arguing that while editing prefs.js should be discouraged for normal users, it does have its place. Most articles that mention a preference would have no reason to even mention that you could edit prefs.js or user.js, but it should be mentioned in articles such as Editing_configuration and Modify_Thunderbird_settings and the occasional advanced section or technical article (which is not suitable for most users due to its subject).
I am trying to support your overall goal of making things less technical while making certain it doesn't go overboard. The basic problem seems to be that I don't see enough support for people using their best judgment (and talking about it if there is a disagreement), there seems too much stress on guilty until proven innocent. A lot of this is due to statements such as "In any case, if a valid reason is given on why to ignore one of the suggestions, that's fine. But in a dispute, reasons have to be given why these things should be ignored, otherwise there's no point in having suggestions at all". That quote makes it sound like you advocate slapping a cleanup template on every half-way technical article until somebody successfully defends it being written for a technical audience in the talk page. Most definitions of suggestion talk about influencing or mentioning something for people to consider, not mandating something must occur unless you can prove otherwise. Tanstaafl 08:36, 12 June 2007 (UTC)
In the current state, when people have a disagreement, each side has to give reasons on why they believe something should be the way they're suggesting it be. If one side doesn't, they "lose" the argument. Do you understand the current state differently? What I'm proposing is a set of suggestions that anyone can point to in a disagreement as reasoning behind their point of view. The person who is more on the side of "non-technicality" doesn't automatically win, because there may be valid reasons to not follow the suggestions in that particular case. But if it comes down to "I think this article is too technical" vs. "I don't see any reason to not be technical", then that's different.--Np 15:52, 12 June 2007 (UTC)
One of the complaints I've heard many times about KB content is that it's too technical and complex..... make it so non-technical users can read the KB without having to understand the technical bits We really need more information about the skill level of the "non-technical users" or which articles are being described as being too difficult. A feedback mechanism built into each article would be helpful or, short of that, a request for feedback as a support forum "sticky" topic which would say something to the efffect that..... " If you are linked to a KB article which is too difficult for you to understand, please post the article name here and describe the problems you had"...... or something similar. I doubt many people would respond but it's worth a shot. We could then get a feel for the scope of the problem. Alice 01:05, 13 June 2007 (UTC)
As to which articles should fall under any guidelines we might set up, I would suggest starting off by limiting these to "Issues" articles and possibly a few others. I dislike the idea of a general guideline that applies to all articles, such as suggesting that we include a label to KB articles such as "Advanced" or "Technical". What I would prefer is to start with a limited set of articles that fall under a set of guidelines and add to these a "Tutorial" or "Support issue" label. "Support issue" articles should be aimed at non-technical users, unless the article or article section is specifically tagged as "for Advanced users". For example, Creating a new Firefox profile on Windows would be considered a "Tutorial" and Lost bookmarks would be a "Support issue" article. The "Tutorial" articles should offer even more basic help, with step-by-step instructions and screenshots, if possible, for common tasks, compared to the Support issue articles. These "Tutorials" could be linked from the "Support issue" articles or from other KB articles with an "If you need extra help" heading. Alice 01:05, 13 June 2007 (UTC)
Where multiple ways of doing something exist, present the easiest first. Present others if they have some sort of advantage over the easiest way. If certain options have no advantage over other options already presented, do not include them. This seems to be overly rigid. I like to present multiple methods even if one doesn't have an obvious advantage, and let the reader decide which he prefers or which he finds easier. Alice 01:05, 13 June 2007 (UTC)