Knowledge Base changes/Archive

This is an archive of resolved issues from Knowledge Base changes. Please do not add additional discussion here.

Finding templates

Is there a Special page which lists all the templates available? I can't find it if there is! If there isn't we should definitely create one, because I can never find the templates that I'm looking for (to remind myself of their exact title). --Mozcerize 02:16, 4 Jun 2005 (PDT)

I would also like to know this. --Wintogreen 02:30, 17 Jun 2005 (PDT)

Seems that Special:Allpages ought to look instead like this one, where you can choose to show all articles in a certain namespace. Are we using an outdated wiki version? --Wintogreen 10:02, 20 Jun 2005 (PDT)

Thanks Wintogreen, and good news---our AllPages now works correctly. It is extremely useful, as you can filter by article title and by namespace, including template and category. But there's a minor problem with it. When you first visit it, is lists only a couple of articles which seem to be randomly chosen! You actually have to click the "Go" button to create the list. Instead, a welcome message should appear, as with the Wikimedia page.

Also, it would still be very useful to have a Special page for templates, like the one that exists for categories. Ideally it would list all templates and display the text which forms each template. --Mozcerize 06:15, 13 September 2005 (PDT)

Hot topic—replacing the FAQs and Issues pages with category navigation

Discussion of this proposal can be found on Talk:Rules/Categories). To summarize the situation so far:

Part of the motivation for implementing categories was to avoid the following situation which occurred with the original FAQs, Issues and Tips pages: article links had to be maintained manually; some articles appeared on more than one page; some articles didn't appear on any page. The result was that people had to look at all three pages to makes sure they didn't miss anything, and then perform a search as well. With categories, the danger that an article was never linked to from anywhere was removed, since a category page automatically lists its articles. There was no opposition to removing the Tips pages.

The suggestion to remove the FAQs and Issues pages was more controversial. Indeed, the problem with relying solely on category listings is that logical order is lost. The initial solution proposed was to use the editable part at the top of the category pages to recreate some logical order by factoring in parts of the FAQs and Issues pages. --Mozcerize

My current opinion on this is that the FAQ and Issues pages should be kept, because they contain more info that could sensibly be placed in the category pages. However, I do think that they should both contain prominant links to the category pages, notifying the reader that there is more info on the KB than the selection of articles advertised on the FAQ and Issues pages. Indeed, I would suggest renaming "Issues " to "Common Issues with Firefox" to emphasise the fact that the Issues page is just a selection. --Mozcerize 15:00, 2 January 2006 (UTC)

First, thanks for the new discussion area and for the invitation to add comments. I've already added some comments to the Talk:Issues with Firefox page, back when it was first removed. I never did see the justification for removing either page, even if they are no longer linked from the front page. (I took it upon myself to restore them... I'm sorry it I stepped on anyone's toes but I was totally unaware of any discussion going on or a decision to remove the two pages. I strongly believe that both pages should be kept as they're a very handy way to organize and locate information, especially the FAQs page, which is unique in that the collection of links isn't duplicated anywhere else, alphabetically or not. Both pages are good places to include links to forum topics, release notes or other external links when there is no KB article covering the topic, plus the link descriptions give much more information than a simple title page link. I'm willing to help keep both pages organized and updated since I refer to them both so often. As far as the Issues with Firefox page, I've already pointed out in the intro that, "A link to an alphabetized list of current articles in the Category, Issues (Firefox) can be found at the end of this article." It might be a good idea to eliminate some of the less common issues on the page, such as the entire "Versions older than 1.0" section, and to emphasize that the page is a collection of "Common Firefox Issues" and is not exhaustive. I don't see the need for a new name but if someone else whats to rename the page "Common Firefox Issues" or similar, that's fine with me. Alice Wyman 20:47, 2 January 2006 (UTC)

"I'm sorry it I stepped on anyone's toes…." Not at all. Thanks for the points you've raised. The links to the forums and other offsite pages are indeed important. I was weighing up the idea of creating KB articles which act as wrappers for offsite links, that is, they have a useful title but their content is just a link. Ultimately, it would be good to have the info that they point to actually transferred to the article. (Anybody got a free week? ;-) I don't claim that this is an urgent task, but it would be good to have the offsite info represented somehow in the category listings. --Mozcerize 11:25, 4 January 2006 (UTC)

I made some changes to both the Firefox FAQs and Issues with Firefox pages today and made a note of this discussion on the Talk pages for each article. Alice Wyman 16:40, 7 January 2006 (UTC)

That's great; thanks! --Mozcerize 12:15, 8 January 2006 (UTC)

One of the current problems is that some of the categories mingle articles written for all of the products, even though you may have navigated there by selecting articles for one product. Somebody looking for information on Thunderbird privacy and security for example shouldn't see stuff such as Disabling autocomplete (Firefox), Mozilla Suite : FAQs : Mozilla Security or Parental controls. Ditto for navigating to Configuration::Preferences for Thunderbird and finding dozens of articles on preferences that Thunderbird doesn't support. I suggest we create a strategy for how to deal with this before creating a SeaMonkey category, which will just make it worse. My impression is that this is being dealt with piecemail by creating new versions of dozens of subcategories specific to an application. Is this what we want? --Tanstaafl 4:00AM, 16 January 2006 (PST)

Well, I don't think that doing things piecemeal is necessarily a bad thing. We spent a lot of time devising the initial category structure, but in practice we found that it was unnecessarily complex and so we undid it afterwards. Potentially the same thing could happen here, and so I'm reluctant to invest much time in it. Our whole approach with the categorization has always been this: come up with a global idea of what the KB would ideally look like if it were jam-packed with articles, devise a mechanism which scales to that level, but only implement the stuff that actually makes sense given the current number of articles, leaving the other stuff to be implemented as and when necessary. In theory I agree that there should be separate app-categories for (e.g.) Privacy and security, but in practice there aren't many articles in the current category, and those which are there are labelled with with the app name in the title. (Surely people looking for TB articles will just skip over articles with "(Firefox)" in the title?) --Mozcerize 11:24, 31 January 2006 (UTC)

New proposal—"Startup and performance" category

I'd appreciate some input on the title for this category, esp. as it would be best to choose a category name that works for all apps. Please add your comments at Talk:Rules/Categories#Some_new_categories. --wintogreen 11:15, 5 January 2006 (UTC)

This proposal is dead as far as I'm concerned. The only question is whether "Startup and performance" would make a viable category name for any application. If not, then it'd be best to remove the links from the category tree at Talk:Rules/Categories. --wintogreen 08:07, 17 January 2006 (UTC)

Naming conventions

The parentheses look ugly (esp in the location bar) and clickme. I suggest we remove this 'rule'. No need to rename the existing ones. We will use the categories instead. --Filipp0s 23:56, 31 March 2006 (UTC)

I don't think this is really possible; the parentheses are there because you can't have two articles with the same name, even if they live in different categories. There needs to be some way of differentiating equivalent articles in the major product categories. --Mozcerize 10:05, 1 April 2006 (UTC)

Why does the wiki escape parentheses? They aren't reserved.

 2.3. Unreserved Characters
   Data characters that are allowed in a URI but do not have a reserved
   purpose are called unreserved.  These include upper and lower case
   letters, decimal digits, and a limited set of punctuation marks and
   symbols.
      unreserved  = alphanum | mark
      mark        = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
   Unreserved characters can be escaped without changing the semantics
   of the URI, but this should not be done unless the URI is being used
   in a context that does not allow the unescaped character to appear.

[1]--Np 19:04, 1 April 2006 (UTC)

Probably because PHP’s urlencode() function escapes them. --Unarmed 21:04, 2 April 2006 (UTC)

I also think the rule should be changed. I created a redirect from Unable_to_install_themes_or_extensions_(Firefox as was brought up on the article's talk page. I also created three more redirects for Standard diagnostic articles that end in parentheses. If the problem is only with article names that end in a parenthesis, why not move the parenthetical phrase to the front on new articles, for example, "(Mozilla Suite) Links"? Alice Wyman 19:46, 3 May 2006 (UTC)

Because that'd mess up any alphabetical listing of articles.--Np 14:09, 4 May 2006 (UTC)

A better solution would have been to eliminate the ugly parentheses altogether as originally suggested and just use : Firefox at the end of the article name. That would solve the reported problems with e-mail links and would look much nicer in the location bar, for example, as Unable_to_install_themes_or_extensions:_Firefox instead of Unable_to_install_themes_or_extensions_%28Firefox%29 and Standard_diagnostic:_Firefox instead of Standard_diagnostic_%28Firefox%29 Alice Wyman 23:42, 4 May 2006 (UTC)

This sounds very reasonable --Mozcerize 08:39, 8 May 2006 (UTC)

Good idea, but I'd prefer "Standard_diagnostic_-_Firefox". The colon seems a little weird.--Np 14:27, 8 May 2006 (UTC)

That'll work, too. Alice Wyman 20:17, 8 May 2006 (UTC)

I've updated In-house style--Np 14:27, 3 June 2006 (UTC)

While we're talking about naming conventions, I find it much easier to refer to pages that have been named with a singular name, vs. plural names.

Requesting articles

Several times I have had ideas for articles (issues from the forums that need an article mainly), but haven't had the know-how to create them myself. Personally I think we should set up a Requested articles page, similar to what Wikipedia already has. Is there any reason not to do this? --name already taken 23:35, 25 May 2006 (UTC)

Methinks this is a good idea. --FatJohn 12:43, 3 June 2006 (UTC)

I just created the page and added several requests, not sure if I should add a category to it or not... --name already taken 10:14, 12 June 2006 (UTC)

Please don't create a category for it. Tanstaafl 22:06, 12 June 2006 (UTC)

Just bung it in the Organization category. Don't forget that you can use the template {{org}} to do this, to save having to type the full name of the category. --Mozcerize 08:59, 13 June 2006 (UTC)

Done. BTW I had no intention of creating a new category, I was more wondering what one it belongs in. --name already taken 09:27, 13 June 2006 (UTC)

I just wanted to mention that I think you should post a link to any new article created as a result of an entry to the Requested articles page (as I did just now), so that anyone checking back can easily find the newly-created article. You can then purge the Requested articles list every so often, but I would add a note to that effect to the article, similar to the way it's done in the Vandalism article. Alice Wyman 21:49, 13 June 2006 (UTC)

I'll add a note to the page explaining that that should be done --name already taken 15:54, 15 June 2006 (UTC)

Would it be possible to allow anonymous editing of that page? --name already taken 02:38, 20 June 2006 (UTC)

Terminology used in the KB

There is a discussion at In-house style#Terminology: hyphenation regarding the use of "popup" vs. "pop-up" as the noun. --Mozcerize

Linking to Editing configuration instead of describing about:config

I would prefer that articles link to the Editing configuration page rather than attempt to describe how to use about:config or "user.js" each time. The advantage of letting Editing configuration do the hard work is that it introduce the concept of preference-setting gently, and describes the benefits of using user.js rather than about:config as regards profile backups and roaming. Further, it avoids having slightly different descriptions of the about:config procedure on many different articles. Note that the pref articles use the "link to Editing configuration" approach themselves. --Mozcerize 10:12, 14 June 2006 (UTC)

Sometimes a simple step-by-step approach is needed when a problem affects many users at all levels of experience, for example, the Software installation disabled fiasco for users who disabled the "xpinstall.enabled" preference in Firefox1.0.x options, then upgraded to 1.5 and found that the UI no longer existed. In that case, the fix using about:config given in the article was the simplest, most direct method to fix a problem that faced users who never even thought of editing configuration files before. I see your point, though, about linking to Editing configuration instead of routinely describing about:config, if only to give users a broader introduction to preference editing. At the very least, if the "about:config" medhod is used in any article, a link to about:config should be given. Alice Wyman 21:41, 14 June 2006 (UTC)

That seems to work better for browsers. A Thunderbird user who wants to change or add a preference would have to click on the about:config link in that article, then find the one liner about the config editor button in the 2nd article, and then search for a article on how to use that feature. If they want to edit one of the config files only one of links for the the ChromEdit extension is for one that works with Thunderbird, and it doesn't have any instructions on how to download it. Unfortunately thats a major issue for many new users. It also ignores the fact there are times when its most appropiate to edit prefs.js (ChromEdit won't let you edit it) because you're trying to fix something thats broken. Since I'm Thunderbird-centric I find it more usefull to link to the Modify_Thunderbird_settings article which leverages the generic about:config, profile, user.js etc. articles.

I've written a few articles where I deliberately didn't leverage any other articles when many users running into that problem were not computer literate and seemed overwhelmed by any attempt to use multiple articles. I'm reluctant to do that since its a lot more work but sometimes its appropiate. I think its a good idea to encourage editors to consider leveraging generic articles but that we shouldn't have a rule about it. Tanstaafl 23:06, 19 June 2006 (UTC)

Question: Feedback on KB articles

