Knowledge Base changes/Archive: Difference between revisions

Revision as of 17:00, 18 May 2007

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)

@@ Line 517: / Line 517: @@
 {{org}}
+==Upload file enabled==
+{| {{prettytable}}
+|-
+|''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]]. [[User:Alice Wyman|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]]--[[User:Np|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 [[Knowledge_Base |KB Main page]] (which now uses images linked from Imageshack) since it's locked.  [[User:Alice Wyman|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]]--[[User:Np|Np]] 01:47, 28 December 2006 (UTC)