Does anyone have any suggestions on what would be the best way for someone to provide feedback on the content of KB articles such as broken links or other problems with the article content? Someone asked me by forum PM, how he could report a broken link in a KB article (the article was Accessibility_features_of_Firefox#Compatibility_With_Assistive_Technologies and the broken link was http://www.mozilla.org/access/compatibility) Where do you report things like that? . Is there a simple avenue for such feedback?

I suggested that he edit the article by removing the broken link and adding an alternate link, or that he add a comment to the article's discussion page, but both involve creating a KB account which he didn't have and he didn't seem to want to go that route. Our MozillaZine Knowledge Base:About page doesn't give any instructions for reporting broken links or other article feedback and doesn't provide a "contact" link other than the statement, if you have any comments, problems, or feature requests related to Mozilla Products, please do not post them here! Rather, post them in the MozillaZine Forums. I checked the Wikipedia:About page for ideas and it says this, under Feedback and questions 'Feedback about content should, in the first instance, be raised on the discussion pages of those articles. You are invited to be bold and edit the pages yourself to add information or correct mistakes if you are knowledgeable and able to do so. Maybe a "Feedback" paragraph should be added to our About page with a link to the MozillaZine Site Discussion forum or maybe even a special thread for KB article feedback? Alice Wyman 14:25, 19 June 2006 (UTC)

Since no one had any suggestions, I added a simple "Feedback" section to the MozillaZine Knowledge Base:About page, as follows: You can post comments about the Knowledge Base to the MozillaZine Site Discussion forum. If you want to correct a mistake, report a broken link or bring up other concerns about the content of specific articles, you can do so on the discussion pages of those articles, or you can edit the pages yourself if you are knowledgeable and able to do so. Alice Wyman 00:57, 20 July 2006 (UTC)

Proposal for new "error loading websites" article

I've added a proposed article here: User:Alice_Wyman/Proposed_article which combines three articles on website-loading problems into one, the current Error loading websites article, and then to redirect those three articles to the combined article. See this discussion Talk:Error loading websites. Alice Wyman 23:37, 29 July 2006 (UTC)

I went ahead and merged the three articles into Error loading websites. Alice Wyman 10:15, 1 August 2006 (UTC)

New article? on Utilities that modify Fx settings

Moved from Talk:Error loading websites and edited slightly for context

I suspect that this could be a common problem.[2] I added a little note in Error loading websites, but changes by third-party software is more general than that. (Nice editing, Alice.) It may be widespread, if not terribly common.<- Posted by AnotherGuest

By "utilities" I guess you meant this and/or this post about "Hide IP Platinum"? If so I think it would be a good idea to mention "Hide IP Platinum" by name in the article or link to the specific post that mentions it. I think you have a good point about other software modifying Firefox settings, even if uninstalled. In fact, I came across a similar issue reported where a "user.js" file was created by "McAfee Privacy Service" which kept disabling the Firefox popup-blocker (see the Popups_not_blocked article and this post). Maybe a new article should be created such as "Software that modifies preference settings" or maybe "Problematic software" if you want to start a list of third-party programs that cause problems with Firefox or Mozilla Suite? Not sure what you had in mind. Do you want to move this discussion to Knowledge Base changes? If so, I'll copy it there (or you can). Alice Wyman 13:24, 14 August 2006 (UTC)

I'm sure there are other examples. For example, Firetune leaves its traces. I vaguely remember software messing with bookmarks. A little off the subject, there are also programs that change system networking and therefore affect Fx -- for example, TreeWalk, a local DNS caching service. Do people have other examples? Do we have enough for an article? Depending on what is actually included in the article, "Software that modifies preference settings" is a good title. --AnotherGuest.

All kind of random malware (on compromised systems) often seem to attack Firefox using user.js. Also, I've seen multiple posts where people have visited hotels that have set their homepage using user.js. Many people have had a fair share of problems because of that. --FatJohn 15:08, 15 August 2006 (UTC)

Malware. Well, we certainly need something on that in KB. This seems like a good place for it. References?--AnotherGuest.

Here's a draft of a proposed article on "Resetting preferences modified by other software" I came up with, based on this discussion: <snip>. Alice Wyman 18:20, 15 August 2006 (UTC) .....For the record, here's the completed article: Resetting preferences (I made it more general) Alice Wyman 22:34, 8 September 2006 (UTC)

New Proposal—Creating an article for each profile file.

Talk:Profile folder

I just wanted to copy the subject and introductory paragraph from the Profile folder discussion page to here, since it better describes the new proposal:

"Profile files" Category

What do you think of making a category that would contain an article for each file in the profile? We could describe what the file does, the consequences of deleting it, etc. Another thing we could do us have Category: Profile files (Firefox) and Category: Profile files (Thunderbird), etc. so each application's users can have a list that applies to them without seeing the cruft. --Np 18:25, 29 January 2006 (UTC)

By the way, the discussion has brought up issues related to other topics discussed here, such as ideas (guidelines?) on what to include in the new articles that describe the profile folder contents as well as how to categorize those new articles. It was mentioned that these considerations should not discourage editors from writing new articles. Alice Wyman 13:30, 31 January 2006 (UTC)

I like the idea of having seperate articles for each applications profile. I've noticed many users have problems finding the appropiate information due to text about other applications. I don't believe a rewrite would solve that problem. However, a seperate article for each file seems like overkill, and biased towards more technically knowledgeable users. I'd prefer to see the effort put into writing more issues articles instead. However, if the consensus is to write a seperate article for each file then each file in the profile article should be linked to the corresponding article. Tanstaafl 22:35, 31 January 2006 (UTC)

On the issue of separate articles for each file, I tend to agree about the "overkill" and technically-oriented bias.... I'm going to reply to that in the Talk:Profile folder discussion. Alice Wyman 16:09, 1 February 2006 (UTC)

Hot topic—Making things less daunting for new editors

Several new editors (or potential editors) have felt a bit daunted by the rules for contributing. I think this is a shame; we want their contributions! (The rules are fairly comprehensive and are written formally; this is for the benefit of regular contributors. But it was never anyone's intention to discourage new editors.) I have added an introduction to the rules page, which states that they don't need to read everthing thoroughly. This could be controversial; please state your view here! Should we include that sentiment in other places too? And should we put a sticky in the forums which tries to bring new editors to the KB? --Mozcerize 13:10, 8 January 2006 (UTC)

Looks good; you have a knack for writing these welcome intros. Where else would that sentiment be included? Instead of a forum sticky, I'd just use a regular thread in the General forums; the regulars will see it. A few suggestions: (1) The "Please don't be offended..." sentence can come out or be merged into the similar point in the "Editing courtesy" section. (2) The "Avoid superfluous information" section could go into In-house style. (3) The "Test editing pages" section could come to the very top, above "Editing courtesy", as a way to invite people to take the plunge into editing. (4) "Talking to authority" should come out; those links are all available in kb Organization category and aren't rules in the first place. (5) Rules/Templates should be renamed because those templates aren't rules; they're editing shortcuts and should be presented as such. --wintogreen 14:36, 8 January 2006 (UTC)

I've implemented some of these suggestions. I suggest we move discussion which is specifically about the Rules page to the corresponding Talk:Rules page. --Mozcerize 17:11, 30 January 2006 (UTC)

I suggest the rules be modified to state that you shouldn't post a notice on a page unless it adds value to the reader. For example, posting a notice stating that the name of the knowledge base page is in error (when its actually due to a limitation of the wiki software) just causes confusion and annoys the person who wrote the article. The reader doesn't care that we're using Wiki software. Note that I'm not arguing against a notice that an article needs rewriting. The reason I'm mentioning this in this section is because behavior that seems perfectly appropiate to somebody steeped in the wiki culture can be upsetting to a new editor who has never had to deal with collaborative writing with strangers. -- Tanstaafl 3:30 AM January 16, 2006 (PMT)

I disagree. The notice regarding "incorrect article title" is very clear in specifying that the name is wrong for "technical reasons" (as opposed to editor error) and it suggests the correct name. I don't see that it is confusing. --Mozcerize 17:11, 30 January 2006 (UTC)

I'm not a wiki person. It was easy to pick up what I needed to know to edit knowledge base articles before we switched to categories. Its more difficult now. An example - I need to create a new category. I read Rules/Categories and it wasn't clear to me how to create a new category, though I understood how to make a category a subcategory because that didn't require any background knowledge. Please think about the barrier to entry you're accidentally creating by assuming a new editor has a wiki background. -- Tanstaafl 3:30 AM January 16, 2006 (PMT)

I hope that it has now been made clearer on the various entrance pages that contributors do not need to worry about categories etc. if they find these things daunting. --Mozcerize 17:11, 30 January 2006 (UTC)

I don't think creating a thread will help attract new editors. -- Tanstaafl 3:30 AM January 16, 2006 (PMT)

Why not? --Mozcerize 17:11, 30 January 2006 (UTC)

I suggest you consider converting MozillaZine_Knowledge_Base:Formatting into a short primer on what you need to know to be an editor. The current article does a good job of covering what you need to know about formatting. But it doesn't cover other common tasks such as how you create a new article or how to categorize it. Yes, there are links to wiki documentation where you can find that but its rather overwhelming for somebody who may know a little HTML or bbcode and is not used to reading rules, in-house style guides, naming conventions etc. while learning yet another formatting syntax. Think of all that we're implying a person should read before doing something small such as update an existing article for a new version. Especially since they really don't need to deal with most of those topics until they create a new article, if they make an attempt to mimic what they see in the article they're editing. I think its telling that some of our most prolific forum posters such as Daifne, SKopischke, GordMcFee and Mr. Liu have never touched the knowledge base as far as I can tell. The current approach seems designed to tell you everything that you need to know to do it right in order to minimize cleanup by other editors. I think we should increase the risk that we'll have to cleanup after a new editor for a while if that makes it easier to lower the barrier to entry (whether its real or perceived). -- Tanstaafl 3:30 AM January 16, 2006 (PMT)

I agree with this sentiment. I hope it is clearer now that new editors need not digest the finer details of the rules and conventions. A primer would be useful; surely someone's already written a decent wiki primer somewhere that we can just link to? --Mozcerize 17:11, 30 January 2006 (UTC)

I'm suggesting that we make it easy for them to get started by letting them get started using just the primer, let them learn more of the conventions/customs (documented in the rules, guides etc.) later on as they tackle bigger tasks, and try to avoid giving them the impression they need to learn everything before they can do anything. Once thats in place its also easier for somebody to encourage somebody to contribute.

It might also help if one or two names (perhaps Wintogreen?) were mentioned in the primer as volunteers that new editors are encouraged to contact via private messages for advice if they need it. -- Tanstaafl 3:30 AM January 16, 2006 (PMT)

I took the liberty of expanding the About page, in particular the "Contributing to the KB" section. If someone could please review it and revise where you think it can be improved, that'd be great. Note that I also added a "Need help with the wiki?" section at the end of the Help wanted page. That's my way of saying I don't want to be a designated go-to guy. ;-) --wintogreen 19:14, 19 January 2006 (UTC)

Question—how to use "SeaMonkey" in the kb from now?

With the SeaMonkey 1.0 release just around the corner, I've been wondering how we should adjust for the use of the "SeaMonkey" name in the kb. As it is now, the article-naming conventions and in-house style both specify that only "Mozilla Suite" is to be used. Since SeaMonkey has features not in the Suite, it seems like it would make sense to start referring to the proper product name when it's needed to differentiate it from the Suite; perhaps we could linkify "SeaMonkey" in such cases so that it leads back to the category page, where there could be a blurb about the two names being used in the kb. Thoughts? --wintogreen 18:23, 4 January 2006 (UTC)

Maybe we could link to the Mozilla_Suite_:_FAQs_:_Status page if we needed to refer to SeaMonkey and mention somewhere that articles referring to "Mozilla Suite" may also apply to "SeaMonkey" and other unofficial Mozilla-based products. Correct me if I'm wrong but all "Mozilla Suite" articles should continue to apply only to the official Mozilla Suite 1.7.xx product. I figure a separate category should be set up for "SeaMonkey" just as there is a Category:Nvu. Alice Wyman 16:35, 5 January 2006 (UTC)

In Category:Preferences we're listing them both.--Np 22:50, 5 January 2006 (UTC)

I agree with Alice; it sounds like we should introduce a new category for Seamonkey. I would think that lots of the Mozilla Suite articles could also be placed in the new category for now (after putting a "this article was written for the Mozilla Suite but also applies to SeaMonkey" notice at the top of them). Sooner or later SeaMonkey will have progressed to the point that the Mozilla Suite articles will no longer apply. At this point, these articles should be taken out of the SeaMonkey category again, and new ones written purely for SeaMonkey. --Mozcerize 11:31, 6 January 2006 (UTC)

Well, hopefully it won't get too messy. I'm thinking I might make an article similar to Menu differences in Windows, Linux, and Mac for Thunderbird - Suite - SeaMonkey menu differences, so that instead of trying to stuff Suite/SeaMonkey menu sequences into TB articles I can just insert a link into the notice at the top that says "...written for TB but also applies to Suite/SeaMonkey (though some menu sequences may differ)". --wintogreen 13:48, 8 January 2006 (UTC)

I agree with Wintogreen about the need for standard one-liner. I have no interest in spending time learning about Seamonkey or Mozilla Suite when writing a knowledge base article for Thunderbird, yet know I have to somehow mention them. --Tanstaafl 3:42AM, 16 January 2006 (PMT)

I've taken a stab at this with a new template -- Template:Tbsuite, now in action here. It lists both Mozilla Suite and SeaMonkey and links to the page Alice suggested. Some articles flagged like this will apply to both the Suite and SM, and some to SM only, but we can let the users of those respective apps worry about it from there.
As for creating SeaMonkey categories... what's to be gained by doing this instead of using the existing Mozilla Suite categories (or redirecting those to become SM categories, as I think can be done)? If SM features or menu sequences need to be differentiated from those for the Suite, that can be done easily enough within the article (like has been done for different TB versions in this article). Considering that the Suite categories are a mess as is, with no one taking care of them, why double the mess by creating a parallel set of SM categories? --wintogreen 17:00, 16 January 2006 (UTC)

I see your linked text in the Template:Tbsuite is Mozilla Suite / SeaMonkey which might make someone think of them as the same product, renamed. The linked page says that "the Suite is no longer an official product" which is ambiguous. I was considering them as separate products when I suggested a separate category for SeaMonkey, with Mozilla Suite being the official product, especially since both products are available and Mozilla Suite is continuing to be updated, if only for security bug fixes. I noticed on the Category_talk:Preferences page containing guidelines for preference articles, the Formating section also referenced Mozilla Suite/SeaMonkey as a single product, while in preference artilces supposedly based on those guidelines, they are listed as separate products. See my comments under Article-writing guidelines below. Alice Wyman 14:16, 17 January 2006 (UTC)

Hi Alice. What I've been thinking, since I made the trial template, is that the linked page should be like the Firefox and Thunderbird pages PLUS serve as a kind of disambiguation page—i.e., by summarizing the Suite/SeaMonkey connection and noting that a handful of articles claiming to apply to the Suite/SeaMonkey may really only apply to one of them, due to changes since the Suite development stopped. That page would have to be modified, or a different page used instead. Yes, they are separate products (or, one's a "product" and one's a "project"), and referring to them in a template as "Mozillla Suite/SeaMonkey" is not ideal. But as tanstaafl pointed out, we do need a practical, simple way of referring to "the Mozilla Suite and/or SeaMonkey" in TB articles. I'm open to other ideas. How about "SuiteMonkey"? --wintogreen 16:53, 17 January 2006 (UTC)

Hi, wintogreen. I agree the linked page for the template should be modified, or better yet, create a new page explaining the Mozilla Suite and SeaMonkey commonalities and differences. In most cases, just a template will do, whatever you want to use as the linked text (I would go with "Mozilla Suite and SeaMonkey") . In new articles that apply to both products, I would probably stay with "Mozilla Suite" with a link to a "Mozilla Suite and SeaMonkey" template, and not refer "SeaMonkey" at all in the article unless I was referring to certain features that are only present in SeaMonkey 1.0 or later. The problem I see is inconsistency. Look at browser.bookmarks.file and browser.cache.disk.capacity under "UI". The first has "Mozilla Suite" and the second has "Mozilla Suite and SeaMonkey". By the way, I was editing below under Article-writing guidelines before I saw your reply here. Alice Wyman 18:03, 17 January 2006 (UTC)

I'd be more inclined to use "SeaMonkey" in an article if I know for sure that it applies to SeaMonkey and especially if I don't know if it also applies to Mozilla Suite (which will more and more be the case as time passes). --wintogreen 19:55, 17 January 2006 (UTC)

...if I don't know if it also applies to Mozilla Suite..... What, you don't plan on keeping both versions, for testing and such? ;-) In that case, if you didn't know for sure that a new article applied to both products, create the category "SeaMonkey" and place the new article there, with a reference that the article was written for SeaMonkey but may also apply to Mozilla Suite? Alice Wyman 21:27, 17 January 2006 (UTC)

You wouldn't believe the number of new Thunderbird users who can't even get it straight whether the dedicated email client they're using is called Thunderbird, Firefox, Firebird or Mozilla. Wintogreens one-liner about Mozilla Suite / Seamonkey alerts somebody that its likely (but not 100% sure) the article also applies to those products and minimizes the amount of work the author does. If somebody ever confirms it applies then they have the option of adding the article to the Mozilla Suite and/or SeaMonkey category and/or stating something specific about the differences in support. I guess I'm arguing that the expense of avoiding inconsistency isn't worth it given all of the bigger fish to fry. --Tanstaafl 2:40AM, 18 January 2006 (PMT)

Update: since the above-mentioned {{Tbsuite}} template is now in use and linking to Mozilla Suite : FAQs : Status, I tried to fill out that page to make it a bit more useful. That page doesn't have to be the permanent target for the template, of course; if someone wants to move the relevant content elsewhere and update the template link accordingly, feel free. --wintogreen 19:40, 27 January 2006 (UTC)

Nice work. The page is a lot more useful now. I did some very minor editing and added a short blurb mentioning "SeaMonkey" at the top. Alice Wyman 20:47, 27 January 2006 (UTC)

Thanks for your further edits to that page. The phrase you've inserted at the top—"Mozilla Suite code development and the SeaMonkey project"—would make a good name for the article. Or maybe just "Mozilla Suite development and the SeaMonkey project" or "Mozilla Suite development and SeaMonkey"? --wintogreen 02:34, 28 January 2006 (UTC)

Those are all pretty long titles so I would go with the shortest, or even "Mozilla Suite status and SeaMonkey" or similar, whatever you decide, as long as the word "SeaMonkey" is in the title. Otherwise, I would change the name of the first section from Development status of the Mozilla Suite to "Mozilla Suite code development and the SeaMonkey project" so that the word "SeaMonkey" is more visible right at the beginning of the article. Alice Wyman 13:57, 28 January 2006 (UTC)

For now I've just changed the first header; appreciate the input and suggestions. --wintogreen 16:30, 28 January 2006 (UTC)

Mozilla Suite Category page

I just wanted to mention that I added information on SeaMonkey to the Category:Mozilla Suite page. Alice Wyman 21:00, 12 March 2006 (UTC)

In-house style page

I removed the In-house_style#Commonly_used_names reference to "Seamonkey" under "Application names" because it can only cause confusion now that SeaMonkey 1.0 has been released and kb articles are referring to SeaMonkey. I also explained my edit on the Talk:In-house style page. Alice Wyman 13:51, 14 March 2006 (UTC)

Hot topic—Specific questions re: "SeaMonkey"

Now that the discussion has been raging for a while, I've decided to list up what seem to be some of the key issues regarding the use of "SeaMonkey" in the kb. With numbers, for your commenting convenience. --wintogreen 20:22, 18 January 2006 (UTC)

In kb articles in general, should Mozilla Suite and SeaMonkey be treated as two distinct products or as one product (i.e., akin to earlier and later versions of the same product)?
If they are to be treated as two distinct products, should we normally refer to them using both product names ("Mozilla Suite and SeaMonkey")?
If we decide to normally use just one product name (either "Mozilla Suite" or "SeaMonkey") to refer to both, which name should we use?
Should any special guidelines apply to the Preferences articles (different from those for the regular user-support articles)?
Should there be separate sets of categories for Mozilla Suite and SeaMonkey?

Very brieflly, here are my own thoughts on the above. --wintogreen 20:24, 18 January 2006 (UTC)

In general, as one product. I don't think kb users will be confused by this, and it will be easier for us editors as well.
No. Using both names all the time would be awkward (except perhaps in a simple template like this).
SeaMonkey. That will seem the obvious choice two years from now.
Not sure.
No. I can't see any benefit in doing this.

I've added my thoughts below: Alice Wyman 21:16, 18 January 2006 (UTC)

In general, as two products, similar to the way Netscape 7.xx and Mozilla Suite are treated.
Either product name can be used with a note that it was written for one but may also apply to the other, or that it applies to both. If writing new articles for both, use both names only if necessary to differentiate and note any differences within the article as is done now for "Firefox 1.0.7" and "Firefox 1.5" differences.
---
I see the question as whether the "de facto" preference article guidelines here should be formalized and made easier to find by new editors Check any of the Category:Preferences articles that have been written already and you will see that they all follow the same format. When I wrote a new preference article it was immediately edited to add the "Has an effect in" section I omitted.
Yes. This is needed for new articles written for SeaMonkey 1.0 where the writer does not know if the content also applies to Mozilla Suite, or knows for sure that it doesn't.

Hot topic—Article-writing guidelines

(Also related to SeaMonkey references in the kb and making things less daunting to new editors)

The Category talk:Preferences page includes guidelines for writing preference articles. Should these guidelines (and possibly guidelines for other article categories) be formalized? Where would you want to place the guides in the kb so that people can find them? Here is part of what I wrote to Unarmed on his Talk page It never occurred to me to look on a Talk page for article-writing guidelines (I would think that anything on a "Talk" page is "informal"). I'd suggest formalizing those "guidelines" for anyone wanting to write a new preferences page. <snip> I'm assuming you want people to follow a certain format in a category like Preferences since that's the impression I got from Np. If that's the case, you should link to an article explaining what you want followed in Rules or In-house style. I'm not sure where you would place an article like that but I would guess somewhere in Category:MozillaZine_Knowledge_Base_organization. I've also suggested that the discussion about formalizing those guidelines be moved here. Since the question about SeaMonkey references in the kb has also come up, the In-house style page should be amended to make clear whether Mozilla Suite and SeaMonkey should be referenced as the same product (e.g. "Mozilla Suite/SeaMonkey") or separate products ("Mozilla Suite and SeaMonkey") and under what circumstances. For example, Category_talk:Preferences#Formatting is using Mozilla Suite/SeaMonkey to refer to a single product, while in preference articles supposedly based on those guidelines, both are listed as separate products, as in the "UI" and "Has an effect in" sections of browser.bookmarks.file and browser.cache.disk.capacity. I would suggest only using "SeaMonkey" as a separate product name when referring to features not found in Mozilla Suite. (Is the "Has an effect in" subheading listing Netscape SeaMonkey Firebird and Phoenix even needed?) Alice Wyman 11:51, 17 January 2006 (UTC)

Um... you're assuming somebody knows whether it applies to either of those two applications when writing an article for another application. Thats not realistic, and just makes it more daunting to new editors. I know my first reaction to the change you propose would be I'd like to help out users of other applications but I don't need this grief, and only mention Thunderbird the next time I write a email article. Being slightly inaccurate is healthy in some circumstances. Especially when you consider the slow pace of updating existing articles. Tanstaafl 2:45AM, 18 January 2006 (PMT)

What proposal? I did propose that the In-house style page should be amended to make clear whether Mozilla Suite and SeaMonkey should be referenced as the same product (e.g. "Mozilla Suite/SeaMonkey") or separate products ("Mozilla Suite and SeaMonkey") and under what circumstances. If you are responding to what I said immediately above, "I would suggest only using "SeaMonkey" as a separate product name when referring to features not found in Mozilla Suite."..... then, in that case, I was thinking about the "UI" and "Has an effect in" sections of preference articles, specifically browser.cache.disk.capacity and browser.bookmarks.file in the context of article-writing guidelines, when the same preference applies to both products. I also mentioned in the separate "SeaMonkey" discussion above that I would probably stick with "Mozilla Suite" in new articles if the features applied to both and not mention SeaMonkey at all if it wasn't necessary. In other words, no one should be forced to refer to SeaMonkey at all. On the other hand, maybe no one should be forced to refer to Moziila Suite either... is that what you're saying? I would agree with you, if someone is writing a new article and his only experience is with SeaMonkey, he should not reference Mozilla Suite or Thunderbirs at all, and the article should have a disclaimer that it was written for SeaMonkey, etc (another reason for a SeaMonkey category). Alice Wyman 17:57, 18 January 2006 (UTC)

New Proposal—Note on the registration page.

I want to add the following line in the registration page, under the "create new account" button.

The purpose of the Knowledge Base is to provide documentation. Post any questions in the Mozillazine Forums, not here.

Do you agree/disagree? Any comments on the wording? --Filipp0s 00:05, 7 March 2006 (UTC)

Sounds fine though I'd suggest you use the same text as in http://kb.mozillazine.org/Main_Page , though the extra visual emphasis you added seems like a good idea for the registration page.

A related question is what should we do if somebody uses a articles talk page to ask questions that clearly belong in a support forum. Right now it seems like they're just being ignored. I'd like to establish the convention that whoever stumbles across this should delete that text as long as there is no question about whether its part of a valid discussion of the article. Tanstaafl 06:06, 7 March 2006 (UTC)

I agree with adding a notice, but with more information. This is what is written in the first paragraph of the "About MozillaZine Knowledge Base" page linked at the bottom (looks like the registration page has plenty of room for it) and I like the friendly tone:

The purpose of the MozillaZine Knowledge Base is to help gather support, resources, hints, tips and answers to FAQs (frequently asked questions) for Mozilla products, all in one place. Anyone can contribute, so feel free to help!

However, if you have any comments, problems, or feature requests related to Mozilla Products, please do not post them here! Rather, post them in the MozillaZine Forums.

Also, about removing questions from Talk pages that clearly belong in the forums, I would agree with that too but I would at least replace the question with a " Post questions in the Mozillazine Forums not here" notice so that if the person comes back to the page he will see why his question is gone. Alice Wyman 21:34, 7 March 2006 (UTC)

How about also including some text to stop people from editing pref or profile articles?--Np 03:57, 14 March 2006 (UTC)

Why would you want to stop people from editing pref or profile articles? Why not just create some formal guidelines for these articles and link to them. I suggested that earlier, under #Hot topic—Article-writing guidelines above. I don't think that you should place any kb articles off-limits but I suppose it's possible to lock the articles and limit access to certain people? Alice Wyman 12:32, 14 March 2006 (UTC)

I mean the people who edit them in an attempt to change their own configuration.--Np 14:15, 14 March 2006 (UTC)

Oh, OK. Right now there are templates that are placed at the top of the individual articles like downloads.rdf and Browser.bookmarks.file that tell people not to edit those pages. You would want something about that on the registration page? I guess the point would be to keep from having to add that information to each article, but I think that it really belongs on top of each individual article, if anywhere (Why anyone would try editing the KB article instead of the file is a mystery to me!) Alice Wyman 19:04, 14 March 2006 (UTC)

The point is to give people an additional chance to realize that they shouldn't be doing what they're doing. People still edit the pages with the warning as it is right now.--Np 19:51, 14 March 2006 (UTC)

I see, an extra warning then. Might help, as long as the registration page remains short and sweet. Only harm I can see is if the page gets so cluttered with messages that all are ignored. Alice Wyman 20:49, 14 March 2006 (UTC)

Between a blurb about a technical error in the title due to the limitations of wikis, the disclaimer about its only written for ... but may also apply to ... and the statements that you shouldn't add a comment in any referenced bugzilla bug reports you want to add yet another potential blurb stating that editing this article doesn't effect your system? I suggest we do nothing unless it becomes clear there is a real problem (more than an occasional edit). Tanstaafl 10:03, 15 March 2006 (UTC)

I want to add it on the registration page, not on the top of the articles. If anything, this would allow us to remove a top-of-the-article blurb because it'll catch anyone who's not logged in and presses "Edit".--Np 19:11, 15 March 2006 (UTC)

Adding that to the registration page sounds fine. I had mis-interpreted it as a proposal to do that on every article. Tanstaafl 22:13, 15 March 2006 (UTC)

Speaking of which, it was brought up on the forums that users have been making anonymous kb edits without registering or logging in. Alice Wyman 19:42, 15 March 2006 (UTC). It's now reported fixed Alice Wyman 04:22, 16 March 2006 (UTC)

The notes should be short, or nobody will read them. I'll make the change as soon as you agree on a text. --Filipp0s 01:28, 19 March 2006 (UTC)

New Main Page

Previous discussion of the existing Main Page can be found on Talk:Knowledge Base.

I rewrote the Main Page. Check User:Filipp0s/Main_Page. Do you like it? I removed false links, redundant information and compacted the layout to make it fit in 2 pages. Any comments? --Filipp0s 01:06, 19 March 2006 (UTC)

I like your new Main Page, and I'm particularly glad that you managed to get some images in to liven it up! (I tried this a while back, and had no success.) It would be good to find some other images to go with the remaining sections. --Mozcerize 10:21, 19 March 2006 (UTC)

I would change the Intro from, "This website provides documentation of Mozilla products and applications " to something like, "This website provides documentation of Mozilla products and Mozilla-based applications." as this would make clear that unofficial products like Nvu and SeaMonkey are covered (shouldn't a SeaMonkey article exist by now?). Under the SeaMonkey (sp) heading I think the description should be A remarkable suite of browser, e-mail client, and more, utilizing cutting-edge technology, the successor to Mozilla Suite ... or similar, showing how the two are related. I would also change the Other Mozilla products heading (or limit it to official products and create a separate heading for "Other Mozilla-based applications").
P.S. I like the images, too. I was wondering if the final page is going to use the imageshack site or if there's a central place for MozillaZine images (the image in the Safe Mode article is linked from upload.wikimedia.org/wikipedia/commons). Alice Wyman 13:52, 19 March 2006 (UTC)

Nice work with the "Other Mozilla-base applications" logo! One thing I noticed: you've removed the links from the paragraph in the current Main Page which says

The MozillaZine Knowledge Base is a wiki; you are free to correct, edit or create pages. Be sure to read the goals of the Knowledge Base and the rules about editing. If you have not used a wiki before then you can also learn how to edit wiki pages.

Was this intentional? I'd like to see the link to the "goals of the Knowledge Base" (which is MozillaZine_Knowledge_Base:About) replaced. That page also links to and discusses the Rules page and the Formatting and Sandbox pages, so I think that's the only link we need. --Mozcerize 17:59, 20 March 2006 (UTC)

Not intentional, fixed it. Shall I replace the current Main Page? (BTW, clicking «Main Page» in the sidebar links now to Knowledge_Base directly) Filipp0s 22:54, 20 March 2006 (UTC)

Can we make one more change? I'd like to change "This website provides documentation of Mozilla products and applications"' to "'This website documents the Mozilla products and applications". I think that we can put the new page up! --Mozcerize 09:29, 21 March 2006 (UTC)

I don't think these two sentences mean the same. If you are sure they do, change it! Replacing the Main Page, since nobody objected. --Filipp0s 21:59, 21 March 2006 (UTC)

Hi there! I'd like to modify the introduction paragraph by highlighting (bold, underline, whatever) the verbs (browse, search, discuss) and add a new verb, contribute, pointing to http://kb.mozillazine.org/MozillaZine_Knowledge_Base:About#Contributing_to_the_Knowledge_Base
Would this make sense to you guys? --FatJohn 23:07, 19 June 2006 (UTC)

Is this in order to make it clear what options the visitor has? Sounds reasonable, but we need to bear in mind that web users often expect "highlighted" phrases to act as hyperlinks. --Mozcerize

That's the general idea. Only newbies will read the introduction to KB and they have no idea what the KB really is. I think bolded entries wouldn't be associated with hyperlinks. --FatJohn 23:10, 19 June 2006 (UTC)

In unrelated news, I tried to make images for development and extensions. See them on Frontpage_suggestion_mockup. Like them? You make better images! :) --FatJohn 01:08, 17 June 2006 (UTC)

These look good! --Mozcerize 10:44, 18 June 2006 (UTC)

I was about to put the new images up, when it occured to me that the rectangular dev image would match the others more if it had a hemispherical feel. How about cropping the rectangle and making it into a cog shape? --Mozcerize 07:01, 30 June 2006 (UTC)

I though about that too but then I decided against it since the other pics are product icons (which happen to be round). However, be my guest. --FatJohn 10:25, 30 June 2006 (UTC)

Merging products' pages with their categories

I merged Firefox with the Category:Firefox content. Editing Category:Firefox will automatically edit Firefox. Check the Firefox page code to see how I did it. If nobody disagrees, we could do the same with the rest products. --Filipp0s 01:28, 19 March 2006 (UTC)

I'm missing something basic. How (and why) would a typical user ever goto Firefox in the first place? I'm used to clicking on Knowledge_Base and then selecting something. Or perhaps I should ask, why do product pages exist at all now that we're using categories? Tanstaafl 02:13, 19 March 2006 (UTC)

They're linked to from the official site.--Np 02:30, 19 March 2006 (UTC)

…and this is a problem. Regarding the merge, I usually find it pretty annoying when I click on a link to a page (such as the link to the Category page from the Firefox page) only to find that the text appears to be the same, because you're never quite sure whether the new page is actually new, or if it's just a loopback to the old page. With what Filipp0s has done, however, there is a fairly funky effect of clicking on the "all Fx articles, arranged by subject" link, and the page changes---but the paragraph text stays motionless and the subcategory listing appears, and it feels like some JavaScript effect where you've 'opened up a hidden section'. (We could even emphasize that by having a little "+ -" twister!) However, I would like to see the following paragraph restored:

Articles that relate to Firefox are grouped by subject into the subcategories listed below. Firefox articles that do not fall into any of these subcategories are listed at the bottom of this page.

because it specifically tries to address the problem of people thinking that the individual articles listing are the sum total of articles in the Firefox section, rather than just those which have not been subcategorized. (IMO, this is a problem with bad section wording in the MediaWiki software, and it annoys me in other wikis, too.) Ideally, it would appear in the equivalent place to the "all Fx articles, arranged by subject" link. This is going to be a bit more fiddly to implement, however, as the main paragraph text would have to be factored into a third article, and then merged into both the Firefox article and the Category page, together with their respective extra snippets. (Personally, I think it's worth it.)

Of course, the best way to solve the whole problem is is to get the official site to link to the Category page directly, and we could then delete the Firefox article altogether. --Mozcerize 10:30, 19 March 2006 (UTC)

Issues categories

I still feel very strongly about the fact that the Issues category should simply be a "view" on the rest of the KB structure, and not the sole place where an article is categorized. (Quoting from the very conception of the categorization idea, on Talk:Rules/Categories:

If an article is categorized in Issues, it should be categorized in another, semantic, category as well.
Make it clear. The point is: we don't want to repeat the mistake [viz. having to look in several different places at once to ensure you've not missed anything] of FAQs/Tips pages again.

Information in the Issues articles should be reachable using semantic navigation of the other categories, if it makes any sense at all to do so. For example, Background music doesn't play should also be placed in the Plugins category. There are also a few TB issues articles which would enjoy semantic homes. --Mozcerize 11:05, 19 March 2006 (UTC)

Good point. I'll take care of that for the existing Thunderbird issues articles. I suggest you add a sentence or two about how the Issues category should be simply another view in the Categorizing articles section in the KB Rules page (assuming nobody objects). Tanstaafl 06:27, 20 March 2006 (UTC)

Searching the KB

Is there any way of improving the Search feature so that it understands about plurals? E.g, search for "attachment" and you don't get any articles with "attachments" in the title, and vice-versa. This seems fairly lame! --Mozcerize 11:36, 19 March 2006 (UTC)

The only solution I can think of is to create new articles with redirects.

KB introduction

I want to merge In-house_style, MozillaZine_Knowledge_Base:About, Rules, Talk and Article_naming_conventions. I get often PMs from people afraid to contribute because it's so complicated and I've seen similar posts in the forums as well. Check User:Filipp0s/KB_Introduction. Still working on it --Filipp0s 23:56, 31 March 2006 (UTC)

That's a good idea, although I don't think that the pages you mention should be deleted. Currently, MozillaZine_Knowledge_Base:About is an attempt to provide the sort of introductory page that you have in mind, but yours is more comprehensive, and likely more useful to new editors. But as stated elsewhere in the KB, the existing pages such as In-house_style, Rules and Article_naming_conventions are aimed more at regular contributors than at new ones. These pages can still remain the "official" points of reference, but links to them can be removed from the front page and other welcome pages; instead, the most important bits can be summarized in your introductory article, as you have suggested. --Mozcerize 10:05, 1 April 2006 (UTC)

Directing people to the forums

Moved here from Talk:Knowledge Base

Would it be possible on the kb account creation/login page (i.e., Special:Userlogin) to include a boldfaced line referring people to the forums? There seem to be more and more pages like User talk:SciFiPecan, and maybe something like {{noquestions}} on the login page would deter some of these people. --Wintogreen 02:30, 17 Jun 2005 (PDT)

I would also like this to be implamented. It is a very good idea Stex 04:10, 6 Jul 2005 (PDT)

PM kerz on the forums, since he doesn't visit here often. Only he can make a change like that. --shadytrees

getting started: no thanks to "Log in/Create Account"

Getting started at this wiki is far more confusing than it needs to be.

I understand that evil spammers make it impossible to allow anonymous edits without signing in.

But we do want more well-intentioned potential users to create an account, log in, and start editing this wiki, right?

When these people see the "Log in/Create Account" link on the right sidebar, some of them may be tricked into thinking that's how one creates an account. The poor deluded fools.

First you must go the forums, create a "forum user account",
then politely send a private message to the appropriate person (I'm being vague here to encourage to you browse a bit more of the forum),
... then that person creates your user account here at the wiki, and you can log in and start typing.

I got 3 different passwords (exactly the same user name) for the following 3 sites (many people jump to the incorrect conclusion that registering for any of them automagically registers for all of them with the same name/password): In reverse order:

http://kb.mozillazine.org/ -- to block spammers, only logged-in users are allowed to edit this wiki. I need a user account before I can log in and edit. To get that account, I need to send a private message via the forums.
http://forums.mozillazine.org/ -- But first, to block spammers, only logged-in users are allowed to send messages (private or not) on the forum. To send that message, I need to create an account here.
http://www.mozillazine.org/ -- But first, I accidentally created an account here. I don't know what use it is, but I certainly can't use the name/password I created here to log in anywhere else.

When I thought all 3 ran off the same name/password system, it seemed like a frustrating loop -- can't log in until I get an account; can't get an account until I register for an account; can't register for an account without sending a message; can't send a message unless I'm logged in.

--DavidCary 04:16, 26 May 2006 (UTC)

I wholeheartedly agree that this system is a sorry mess and something should be done about it! (If nothing else, at least it should be made more clear what the usernames/passwords are and are not good for.) --FatJohn 03:38, 20 June 2006 (UTC)

Ideas for Extensions

Moved here from Talk:Knowledge Base

Hello,

I was wondering whether it would be appropriate to set up a section linking from here to collect ideas for developers on ideas for new or adapted extensions (for Firefox, Thunderbird, etc.) or the main programs themselves. If not, I have set up a wiki at http://allyourideas.com to which corresponding section(s) could be easily added to the relevant subsection(s). I think a wiki is an ideal way to organize ideas and feature requests for developers in a readable fashion (unlike discussion forums which could run on and on without any structure and with ideas being constantly repeated). Thanks. Brettz9 04:07, 16 October 2005 (PDT)

Identifying preferences that aren't in released applications

I noticed a lot of articles for preferences that aren't added until v2.0 of Firefox. They're lumped with all of the other preferences in the Preferences category. I assume a similar situation might occur for other applications later on. It would seem usefull if there were some way to distinguish between articles that apply to released versions, and ones that only apply to nightly builds (or future major releases) without having to read each article. Is there a way to do this without causing a lot of work? Tanstaafl 21:17, 22 May 2006 (UTC)

Akin to the Category:Unused preferences category? --Unarmed 01:09, 23 May 2006 (UTC)

Yes. Tanstaafl 22:16, 24 May 2006 (UTC)

Suggestion: Realtime collaborative editing

I think It might be a good idea to edit some of these articles in real time collaboratively, say using an IRC channel to group up all interested parties so questions can be asked and opinions exchanged. Often it's lack of information and facts that gets in the way... and cosiderations for the layout or in-house style. (I'm not saying ignore the in-house style but merely that different people should be charged with content and composition) Now many articles seem to be going nowhere. Or then it's just my articles... --FatJohn 11:15, 4 June 2006 (UTC)

I like this idea. It'll take a bit of organization though! Anybody fancy the task? --Mozcerize 08:59, 13 June 2006 (UTC)

I can do the honors. Which I guess includes founding an IRC channel and announcing it's location, name and password and the time of the gathering. Is there something else too? Suggest an article we could try this on and everybody who's interested in this idea, scratch your John Hancocks under the article. Let's see if this idea takes off or not. (I'm waiting for people to register for the event before annoucing the time and place.) --FatJohn 13:47, 13 June 2006 (UTC)

Irrelevant information

I feel the KB has a massive problem with too much information being contained in articles. Case in point: Firewalls

Overly technical information: "There are times when your computer needs to exchange ICMP type 3 and type 4 data with the gateway, and if that traffic is blocked, you will get web timeouts and failed ftp uploads."; Even for most techies, this information is over-technical. It also doesn't help anyone fix their problem.
Multiple points when one is sufficient (or better): "The Symantec Web site now has documentation on connection problems. Or read these step-by-step configuration instructions."; Why would we provide a link to the Symantec website (which goes to the main page and not a set of instructions, mind you) in addition to and ahead of the information that the user really wants?
Information not intended for users: "(The following is taken from the My-eTrust.com Knowledge Center article, I cannot surf the Internet since installing EZ Firewall, Document ID: 2207)."; This is a note for editors, not users. Why isn't it on the talk page? I don't know.

Information in most articles should be geared towards "how do I (the user) fix this?" Instead, many articles are just a hodge-podge of any related info. I tried to fix this article, but Alice Wyman reverted it. I propose the following guidelines that I believed were obvious, but apparently they aren't

Keep information not directly related to helping the user to a minimum. Especially do not include it if it's over-technical or confusing.
If one solution always works, do not include a second.--Np 17:54, 31 July 2006 (UTC)

I note that some useful changes accidentally got removed in the reversion. Some of them have already been restored.

Given that we have between 40 million and 100 and some odd million users who are constantly finding new ways to muck up, it's not always easy to know what's essential information or whether a solution always works. The KB sometimes changes in response to user confusion and other events. So I don't think KB is too bad for a committee effort, and it's improving steadily (particularly due to the efforts of Alice and NP!). But NP has definitely located some cruft here. And he is definitely right: keep it simple and brief. --AnotherGuest.

Information in most articles should be geared towards "how do I (the user) fix this?

That's a matter of opinion. I think that the goal of KB articles should be to give the user enough information and reference links that he can better understand the problem and maybe find solutions on his own. Alice Wyman 23:28, 31 July 2006 (UTC)

I tried to fix this article, but Alice Wyman reverted it.

See Talk:Firewalls for the background. Alice Wyman 23:28, 31 July 2006 (UTC)

I propose the following guidelines that I believed were obvious, but apparently they aren't

* Keep information not directly related to helping the user to a minimum. Especially do not include it if it's over-technical or confusing.

* If one solution always works, do not include a second.

I don't go along with that at all. I think that the more information we can provide, the better, and there's no harm in giving two different methods to fix a problem and letting the user decide which one is easier or better.. If an article gets too long we can always move sections to a new article, like I did with the Error loading any website article by removing the section on Firewalls to a new article (by the way, the "Firewalls" section was copied to the new article just about verbatim, except for some additions AnotherGuest made, which was, I thought, the main reason for NP's changes and AnotherGuest's request to revert the article. Alice Wyman 23:28, 31 July 2006 (UTC)

But surely you're both right. Some articles (e.g., "JavaScript is not Java" and about:config entries) are inherently informative, while others require lists of troubleshooting steps. It seems to me that problems occur when narrative is interspersed with lists, when text is verbose or poorly written, or when extraneous information is presented. Surely explanations followed by lists of steps should not be a problem, if both are well written and brief. Right? --AnotherGuest.

Yes, of course the intention of informational articles is to inform. I'm talking solely about instructional articles, for example Profile in use. That article includes instructional information on how to fix the problem, but also provides information about what causes the problem. I have no problem with most of that article because the information is brief, clear, and helps understanding. Saying that my computer needs to exchange ICMP type 3 and type 4 data with the gateway is not clear and does not help me understand the problem at hand. --Np 16:37, 1 August 2006 (UTC)

Wisely, the purpose of the KB has always been left carefully unspecified so that it is useful both as an end-user support manual and as a reference for advanced users and, to and extent, developers. My personal opinion on the matter is the same as Alice's; I like it if the user leaves with a slightly deeper understanding of the issue he is reading about so that he is more able to solve his own problems. Hence situations do arise where a little extra info beyond the minimum to solve the problem is useful. However, whatever our individual opinions, I imagine we all agree that every article needs to be treated on its own merits, and that all editors should spend a second or two thinking about the target audience for an article and, importantly, the likely route taken to reach the article. For example, it is common to find more technical language and detail in articles which are reached as "factors" of other articles. However, points of entry---including articles frequently advertised in the forums---should be written so that non-technical users can fully benefit from them.

The aim should be to achieve a balance between facts and methods, and to be honest I don't think that this is easy to legislate for; it largely depends on an editor's experience in reading and writing support and reference documentation. I agree with some of Np's criticisms, but these boil down to matters of editorial style rather than to real disagreements over content. Let's try to keep things calm! --Mozcerize 17:45, 1 August 2006 (UTC)

Rename of Page display category

Just want to make sure people have seen this - Category talk:Page display--Np 17:11, 7 September 2006 (UTC)

Suggestion for this page

I suggest that we indicate to people that discussion should normally happen somewhere else. For example, if I'm talking about changing something regarding Category:Firefox, I'd put up a link on this page to Category talk:Firefox. That way, both those who monitor this page and are watching pages they're interested in would notice the discussion. Of course, this doesn't apply to discussions that aren't contained to a single article or category.--Np 18:55, 8 September 2006 (UTC)

Ownership and dispute resolution

Prompted by the comments in this forum thread, I believe we need to some sort of dispute resolution mechanism and general guidelines in the KB. Otherwise, disagreements can easily escalate into edit wars and contributors leaving. The obvious solution is to have the Sysops handle these things, but I don't know if there are enough active Sysops to present a decision ("The Sysops said so, so I'll do it" vs. "Np is crazy, screw him"). Thoughts?--Np 21:43, 6 December 2006 (UTC)

I also noticed that thread and it wasn't a nice read. I've been overrun a few times myself. Usually with an accompanying explanation though. Maybe you need more sysops then. If a policy is made, it should be promptly introduced to new editors to make sure they're aware of it. PS. I wish all KB editors should "watch" this page. Could it be automatically inserted into new editors watchlist? --FatJohn 01:28, 7 December 2006 (UTC)

As of right now, the Sysops don't have the ability to change people's watchlists. Administrators might.--Np 03:23, 7 December 2006 (UTC)

First, what do you mean by "ownership"? Should articles be "owned" by different editors or Sysops who have the final say on edits, for example, give Vectorspace all the plugin articles, Tanstaafl all the Thunderbird articles and you and Unarmed take the preferences articles? Or did I misunderstand?

No, what I mean is that someone or a group of people is "in charge" of the Knowledge Base, to create and modify policy and resolve disputes between members. There would not be anyone in charge of particular articles; members would be free to edit as they currently do (of course, with the exception of the dispute resolution process and any new policy created). --Np 03:23, 7 December 2006 (UTC)

Second, I think that the current system of resolving editing disputes by posting to the article's Talk page should work in 99% or the cases. Hopefully, other editors would add to the discussion but if not, or if the issue still isn't resolved after a reasonable period, I suppose a Request for mediation page might work, something similar to the Pages voted for deletion discussion? Or, maybe one of the involved parties could simply post a "Mediation request" here, on this page? Once such a request is made, further editing of the page by the disputing parties should cease until the editing conflict is resolved. 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. I mentioned in the forum thread that some sort of "KB quality control" process is needed, besides just hoping that errors are caught and fixed as people review the recent changes or happen to read an article and spot a problem. Alice Wyman 01:59, 7 December 2006 (UTC)

Yes, the talk pages are usually sufficient in resolving disputes, though I suspect that many of disputes that arise are dropped by one of the parties to avoid the edit war. With a dispute resolution system, people wouldn't have to fear alienating users or entering an endless argument by asserting their views.

If you don't want people to risk alienating other editors then maybe a Request for quality review of the article (made by either one of the disputing parties OR by anyone else observing the conflict) would be the better route, but first a quality review process should be in place, hopefully similar to the review process taken before deleting an article, where everyone has the opportunity to contribute. I guess what I'm trying to get at is that a mediated compromise is preferable to an arbitrary Sysop decision (in the sense of mediation as opposed to arbitration). Of course it's easier for a Sysop to dictate what the resolution should be but I think that an open process where all editors are free to participate is better in the long term. Alice Wyman 12:00, 7 December 2006 (UTC)

Quality Control

The ability to change policy would help with quality control - we could dictate by policy in general terms what an article should or shouldn't be like.--Np 03:23, 7 December 2006 (UTC)

There are already general guidelines given in Rules#Editing_courtesy about documenting controversial changes (the linked Talk page even mentions using the Talk pages to suggest "Possible solutions to edit wars" in the "How to use Talk" section) so maybe that's where dispute resolution should be mentioned, but nothing specifically about quality guidelines, I guess because it's a difficult subject. Alice Wyman 12:00, 7 December 2006 (UTC)

We already have the ability to add a tag stating that the article doesn't meet wikipedia standards. The few times I've seen it used it didn't cause a dispute because it was pretty obvious that it deserved it. Perhaps the real issue is what types of disputes shouldn't be left to the talk pages. I remember the great difficulty several editors had dealing with one person who was basically kidnapping the anti-virus article to evangelize not using anti-virus software. That wasn't just two editors having a dispute, it was a case of whether one of the editors was acting inappropriately. Tanstaafl 15:47, 7 December 2006 (UTC)

The issue isn't messy pages. We have plenty of standards for grammar and formatting, but none about content. For example, should support articles present easy information to users to get them going again, or should they explain things in detail? In what order should solutions be posted - easiest first or most likely first? Should solutions be referenced so we know editors aren't just making stuff up? This is the type of policy we don't have that I think we desperately need. With an official policy on these things, users would be more comfortable changing "other people's" articles.

Regarding the dispute you mention, this is exactly where dispute resolution would come in. Right now, the only way to "win" a dispute is to convince the other editor or to be more persistent in implementing your version. With a dispute resolution process, the latter is replaced with an official process that takes less time, is less alienating and frustrating, and is more likely to yield the "correct" solution.--Np 18:18, 7 December 2006 (UTC)

"For example, should support articles present easy information to users to get them going again, or should they explain things in detail?"

Both, but sometimes often there are no easy answers because there are too many variables or unknowns. Sometimes the best that can be done is to explain how things work and suggest a check list or some guidelines for troubleshooting.

"Should solutions be referenced so we know editors aren't just making stuff up?"

Yes and no. What would you reference for the Standard Diagnostic? That's more of a messy consensus than a referenceable procedure. Although it may not be efficacious to reference a procedure, information should usually be referenced unless it's common knowledge and beyond dispute. --AnotherGuest 7 Dec 06

I wasn't intending on actually forming the policy in this discussion. I just want to figure out whether a defined policy would be useful, and who would create it.--Np 20:47, 7 December 2006 (UTC)

I am uncomfortable with the direction you're advocating. I don't mind a honest disagreement with other editors but I've repeatably had problems with what I consider grammar/style guide nazis who don't use any judgement, do their damage, and move on without contributing anything to the article. On the face of it there is nothing wrong with some of the standards you're proposing but based on past history it will just make things worse.

You mention With an official policy on these things, users would be more comfortable changing "other people's" articles. I'm not convinced thats a big problem. What I have noticed is we're not getting enough new articles about users problems (reference articles about a specific preference don't count) and too many cases where a ordinary user writes one article and then decides they've had it with the knowledge base.

I consider our biggest problem to be lack of contributers, not how professional the editors are, or how willing they are to edit somebody elses work. There appears to be a core of about six or seven individuals that do the majority of the work. I find a wiki style of collaboration to be difficult at times since you don't own any articles you write. I've found I usually have no problem when just one editor edits whatever I've written, regardless of how extensive the changes are or the differences in styles (as long as its clear they're not making changes just for the sake of standards). It gets more difficult the more editors are involved because there is no longer one consistent writing style. That can reduce the quality more than any deficiencies in my writing skills. It also creates complications because if you get too aggressive on rewriting an article the other contributers may feel they're being edited out. I can deal with that. However, I have a problem when you combine that with "editors" that don't contribute anything to articles for that application but want to dictate in detail many decisions.

Yes, lack of contributors is a major problem, but I'm not trying to address that with this discussion.--Np 20:54, 8 December 2006 (UTC)

I'm used to collaborating with some of the more prolific helpers in the forums. I'm struggling to find a way to encourage users who don't want to write/edit an article to contribute/pool information that I'll use to write an article. For example, I've been trying to get users that I've been helping with problems with the U3 version of Thunderbird to post background information such as the USB drive layout. However, I basically just want to be left alone by other editors, unless they're going to actually contribute to an article. I've noticed that the "standards" are in practice dictated by a few editors who hold similar views, not by consensus of all of the editors. I don't consider somebody mindlessly editing an article to make it conform to some standard that I didn't agree with in the first place as adding any value. Tanstaafl 04:32, 8 December 2006 (UTC)

The standards would not be arbitrary nitpicky things, much less nitpicky than the current in house style. They would instead be major issues that affect how useful an article is to a user. An example of a standard for an "issue" page could be "Start with a short description of the article. What are the common symptoms of the problem? What other problems are related to this problem, but are covered elsewhere? Then, as plainly as possible, describe the steps to solve the problem. Then, provide technical information for the more advanced users".

Furthermore, this would not be "Let's make Tanstaafl write articles how Np wants". This would be "Let's get all the editors get together, corroboratively decide the standards that would help users, then work on making articles fit those standards."--Np 20:54, 8 December 2006 (UTC)

You haven't convinced me there is a real problem while I am well aware of potential downsides. I prefer the current solution which is to let other editors improve articles as needed and lead by example. Tanstaafl 09:05, 9 December 2006 (UTC)

Including references in articles not only helps the reader but helps anyone reviewing the article verify accuracy. When I suggested a quality control process I meant that a review process should be set up so that articles get updated or corrected systematically. For example, the About:config entries article needs updating for Firefox 2 menu option changes, since right now it is not technically accurate in some instances as menu options are changed, as are prefernce default settings. 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. Maybe some editors could look at the Lost bookmarks article and it's Talk page as a case in point? Alice Wyman 02:23, 9 December 2006 (UTC)

I periodically browse most of the Thunderbird articles looking for ones that seem out of date. That doesn't mean I'll do something about every one I find (I know the bouncing messages article needs updating for 1.5 for example, but I keep dropping it to the bottom of my list of things to do) but I do make the effort. I assumed other people did the same thing for areas that they concentrated on.

You mention two different reasons - a poorly written article and its out if date. Your example seems more like a poster child for dispute resolution (between three editors) than a quality review process. Yes, there's some overlap but I think we're better off treating dispute resolution as a separate problem.

I suggest we start small and maintain a list of articles that are out of date, that includes a one line description of the problem. Thats less likely to cause disputes or hurt feelings and makes it easier to bring to somebodies attention since they don't have to scan the articles looking for a update tag. If the process works well then we could expand it (in several iterations) to deal with whether its well written or understandable (which is a much trickier issue to deal with since that may involve dispute resolution, standards, how good user feedback is, and political minefields such as the profile folder article) later on. I'm basically arguing for a iterative process (to discover and/or adapt whatever meets our needs), rather than mimicking whatever the Wikipedia does since we have only a few dozen editors while they have over 2.5 million.

The Thunderbird and Firefox support forums have a FAQ sticky thread (I don't know why SeaMonkey doesn't). I (or somebody else) could add a short blurb that links to that page, a similar blurb to the top of http://kb.mozillazine.org/Knowledge_Base and a thread in the general forums about it (mainly to let the more prolific posters know about it and ask them to mention it as needed). Tanstaafl 06:03, 9 December 2006 (UTC)

I'm afraid I didn't understand your point about the FAQ sticky thread... you mean adding a link to the Out of date articles page to alert helpers or users that the information is outdated? I'm all in favor of a page listing articles that need updating, in addition to the update template that belongs on each article (similar to the Pages voted for deletion system). If it works then it can be expanded it to include a "Quality review requested" or "Comments requested" list and associated template for the article or its Talk page. It still doesn't address the question of how these articles get tagged in the first place, but it's a start. Is any one responsible for reviewing all Firefox articles, for example, after a new application version is released, to see which ones are out of date? I was haphazardly updating articles for Firefox 2 as I came across them. I saw no systematic process and none of the articles I updated were tagged. Alice Wyman 16:50, 9 December 2006 (UTC)

Yes. The page isn't as useful if ordinary users and helpers don't know about it, and its only used by editors. Adding a link to it in an existing sticky thread in the forums, and in the main knowledge base page lets ordinary users stumble across information about it. The thread in the general forum was meant to evangelize the idea of that page to helpers, who typically point users to articles that might help them. I'm hoping that if the user they're helping discovers the article was out of date that the helper will suggest the user mention that in the Out of date articles page (or mention it themselves).

I'm not suggesting that anybody is responsible for reviewing any articles though I'm hoping that if we create this page that editors will get in the habit of reviewing articles in whatever area they normally edit/write articles after every major version (perhaps with a little encouragement), and will update the page as needed. Right now there is no incentive for them to review the articles unless they're willing to do the work updating them.

My impression is that editors are reluctant to use the update template, for whatever reason. I'm suggesting that we encourage them to use that template, but as a minimum add the article to the Out of date articles page. If they do both, great. The main problem I see is that you have to sign up for a knowledge base account to edit an article, and thats a lot to ask a ordinary user to do. I'm hoping that we can find a way to let users edit a single dedicated knowledge base page without having to login. That might cause it to get spam, but I think thats an acceptable tradeoff since we're only talking about one page. Worst case I assume we could create a knowledge base account with a public username and password (guest ?) that was limited to only being able to edit that one page. Tanstaafl 23:05, 9 December 2006 (UTC)

Dispute resolution process

I've moved the discussion to the discussion page of a draft Dispute resolution process article that Alice and I wrote. Tanstaafl 01:57, 12 December 2006 (UTC)

I've made a few last edits to the article. It would be great if there were some other contributions besides mine and Tanstaafl's, or at least some new comments on the article's Talk page. In any case, just going through the process of writing a draft on how KB disputes should be settled and getting it down "on paper" has some value, I think. Alice Wyman 03:54, 15 December 2006 (UTC).

I added a "dispute resolution" paragraph to the rules that points to the "unapproved working draft". Half of the paragraph was about using the knowledge base changes page to announce new suggestions. I tried to avoid any controversy. Tanstaafl 00:02, 9 April 2007 (UTC)

Quality control standards

I wouldn't want to set any specific standards for what to include in articles such as should support articles present easy information to users to get them going again, or should they explain things in detail, or whether to place the easiest versus the more common solutions first since you can't really generalize. Like I said before, what we really want is for the article to be well written, understandable by the intended reader and technically accurate. Alice Wyman 02:23, 9 December 2006 (UTC)

I'm not sure why you're opposed to setting a standard of how an article's content should be arranged. I feel this is incredibly necessary. Not only does it make it easier for those wanting to contribute information to compose the article, having a standard format makes it much easier for users to find the information they need. How the information is presented does have a giant role in making it easy to understand and easy to use. Take our bookmarks article for example. You feel strongly that the instructions for restoring bookmarks should be at the top. I feel strongly that the steps to triage the issue need to come first. This is something that should be set in policy. Someone who knows what they're doing in regards to user support should step in and tell us how best to present the information to get it to the users that need it, and then it should be done that way. --Majken 16:29, 17 December 2006 (UTC)

I'm not opposed to setting standards, but they should be general ones such as readability and accuracy. As I saidm I'm opposed to setting specific rules for article layout that would apply to all "support" articles, such as support articles should present easy information to users first, or explain things in detail, or place the more common solutions first and similar guidelines. I did prefer a speciic layout in ONE article, placing all sections on "how to recover lost bookmarks" solutions at the top of the Lost bookmarks article, and go into possible causes and prevention in later sections, because I thought that most users would be primarily looking for how to recover lost bookmarks first, when going to that article. Alice Wyman 17:57, 17 December 2006 (UTC)

Do you have a suggested format for presenting all KB "support" article content? You first need to define what is a "support" article, since we don't have a "support" category. Lost bookmarks, for example, is in both the "Firefox Issues" and the "Bookmarks" category. The Import bookmarks article is also a "support" article, as is the Flash article from the "Plugins" category, and there are many many other articles that could be considered "support" articles. Only the "Preferences" articles have a specified format, set forth on the Category_talk:Preferences talk page. If you want to stick with "Issues" article, here are a few taken from the Issues with Firefox article ... maybe you want to give an example of a standard for arranging the content that would apply to all these articles as well as to the Flash Import bookmarks and and we can discuss it from there:

P.S. I don't have preferences any longer regarding the Lost bookmarks article. I'm no longer actively editing it, as I mentioned in the discussion page, since I thought it would be better for others to have a turn at it. Alice Wyman 17:57, 17 December 2006 (UTC)

KB user feedback

The forum thread mentioned above also included comments about quality control and feedback regarding user support documentation in general and in KB articles. I suggested something here awhile back on a feedback process, when problems are found in KB articles (a "bad link" in the specific case I brought up) but got no response. I ended up adding a section on Feedback to the "About" article, but it brings up an important point. Maybe the concept of "KB feedback" should be expanded to include a process by which people on the forums (both helpers and people asking for help) who use a KB article can have a way of giving some feedback on how the article did or didn't help solve a problem? The process should not require the individual to set up a KB account just to post a comment on the article talk page, for obvious reasons. One option is to post a comment to the forum, but maybe a link at the bottom of every KB article to a Feedback form is another possibility (I don't have the technical ability myself to come up with such a page but I'm sure others here do!). Unfortunately, quality control and KB feedback is always going to result in potential alienation of editors if an error they've made is pointed out or if their contributions are rewritten or removed from an article, but that's the price you pay for trying to improve the quality of articles. Alice Wyman 12:00, 7 December 2006 (UTC)

How is that better than using the associated discussion page? The discussion of the tradeoffs of alienating an editor seems to make the assumption there was only one editor for that article. Maybe I have too thin a skin, but if somebody writes an article and does most of the maintenance of it (i.e. they have an emotional investment) I'm concerned about their reaction if it gets publicly criticized and they think its due to changes made by somebody else. The collaborative style of a wiki is the not the type of collaboration most people are used to. I think there is a tradeoff in how much of a big deal you make of any feedback when you don't have many editors and the most common "feedback" nowadays is somebody trying to misuse the article to ask a question that should be asked in the forum. Tanstaafl 15:47, 7 December 2006 (UTC)

There are two types of feedback - that from other editors and that from users. I think the talk pages are fine for editors to post feedback. For users, we really need a "did this help?" feature like many other documentation sites have. Unfortunately, I doubt this is something that "comes with" MediaWiki - it would have to be built.--Np 18:18, 7 December 2006 (UTC)

Don't expect much from users. You will get two kinds of answers: "yes" and "no, it's written for geeks". I don't think you will get much useful information from people who had trouble understanding it, and you are even less likely to get useful technical suggestions. I don't know, you may not even get useful information on what is confusing them. I doubt that it will be worth the trouble.

Also, if they write "no", you might not be able to tell whether it's because the article doesn't apply or whether they just didn't understand. If they don't understand, you can dumb it down, but I think there will be a large fraction of users who won't get it no matter what. I think the best you can do is just write as clearly and as simply as you can, right from the beginning, but keep the information in the article. Feedback won't do anything but waste your time. --AnotherGuest. 8 Dec 06

While I agree that some users won't understand regardless of how it's worded, I still think it would be useful to have feedback on the articles. For example, if 75% of people find one solution helpful, and 30% find another solution helpful, that would say to me that we should talk about the 75% first. If no one found a suggestion helpful, we could remove it.--Np 03:40, 9 December 2006 (UTC)

If you structure it to get what you want, maybe. --AnotherGuest. 9 Dec. 06

Bugmenot

Bugmenot is a tool to find and share logins for websites that force you to register. Patient X has posted his knowledge base account username and password with them. A search of the logs shows Patient X has made many minor edits. Its my impression that they posted the username/password with bugmenot today. I added the following note to their talk page:

Please see the discussion in http://kb.mozillazine.org/Knowledge_Base_changes about your sharing your username/password. However, since this account is shared if I find anybody has been abusing it (posting spam, vandalism etc.) I will immediately block it rather than issuing a warning etc.

We don't have a explicit policy about this. I would like to modify the rules to prohibit sharing accounts as it increases the risk of spam and/or vandalism, and prevents us from identifying who made any changes. How can you resolve a dispute or issue a warning when you don't know who used that account?

I've also raised the question of what should be our policy about using tools such as bugmenot with the forums in the moderators forum. Interestingly, bugmenot has banned somebodies attempt to share an account for the forums but not the knowledge base. Tanstaafl 22:37, 5 April 2007 (UTC)

Sharing accounts or publicizing your kb.mozillazine.org username and password on a site such as http://www.bugmenot.com should be prohibited. One reason being, it results in "de facto" anonymous user editing, which is intentionally disabled as mentioned here. Another reason, it creates a record of contributions that are falsely attributed to a single person, who might gain credibility so that each of "his" succeeding edits might get less scrutiny than edits by unfamiliar editors would, if that makes sense. Alice 23:26, 5 April 2007 (UTC)

I made the edits to the Rules page. Tanstaafl 00:02, 9 April 2007 (UTC)

License issues

Jmontano (who is also a wikipedia editor) just created a DualLicenseWithCC-BySA-Dual licensing template, and created the Creative Commons Attribution-ShareAlike 1.0 Dual License and Creative Commons Attribution-ShareAlike 2.0 Dual License categories. This was not discussed beforehand on this page. His only other contributions have been an entry on a talk page.

We've never had to deal with the issue of licenses before (as far as I know), and have only been concerned that nobody uses copyrighted material. We've always taken the stance that nobody "owns" an article. Using that template creates potential issues for anybody else editing that article. IMHO it doesn't make sense for each article to have its own license, the same license should apply to all articles. I request that nobody use those categories or that template until after we develop a consensus about licensing. Tanstaafl 21:58, 12 April 2007 (UTC)

I've created a thread in the moderators forum to make the mozillaZine admins aware of this issue. Tanstaafl 22:30, 12 April 2007 (UTC)

I agree that the Template:DualLicenseWithCC-BySA-Dual should not be used by anyone, pending review by MozillaZine admin. As far as references to licenses or copyrights (copylefts) in the KB, I would think that the KB itself is the issuer or holder of such, not any indiviual contributor. This statement appears at the bottom of the text box whenever you create or edit an article (my emphasis):

Please note that all contributions to MozillaZine Knowledge Base may be edited, altered, or removed by other contributors. <snip> 'You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see Project:Copyrights for details) <snip> Alice 01:35, 13 April 2007 (UTC)

I went ahead and removed the page. Please contact me directly either via the forums or email to discuss if you want to use other licenses here. Thanks. kerz 06:24, 13 April 2007 (UTC)

Upload file enabled

Copied from Np's Talk page:

Special:Log/upload - I see that the "Upload file" feature is now enabled, or was this just for testing? I uploaded Image:Fx15safe.png just now for the Safe Mode article and was wondering if it would be OK to do the same for other articles for which we have images that are now linked from other locations such as Summary of Mozilla products. Alice Wyman 13:10, 27 December 2006 (UTC)

It's enabled now. Go ahead and use it, I have already. Gray bar below status bar--Np 15:32, 27 December 2006 (UTC)

I just uploaded the images used in the Summary of Mozilla products and Live Bookmarks - Firefox articles and replaced the external links with the new kb.mozillazine.org links. A SysOp will need to do the KB Main page (which now uses images linked from Imageshack) since it's locked. Alice Wyman 23:56, 27 December 2006 (UTC)

I've created Template:Right-pic which floats an image off to the right. See it in action at Gray bar below status bar--Np 01:47, 28 December 2006 (UTC)

Punctuation or other symbols in article names

I just came across a link on the forums to a KB article that included a contraction in the name (Images or animations don't load) and the link was cut off before the apostrophe. That article has already been renamed but the problem with using punctuation or other typographic symbols in article names has been brought up before, just recently on this article's Talk page. I was wondering if we should set a rule that article names should not contain certain punctuation marks or symbols such as apostrophes or parentheses, since it causes link problems. For example, instead of Video or audio doesn't play the article should be named Video or audio does not play (I just moved it). I was going to suggest this in Talk:Article naming conventions but thought I should bring it up here. If there are no objections, I would like to add a short paragraph to Article naming conventions on "Use of punctuation marks or symbols" stating that parentheses and apostrophes should not be used in article names and that other punctuation should be avoided, if possible (the exception, of course, would be about:protocol, file name or preference name articles). I could use the "Images or animations don't load" article as example. Alice 12:48, 4 March 2007 (UTC)

Thats a good idea. We need to be conservative in what characters are allowed in the article name or we run the risk that this type of problem will reoccur every time the Wiki software is updated. Tanstaafl 16:39, 4 March 2007 (UTC)

The issue isn't with the Wiki software, it's with the forum software.--Np 06:48, 5 March 2007 (UTC)

I'd say we create a list of characters that shouldn't be used rather than discourage all punctuation. We actually currently encourage hyphens.--Np 06:48, 5 March 2007 (UTC)

Instead of listing all symbols not to use, we could simply say something like:

Punctuation marks or symbols

Avoid using punctuation marks or typographical symbols in article names such as exclamation points, parentheses, apostrophes, quotation marks, etc., because it can result in broken links when posting the article URL in mail or newsgroup messages or on webpage forums. Exceptions include article names consisting of filenames, about:protocols and preference articles, or when adding a dash (hyphen) followed by the application name to the end of the article name, as noted above.

*Bad: [[Yahoo! Music videos don't work]]

*Bad: [[Standard diagnostic (Thunderbird)]]

I would be fine with a list, whatever people decide. Alice 21:37, 5 March 2007 (UTC)

I prefer Alice's latest text (rather than a list). She states when hyphens are appropriate etc. Tanstaafl 20:04, 6 March 2007 (UTC)

My preference would be not using a list and using the above (edited) text, if only because I wouldn't be sure whether any list would be complete or not. Alice 20:21, 7 March 2007 (UTC)

The text proposed is good. I didn't mean an exhaustive list, just some common examples of titles with discouraged characters. An example using parenthesis would be a good addition.--Np 20:43, 7 March 2007 (UTC)

OK, I edited the sample paragraph again. If no one objects I'll add it, or someone else can. Alice 02:55, 8 March 2007 (UTC)

Added Article naming conventions#Punctuation marks or symbols. Alice 23:57, 9 March 2007 (UTC)

Found a link in my collection that needs moving Image_tooltips_don't_work--Dickvl 20:26, 11 March 2007 (UTC)

I just moved it, thanks. The problem is, when you get redirected to the new article, it comes up with the old article's URL and people keep bookmarking and linking the old URLS. I've been updating those links in the Issues and Faqs articles and in other articles, when I notice them. I see you've been doing that, too. Alice 15:32, 12 March 2007 (UTC)

I had updated my links and changed the links with single quotes and to be sure I tested them. I also did a KB search to see if any links needed to be modified (hmm: "don't" doesn't work on its own; lol, that's two of them).
I just noticed another one in my collection: Flash#Flash_files_don.E2.80.99t_play. How to deal with those? --Dickvl 17:23, 12 March 2007 (UTC)

You make a good point, that article sections containing certain characters (such as Extensions.* files in the Unable to install themes or extensions - Firefox article?) might also cause link problems. You can edit existing articles to eliminate the special characters (I just changed "Extensions.* files" to "Extensions.xxx files" in that article) but existing links will no longer go to the specific article section. I could add something about avoiding punctuation marks or symbols in section headings to In-house style, if no one objects. Alice 21:22, 12 March 2007 (UTC)

Plugin warning

We have various pages on plug-ins that include "Security alert" sections. These sections specifically mention noteworthy vulnerabilities for the plug-in in question. In my opinion, we shouldn't discuss specific plug-in vulnerabilities. There are few reasons for this:

We're not close to the plug-in vendors. It's very likely we could be very late in discussing a severe vulnerability, or might not even hear about it at all. For example, the page on Flash doesn't discuss any vulnerabilities, though undoubtedly there have been a few big ones over the years.
We're not experts on the workings of plug-ins, and we shouldn't be viewed as such or as being in any way responsible to disclose their problems to our users.
We have no data on plug-in usage, so it's difficult to tell when a warning about a specific version should be taken down due to the fact that no one uses it any more.
Beyond "Make sure you're using the latest version", few users care about the specifics of the vulnerabilities.

Instead, I recommend that we include a template on the top of each plug-in's page that states a few things:

Plug-ins are not created by Mozilla.
Plug-ins are not updated as part of Mozilla products' updates.
Mozilla products do not provide protection against vulnerabilities in plug-ins.
Instructions (or a link to instructions) on how to check for and/or update to the latest version of the plug-in.

Comments? --Np 05:20, 1 May 2007 (UTC)

For example, the page on Flash doesn't discuss any vulnerabilities..... It used to but Flash had three security updates last year and we weren't keeping up. I thought it best to remove the section and, instead, link to the Adobe page on security vulnerabilites under "External links". A template for each article, like you suggested, may or may not be helpful and maybe I should have at least added a note to the Flash article about keeping up to date for secutity reasons, I don't know. I wouldn't be against removing the security warnings in other plugin articles like Quicktime and Java if a link to a page that discusses security vulnerabilites in these programs could be likewise added. Regarding the Windows Media Player article's security alert, see my reply here. I think it would be fine to add some general information about plugin updates and security to the Category:Plugins page, whether or not we add templates to each plugin article. Alice 13:24, 1 May 2007 (UTC)

I didn't see any risks in the WMP and Quicktime pages. I don't buy the argument that any security information is useless since we're supposed to always run Windows update. There are sometimes good reasons not to run update (or not to update certain software if you do a custom update). Pointing to other web sites for detailed information about security vulnerabilities seems a good way to limit our involvement, and set peoples expectations. I think most users have realistic expectations about how up to date any information is.

The main thing I have against the proposed template is it seems like a Mozilla lawyers instinctive response and spoils the impression that this is a independent community web site. As an aside, the proposed wording helps mislead users into thinking we're part of Mozilla. Tanstaafl 00:49, 2 May 2007 (UTC)

My comment wasn't meant to be the actual wording; it was just some bases that I felt we should cover.--Np 00:59, 2 May 2007 (UTC)

Plug-ins are not created by Mozilla.
Plug-ins are not updated as part of Mozilla products' updates.
Mozilla products do not provide protection against vulnerabilities in plug-ins.
Instructions (or a link to instructions) on how to check for and/or update to the latest version of the plug-in.

Excellent idea. And please add a reference to bug 271559, "Countermeasures for Java/plugin/extension vulnerabilities (disable, warn)".

AnotherGuest. 8 May 07

First shot (example, may not be the actual instructions we give):

Windows Media Player is a third-party plug-in not supported by Mozilla. Out of date plug-ins may cause crashes or security problems; you should ensure Windows Media Player is up-to-date by checking Windows Update.

--Np 16:41, 8 May 2007 (UTC)

That template seems innocuous. Tanstaafl 21:26, 8 May 2007 (UTC)

Is that good or bad?--Np 01:42, 9 May 2007 (UTC)

Good (it addressed most of my concerns) Tanstaafl 08:27, 9 May 2007 (UTC)

"Windows Media Player" isn't really a plugin, though, it's an application that includes a browser plugin. Same with the Quicktime Player and Adobe Reader. Also the term "third-party" may be confusing, and most plugin articles already include a link to download the application/plugin so another download link is unnecessary. If you do want some sort of template, why not just say something like,

Quicktime is not supported by Mozilla. Outdated browser plugins may cause crashes or security problems.

What I see missing, though, is a link to a page with security information, similar to what's in the Flash "External links" section (or in the WMP article intro) but I guess that could remain part of the content of the article itself. Alice 23:59, 8 May 2007 (UTC)

Saying that WMP, Quicktime, and Adobe aren't plugins is just semantics. We call them plug-ins all over the KB, and in the context of Firefox, that's what they are. I actually think linking to a security info page would be better than a download page because they will usually contain info on how to upgrade anyway. I made the template to allow whatever text you want to put, whether it's "use Windows Update" or "read this article".--Np 01:42, 9 May 2007 (UTC)

Windows Media Player is a plug-in not supported by Mozilla. Out of date plug-ins may cause crashes or security problems; you should ensure Windows Media Player is up-to-date by reading this article at Microsoft.com.

Saying that WMP, Quicktime, and Adobe aren't plugins is just semantics. We call them plug-ins all over the KB, Maybe so but I don't think we should perpetuate the confusion between a browser plugin and the associated application. Windows users missing the WMP plugin ran head-on into this when they couldn't figure out why updating to or reinstalling Windows Media Player 11 didn't add the missing WMP plugin (bug 360336). Alice 12:06, 10 May 2007 (UTC)

I think this warning misses some of the essential points in your bullets, in particular that Fx provides no protection against vulnerabilities, and does not update them. But beyond that, there are two other problems with the warning as stated:

(1) can up-to-date plugins cause problems? (certainly).

(2) what does "not supported" mean? To some people that's a pejorative. It means it might not work right, when what we actually mean is that Moz can't fix it. --AnotherGuest. 9 May 07

How about something like this:

Mozilla applications are regularly updated for security and stability; however, Mozilla does not provide updates for installed plugins, which can cause crashes or hangs and which may contain security vulnerabilities. Specific information about security issues that affect <insert plugin article name> is available here.

Alice 12:58, 10 May 2007 (UTC)

Edited for ...er, grammar and punctuation.

Other changes: About compatibility. Does that mean that Firefox should just be made "compatible"? And why is WMP singled out in this message? Should there not be a reference to all plugin issues? --AnotherGuest. 10 May 07

See my re-edited version above. I removed "outdated or incompatible". I also re-edited my proposed template to allow for multiple page links. Alice 10:01, 12 May 2007 (UTC)

I also removed the "Security alerts" from the Java Quicktime and Adobe Reader articles and replaced them with more general information on security updates and links to current advisories. Alice 10:01, 12 May 2007 (UTC)

Looks good. Shouldn't this be put at the highest level to which it applies? It would go nicely in Issues related to plugins, minus the last sentence. --AnotherGuest. 14 May 07

I think the point is to put it where most users will see it, on the plug-in pages themselves.--Np 18:09, 14 May 2007 (UTC)

The first sentence is a little clunky and long. There's also a few words in there that could be snipped, namely "installed" and "specific". How about "Mozilla applications are regularly updated for security and stability; however, Mozilla does not provide updates for plug-ins. Plug-ins can cause crashes and hangs and may contain security vulnerabilities. Information on security and stability issues affecting <insert plugin article name> is available here."--Np 18:09, 14 May 2007 (UTC)

That's fine with me. Alice 12:22, 18 May 2007 (UTC)

Mozilla applications are regularly updated for security and stability; however, Mozilla does not provide updates for plug-ins. Plug-ins can cause crashes and hangs and may contain security vulnerabilities. Information on security and stability issues affecting Java is available You forgot the security-text parameter.

Good?--Np 17:04, 18 May 2007 (UTC)

That's maybe a little choppy but it's OK. Keep in mind, Java is a special case since updates don't remove older versions. It's also going to need multiple links on security issues, if you think that will work out OK in the template. I haven't found any good Sun link for security issues specific to the JRE... all I could find was this page and the "Sun Alert Notifications" link for issues after 11/19/02 gets you this. Best I could come up with was linking to separate Secunia pages based on JRE version, which I placed under "External links" and dealt with it like this. Alice 20:48, 18 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 [3][4]

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[5][6]

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)

[7]--Np 08:15, 7 June 2007 (UTC)

The interface sucks[8][9][10]

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

No one talks about it[11]

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

Don't think changes would be accepted[12]

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[13][14]

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"[15][16]

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[17]

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

Not seen as important[18][19]

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[20]

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

Lack of guidelines[21]

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

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

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[23]

"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:
1. 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.
2. 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)

I'd prefer to give them the option that they're least likely to get wrong.--Np 03:19, 13 June 2007 (UTC)

Me too, and different procedures are "least likely to be got wrong", or, let's say, "easiest", for different people. We don't need to be dependent on third-party software: therefore if some result can be achieved with no need for an extension, we should tell the users how; and some technical users will consistently prefer the solution (if any) which doesn't require installing an extension. But some feats are achieved most easiest, and with least risk of doing it wrong if the person doing it is a novice, by using some well-chosen extension. Then, IMHO, the extension(s) in question should be mentioned in addition to the "extension-less" procedure. — Tony 05:40, 16 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)

Yes, a feedback mechanism would be very helpful, but would require technical changes that just aren't going to happen here. We do have a sticky in the site discussion forum, an addition to a support sticky might be useful as well.--Np 03:19, 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)

Yes, this would apply mostly to support articles because those who want to read non-support articles are generally more technically inclined. I don't suggest labeling entire articles as being "technical", I intended that to be applied to necessary technical sections in otherwise non-technical, support articles. Technical articles just need something in the intro that describes what and who the article is for.--Np 03:19, 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)

I disagree, I think that presenting options where one way works unnecessarily complicates things. We've been over this, so I don't think we need to rehash it.--Np 03:19, 13 June 2007 (UTC)

You don't think we need to rehash it? You started off saying, 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 ...<snip>. I think we should rehash it if your goal is to come to a consensus on KB guidelines. If majority rules, then where was a "vote" taken? Even so, I think it should be "rehashed" again, since opinions change. Alice 09:48, 13 June 2007 (UTC)

I just meant that I know I'm not going to convince you, and I don't think you're going to convince me... But you're right, I should put forward an argument so that others can decide.--Np 14:54, 13 June 2007 (UTC)

About multiple possibilities, I think that not all cases are equivalent. Sometimes one method will be obviously superior to another: then the latter may (and should) be omitted. Example: using about:config vs. editing prefs.js. Other times, different methods may appeal differently to different users: then they should both be mentioned, with the simplest / least technical one on top. Example: using a hidden pref in about:config vs. making the pref visible by means of an extension. — Tony 05:40, 16 June 2007 (UTC)

Here's an example of an article offering multiple methods: Corrupt localstore.rdf. On the surface, you might be tempted to remove the "Alternate method" which involves finding the profile folder and manually deleting the localstore.rdf file, and keep the Safe Mode method, since it appears easier. However, assuming this article also applies to MacOS, starting Firefox in Safe Mode on a Mac involves using the terminal utility, which is likely more complicated than manual deletion of the localstore.rdf file. I would let the user decide. In any case, I think that a KB guidelines "draft" should be set up and discussion continued on its Talk page. Alice 10:19, 13 June 2007 (UTC)

I think that if manual deletion of localstore.rdf is easier for Mac users, then only that option should be presented to them. It's a tautology, but someone who is not familiar with the terminal or with finding the profile folder will not be familiar with the terminal or with finding the profile folder, and therefore has no knowledge to base a choice on.--Np 14:54, 13 June 2007 (UTC)

And I think that both options should be presented. Who are we to decide for all users, which is the easier or better method? I'm a novice Mac user and I'm somewhat familiar with the terminal and also minimally familiar with using OSX 10.2 to find files and folders. Let me decide which method I want to use, not you. Alice 03:23, 14 June 2007 (UTC)

"Who are we"? We're the experts, here to tell them how to fix whatever's wrong with their systems. The point I'm trying to make is that providing choice where the options are not understood and where the result is the same brings confusion.[24]--Np 04:58, 14 June 2007 (UTC)

We're the experts, here to tell them how to fix whatever's wrong with their systems. Really? Do you consider yourself an "expert" on all versions of MacOSX ? Windows Vista? SeaMonkey, for that matter, on any OS? By "we" I meant anyone with a KB account who wants to edit articles. "We" (meaning most of us) are probably not experts in any operating system or Mozilla application, much less all of them. The best most of us can do is to add our bit of knowledge and hope it helps. My point in giving the Corrupt localstore.rdf example was to point out that if your guideline If certain options have no advantage over other options already presented, do not include them..... were in effect, a KB editor might not include a second method of solving an issue, or might remove an "Alternate method" already given. He might not even realize that the second option might be easier or have other advantages for certain users. Anyone who then wanted to add a second option would have to justify it, while the person removing it could just point to the guidelines. Removing the option to use Windows Task Manager from these Vista instructions in the Browser will not start up article and leaving just the option to restart the computer is another case in point. It may be easier for a novice user but the average user might find ending the xpicleanup process quicker. You also said The point I'm trying to make is that providing choice where the options are not understood and where the result is the same brings confusion. How do you know that the options are not understood? You gave a reference to a Choices = Headaches - Joel on Software page. That's Joel's opinion; he basically complains about how many choices Windows users have for accomplishing various actions and gave turning off the PC on Vista as an example of too much choice. Here's an example from Microsoft's kb where multiple methods for accomplishing the same task (finding hidden files on Vista) in various situations are offered: It states in the "Resolution" section, To resolve this issue, use one or more of the following methods, as appropriate for your situation. Since opinions vary, I would not set a guideline on whether or under what circumstances we should be offering multiple options to accomplish the same task. It's micromanagement at its worst. Alice 10:54, 14 June 2007 (UTC)

By "we" I mean the combination of all contributors. "It may be easier for a novice user but the average user might find ending the xpicleanup process quicker." Right, that's why I said "Using the Task Manager requires more skill, but is quicker for those who already know how to use it.". Being quicker is an advantage, and therefore it's OK to stay in my mind. I don't think the Microsoft KB is something we want to emulate.--Np 14:13, 14 June 2007 (UTC)

Then why did you remove the Task Manager method from the Browser will not start up article Vista section in this edit? And why wouldn't you want to take the good from the Microsoft kb? I would have thought you'd at least think about adapting the content structure of the article, which is broken down into SUMMARY SYMPTOMS CAUSE and RESOLUTION sections. It might be a good addition to In-house style for a "Support issue" category of articles, if we do create one. Alice 15:32, 14 June 2007 (UTC)

I removed it to add a simpler method. It was a mistake to completely remove Task Manager.--Np 15:57, 14 June 2007 (UTC)

I see you added it back. Thanks. Alice 13:06, 15 June 2007 (UTC)

I'm against yet another document. I'd prefer to see fewer guidelines and that they are added to a short "Write for the appropriate audience" section in rules. I'd prefer Np didn't draft that. I suggest Alice draft that. Anything from Np's list that doesn't get added to that section (in one shape or another) could be proposed as an addition to In-house_style , and discussed in its talk page. I've taken the liberty of editing Np's list to have numbers so that I can refer to particular items. I think the topics brought up in 1 , 2 and 3 might be appropriate for "Writing for the appropriate audience" Tanstaafl 01:45, 14 June 2007 (UTC)

I just assumed that np was going to draft some guidelines no matter who objected here, which is why I suggested he go ahead and do so, at which point we can comment on the proposal once it's "down on paper". Even though np said that he's '... been trying to avoid talking about specific articles.. I think we do have to get down to specifics since that's the best way to see if "standards" or "guidelines" actually work. I was going to then suggest that we nominate specific articles that np could edit in a sandbox and see whether the proposed guidelines "work". I was going to nominate Lost bookmarks Profile in use and Error loading websites. I mentioned these last two articles here in the Archive; at the risk of rehashing:

In his 7 December 2006 comment, np asked, ... should support articles present easy information to users to get them going again, or should they explain things in detail? In what order should solutions be posted - easiest first or most likely first? Should solutions be referenced so we know editors aren't just making stuff up? then concluded, This is the type of policy we don't have that I think we desperately need. With an official policy on these things, users would be more comfortable changing "other people's" articles.
In reply, I said that I wouldn't want to set any specific standards for what to include in articles <snip> since you can't really generalize. Like I said before, what we really want is for the article to be well written, understandable by the intended reader and technically accurate.
To which Majken asked me, I'm not sure why you're opposed to setting a standard of how an article's content should be arranged. I feel this is incredibly necessary. Not only does it make it easier for those wanting to contribute information to compose the article, having a standard format makes it much easier for users to find the information they need.
To which I said, .. maybe you want to give an example of a standard for arranging the content that would apply to all these articles <snip> and we can discuss it from there: <list of articles> at which point she stopped responding . Alice 03:23, 14 June 2007 (UTC)

I'm against yet another document. I'd prefer to see fewer guidelines and that they are added to a short "Write for the appropriate audience" section in rules. I'd prefer Np didn't draft that. I suggest Alice draft that. Nah, I'm getting KB burn-out. I was going to edit a few more articles and then take the summer off. Alice 03:23, 14 June 2007 (UTC)

I was going to draft something up based on the feedback I got here, and then try to get feedback from a wider audience by posting it to the forum, newsgroups, IRC etc. I'd really like to get more than four people's opinions on this. A lot of people have been complaining about the quality around here, so I think at least some of them would be willing to provide input. Regarding "yet another document", I would like it if we could integrate whatever we come up with in existing documents, but I'm not sure how well it fits in with "Rules", which makes it sound like something editors must do, and only #4 seems to concern style.--Np 04:58, 14 June 2007 (UTC)

Thats called shopping for votes where I come from. I suggest you lead by example, editing several of the most popular articles to make them less technical. That will provide something concrete that people can react to in the talk pages or the sticky thread (which nobody has posted in yet), and perhaps get other editors to experiment with similar changes. Than later on, discuss whats been learned. Think "iterative design". We keep talking about improving quality and reviewing articles for quality, but without experimenting with different changes where do we get the data to decide what really works? I'll take a stab tomorrow at restructuring Transferring data to a new profile which I think is still way too technical. I can hardly make it worse.

Perhaps we should rename the rules document to guidelines. It really has only three "rules" (no edit wars, don't share your username/password, and use common sense), with the remainder of the document being guidelines that we explicitly state you don't have to follow. Tanstaafl 06:09, 14 June 2007 (UTC)

Perhaps we should rename the rules document to guidelines I agree. Alice 11:07, 14 June 2007 (UTC)

A lot of people have interest in how the KB is written other than the editors. Call it what you will, but I'd like to get their opinions. These guidelines are essentially what I've been trying to follow for the past while now. Look at my recent edits for good examples.--Np 13:34, 14 June 2007 (UTC)

I know we're not going to get full agreement on everything, but what I think would be useful would be summarize any arguments against any section and then try to gauge the opinions of a wider audience. Based on those opinions, we can modify or drop sections. I've prepared a draft below that I hope address some of the issues raised in the above discussion. I know I'm in disagreement with Alice and AnotherGuest. on the "providing choice" thing. I'm going to try to summarize the arguments for and against it; feel free to edit the argument if I'm not reflecting people's views correctly.--Np 15:01, 14 June 2007 (UTC)

Eliminate #2, multiple ways of doing something. General guidelines or in-house style formatting guidelines are one thing; specific details on what to include in articles is another. You run the risk of lowering morale and losing what contributors we already have if you try to micromanage the article-writing process too closely. Read http://en.wikipedia.org/wiki/Micromanagement and do some research on the impact of autocratic style of leadership on organizations.. Alice 15:32, 14 June 2007 (UTC)

This is not an autocracy. This is a proposal I, as a non-privileged editor, am putting forward. You've given your opinion on the proposal, I've given mine, and I want to hear everyone else's. If the larger community doesn't like it, I have neither the intention nor the ability to overrule.--Np 15:57, 14 June 2007 (UTC)

You're not a "non-privileged editor" by definition, since you're a SysOp. Why do you think there was so much concern about the potential appearance of abuse of power in the discussion for the proposed dispute resolution article? We've tried to always make changes by consensus among the editors. The problem I have with your posting a link to your draft in the KB thread is that the way you did it makes it appear that rather looking for more input (which is good), you're trying to stack the deck. Tanstaafl 11:07, 16 June 2007 (UTC)

I meant "non-privileged" in the context of creating guidelines. As I understand it, SysOps' only powers above editors is protection and blocking. If the way I posted it makes it look biased, I didn't intend that, and I've edited my post in the "what's stopping you" thread to match what I wrote in the feedback thread. I give you permission to edit it further, if you see fit.--Np 17:47, 16 June 2007 (UTC)

Jeeze, don't you guys do a lot of talking! haha. Must admit haven't read every word here and don't intend to, but noticed that Alice seems to have some good ideas here. This stuff ain't exactly hard to work out, you know. KB too technical? ...find out. Get up in the morning, make tea and within 10 minutes of waking up come here...if you don't immediately understand every word of the most needed and used articles, then yes, it was either too technical or written poorly.

Never tell the customer more than they need to know to solve their problems. In this case, simple, clear, concise tutorial articles that explain the simplest solution only. Put links to the other various Moz apps or OSs at the head of those articles and repeat the whole tutorial including the variation, at the ends of those links. That way, a customer is only ever 2 clicks away from the tutorial article that is directly relevant to their problem/app and OS.

DO NOT keep adding layer upon layer of ifs and buts to the original article. Guess why? It's not because the stuff is too technical that people don't understand it, it is because it's so poorly written and convoluted that only the people who wrote it can understand the damn thing, that's why .

At the foot of each article, put in bold 'The following stuff is of geek interest only'...and put the other solutions in a clearly numbered format, together with the advanced in-depth background info. - don't keep using bullet points everywhere, normal people do things in stages and need to know, by number, what stage they have reached.

Anyone not understand this? http://kb.mozillazine.org/Creating_a_new_Firefox_profile_on_Windows Anyone not understand what I've written here today? Communication and being understood is what it's all about...and that is why I write the way I do. :) --Frank Lion 16:32, 16 June 2007 (UTC)

Articles such as creating a profile easily map to step by step instructions with lots of screen shots. They're not the issue. They're the type of stuff I'd hope that Mozilla eventually provides as part of the end-user documentation, the only reason we're documenting it is the end-user documentation is scattered , out of date, and doesn't cover many common tasks. Your wisecrack about labeling "The following stuff is of geek interest only" makes me suspect you haven't written many troubleshooting articles. Tanstaafl 23:32, 16 June 2007 (UTC)

Tanstaafl, there is a thread on MozillaZine that is asking for opinions on this. That is my opinion. You trying to deliberately miss the point here, hmm? The format that I outlined above can apply and does apply to every single article here, there are none that cannot be laid out like that. How do I know? Well, despite your - makes me suspect you haven't written many troubleshooting articles - defensive dig at me, you should perhaps know that I have been writing/editing/condensing complex technical material for many years now. Duh, it is part of what I do for a living. So you suspected wrong, didn't you? That so-called 'wisecrack' is used and understood all over the Net.

Now, you guys want to get all defensive and shirty with the next guy who you have asked for their opinion? Fine, but don't be surprised if you end up having to sort out this 'KB', all by yourselves. --Frank Lion 01:27, 17 June 2007 (UTC)

I don't think Tanstaafl was trying to say you shouldn't have given your opinion, I think he was trying to debate on the issues you raised.--Np 20:58, 19 June 2007 (UTC)

The guideline to limit choice is based on the belief that providing users choice where the consequences are the same or choice where the options may not be understood can be confusing to users. This guideline makes the editors the "decider" of which option is better for the user. An alternate view is that we should provide choice to the user as to which option to pick, because the user is the best one to decide which option is easiest to them. Providing users the option will also give them something to fall back on should they fail at the initially chosen option.

Draft

These are not hard and fast rules - they may be ignored if there's a good reason to - but in the absence of any good reason not to follow them, they should be followed. These guidelines apply to support articles (directing people how to fix a problem) and how-to articles that support articles use (such as Profile folder).

Articles should be written appropriately for the audience. This means that an article for a situation that could happen to a novice user or an article that describes steps that a novice user might want to take should be written at the level of a novice user. For example, a novice user will not likely know how to "set extensions.checkCompatibility to false" without us providing step-by-step instructions, whether directly in the article or via a link to another article (example). Conversely, articles that are written for situations that would only happen to more advanced users can assume that these users would know how to set preferences and do other somewhat advanced things (example).
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. Therefore, both options should be included.
- To access the Profile Manager in Firefox on Windows, users can run the command firefox.exe -profilemanager or firefox.exe -P. The result is the same in both cases, and neither has an advantage over the other. Choose one to present and drop the other.
In an article intended to be understood by novice users, if the only way to perform a task is technically involved, it should be marked as "Technical" or "Advanced" in the section header (example).
Where an article has other articles similar enough to it that users might reasonably choose the incorrect article, provide links in the article's intro that contrast the current article to the other articles (example).
Keep technical explanations in articles intended for novice users to a minimum. If you feel it should be included, put it in a section called "Technical overview" or similar.

Responses to draft

Regarding np's unsigned draft proposal. Is this a draft for a new document or a proposal to add a new section to a current document? Tanstaafl already said above that he is against a new document, and so am I. I would suggest adding portions of the above draft (except for #2 which I said earlier should be scrapped) to either the Rules article (and then rename it "Guidelines") or to the In-house style article, for labeling section headers as " - Technical" or " - Advanced users" (no parentheses, please ... eliminating parentheses and other punctuation or symbols from article names and section titles was hashed out before, since it could cause link problems, and is now included in Article naming conventions and also mentioned in In-house style). If this "Draft" is intended as a draft article, assuming that others agree that it's needed, where do we edit it or add our comments? You removed my comment from the "Draft" section and placed it under one of my other comments above. I suggested earlier that you create a separate article (maybe on your user page or elsewhere, if it is clearly marked as "Draft" and uncategorized) so that we all (or maybe just you and another SysOp or interested person) could edit and discuss it. Alice 13:06, 15 June 2007 (UTC)

This is a draft for new guidelines. I don't have any particular place in mind for it, but your idea to put it in Rules and renaming it Guidelines sounds good. I was going to set up a section for comments, but you've done it, so here's good. I just didn't want comments in the "Draft" section lest people think it's part of the draft.--Np 16:02, 15 June 2007 (UTC)

What about editing the draft in the "Draft" section? For example, should I go ahead and edit #2? Alice 16:50, 15 June 2007 (UTC)

No, I'd rather have an unchanging draft for people to comment on and then create another draft based on everyone's feedback. I know your objections, and unless there's overwhelming support among everyone else for #2, it's not going in as written.--Np 16:54, 15 June 2007 (UTC)

All those "draft" guidelines sound quite reasonable to me, including that #2. What are the arguments against them, that I may try to rebut them? — Tony 03:48, 16 June 2007 (UTC)

You can read through what Alice and AnotherGuest posted above. Search on "This seems to" and "I don't like the idea" to find the respective starts of their arguments.--Np 04:39, 16 June 2007 (UTC)

I don't have an issue with the latest draft other than I don't think it should go to that level of detail in a guidelines document, I think #3, #4, and #5 belong in the style guide. However, as long as we don't create a new document, fine.

AnotherGuest hasn't commented yet on the latest draft, but perhaps your rewording also resolved his issue about losing overviews (especially when troubleshooting). It resolved my issue about dumbing down technical articles, which I don't think is that different.

Alice, did getting rid of the text in #2 about the relative order of what to use in setting a preference help at all in reducing the micromanagement? Could you suggest a alternative version of #2 that would suggest some good practices for less experienced editors without it turning into micromanagement? If you can't, could you suggest in general how we should suggest good practices? Tanstaafl 11:07, 16 June 2007 (UTC)

No, specifying that level of detail in #2 is micromanagement, even without those specific examples. I would eliminate #2, since it's really a matter of opinion whether "easier" "quicker" or even "most likely" should come first or if providing users with choices is good or bad. For example, someone (not me) might make the case for replacing #2 with the following: Alice 14:32, 16 June 2007 (UTC)

2. Be aware that multiple ways of solving a problem or performing the same task may exist, and one method may appear to you as easier, quicker, or more likely to work, but that might not be the case for many users, depending upon factors such as skill level, operating system, or the specific Mozilla application. Although it may not be obvious that providing users with a choice of methods has any advantages, the user is the best one to make that choice. Providing users with options will also give them something to fall back on should the presented option fail. An example would be instructions to use Safe Mode in the event of a Corrupt localstore.rdf file when deleting or renaming the file will also work. You may not realize that file deletion might be easier for a Mac user. Renaming the file might be the best option of all, since it allows the user to reverse the changes. Regarding the presentation of instructions that are not technically accurate but which might appear easier, for example, using "-P" instead of "-profilemanager" for starting the Profile Manager since it is easier on Windows, it may be presented as a secondary option but should not replace "-ProfileManager" (see Command line arguments); additionally, a Linux or Mac user who mistakenly uses the lower case "-p" will find that it does not work ref.

Np's text supports the idea of multiple ways to do something but because it focuses on meeting the needs of most users (the whole idea behind the KB is too technical) it makes the assumption that the author can figure out the best way to do something, and subtly discourages presenting multiple methods because it says to document them only "if they have some sort of advantage over the easiest way." This assumes you understand the needs of everybody, including users on different operating systems. Alice's text doesn't deal with presenting the simplest answer for most people first, its focused on making certain that the needs of all users (not just the most common) are met, and providing alternatives in case the recommended solution is a poor choice.

I don't seem them as fundamentally incompatible. It seems the problem is how to modify Np's text to support the idea of presenting multiple ways to do something in order to make certain the needs of all users are addressed and to offer alternatives, without losing the emphasis on recommending the easiest way for most users, and only presenting another way to do something if it offers an advantage.

I don't see that as meaning you should document every way to do something, there still has to be a reason why its worth documenting. For example, in Finding_the_profile_folder_on_Windows the "Windows 2000 and later" section has three different ways to go to %APPDATA% under Vista. In this case who cares if one is more natural, this is not something you do often. Telling Vista users one way (that will always work) to go to %APPDATA% and then navigate to their profile, and also being told how to find the profile by specifying what folder to open is sufficient. Tanstaafl 23:03, 17 June 2007 (UTC)

... the "Windows 2000 and later" section has three different ways to go to %APPDATA% under Vista. I won't go into excruciating detail but I've since removed the second method ("Start Search" box) from the Finding_the_profile_folder_on_Windows article and instead I just left a reference link which gives the user more information. My point is that I don't think that a rule or guideline should govern if, when, or in what order articles can present multiple methods for performing the same task. If you want a "rule", just say that articles should strive to present information clearly and concisely without sacrificing accuracy and that references should be included so that a user can get more information, especially if the editor decides not to include detail in the article itself. This isn't just a cookbook where you can follow someones step by step recipe. It's also "knowledge base", even for users looking for support. Alice 01:44, 18 June 2007 (UTC)

The problem with your rule is that its all goal and no practical advice. Why have you been objecting to #2 while having no problem with "These are not hard and fast rules - they may be ignored if there's a good reason to - but in the absence of any good reason not to follow them, they should be followed."? If you're worried about the guidelines turning into a cookbook why not suggest getting rid of that sentence and rewording #2 to be something like (plus the existing examples):

"Where multiple ways of doing something exist, present the easiest first. Don't describe another way just because it exists - add it if offers some advantage, a fallback is needed, or it might be more appropriate for a different type of user (such as a more skilled user or one using a different operating system). Tanstaafl 03:18, 18 June 2007 (UTC)

I'm objecting to 1) micromanagement of article content, as I've stated above, 2) using one person's opinion ("choice = confusion") over another ("choice is a good thing") to create a rule and 3) developing rules using "quicker" or "easier" as criteria for including or ordering content when the editors are not experts in all operating systems or all versions of Mozilla applications. I see that I am butting my head against a brick wall here so I'll stop commenting on this. I won't be around too much for the next couple of months, anyway (taking a summer break). Alice 09:46, 18 June 2007 (UTC)

I don't feel that #2 or Tanstaafl's alternate #2 are micromanagement - they both seem to be fairly broad guidelines. If it were to say in what format the options would be presented, or specifically which options are acceptable to present, then I could see it as micromanagement, but currently it's much more broad than many of the existing rules and guidelines we have.

The second argument (using my opinion over Alice's) is bunk - there are six people who bothered to post here, with six different opinions. It's not likely that anyone will get exactly what they had in mind, but we're trying to address everyone's concerns. That's why this conversation is happening.

I don't see how the third argument applies - how does presenting more options and not ordering them overcome the fact that we're not experts on everything? We don't have perfect information, even on Mozilla-related things, but that hasn't stopped us before on making judgment calls on what things are better, easier, more useful, etc.

I understand the argument that choice is a good thing; I think it's just a matter of disagreement of where to draw the line between usefulness and uselessness. There will always be more choices than what we provide because some choices are just really useless. "Can't run Windows Media on Mac? Buy a PC with Windows on it." That's stupid advice to give, but it's an option. I wrote #2 to where I believe the line to be. Alice, can you propose an alternate guideline as to where the line should be?--Np 20:53, 19 June 2007 (UTC)

My last comment on this topic, really. The current draft states, 2. 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. then what follows are two examples, taken from existing articles. The examples constitute micromanagement since it stifles anyone from changing those specific articles, since they exist in the rules. Without specific examples, the rule is so vague as to be useless. Your second example isn't even what's in the current Profile Manager article. Do you plan on changing that article before or after implementing this rule? Even if you didn't include any examples, I would object to #2 because it presupposes that we want to limit presenting multiple methods for the same task, in cases where one has no obvious advantage over another. That's where not being experts comes in, since Windows XP users might not see any advantage in an alternate method presented that might help Vista users. How whould you change Profile folder - SeaMonkey as written, to meet your proposed guidelines? Would you eliminate one of the Vista methods for opening %Appdata%? If so, which one... the "Windows key+R" method or the "Start-> Start Search" method? Which would you choose if you didn't know that both methods don't have the same outcome, as I quoted Daifne mentioning, here? What if only presenting a single choice (Start Search method) resulted in the confusion, since Vista users might mistake that for using the Search tool instead of the "Start Search" box? More importantly, how is providing Vista users with a choice making the article too technical? Alice 22:03, 19 June 2007 (UTC)

I'd be fine with taking out the examples. They weren't present in the first draft, but tanstaafl wanted some specifics. I think you're slightly confused as to what the guidelines are trying to say. It's not "only present one option unless you know that there are other good ones", it's "don't present options you know aren't good". In other words, don't remove things unless you know that the option is useless. I don't know Vista, so I wouldn't advocate removing a specific option, but I would encourage someone to do so if they knew what each one meant. On the other hand, I know that -P and -profilemanager are the same on Windows and would only present one. Perhaps this should be made more clear..

Choices don't necessarily make an article too technical, but they make an article more confusing and complex. The choices themselves are often too technical, though.--Np 01:57, 20 June 2007 (UTC)

OK, here's my very last comment (I keep saying that, sorry, but I'm getting very tired of it all). Just say that including multiple methods for doing something, when one method has no advantage over another and results in the same outcome, should be avoided if it makes the article too technical, confusing, or complex. If you agree to that single "rule" for #2, including the underlined portion, then I can live with it. Alice 12:25, 20 June 2007 (UTC)

I don't know... That seems to change the meaning too much for me, from "Avoid presenting options because they make things complicated" to "Avoid presenting options if they make things complicated". How about something like "Avoid presenting options if there's no reason to as they sometimes make things complicated"?--Np 16:25, 26 June 2007 (UTC)

I think we have consensus for everything except #2. How about we accept them all and continue discussions on #2?--Np 20:53, 19 June 2007 (UTC)

The "Intro" also needs revising since it is overly vague about what constitures "support" articles: These guidelines apply to support articles (directing people how to fix a problem) and how-to articles that support articles use (such as Profile folder). I would instead say something to the effect that it applies to all articles in the "Issues" categories, forgetting the "How to" articles for the moment until you can come up with a "How to" category or a template for identifying such supplemental articles. We could even kill two birds with one stone and include a request for feedback in a "How to article" template with a link to the forum sticky you created for KB feedback (or elsewhere). Alice 22:03, 19 June 2007 (UTC)

I don't really want to base it on what category the article's in, because our categorization might change in the future, people might change the categorization so that the guideline doesn't apply, and it misses the how-to articles. In what way is the current intro vague? Do you have specific articles in mind that you're not sure the guideline would apply to?--Np 01:57, 20 June 2007 (UTC)

I also don't like specifying categories. Is it sufficient to say it applies to issue , support and how-to articles but not reference articles without defining the terminology? I like Np's suggestion of going with what portions of the draft we have consensus on. Tanstaafl 07:50, 20 June 2007 (UTC)

Fine, I'll go along with saying that these guidelines apply to issues, support and "how-to" articles, if you both prefer to keep it vague (for now, at least) as to what constitutes those types of articles. Alice 12:25, 20 June 2007 (UTC)

I've added everything except #2 to Rules and guidelines (which is Rules renamed). Can someone check it over and make sure I didn't mess anything up?--Np 16:25, 26 June 2007 (UTC)

Looks fine. Tanstaafl 18:47, 26 June 2007 (UTC)

Promoting feedback on articles

Posted above by Alice: "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." I think this is a good idea. I would really like some sort of feedback mechanism where users could provide comments directly on the page, which would then be visible to editors somewhere. Since our customization options are pretty limited, we likely won't get that good of a system. One thing we could do is change the system messages so that some common messages include links a thread in the forum or the article talk page. One candidate is the copyright text at the bottom.--Np 19:41, 14 June 2007 (UTC)

You mean the text "MozillaZine and the MozillaZine Logo Copyright © 1998-2006 MozillaZine. All Rights Reserved"? Fine, if MozillaZine admin agrees that we don't legally need to include that information. We could also modify the text in the MozillaZine_Knowledge_Base:About link since that article already talks about feedback and includes a link to the Site Discussion forum. Alice 13:06, 15 June 2007 (UTC)

I didn't mean remove it, I meant add text before it. MozillaZine_Knowledge_Base:About already has what I'm looking for, but what I really want to have one button users can click on and be brought to somewhere they can give feedback.--Np 16:20, 15 June 2007 (UTC)

one button users can click on and be brought to somewhere they can give feedback You could add to the "copyright" text like you suggested, then, to include a link to the sticky you've already set up for KB feedback in the Site Discussion forum.... can you increase the size of the text or add color to make it stand out? Another option might be to add a link in the navigation area to the right, if possible, maybe directly above or below the "submit news" link and title it "submit feedback on this article". You could then link to the Site Discussion forum sticky topic or elsewhere. Alice 17:05, 15 June 2007 (UTC)

I think I can play around with the formatting. I don't think I can change the stuff on the right, though. Does the Site Discussion forum require you to be logged in to post?--Np 17:12, 15 June 2007 (UTC)

Anonymous/guest posting is allowed, even though it's not specifically stated in the Site Discussion forum description. Alice 17:47, 15 June 2007 (UTC)

This sounds interesting, but frequently I never see that line since I don't scroll the page down that far. The only person who has ever posted in the KB thread is Np. I don't think we should start mucking with the copyright line when its not clear that it will do much good.

Adding a link near "submit news" would probably get more attention. However, if we're going to ask Kerz for changes why not be more ambitious? The box of links that starts with submit news is pretty useless, especially if you're not at the news or forum main page. We might try interesting Kerz in replacing that box with a different one when somebody is in the knowledge base. It could have links just to the forums, KB main page, and the KB feedback thread. And real buttons, if that makes sense. Tanstaafl 20:55, 15 June 2007 (UTC)

Yeah, if kerz is willing to make code changes, that'd be better. I'm not sure it'll happen though.--Np 21:17, 15 June 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:

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.

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:

Comments are being requested to either resolve a deadlocked disagreement or to help develop a consensus for improving the quality of this article. Please add your comments to the discussion page. Once all issues are resolved and the article has been revised you may remove this message.

(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)

I've gone ahead and updated Rules/Templates. Is everything all decided on this for now?--Np 19:53, 14 June 2007 (UTC)

Consolidate show hidden files and directories information

We have numerous profile-centric articles that contain instructions for one or more operating systems on how to display hidden files. At least two of them also have a figure for the windows explorer folder options window.

This is critical information for less computer literate users, but many users already know how to do that. For those who already know how to do that it just clutters up the article and makes it harder to read. Also, the existing text isn't always consistent.

We don't tell Linux or OSX users how to show hidden files and directories. None of the articles mention how to show hidden files within Thunderbird (when attaching files for example) under Linux or OSX, or about how to use ui.allow_platform_file_picker to enable the built-in file picker (which is faster and has a show hidden files and directories checkbox). While its obviously more important to provide the information needed for Windows users, I don't see why we should ignore non-Windows users, especially when there was enough demand for a less than four month old Moving_from_Windows_to_Linux article to be accessed 7,226 times.

What do you think about creating a "Displaying hidden files and directories" article, and linking to that instead? We could keep Finding_the_profile_folder_on_Windows as it is, as fallback.

If this proposal seems reasonable I'll make a mockup of the proposed article on my user page that people could critique beforehand. Tanstaafl 16:48, 21 February 2008 (UTC)

I like the idea. It would allow keeping all the relevant info about hidden F&D in a single article, which would help keep it complete (no need to make the same text updates in umpteen different locations) and also would unclutter other pages for users who already know how to make hidden F&D visible. -- Tony 17:41, 21 February 2008 (UTC)

I'm not sure that Mac OS X has hidden files and folders but in any case, I have no objections to combining Windows and Linux instructions in a new article. The name should be simpler, that easily fits in for linking, such as "Show hidden files and folders" with sections for each OS. Minor point I guess but since hidden files and folders of interest to Mozilla users are not limited to the profile folder any longer (e.g. "updates.xml" and "cache" folder", both now under Local Settings on Windows XP) you might want to think of another category besides Profiles (General concepts?). Alice 19:51, 21 February 2008 (UTC)

Please see the draft at User:Tanstaafl. If its in the right ballpark I'll create the article and we can discuss any changes it needs in its talk page. Tanstaafl

I suppose it's "in the right ballpark" as far as Windows and Linux but I don't know about the Mac section. As far as why viewing hidden files might be useful to Mozilla users, the article intro says that "You may need to make them visible in order to browse your [[profile folder | profile] or include certain files as an attachment." The profile folder isn't hidden on Mac OS as far as I know, so you should insert (Windows or Linux) after profile. I would also add "other hidden locations" after "profile". Uninstalling Firefox#On Windows links to Finding the profile folder on Windows because you need to remove files and folders in the hidden "Local Settings" (2000/XP) or "AppData\Local" (Vista) folders, which are outside of the profile folder path. Besides wanting to unhide a hidden file (a system file? One you hid yourself?) to send as an attachment, do you have another example why a Mac user might need to unhide a file? I don't know which Mac OS files or folders, if any, are hidden by default since I only have limited Mac experience. Alice 22:08, 24 February 2008 (UTC)

Also, the "File Picker" section is confusing to me, since it seems to be mainly about Linux, so should be under the Linux section. That section doesn't seem to apply to Mac OS and, on Windows, the file picker follows the View -> hidden files and folders" selection so doesn't need a separate section. Alice 22:08, 24 February 2008 (UTC)

I don't know OSX either (never owned a Mac), and the Windows and Linux sections seem all right to me too. -- Tony 22:31, 24 February 2008 (UTC)

Actually, the file picker section is under the Linux section. I'll remove the section header since its causing confusion and you don't think its needed. I'll tweak the opening paragraph. I know needing to unhide a file is a common problem with OSX but agree it doesn't appear the default profile location is hidden. However, I don't think we should omit a operating system just because the default profile location is not hidden. User needs can be hard to predict, just the other day a windows user had a problem with their signature due to a file being hidden. I found a recent thread where one OSX user had to deal with hidden files for Thunderbird and another for Firefox and Camino due to FileVault (a system that protects files on a Macintosh computer). I assume if I knew more about OSX I might find some other OSX threads dealing with hidden files. Tanstaafl 04:20, 25 February 2008 (UTC)

Thanks for the information. I knew nothing about FileVault or that it can hide the profile folder if it is enabled. I would work that into the Mac section of the article somehow. According to this apple.com article FileVault is included in Mac OS X 10.3 or later and my limited Mac experience is with 10.2. Alice 16:40, 25 February 2008 (UTC) P.S. Since you have created the article I'm copying the comments (starting from your "If its in the right ballpark" comment) to Talk:Show hidden files and folders. Alice 17:02, 25 February 2008 (UTC)

Content of front page

I think that the new content structure isn't a very good one. It's somewhat hard to find stuff. Even when I know that an article exists! Perhaps a topdown+bottomup approach would work? I mean the first link (of the currently 2 links under all products) could be a link to the product's categories and the second link could be to alphabetical list of all the product related articles? FatJohn 03:15, 19 April 2006 (UTC)

Firstly, could you explain what you mean by an alphabetical list of all the product related articles? Do you mean (e.g.) a list of every single article in the Firefox category and its subcategories? If so, I don't think MediaWiki can produce such a thing, and it would be undesirable to manually maintain such a large list. (Currently, the category pages provide an alphabetical list of all articles at that level in the category but don't list articles in subcategories; personally I find this behaviour annoying. Also, we manually maintain a FAQ page for each product which is not linked to from the front page but which is linked to from the category page.

Secondly, could you give an example of when it was hard to find a specific article? I tried to lead the guy who commented in the #Overview pages (below) through such an example, but he never really gave a detailed explanation. What we really need is a walkthrough, i.e. a kind of "I wanted to do this, I expected to be able to click here then here, but in fact I was made to click here and search here..." explanation. This is the only way that we have of evaluating how the current setup works. Cheers! --Mozcerize 10:10, 20 April 2006 (UTC)

Hi there! 1) Yes, that's what I meant, the big list. I agree it's annoying. 2) Say for example my article about uninstalling Firefox. I go to main page and as I think that uninstalling shouldn't be an issue, then it's probably under all firefox articles There I'd expect to find the article under U in either category, articles or subcategories. Personally I think that these categories and subcategories are a little confusing here, since it's not like there's 100s or articles under them(?) Just makes things more complex to me. (Actually the article seems to be located under Installation and update (Firefox) category. Stricly speaking it's really neither) Do you understand what I meant with the updown, downup approach? Does it make sense to you? (any and all of you) FatJohn 22:08, 24 April 2006 (UTC)

Hi! Thanks for the specific example. However, I don't think that it shows the category system to be (inherently) confusing. To me, it just shows that articles are not ideally categorized at the moment. For example, either the existing category could be called "Installation, update and uninstallation" (which seems a bit long) or we could introduce a new category called "Uninstallation". I'd prefer the latter. There haven't been many changes to the category tree recently, but there's no reason why changes can't be made.

Your suggestion for top-down / bottom-up alternatives makes perfect sense, but I don't think think that there are just two alternatives here. The main methods of article discovery in the KB at the moment are: Category navigation; List of issues; Firefox FAQs; Search. I would like "complete alphabetical list" to be available too, but seeing as it can't be generated automatically I'd rather not have it at all than have a flawed manual list. How do you regard Firefox FAQs? Do you think it's a useful idea? Is it too long or too short? --Mozcerize 12:41, 29 April 2006 (UTC)

Howdy! I think that the FAQ is excellent. And since this is the KB, it can only be too short. :) It's looking really good imho. --FatJohn 22:53, 19 June 2006 (UTC)

It really is too bad the alphabetical list cannot be generated automatically, because it's really needed. I'm not at all sure all articles can even be reached by the methods of discovery that were listed. Some of them are certainly hard to find. Is it possible that some articles don't have category listings?

An alphabetical list could be generated by adding each article to under the category "Alphabetical list of Firefox articles". There must be a way of actually finding all the articles, isn't there? (I don't think I know how.)

FAQ page is good, and I think a link should be right on this page. *Issues with Firefox; *FAQ; *Firefox articles arranged by subject; and maybe *Firefox articles arranged alphabetically.--AnotherGuest.

This page is OK, but organization is rotten one level down

Just click down one level lower. Try, for example, "All Firefox articles, arranged by subject". Unfortunately, it doesn't show all Firefox articles and they aren't arranged by subject! I'm not even sure you can reach all articles from there.

There are other problems too. Take, as an example, Category:Firefox. The whole organization structure is bloody awful. First, where do you start? With "Articles in Category Firefox", or with "Subcategories"? The titles of those two sections are confusing, and you're forked before you even start. Why are there almost as many categories (17) as articles (24), and what do the articles have to do with the categories have to do with the articles? (answer: probably nothing, but some of the titles could accidentally below in one or more categories) The heirarchy is fractured, and to make it worse, the titles are just a random sampling of subjects, with many gaps and omissions. And just what does the title "Category:Firefox" mean anyway?

Automatic sorting into categories might work if:

Everything were sorted neatly into proper subject headings (and not too many of them)
If you must have single articles that don't fit into categories, why are there so many of them?
If you must have single articles that don't fit into categories (and I don't see why this is necessary), at least differentiate somehow between single articles and subheadings.
Do away with peculiar titles such as "Category:Firefox". Use English-language titles, not Wikipedia-speak. Remember, you aren't writing this for geek editors, you're writing it for real users.

It might work, but it needs a lot of organization that isn't there. As it is, I have to agree, it really is bloody awful, it's ridiculuously hard to find anything. Remember, Granny has to start here when things go wrong.--AnotherGuest.

Essentially, you're saying "make sure everything is in a category" which is fine and dandy. Where do you suggest the current entries be put? I don't think "Category:Firefox" is all that confusing. It's only missing a space.--Np 02:33, 16 August 2006 (UTC)

Yes, I think that's most of the problem. Specific suggestions moved to Category:Firefox

No, I don't know what "Category:Firefox" means. I can sort of imagine it if I think like a database or a machine. How about "Firefox articles arranged by subject"? Maybe each of those "Category:this" and "Category:that" titles need to be replaced by a hand-written title.--AnotherGuest. 16 Aug. 06

For discussion about categories, please refer to the long discussion at Talk:Rules/Categories. I really do understand that the entry to the category system is far from ideal, but I'm getting a bit tired of defending this corner now, and so I ask just two things from detractors of the category system. Firstly, please know that before categories were devised (after detailed discussion) it was completely impossible to find anything on this KB. Now it is only fairly difficult to find things, and this is not a fault of the category system per se but rather because of the following things:

A lot of articles are uncategorized. I make occassional requests for people to categorize articles carefully, but a lot of articles don't fit well into the existing categories and are dumped in the top level (eg. Category:Firefox). However, if you can put such articles into a more appropriate subcategory then please do...we need iterative effort here!
The category names are not perfect. Please don't moan about this unless you are prepared to suggest better alternatives or supplements. (I challenge you to find a way of dividing up the vast variety of Firefox articles on this KB into a smaller number of subcategories while still making them meaningful. Originally I proposed having subsubcategories to solve this problem, but it was unpopular due to the number of steps involved in arriving at an article, and I came to agree with that as well.) The subcategory titles do indeed seem a bit random, but please explain what you would prefer to have instead! It is a non-trivial task to create a workable hierarchy.
MediaWiki is crap. That's all there is to it. We can't change the name "Category:Firefox". (Else we would have done; I would have thought that this were obvious.) We can't change the wording "Articles in Category:Firefox" else we would have done: after all, it does not contain all articles in all subcategories but only those articles which do not sit inside some subcategory (hence the apparent randomness of the articles listed; they are the stray dogs!). I have mentioned this irritating wording elsewhere, probably on the talk page for that category or on the categories talk page. I think that I even suggested that we made this clear in the blurb on the Category:Firefox page. However, all Firefox articles can certainly be navigated to via the top level category (contrary to the claim above). It is just not ideally explained. (And as for "organised by subject", is it not clear that the subcategories are the subjects?)

The second thing that I ask is that people read all of Rules/Categories and Talk:Rules/Categories if they want to understand the rationale, advantages and shortcomings of the categories system before proposing major changes. A lot of time and effort was spent on developing and implementing the idea; it was not just some random, off-the-cuff idea. I am happy to have the categories system criticized...but not without some understanding shown for the limitations of the wiki and the difficulty of creating an effective system. Despite the large number of complaints I hear about the the system, I have yet to hear many arguments that have not already been pondered in some detail in the talk pages that I've mentioned. --Mozcerize 16:04, 20 August 2006 (UTC)

Right. Now that I understand more about how it is put together and where the relevant discussion pages are, there will be less need to rant and rave. It helps also to see that there are rational beings behind it, and to see which features are not under human control. You'll notice that I have been banging away at the Firefox categories but have been cautious about striking just yet. It's a tossup between working in the Category:Firefox discussion or the Rules/Categories discussion.

Ok. I'm away in France and Spain at the moment so can't contribute much to discussions at the moment. Good luck with the category work; the discussion on Talk:Rules/Categories and Category talk:Firefox has been interesting. --Mozcerize 14:19, 25 August 2006 (UTC)

As for the Wiki titles, is is possible to add a human-readable title? Is it also possible to suppress the computer-generated title? If not, we'll just work around it. Thanks for all your efforts.--AnotherGuest. 21 Aug 06

Alas I don't think this is possible, but I don't know much about the inner workings of MediaWiki. You should probably turn to Kerz for this, as I think he's the only one who can make changes to the wiki software. --Mozcerize 14:19, 25 August 2006 (UTC)

I think we can make do by adding our own titles and other info. --AnotherGuest. 25 Aug 06

"And as for 'organised by subject', is it not clear that the subcategories are the subjects?" No, I don't think it was clear, but I can't look at this with fresh (and bewildered) eyes anymore. --AnotherGuest. 21 Aug 06 (later)

Also see discussion below: Overview pages.

Overview pages

As a new user to this site, but long term user of Firefox, it strikes me that it is difficult to find information. The first two links are just lists of categories, the next is the Firefox support page (can't edit that) and the final link is a more comprehensive overview page that gives an indication on where to go for the relevant information I am looking for. However, these are just links to external (mostly private?, but thanks all the same!) sites. Anyone fancy a more structured overview page, with more text explaining why you would follow a link? Joe1011010 22:46, 1 January 2006 (UTC)

Thanks for the feedback; it is very welcome. It would be really useful if you could tell us precisely what information you were looking for, the route you took to try to locate it, any difficulties you experienced while following that route, and any alternative suggestions you have that would allow users to find this information more easily. Did the list of categories help you to narrow your search, or did they hinder it? --Mozcerize 10:31, 2 January 2006 (UTC)

I think the biggest problem is not knowing what to look for. Try this suggestion for size User:Joe1011010/temp1. Joe1011010 20:43, 2 January 2006 (UTC)

Without a specific example of the information which you are trying to find, it is hard to evaluate the ways in which the current approach succeeds or fails. The page you have created seems a bit like a partner to the Getting started with Thunderbird page. Such a page might well be a good idea. But don't forget that there's no point in the Knowledge Base trying to replace the official Mozilla Help pages at http://www.mozilla.org/support/firefox/; those offsite pages should be the first port of call for anyone who needs to be told what Firefox is, where to obtain themes and extensions, etc.

Specifics about your page: it seems a little odd to assume the user doesn't know what Firefox is in one sentence and then be telling them to use about:config in another. (Actually, users interested in manual configuration should be directed to Editing configuration rather than about:config.) Before you direct people to the forums, it would be better to encourage people to use the Knowledge Base for answers for specific questions (where they do know what they're trying to find). Is this what your implied link was meant for? --Mozcerize 22:37, 2 January 2006 (UTC)

Several problems with the current approach, given that any skill level from basic 'I clicked on the link and installed Firefox - What now?' to 'I know everything there is to know about all programming technologies and languages' could be using this site and the official Mozilla Help pages and the Forums.... How do users know how skilled they need to be to try any of the activities given here?... I tried to find an answer to installing extensions globally, see http://forums.mozillazine.org/viewtopic.php?t=360439&highlight= but found the official information unclear, and the Forum a bit unspecific.... I cannot change the official information, although I did email the webmaster offering to submit more clear information before finding this site.... A search here for 'Global Extensions' does not show a clear enough answer. The problem with a search based approach is being able to put the 'correct' words in the search box to find the answer.... I have not yet installed Thunderbird and I like the 'Getting started...' page, although I see it is not linked directly from the main page.... My page is a bit light on specifics as I wrote it quickly as a suggested way of simplifying navigation, and as a way of showing that Official Pages, Knowledge Base and Forums are integrated (how many Forum pages reference the Knowledge Base?).... I hope this does not sound too negative - I don't mean it to be. Joe1011010 01:07, 3 January 2006 (UTC)

You don't sound too negative! This is a fruitful discussion. It sounds like your suggested page would be best presented as a "Where to find support" article. Although at heart it would be a copy of http://www.mozilla.org/support/firefox/, we could indeed explain how the different sources of support are related, and we could emphasise that that the official support site that I just mentioned should be used prior to using the KB. (Indeed, that page does state that the KB is "for more advanced questions".)

As for the level of knowledge required to try the KB activities, the current KB articles seem pretty gentle in the way they introduce new ideas such as application preferences, and they always include very strong warnings when an activity could potentially break a profile or the whole app. The "where to find support" article could make this clear.

As for the info about global extensions that you were seeking, I would expect that people would visit "All Firefox articles, arranged by subject" which takes them to the Firefox Category, and then visit the third subcategory in the list, Extensions (Firefox), and take a look at the articles listed. Sadly none of the titles have anything to do with installing extensions, let alone global installation—hence the info is not on the KB. :-( Incidentally, info about extension installation would make a great article; feel free to write it! :-P ) The search you did failed, yet the search term you used seems perfect to me, and would have worked had the info been available. As a new user to the KB, your thoughts on whether this was actually how you saw the mechanism working are very gratefully received.

--Mozcerize 11:52, 4 January 2006 (UTC)

Use of categories

Right now, the MediaWiki:Categories page is protected and includes the exciting text "Categories" and only that. Alternatively, Special:Categories includes a grand total of 6 different categories, none of which include that categories on the main page. Superm401 12:30, 5 Feb 2005 (PST). As an example of what we could have, see Wikipedia:Browse by category. Note, I realize that this isn't aspiring to be Wikipedia, and it shouldn't be, but this could make the system much more organized. Superm401 12:30, 5 Feb 2005 (PST)

This looks promising. Any way to get categories to "embed" themselves into the front page? I want users to have a working table of contents with links to various places the moment they arrive at the front page. There's also the issue of whether or not a sysop can protect a category from inclusion, so that the sysop still has a tight rein on whether or not something appears to a user the first time he arrives here (like the protection we have on the front page right now to prevent links to any articles/links from being added).

The front page will probably have to be edited manually to point to categories; please discuss this on Talk:Rules and Talk:Rules/Categories. --asqueella

To me, the Search is (and should be) the strongest point in the whole 'Category' filing; and to me, the Category filing is a little confusing. To a common end user (which I believe could be considered a newbie), Google and a fast, strong search is what they would be used to. As you point out, if I were to arrive at a specific article and didn't know about the Category line at the bottom, I wouldn't know how to browse the Category's. Currently, the Main Page link takes you to the Main Page, but that has nothing to do with Categories, which is fine, for now. Although I don't believe the Categories page should be the Welcome page for new users. Just my two cents. I would like to see the Search button go higher in the page, right under the Main Page link. --Marc 09:22, 22 October 2005 (PDT)

Thanks for your thoughts on this! I agree entirely that a decent search interface should be a priority, and it should be displayed far more prominantly. --Mozcerize 10:09, 22 October 2005 (PDT)

Tentative try. --shadytrees

Some sections have been moved to Knowledge Base changes

Add-ons misspelled

Addons => Add-ons --American Finn 22:08, 24 September 2006 (UTC)

+1 Cameron 12:57, 1 December 2006 (UTC)

Got it.--Np 16:35, 1 December 2006 (UTC)

Mozilla Add-ons link

"Mozilla Update" is now called "Mozilla Add-ons"

Got it.--Np 16:36, 1 December 2006 (UTC)

Add-ons section needs better KB article links

The section subheading is Extensions, Themes and Plugins. The only linked KB articles are Problematic extensions and Uninstall search plugins, which gives a quite negative impression that add-ons are troublesome, don't you think? General articles like Themes and Installing extensions or category links to Category:Extensions (Firefox) and Category:Plugins would be better. Alice Wyman 23:57, 28 November 2006 (UTC)

Imageshack links

The "Upload file" feature was enabled in the KB last December but the Knowledge Base front page still links to imageshack for images. I think that the front page would be more professional if we used our own images.
I uploaded Wikitb0rn.png , Wikism0yt.png , Wikifx5nm.png and Sunbwiki3ej.png to the KB but a SysOp needs to edit the front page since it is locked. Alice 11:52, 7 June 2007 (UTC)

Done.--Np 21:27, 7 June 2007 (UTC)

Minor changes required on front page

There should be links to Firefox FAQs and Thunderbird : FAQs.

Also, SeaMonkey is miscapitalized as Seamonkey.

Appearance of front page

I'm designing a layout that I think wil be easier for first-time browsers of this site. Please check my Userpage to see what I am doing Stex 07:20, 6 Jul 2005 (PDT)

Note that since the move to categories, there is no longer any distinction between Tips and FAQs. (Tips lists have been removed entirely.) --Mozcerize 11:53, 2 January 2006 (UTC)

Discussion regarding a redesign of the front page was continued on the Knowledge Base changes page. Several designs were considered, including that introduced above. The new design chosen (utilising a table-like layout with small images to accompany each heading) was created by Filipp0s.

I think this new look is excellent! Very professional and pretty. FatJohn 06:13, 22 March 2006 (UTC)

IMAP category

I'd like to add a IMAP category. We're seeing more new IMAP users due to Gmail, its awkward for new IMAP users to find many IMAP-centric articles when they don't have the right vocabulary, and I'd like to write some more IMAP-centric articles. I don't see any need for a corresponding category for POP - its the mainstream. We already have a Calendar , a Newgroups (Thunderbird) and a RSS (Thunderbird) category. Any objections or concerns? Tanstaafl 12:42, 20 November 2007 (UTC)

I looked over Rules/Categories#Creating a new (sub)category for the background and did a KB search on IMAP to make sure there were enough existing articles to justify a new category (there were 7 with "IMAP" in the title). I don't have a problem with a new IMAP category except that it should be named IMAP - Thunderbird (with a dash, not parentheses) if that's the name you were going to use. Since IMAP mail applies to both Thunderbird and SeaMonkey, I would prefer simply naming the category IMAP mail or similar. Alice 19:05, 20 November 2007 (UTC)

I'd intended to simply use "IMAP". Since that doesn't seem to be a problem (its not application specific) I'll go with that. Tanstaafl 15:11, 25 November 2007 (UTC)

I see you created Category:IMAP and placed articles under it but you haven't yet categorized the new category. Unless you had something more specific in mind, I guess it could be categorized under Category:Thunderbird and Category:Mozilla Suite? Alice 21:50, 25 November 2007 (UTC)

Done. Tanstaafl 23:24, 25 November 2007 (UTC)

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)

SUMO use of MozillaZine KB articles

Update: There is a current discussion taking place here concerning how the official Firefox support (SUMO) KB should credit content derived from MozillaZine KB articles. Alice 22:40, 13 January 2008 (UTC)

KB account creation

I've created a mozillaZineKB at gmail dot com account to handle new account requests, sent the password to all SysOps (except for np who has publicly stated he's not interested in handling requests), and updated the login page. We used to average only about one request every two days before, and the login page encourages users (if they have a forum account) to request a knowledge base account using the moderation requests thread in the mozillaZine site discussion forum. Thats practical now that most moderators are also SysOps. However, we probably should come up with some conventions to avoid problems due to multiple people reading a message requesting an account. Its a IMAP account by the way, I figured that would make it easier to monitor. Tanstaafl 20:20, 26 November 2007 (UTC)

Related KB article: Create_a_knowledge_base_account Alice 12:45, 9 December 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)

Removing obsolete information

I notice that some articles, such as Multiple_SMTP_servers_-_Thunderbird have multiple sections for obsolete versions. I suggest we add a rule of thumb that such text should be removed if its for a version thats more than two major releases ago to In-house_style . i.e. since Thunderbird is at 2.0.0.6 keep the text about 1.5 or later but dump the 1.0.x text if it simplifies the article. Tanstaafl 01:18, 13 October 2007 (UTC)

I agree about removing obsolete sections, especially if the "obsolete" part is long and uninteresting. I think though, that e.g. in about:config articles, the lines "Applies to Mozilla since 19980425" or "Applies to Firefox since release 0.9" etc. can stay. -- Tony 02:06, 13 October 2007 (UTC)

Agreed. Tanstaafl 10:37, 14 October 2007 (UTC)

I have no problem with the rule about removing obsolete information but I don't think it belongs in the In-house style article, which mainly covers things like commonly used terms, formatting and punctuation, tables, and other style issues. I think that a rule about removing obsolete information is more about keeping KB articles technically accurate and up-to-date and would fit better in the Rules and guidelines article, which already includes a "Quality" section and "Technical information" subsection. I think that the "Removing obsolete information" paragraph would fit in better there, either as a subsection of "Quality" or as a separate section. Alice 12:32, 11 February 2008 (UTC) P.S. I added a section to Talk:In-house style for discussion. Alice 13:04, 11 February 2008 (UTC)

If we did move it the Quality section doesn't seem appropriate - its own section would be the best bet. We have text about how to make an article more usable in both articles, so I guess its really a question of whether you think it falls in to the guidelines or the look consistent camp. I prefer the current location, but it doesn't really matter. I have no problem with you moving it after waiting a couple of days to see if anybody else has a opinion. Tanstaafl 13:54, 11 February 2008 (UTC)

OK, I'll wait a few days. I'm also copying your reply to Talk:In-house style#Keeping_this_article_about_style with a link to this discussion for the background. Alice 14:15, 11 February 2008 (UTC)

Prep for switch to new web site

We're getting closer to switching to the new web site. Kerz has stated he'll enable automatic account creation when we switch. See this thread for more details. He has created a subforum for the knowledge base, so we won't be limited to just talk pages and this article when discussing some issues. He has offered (in the moderators forum) to move a small number of threads to the new web site if they're identified ahead of time. However, given the recent history of lost accounts and the fact nobody has started to make a list of the threads I suggest we assume the worst, and start migrating information in any referenced threads into the article. It will also give us a chance to make the information more up to date and easier to find/read. After the move we can update any links to dedicated discussion threads for extensions/themes. Does this seem reasonable?

I notice Alice has converted the request for comments template in preparation for the move. Any other changes that we should think about? Tanstaafl 01:19, 11 November 2007 (UTC)

In the "Request for Comments" template, I switched from forum thread link to MozillaZine Site Discussion forum since I assumed that links to the main forums (Firefox, Thunderbird, Site Discussion, etc.) would be redirected to the corresponding new forum. (We also link to the MozillaZine Site Discussion forum at MozillaZine_Knowledge_Base:About#Commenting_on_articles). Once we switch to the new forum, we could link that template and the About page directly to the new Knowledge Base subforum. But, I'm not so worried about that. You said, :I suggest we assume the worst, and start migrating information in any referenced threads into the article. What do you mean by "referenced threads"? We have many, many references to forum threads in KB articles. You don't mean that all those references will be lost, do you? I have an entire web page of useful threads that I reference quite a bit: http://wymette.home.att.net/mozforum.html (I haven't updated it since August 2007, but I do update it from my bookmarks!). Alice 01:40, 11 November 2007 (UTC)

You have two hundred and forty six links on that page, and some of them are for pretty long threads. I have difficulty seeing Kerz move all of them, especially if several other people have long lists that don't overlap that much with yours. Your guess is as good as mine what will actually happen, but nobody has even started to compile a list in the five months since the beta of the new web site was first available, and its called a "grand forums restart" for a reason.

My impression is that there aren't many references to threads in Thunderbird articles, and most users in the Thunderbird forums point to articles rather than old threads. I'm going to start replacing some of the references in the Thunderbird articles as a precaution, but it wouldn't be a disaster if we suddenly lost access to those threads. I'm basically trying to suggest contingency planning for Firefox and SeaMonkey, which are much more vulnerable. Tanstaafl 05:21, 11 November 2007 (UTC)

You have two hundred and forty six links on that page There are probably more, since I've just updated my mozforum page. I don't care if the threads are carried over to the new forums, I just don't want the linked pages to "disappear" altogether (then I'll have to depend on google's cache or the wayback machine to get that content). I really hope that all those threads aren't lost. Besides the KB, other sites link to our forum threads, notably Bugzilla reports. If I can find the time, I'll try to go through some KB articles and see what information in linked forum threads should be incorporated into the KB (some are simply references to justify the information given in the KB, e.g., forum references in the Problematic extensions article). Alice 14:43, 11 November 2007 (UTC)

I'm going to assume that links to forums.mozillazine.org threads in KB articles, Bugzilla, google groups, newsgroups, etc., will not be lost.... that they'll be archived and available for "read-only" access. Maybe you can confirm, but that's how I understand it, based on the following Nov 3 2007 post in the new Site Discussion forum, by "steviex"

It looks like Threads that are reposted here need rewriting to remove any HTML formatting, and replace it with BBCode.... Any links back to the old board should be OK, as I would guess that the archived posts would be viewed with phpBB 2, in the old format.

...Even so, it wouldn't hurt to prepare for the worst and incorporate as much information as possible into KB articles, instead of depending on forum links. I created a new Problems printing web pages article that used to be just a forum link in the Issues with Firefox article, with that in mind. Alice 18:39, 14 November 2007 (UTC)

KB articles to update for the new website

KB articles that tell people to post KB requests or feedback to a specific thread, including Create_a_knowledge_base_account and Special:Userlogin.
KB articles that link to a specific forum, such as MozillaZine Site Discussion, may not be redirected properly and may need updating to the new Site Discussion forum or to the Knowledge Base subforum on the new board.
Rules and guidelines links to forums.mozillazine.org/rules and that page may no longer exist after the move, so we'll either need to update the link or edit the article to summarize those rules.

All articles in the Category:MozillaZine_Knowledge_Base_organization should be reviewed for needed updates. If I find any articles outside of that category I'll post them here. Alice 13:08, 9 December 2007 (UTC)

Use of color

A discussion was started asking for for opinions on using color in KB articles. Please post any comments to Talk:In-house style#Use of color. Alice 22:40, 13 January 2008 (UTC)

Using external sources and references in KB articles

I've moved the discussion about using content from other sources and referencing certain material to Talk:Rules_and_guidelines . Tanstaafl 08:38, 20 January 2008 (UTC)

In-house style: Special formatting

There is a current discussion about whether to change the In-house style guidelines for special formatting for folder and file names and paths. It has been suggested to use italics instead of monospace font for folder/file paths. Also under discussion is whether to add a new guideline covering when and how to format preference names; bold text has been suggested. Please add any comments to the In-house style discussion page under Use of monospace font for path folder and file names and Preference names. Alice 15:11, 8 February 2008 (UTC)

Consolidate show hidden files and directories information

Its been archived after Show_hidden_files_and_folders was created. Please continue the discussion about the article and how to use it at its talk page. Tanstaafl 08:55, 26 February 2008 (UTC)

Using AMO links instead of author's website whenever possible

Asked in Talk:Updating_add-ons: A question though. Some of the pages here link to AMO, others to the author's website. Is there a rule of thumb to be followed here? I answered that I don't see a rule in Rules and guidelines and that I've been using addons.mozilla.org links wherever possible, for security reasons and because the install will go through seamlessly from AMO while installing from another site may trigger a yellow message bar, asking the user to allow the site, unless the install link actually goes to AMO. Should there be a rule to use AMO links for add-ons whenever possible, if an AMO link can be found? If no one has any thoughts on the matter I'll just assume that no rule is needed and it can be left up to whomever is editing a page. Alice 01:45, 9 July 2008 (UTC)

I'd say use AMO links unless there are good reasons to the contrary; but circumstances may vary: for instance, sometimes the author's site offers a more recent version, either a test version or the latest release not yet uploaded to AMO. On the whole though, I believe using AMO links when possible is a good rule of thumb. -- Tony 07:56, 9 July 2008 (UTC)

I posted a link here in Talk:Rules and guidelines. Let's wait a a few days for more comments then, if no one objects, I can add a short "Add-on links" paragraph under Rules and guidelines#Article content, simply saying, As a general rule, link to addons.mozilla.org (AMO) whenever possible, instead of linking to the author's website or elsewhere, unless you have a good reason to use an alternate link. Alice 17:56, 9 July 2008 (UTC)

Thanks Alice. I didn't think to post the question here. I agree with everyone else here -- AMO should be it. --LoudNoise 20:37, 9 July 2008 (UTC)

Rules and guidelines#Add-on links section added. Alice 15:37, 14 July 2008 (UTC)

Extension listings in the Knowledge Base

A request for a KB account from an extension author

This brings up an interesting question. I assume that we don't want the KB to become a marketing tool. However, why does Adblock and Chromedit have articles in the KB? Should they be removed?

This isn't meant to suggest that the folks behind Adblock or Chromedit are doing anything shady.

--LoudNoise 17:41, 17 July 2008 (UTC)

Adblock also includes information about Adblock Plus. ChromEdit and Keyconfig extension have their "own" KB articles (not sure if there are many more) and Linky is basically a redirect already. (There is another article, MozBackup, which is a Windows utility, not an extension, but I think the same idea applies). We could redirect some or all of those articles by replacing the content with links to AMO (or to the author's webpage, if an AMO link is not available). Another option would be to rename those articles, for example, "Adblocking extensions" (the Adblock article is already about Adblock and Adblock Plus) and "Configuration extensions", which would include "ChromEdit" and "Keyconfig extension" as subsections. Just a thought, but that way, we could flatly prohibit articles specific to any particular extension, and the original article name would still "work", and the redirect to the new article name could still be "listed" by keeping the category listing. Thoughts? Alice 00:48, 18 July 2008 (UTC)

Sounds good to me. -- Tony 01:45, 18 July 2008 (UTC)

Sounds terrible to me. Tanstaafl 02:19, 20 July 2008 (UTC)

We can start by renaming Adblock to "Adblocking extensions" and renaming ChromEdit to "Configuration editing extensions" if no one objects. I'll add a note to the discussion sections of those two articles, then wait a few days. I took a closer look at Keyconfig extension and that would need major editing to trim it down, since it also includes two "spin-off" articles. I'm just concerned about stepping on toes when it comes to limiting KB articles about individual extensions. After all, MozillaZine does provide an Extensions and themes forum where individual extension authors give support. Alice 02:06, 18 July 2008 (UTC)

I object. Please see my later comments. Tanstaafl 02:19, 20 July 2008 (UTC)

We should at least consider adding to Rules and guidelines a new rule (under Article content) prohibiting creation of any new KB articles about individual extensions, or at the very least prohibiting any article that is clearly intended to "market" an extension. We should then add to Pages voted for deletion any new article that some extension author decides to "market" by creating a KB article. (Someone actually created a Marketing category awhile back, and it was quickly deleted [25] What do other people think? Alice 00:48, 18 July 2008 (UTC)

For blocking content there is also already this stub article Removing unwanted content on webpages and ChromEdit is also linked to from Editing configuration and Editing configuration/Manual editing. The others that I had in my notes (checked an old backup) no longer exist or have been moved already (All-In-One_Sidebar, SessionSaver). --Dickvl 20:21, 18 July 2008 (UTC)

I would vote for this- "prohibiting creation of any new KB articles about individual extensions" . I would have some problems with deciding if an article was "clearly intended to 'market' an extension". After all, most extensions are created to fulfill something that the author feels there is a crying need for. Enthusiasm might be mistaken for marketing :).--LoudNoise 21:28, 18 July 2008 (UTC)

I would think that it is acceptable to put a link in an External section at the bottom of articles that are related to the extensions if such articles already exist. Adblock Plus can link to Removing unwanted content on webpages and Chrome Edit Plus to Editing configuration and Editing configuration/Manual editing and remove the originals --Dickvl 21:40, 18 July 2008 (UTC)

I like Dickvl's suggestion. Organizationally it makes good sense. Someone is obviously looking for a solution for a particular problem at the point. It might make sense to have a new header, something like "Extensions", where folks could list links to reliant extensions. This would be fairly easy to police and allow extension authors' some exposure if they wanted it.

Another reason to ban extension KB articles. Imagination the fun to be had if some of the Conduit Toolbar folks decided that the KB needed an article about their useful toolbar. By not allowing extension articles we can neatly sidestep all sort of issues. --LoudNoise 22:01, 18 July 2008 (UTC)

I added a section under Talk:Rules and guidelines#Prohibiting articles about individual extensions proposing a rule prohibiting new extension articles, with a link to this discussion. What about saying.... In the past, KB articles had been written about individual Mozilla application extensions (e.g., Adblock). To avoid a situation in which extension authors create new KB articles to promote or "market" their own extensions, no new article about any specific extension will be permitted. If you create such an article it will be subject to deletion. Too much? Alice 02:02, 19 July 2008 (UTC)

Dick and LoudNoise, do you want me to simply redirect Adblock to Removing unwanted content on webpages? I added a link to Adblock there (it only had Adblock Plus) so I would go along with that. Also , If I understand right, you want me to redirect ChromEdit to Editing configuration? I also replaced the ChromEdit link there with the AMO link and added a condensed version of the rest of the article content. (Another option is to simply leave the Adblock and ChromEdit articles as they are, but place them in the Category:Redirects. I already placed Linky in the Redirects category.) Alice 02:02, 19 July 2008 (UTC)

Popular categories are probably malware/spyware scanning/removing programs and form fill extensions and media download extensions (not sure if that one should deserve space in the KB). There are often questions of the forum about these and linking to a stub KB article is easier than posting the full link every time. Then only the KB article needs to be updated and forum links that come up with a search point to a KB article with the current programs and extensions. --Dickvl 22:21, 18 July 2008 (UTC)

I don't know about a separate "media download extensions" article.... we already link to such extensions in Video or audio does not play#Add-on solutions... but go for it. Same with "Form fill extensions" (see below, on #Malware scanning and removal tools). Alice 02:02, 19 July 2008 (UTC)

Quick question Dick. Stub articles does not seem to shed a good light on stubs. Are you talking about one of the category pages?--LoudNoise 18:33, 19 July 2008 (UTC)

I'm missing some of the context of this discussion. I haven't seen authors creating articles about thier extension as being a real problem. Please point me to several examples where somebody wrote an artcile about thier addon, and highlite which ones were inappropiate. I see lots of referrals to the adblock and chromedit articles in the forums, they serve a real need. If an extension is popular having a article you can point to is very useful. We need to distinguish between shameless self-promotion and articles that help users. I wrote Importing folders for example (which documents how to install and use ImportExportTools) because I got tired of rewriting the same text when trying to help somebody who didn't know how to import a mbox file and wasn't computer literate. You can't rely upon AMO or the add-on author to do that sort of hand-holding.

I think its counterproductive to rename the Adblock article. Its tough enough for many people to find the appropiate article already.

The whole idea of something like the Mozbackup article is that its on a wiki, so users can contribute to it. Why in the world do you want to eliminate that by pointing people to AMO (which has terrible documentation, and whose web site keeps going down hill) or the authors web page instead? Tanstaafl 02:19, 20 July 2008 (UTC)

Both the ChromEdit and Adblock articles simply state that both are useful programs and here is where to get them. Both of these items could be added (if the info isn't already there) to the articles that deal with chrom editing and ad blocking. Since these are not necessary why bother having them? Since there is the possibility of abuse why not have a policy of not allowing KB articles about specific extensions? --LoudNoise 17:25, 20 July 2008 (UTC)

1. That is over-generalizing from 2 cases. Keyconfig_extension and Keyconfig_extension:_Thunderbird for example have lots of information. I suggest you argue with Rod Whiteley if you think the time and effort he spent on them was a waste of time.

2. I already gave one example of a article about an extension where the information was useful, and you couldn't get it by just pointing to AMO or the authors homepage. I'm currently working on a webmail add-on article because it will make it easier to handle common questions about it. Pointing to the dedicated thread or the authors home page doesn't meet most users needs.

3. Its not clear it would solve a real problem (so far it seems to be just a potential problem), and the proposed solution would prevent users from contributing information to help other users. Any restrictions should be proportionate to the potential harm. We already have a mechanism for dealing with inappropriate extension articles - voting to have it deleted. We haven't had to do that yet.

4. It overlooks the possibility that it can be useful if the author of a popular add-on created an article. Ausdilecce has several popular Thunderbird extensions that require a lot of knowledge how to use/customize. His web site is gone and nobody has been able to reach him for years. Think how useful it would have been if we had encouraged him to write some articles on his add-ons rather than having that information scattered through threads that the average user can't find. Having users polish and contribute to the article would have improved the quality, and probably encouraged him to provide more raw information that users would clean up....

5. We haven't evaluated "lesser" alternatives such as a MARKETING_FLUFF template that could be used if somebody thought an article was just a marketing tool and/or a rule that add-on authors can't write an article about thier own add-on.

Whatever is decided is fine by me. I am certainly not married to the idea. --LoudNoise 20:28, 21 July 2008 (UTC)

The question of what to do about new articles by extension authors has come up again. See Talk:Forward. Alice 02:27, 7 January 2010 (UTC)

Malware scanning and removal tools

Dick, you mentioned in the extensions listing discussion, that Popular categories are probably malware/spyware scanning/removing programs..... An article about spyware and malware scanning and removal tools, with links to security forums, would be a great help for people whose Mozilla applications are showing malware-related symptoms, maybe under the Category:Privacy and security (which already includes an Antivirus software article)? It could include links to other articles that talk about malware issues such as Firefox.exe always open and Unable to search or add new engines. Alice 02:16, 19 July 2008 (UTC)

The Firefox.exe always open is very special (Poison Ivy) and the other two articles I know of (Popups_not_blocked#Spyware_on_Windows and Unable_to_search_or_add_new_engines#Spyware_and_malware that mention malware are not easy to find. Recently there have been a lot of occurrences of Vundo and doing a malware scan with some programs never hurts. I wasn't aware of the Antivirus_software article (it says that it is for Tb and Moz Suite, shouldn't that also mention SM?). I think that Category:Privacy and security would be a good place for such an article (maybe something for Daifne?). --Dickvl 03:36, 19 July 2008 (UTC)

Yes, the Antivirus software article should also mention SM but that's a given when an article refers to TB/Mozilla Suite. As for the Firefox.exe always open article, it could use a link to a new "Malware scanning and removal tools" article so that less experienced users can find a forum that can help them with malware removal. It would be great if Daifne could write such an article but you or anyone else could, too :) Alice 20:18, 19 July 2008 (UTC)

Antivirus_program_claims_Thunderbird.exe_has_a_virus has links to several anti-virus scanners. It and the proposed spyware/malware removal article should link to each other. Tanstaafl 03:08, 20 July 2008 (UTC)

Please keep in mind the big fuss we had in Antivirus_software where one person turned it into a soapbox against using anti-virus software. Lots of people have strong opinions about which tools to use, and may also write disparaging comments about certain vendors such as Norton/Symantec. I suggest the article have a short section setting expectations on whats acceptable. Tanstaafl 03:08, 20 July 2008 (UTC)

The suggested new "Malware scanning and removal tools" article hasn't been written so I added a separate Check for malware section to the Standard diagnostic - Firefox article for now, to centralize the information for Firefox users which is now spread among many different articles. Alice 22:24, 31 December 2008 (UTC)

Special:Userlogin needs copyediting

Log in/Create Account has the following problems:

"Please ignore the preceding paragraph, its hard coded text displayed by the wiki software thats its awkward to get rid of."

=>

Delete sentence since there is no preceding paragraph. (If some paragraph should be there that is hidden, correct sentence as follows: "Please ignore the preceding paragraph; it's hard-coded text displayed by the wiki software that is awkward to get rid of.")

"A knowledge base account is not meant to ask for help or to discuss your problem - post in the forums instead. We're not run by or formally associated with Mozilla, though they do link to our web site on their support page. We're a independent user community site. If you want to report a bug or gripe about how something works (enhancement requests are legitimate bug reports) use Mozilla's bug reporting system ."

=>

"A knowledge base account is not meant for asking for help or for discussing a problem you're having - post in the forums instead. We're not run by or formally associated with Mozilla, though they do link to our website on their support page. We're an independent user community site. If you want to report a bug or gripe about how something works (enhancement requests are legitimate bug reports), use Mozilla's bug reporting system."

"A knowledge base account is available for the asking, the only reason for this process is to help combat spam. The account will let you edit or create articles on our wiki. You don't need it to read the articles."

=>

"Anyone can get a knowledge base account. The only reason for the registration process is to help combat spam. The account will let you edit or create articles on our wiki. You don't need an account to read the articles."

"If you have a MozillaZine forum account its recommended you request a knowledge base account in the Moderation / Spam / Registration / Login Activation Requests thread. Please mention what username you'd prefer. Otherwise you can send a email message to mozillaZineKB AT gmail DOT com to request a knowledge base account. You'll usually get a reply within 24 hours if you use the thread. If you send a email it will typically take at least a couple of days."

=>

"If you have a MozillaZine forum account, it's recommended you request a knowledge base account in the thread Moderation / Spam / Registration / Login Activation Requests. Please mention what username you'd like. You can also send an email to the address mozillaZineKB AT gmail DOT com to request a knowledge base account. You'll usually get a reply within 24 hours if you use the thread. If you send an email, registration will typically take at least a couple of days."

"You must have cookies enabled to log in to MozillaZine Knowledge Base."

=>

"You must have cookies enabled to log in to the MozillaZine Knowledge Base." --American Finn 07:53, 24 May 2009 (UTC)

The sentence about the preceding paragraph is due to "Don't have a login? Create an account." text that everybody used to be able to see. Something changed, now you only see it if you're already logged in as a SysOP.

I deleted the paragraph and updated the rest of the text. Some of it follows your suggestions. Next time please add italics in your comment to highlight the existing text. Tanstaafl 18:25, 24 May 2009 (UTC)

Thanks, but you missed quite a few spelling, grammar, and vocabulary errors. It would have been better to simply copy my copyedited version and then add your changes, and it wouldn't have hurt to thank me for my work. The reason i didn't use italics was that i originally used them to highlight the mistakes and changes, but i decided to leave them out so that my corrected text could be simply copied and pasted and so that minor corrections like punctuation would hopefully not be left out. Only corrections of major problems are in bold below; there are corrections elsewhere too.

A knowledge base account is not meant to ask for help or to discuss your problem...

=> "A knowledge base account is not meant for asking for help or for discussing a problem you're having with a Mozilla product..."

web site

=> website (or Web site)

The account will let you edit or create articles on our wiki. You don't need it to read the articles.

=> "An account will let you edit or create articles here, but you don't need it to read the articles."

If you have a MozillaZine forum account its recommended that you request a knowledge base account in the Moderation / Spam / Registration / Login Activation Requests thread in the MozillaZine Site Discussion forum. Please mention what username you'd prefer. Otherwise you can send a email message to mozillaZineKB AT gmail DOT com to request a knowledge base account. You'll usually get a reply within 24 hours if you use the thread. If you send a email it will typically take at least a couple of days.

=> If you have a MozillaZine forum account, it's recommended that you request a knowledge base account in the Moderation / Spam / Registration / Login Activation Requests thread in the MozillaZine Site Discussion forum. Please mention what username you'd like. You can also request a knowledge base account by sending an email to the address mozillaZineKB AT gmail DOT com. You'll usually get a reply within 24 hours if you use the thread. If you send an email, it will typically take at least a couple of days. --American Finn 14:13, 31 May 2009 (UTC)

I made some edits based on the above (I first had to hunt up Create a knowledge base account which says, The reason for the confusing text at Special:Userlogin is because we can only change part of it, by editing MediaWiki:Loginprompt.). Alice 15:21, 31 May 2009 (UTC)

Thanks. It's getting better, but at least these still need to be corrected:

A knowledge base account is not needed to ask for help or to discuss your problem...

=> "Please do not create or use a knowledge base account to ask for help or to discuss your problem...

or => "A knowledge base account is not meant for asking for help or for discussing a problem you're having with a Mozilla product..."

If you send an email it will typically take...

=> "If you send an email, [comma] it will typically take..." --American Finn 17:06, 31 May 2009 (UTC)

History category

A new History category was added based on a discussion here: Talk:Counts#Article_title_and_categories. Alice 21:20, 19 June 2009 (UTC)

Use of categories

We seem to use the following policies in categorizing articles:

If its added to an Issues category, make certain its also added to a non-Issues category.
Use Thunderbird, Firefox etc. as catchall categories when you can't find a more specific category.
Don't add every article about an application to the category named after the application (the catchall category).
Use restraint in how many categories you add an article to. Most articles only get added to one non-Issues category for that application.
Don't create version specific categories.

Should we update the categorizing section in the rules?

New editors frequently don't know any of the rules or unwritten conventions. We've deliberately downplayed having to learn anything before editing an article, accepting the cost of more experienced editors occasionally having to clean things up in order to encourage new editors to participate. That seems to work well since most editors just edit an existing article.

It doesn't work as well with categories. We've occasionally had problems with new editors creating duplicate categories and recently had a problem with one adding many Thunderbird articles to the Thunderbird category (the catchall category). I've also noticed there is somebody who keeps creating version specific calendar and calendar issue categories. That is inconsistent with what we've done for every other application but hasn't caused any real harm. However, somebody else might start mimicking that for Firefox, Thunderbird etc.

Its been on Kerz's (the site owner/admin) to do list for over two years but someday he will make the changes necessary so that all users can edit articles without having to sign up for an account. Some of the trade offs we make today won't work so well when that happens. Is there anything we can do to minimize problems without discouraging new editors that will help us be ready for that?

I read the MediaWiki article on modifying user rights. Other than Kerz almost everybody is either a user or a Sysop but one possibility would be to have Kerz restrict what the user group could do and create another group (meant for experienced editors that read the rules) that lets them do what everybody can currently do. If we want to use that type of approach to solve the problems that will occur when every registered forum user automatically gets a knowledge base account it would be a good idea to implement it beforehand, when its easier to learn from any mistakes.

I noticed the article listed a autoconfirmed group (registered accounts at least as old as $wgAutoConfirmAge and having at least as many edits as $wgAutoConfirmCount) that might be a useful way to automatically add people to an experienced editor group. I haven't figured out yet whether or not we have that group yet, Special:Specialpages doesn't list anything about groups.

However, you could also argue that if Kerz doesn't install the new software for several more years all it would do is make things difficult for new editors that want to write an article (have to jump though yet another hoop).

Opinions? Tanstaafl 23:29, 5 August 2009 (UTC)