Knowledge Base changes: Difference between revisions

From MozillaZine Knowledge Base
Jump to navigationJump to search
 
(355 intermediate revisions by 13 users not shown)
Line 1: Line 1:
{{org}}
{{org}}
==Introduction==
This page has been created for several reasons.
This page has been created for several reasons.


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


This page is the primary place to announce new suggestions. Please visit it regularly!
This page is the primary place to ''announce'' new suggestions. Whenever possible, issues should be ''discussed'' in a more appropriate place, such as the discussion page of the article or category that the suggestion affects. Once suggestions are resolved, they are moved to [[Knowledge Base changes/Archive]].


==Welcome to new editors==
You can request somebody create an article at [[Requested articles]] .
Hello! Great to have you here. Please add a comment here :-)


* Hello Knowledge Base! FJ reporting to duty! *bows at all* [[User:FatJohn|FatJohn]] 11:30, 3 January 2006 (UTC)
==Copyright/License problems==
* I guess I'm new, I am "name already taken" from the forums, hello to everyone! --[[User:Lethargy|Lethargy]] 21:34, 10 May 2006 (UTC)
I suggest we think about adding a short "Copyright/License problems" section in [[Rules_and_guidelines]] that sets peoples expectations on what they can legitimately copy/modify. I'm splitting this out as a separate topic from "Using external sources and references in KB articles". Please discuss this at [[Talk:Rules_and_guidelines]] . [[User:Tanstaafl|Tanstaafl]] 08:32, 20 January 2008 (UTC)


==Hot topic—Making things less daunting for new editors==
Roland Tanglao (tech support lead at Mozilla Messaging) is going to talk to Kerz about the possibility of our using a license compatible with the license SuMoMo (The official knowledge base at support.mozillamessaging.com) uses. The issue came up when we planned some events where people on the tb-support-crew AT mozilla.org mailing list (mainly from the MozillaZine and Mozilla Messaging/GetSatisfaction communities) collaborate on writing KB articles. They are initially developed here and then ported to their site. That doesn't raise any legal issues if they are started from scratch. However, someday we may want to merge content from several articles (some of which are on their site) when creating a new article, and there is always the issue of not being able to use updates added to the SuMoMo version of the article on this sites version of the same article unless you start spending a lot of effort tracking and justifying stuff.
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? --[[User:Mozcerize|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. --[[User:Wintogreen|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. --[[User:Mozcerize|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. --[[User:Tanstaafl | Tanstaafl]] 3:30 AM January 16, 2006 (PMT)
See the [http://kb.mozillazine.org/Knowledge_Base_changes/Archive#License_issues archive of license issues]. [[User:Tanstaafl|Tanstaafl]] 11:39, 19 November 2010 (UTC)
: 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. --[[User:Mozcerize|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. --[[User:Tanstaafl | Tanstaafl]] 3:30 AM January 16, 2006 (PMT)
==Using the new SeaMonkey category==
: 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. --[[User:Mozcerize|Mozcerize]] 17:11, 30 January 2006 (UTC)
A new [[:Category:SeaMonkey]] was created awhile back, which went under my radar ;-). I was thinking, why not use this new category to track SeaMonkey 2 articles for now?  I started a Discussion page here: [[:Category talk:SeaMonkey]] [[User:Alice Wyman|Alice]] 14:36, 9 February 2009 (UTC)


I don't think creating a thread will help attract new editors. --[[User:Tanstaafl | Tanstaafl]] 3:30 AM January 16, 2006 (PMT)
[http://kb.mozillazine.org/User:Skierpage Skierpage] is looking for advice on how to update old Mozilla Suite stuff for SeaMonkey, especially for Linux.  [[User:Tanstaafl|Tanstaafl]] 11:44, 19 November 2010 (UTC)
: Why not? --[[User:Mozcerize|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). --[[User:Tanstaafl | Tanstaafl]] 3:30 AM January 16, 2006 (PMT)
==Replacement of Profile Manager==
: 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? --[[User:Mozcerize|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.  
The profile manager is going to be eliminated after Firefox 4.0. [http://www.ghacks.net/2011/01/19/firefox-profile-manager-to-be-removed-soon/] [http://forums.mozillazine.org/viewtopic.php?f=38&t=2066609] Thunderbird will probably also do the same. [http://forums.mozillazine.org/viewtopic.php?f=29&t=2073455] The separate profile manager utility is not designed for end users, and its not clear yet whether it will even be bundled with the Mozilla application.  


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. --[[User:Tanstaafl | Tanstaafl]] 3:30 AM January 16, 2006 (PMT)
How do we want to handle documenting both? Its already very awkward documenting how to use the profile manager for multiple applications and multiple operating systems in one article. That is the reason why [[Moving_your_profile_folder_-_Thunderbird]] was created for example. Given the different release schedules for Firefox, SeaMonkey, and Thunderbird, and how some users keep using old major versions for a very long time we will probably have to deal with both for at least several years.


:I took the liberty of expanding the [[MozillaZine Knowledge Base:About|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. ;-) --[[User:Wintogreen|wintogreen]] 19:14, 19 January 2006 (UTC)
Do we want to adopt some naming convention in other articles to make it clear which one we're talking about or do we want to refer to both as the profile manager?


==Hot topic—replacing the FAQs and Issues pages with category navigation==
I realize this is early but I'd like to document how to use the replacement with Thunderbird (if only to get more people to try it and provide feedback to the author) and don't want to make that a isolated stand alone article. [[User:Tanstaafl|Tanstaafl]] 02:27, 21 January 2011 (UTC)
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.
:I've already added this note to the top of the [[Profile Manager]] article:<br>
 
:{| {{prettytable}}
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. --[[User:Mozcerize|Mozcerize]]
|-
 
|'''''Note:''' Mozilla is planning to remove the built-in Profile Manager  from future Mozilla applications (after Firefox 4.0) and a standalone "Profile Manager" application will be available. "Profile Manager 1.0 Beta 1" is described [http://jagriffin.wordpress.com/2011/01/11/profilemanager-1-0_beta1 here]. For more information, see [http://www.ghacks.net/2011/01/19/firefox-profile-manager-to-be-removed-soon/ this blog post] and [https://developer.mozilla.org/en/Profile_Manager this article at MDC]. [http://forums.mozillazine.org/viewtopic.php?p=10275581#p10275581] [https://bugzilla.mozilla.org/show_bug.cgi?id=214675] [https://bugzilla.mozilla.org/show_bug.cgi?id=539524]''  
: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. --[[User:Mozcerize|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.  [[User:Alice Wyman|Alice Wyman]] 20:47, 2 January 2006 (UTC)
:According to [https://bugzilla.mozilla.org/show_bug.cgi?id=539524#c22 bug 539524 comment 22] the standalone PM application will probably not be bundled with future Firefox downloads when it is removed from Firefox and  will be a separate, optional download.  I thought that we might make a template similar to the above note and add it to the top of all articles about profiles.   When the built-in Profile Manager is actually removed (sometime after Firefox 4.0) we could add something to the effect that the article or article section ''applies to Firefox 4.0 and below.'' We could then create a new "Profile Manager application" or "Profile Manager utility" article and link to it, just like we have  for the [[MozBackup]] standalone utility.  [[User:Alice Wyman|Alice]] 14:10, 21 January 2011 (UTC)
 
:::''"I'm sorry it I stepped on anyone's toes&hellip;."'' 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. --[[User:Mozcerize|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. [[User:Alice Wyman|Alice Wyman]] 16:40, 7 January 2006 (UTC)
:::::That's great; thanks! --[[User:Mozcerize|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? --[[User:Tanstaafl|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?) --[[User:Mozcerize|Mozcerize]] 11:24, 31 January 2006 (UTC)
 
==Question&mdash;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? --[[User:Wintogreen|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]]. [[User:Alice Wyman|Alice Wyman]] 16:35, 5 January 2006 (UTC)
::In [[:Category:Preferences]] we're listing them both.--[[User:Np|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. --[[User:Mozcerize|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)". --[[User:Wintogreen|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. --[[User:Tanstaafl|Tanstaafl]] 3:42AM, 16 January 2006 (PMT)
 
::::::I've taken a stab at this with a new template -- [[Template:Tbsuite]], now in action [[Compacting folders|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.<br>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 [[Multiple SMTP servers (Thunderbird)|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? --[[User:Wintogreen|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 [[Mozilla_Suite_:_FAQs_:_Status | 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 [[Category_talk:Preferences#Formatting | 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 [[Knowledge_Base_changes#Article-writing_guidelines | Article-writing guidelines]] below.  [[User:Alice Wyman|Alice Wyman]] 14:16, 17 January 2006 (UTC)
 
:::::::: Hi Alice. What I've been thinking, since I made the trial template, is that the [[Mozilla_Suite_:_FAQs_:_Status | linked page]] should be like the [[Firefox]] and [[Thunderbird]] pages PLUS serve as a kind of disambiguation page&mdash;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"? --[[User:Wintogreen|wintogreen]] 16:53, 17 January 2006 (UTC)
 
::::::::: Hi, wintogreen.  I agree the [[Mozilla_Suite_:_FAQs_:_Status | 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 [[Knowledge_Base_changes#Article-writing_guidelines | Article-writing guidelines]] before I saw your reply here. [[User:Alice Wyman|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). --[[User:Wintogreen|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?    [[User:Alice Wyman|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. --[[User:Tanstaafl|Tanstaafl]] 2:40AM, 18 January 2006 (PMT)
 
::::::::::::: Update: since the above-mentioned <nowiki>{{Tbsuite}}</nowiki> 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. --[[User:Wintogreen|wintogreen]] 19:40, 27 January 2006 (UTC)
 
:::::::::::::: Nice work.  The [[Mozilla Suite : FAQs : Status | page]] is a lot more useful now.  I did some very minor editing and added a short blurb mentioning "SeaMonkey" at the top. [[User:Alice Wyman|Alice Wyman]] 20:47, 27 January 2006 (UTC)
 
::::::::::::::: Thanks for your further edits to that page. The phrase you've inserted at the top&mdash;"Mozilla Suite code development and the SeaMonkey project"&mdash;would make a good name for the article. Or maybe just "Mozilla Suite development and the SeaMonkey project" or "Mozilla Suite development and SeaMonkey"? --[[User:Wintogreen|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. [[User:Alice Wyman|Alice Wyman]] 13:57, 28 January 2006 (UTC)
 
::::::::::::::::: For now I've just changed the first header; appreciate the input and suggestions.  --[[User:Wintogreen|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. [[User:Alice Wyman|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. [[User:Alice Wyman|Alice Wyman]] 13:51, 14 March 2006 (UTC)
 
===Hot topic&mdash;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. --[[User:Wintogreen|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 [[:Category:Preferences|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. --[[User:Wintogreen|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 [[Template:Tbsuite|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:  [[User:Alice Wyman|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 [[:Category_talk:Preferences | 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.
------------------------------------------------
 
==New proposal&mdash;"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]]. --[[User:Wintogreen|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]]. --[[User:Wintogreen|wintogreen]] 08:07, 17 January 2006 (UTC)
 
==Hot topic&mdash;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 [[User Talk:Unarmed |  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]].''  [[Category_talk:Preferences#Moving_some_of_this_to_a_separate_page | 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?)  [[User:Alice Wyman|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.  [[User:Tanstaafl|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).  [[User:Alice Wyman|Alice Wyman]] 17:57, 18 January 2006 (UTC)
 
==New Proposal&mdash;Creating an article for each profile file.==
[[Talk:Profile folder]]
:I just wanted to copy the subject and introductory paragraph from the [[Talk:Profile folder | 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.  [[User:Alice Wyman|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. [[User:Tanstaafl|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.  [[User:Alice Wyman|Alice Wyman]] 16:09, 1 February 2006 (UTC)
 
==New Proposal&mdash;Note on the registration page.==
I want to add the following line in the [[Special:Userlogin | registration page]], under the "create new account" button.
 
The purpose of the Knowledge Base is to provide documentation. <font color=red><b>Post any questions in the [http://forums.mozillazine.org/  Mozillazine Forums], not here.</b></font>
 
Do you agree/disagree? Any comments on the wording? --[[User:Filipp0s|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. [[User:Tanstaafl|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 [[MozillaZine_Knowledge_Base:About | "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: <p>
::''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!''<br>
::'''''However, if you have any comments, problems, or feature requests related to [[Summary of Mozilla products|Mozilla Products]], please do not post them here! Rather, post them in the [http://forums.mozillazine.org/ MozillaZine Forums].'''''</p>
::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  "<font color=red> Post questions in the [http://forums.mozillazine.org/  Mozillazine Forums] not here</font>" notice so that if the person comes back to the page he will see why his question is gone.  [[User:Alice Wyman|Alice Wyman]] 21:34, 7 March 2006 (UTC)
How about also including some text to stop people from editing pref or profile articles?--[[User:Np|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?  [[User:Alice Wyman|Alice Wyman]] 12:32, 14 March 2006 (UTC)
::I mean the people who edit them in an attempt to change their own configuration.--[[User:Np|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!)  [[User:Alice Wyman|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.--[[User:Np|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.  [[User:Alice Wyman|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).  [[User:Tanstaafl|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".--[[User:Np|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. [[User:Tanstaafl|Tanstaafl]] 22:13, 15 March 2006 (UTC)
Speaking of which, it was [http://forums.mozillazine.org/viewtopic.php?p=2139988#2139988 brought up on the forums]  that  users have been making anonymous kb edits without registering or logging in.  [[User:Alice Wyman|Alice Wyman]] 19:42, 15 March 2006 (UTC). It's now reported  fixed [[User:Alice Wyman|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. --[[User:Filipp0s|Filipp0s]] 01:28, 19 March 2006 (UTC)
 
==New Main Page==
''Previous discussion of the existing [[Knowledge Base | 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?  --[[User:Filipp0s|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. --[[User:Mozcerize|Mozcerize]] 10:21, 19 March 2006 (UTC)
::I would change the Intro from, "This website provides documentation of [[Summary of Mozilla products|Mozilla products and applications]] " to something like, "This website provides documentation of [[Summary of Mozilla products|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").<br> 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).  [[User:Alice Wyman|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. --[[User:Mozcerize|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) [[User:Filipp0s|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! --[[User:Mozcerize|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. --[[User:Filipp0s|Filipp0s]] 21:59, 21 March 2006 (UTC)
::::::::Hi there! I'd like to modify the introduction paragraph by highlighting ('''bold''', <u>underline</u>, 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<br>Would this make sense to you guys? --[[User:FatJohn|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. --[[User:Mozcerize|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. --[[User:FatJohn|FatJohn]] 23:10, 19 June 2006 (UTC)
::::::::::::In unrelated news, I tried to make images for [http://img147.imageshack.us/img147/8283/screenshot222228kk.png development] and [http://img138.imageshack.us/img138/5492/screenshot11111222226lv.png extensions]. See them on [[Frontpage_suggestion_mockup]]. Like them? You make better images! :)  --[[User:FatJohn|FatJohn]] 01:08, 17 June 2006 (UTC)
:::::::::::::These look good! --[[User:Mozcerize|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? --[[User:Mozcerize|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. --[[User:FatJohn|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 [http://kb.mozillazine.org/index.php?title=Firefox&action=edit Firefox page code] to see how I did it. If nobody disagrees, we could do the same with the rest products.  --[[User:Filipp0s|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? [[User:Tanstaafl|Tanstaafl]] 02:13, 19 March 2006 (UTC)
::They're linked to from the official site.--[[User:Np|Np]] 02:30, 19 March 2006 (UTC)
:::&hellip;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. --[[User:Mozcerize|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 ''<nowiki>[viz. having to look in several different places at once to ensure you've not missed anything]</nowiki>'' 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. --[[User:Mozcerize|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). [[User:Tanstaafl|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! --[[User:Mozcerize|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 --[[User:Filipp0s|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. --[[User:Mozcerize|Mozcerize]] 10:05, 1 April 2006 (UTC)
 
==Naming conventions==
The parentheses look ugly (esp in the location bar) and [[Talk:Unable_to_install_themes_or_extensions_%28Firefox%29#better_URL|clickme]]. I suggest we remove this 'rule'. No need to rename the existing ones. We will use the categories instead. --[[User:Filipp0s|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. --[[User:Mozcerize|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.
:[http://www.ietf.org/rfc/rfc2396.txt]--[[User:Np|Np]] 19:04, 1 April 2006 (UTC)
::Probably because PHP’s <code>[http://php.net/urlencode urlencode()]</code> function escapes them. --[[User:Unarmed|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 [[Talk:Unable_to_install_themes_or_extensions_%28Firefox%29#better_URL | 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"?  [[User:Alice Wyman|Alice Wyman]] 19:46, 3 May 2006 (UTC)
::Because that'd mess up any alphabetical listing of articles.--[[User:Np|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  [[User:Alice Wyman|Alice Wyman]] 23:42, 4 May 2006 (UTC)
::::This sounds very reasonable --[[User:Mozcerize|Mozcerize]] 08:39, 8 May 2006 (UTC)
::::Good idea, but I'd prefer "Standard_diagnostic_-_Firefox". The colon seems a little weird.--[[User:Np|Np]] 14:27, 8 May 2006 (UTC)
:::::That'll work, too.  [[User:Alice Wyman|Alice Wyman]] 20:17, 8 May 2006 (UTC)
I've updated [[In-house style]]--[[User:Np|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.
 
==Categories==
* I suggesting merging [[:Category:Extensions_%28Firefox%29]] with [[:Category:Extensions_%28Thunderbird%29]] to [[:Category:Extensions]]. Not really a reason for both of them.
:I suspect this idea will not be universally popular. There is currently debate about ''splitting'' categories (such as Privacy and security) into app-specific categories. --[[User:Mozcerize|Mozcerize]] 10:05, 1 April 2006 (UTC)
* I deleted [[:Category:Sandbox]], [[:Category:Marketing]] and am moving all [[:Category:Introduction]] articles to [[:Category:Top_level]] (necessary after [[Knowledge_Base_changes#Merging_products.27_pages_with_their_categories|merging products' pages with their categories]]). --[[User:Filipp0s|Filipp0s]] 23:56, 31 March 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 <nowiki>{{noquestions}}</nowiki> on the login page would deter some of these people. --[[User:Wintogreen|Wintogreen]] 02:30, 17 Jun 2005 (PDT)
:I would also like this to be implamented. It is a very good idea [[User:Stex|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. --[[User:Hao2lian|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 "[http://kb.mozillazine.org/index.php?title=Special:Userlogin 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.
 
--[[User:DavidCary|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.) --[[User:FatJohn|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. [[User:Brettz9|Brettz9]] 04:07, 16 October 2005 (PDT)
 
==Finding templates==
''Moved here from [[Talk:Knowledge Base]]''
 
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). --[[User:Mozcerize|Mozcerize]] 02:16, 4 Jun 2005 (PDT)
:I would also like to know this. --[[User:Wintogreen|Wintogreen]] 02:30, 17 Jun 2005 (PDT)
::Seems that [[Special:Allpages]] ought to look instead like [http://meta.wikimedia.org/wiki/Special:Allpages this one], where you can choose to show all articles in a  certain namespace. Are we using an outdated wiki version? --[[User:Wintogreen|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. --[[User:Mozcerize|Mozcerize]] 06:15, 13 September 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? [[User:Tanstaafl|Tanstaafl]] 21:17, 22 May 2006 (UTC)
:Akin to the [[:Category:Unused preferences]] category? --[[User:Unarmed|Unarmed]] 01:09, 23 May 2006 (UTC)
::Yes. [[User:Tanstaafl|Tanstaafl]] 22:16, 24 May 2006 (UTC)
 
==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:Wikipedia:Requested articles | Wikipedia already has]]. Is there any reason not to do this? --[[User:Lethargy|name already taken]] 23:35, 25 May 2006 (UTC)
: Methinks this is a good idea. --[[User:FatJohn|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... --[[User:Lethargy|name already taken]] 10:14, 12 June 2006 (UTC)
:::Please don't create a category for it. [[User:Tanstaafl|Tanstaafl]] 22:06, 12 June 2006 (UTC)
::::Just bung it in the Organization category. Don't forget that you can use the template <nowiki>{{org}}</nowiki> to do this, to save having to type the full name of the category. --[[User:Mozcerize|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. --[[User:Lethargy|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.  [[User:Alice Wyman|Alice Wyman]] 21:49, 13 June 2006 (UTC)
::::I'll add a note to the page explaining that that should be done --[[User:Lethargy|name already taken]] 15:54, 15 June 2006 (UTC)
:Would it be possible to allow anonymous editing of that page? --[[User:Lethargy|name already taken]] 02:38, 20 June 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... --[[User:FatJohn|FatJohn]] 11:15, 4 June 2006 (UTC)
:I like this idea. It'll take a bit of organization though! Anybody fancy the task? --[[User:Mozcerize|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.) --[[User:FatJohn|FatJohn]] 13:47, 13 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. --[[User:Mozcerize|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. --[[User:Mozcerize|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 [[Unable_to_install_themes_or_extensions_-_Firefox#Software_installation_disabled | 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.  [[User:Alice Wyman|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. [[User:Tanstaafl|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 [[Summary of Mozilla products|Mozilla Products]], please do not post them here! Rather, post them in the [http://forums.mozillazine.org/ MozillaZine Forums].''  I checked the [http://en.wikipedia.org/wiki/Wikipedia:About Wikipedia:About] page for ideas and it says this, under <u>Feedback and questions</u> '''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 [http://forums.mozillazine.org/viewforum.php?f=11 MozillaZine Site Discussion forum] or maybe even a special thread for KB article feedback? [[User:Alice Wyman|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 [http://forums.mozillazine.org/viewforum.php?f=11 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. '' [[User:Alice Wyman|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]]. [[User:Alice Wyman|Alice Wyman]] 23:37, 29 July 2006 (UTC)
 
I went ahead and merged the three articles into [[Error loading websites]].  [[User:Alice Wyman|Alice Wyman]] 10:15, 1 August 2006 (UTC)
 
==Irrelevant information==
I feel the KB has a massive problem with too much information being contained in articles. Case in point: [http://kb.mozillazine.org/index.php?title=Firewalls&oldid=27051 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.--[[User:Np|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. --[[User:AnotherGuest.|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.  [[User:Alice Wyman|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. [[User:Alice Wyman|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.  [[User:Alice Wyman|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?  --[[User:AnotherGuest.|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. --[[User:Np|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! --[[User:Mozcerize|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]]--[[User:Np|Np]] 17:11, 7 September 2006 (UTC)

Latest revision as of 14:10, 21 January 2011

This page has been created for several reasons.

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

This page is the primary place to announce new suggestions. Whenever possible, issues should be discussed in a more appropriate place, such as the discussion page of the article or category that the suggestion affects. Once suggestions are resolved, they are moved to Knowledge Base changes/Archive.

You can request somebody create an article at Requested articles .

Copyright/License problems

I suggest we think about adding a short "Copyright/License problems" section in Rules_and_guidelines that sets peoples expectations on what they can legitimately copy/modify. I'm splitting this out as a separate topic from "Using external sources and references in KB articles". Please discuss this at Talk:Rules_and_guidelines . Tanstaafl 08:32, 20 January 2008 (UTC)

Roland Tanglao (tech support lead at Mozilla Messaging) is going to talk to Kerz about the possibility of our using a license compatible with the license SuMoMo (The official knowledge base at support.mozillamessaging.com) uses. The issue came up when we planned some events where people on the tb-support-crew AT mozilla.org mailing list (mainly from the MozillaZine and Mozilla Messaging/GetSatisfaction communities) collaborate on writing KB articles. They are initially developed here and then ported to their site. That doesn't raise any legal issues if they are started from scratch. However, someday we may want to merge content from several articles (some of which are on their site) when creating a new article, and there is always the issue of not being able to use updates added to the SuMoMo version of the article on this sites version of the same article unless you start spending a lot of effort tracking and justifying stuff.

See the archive of license issues. Tanstaafl 11:39, 19 November 2010 (UTC)

Using the new SeaMonkey category

A new Category:SeaMonkey was created awhile back, which went under my radar ;-). I was thinking, why not use this new category to track SeaMonkey 2 articles for now? I started a Discussion page here: Category talk:SeaMonkey Alice 14:36, 9 February 2009 (UTC)

Skierpage is looking for advice on how to update old Mozilla Suite stuff for SeaMonkey, especially for Linux. Tanstaafl 11:44, 19 November 2010 (UTC)

Replacement of Profile Manager

The profile manager is going to be eliminated after Firefox 4.0. [1] [2] Thunderbird will probably also do the same. [3] The separate profile manager utility is not designed for end users, and its not clear yet whether it will even be bundled with the Mozilla application.

How do we want to handle documenting both? Its already very awkward documenting how to use the profile manager for multiple applications and multiple operating systems in one article. That is the reason why Moving_your_profile_folder_-_Thunderbird was created for example. Given the different release schedules for Firefox, SeaMonkey, and Thunderbird, and how some users keep using old major versions for a very long time we will probably have to deal with both for at least several years.

Do we want to adopt some naming convention in other articles to make it clear which one we're talking about or do we want to refer to both as the profile manager?

I realize this is early but I'd like to document how to use the replacement with Thunderbird (if only to get more people to try it and provide feedback to the author) and don't want to make that a isolated stand alone article. Tanstaafl 02:27, 21 January 2011 (UTC)

I've already added this note to the top of the Profile Manager article:
Note: Mozilla is planning to remove the built-in Profile Manager from future Mozilla applications (after Firefox 4.0) and a standalone "Profile Manager" application will be available. "Profile Manager 1.0 Beta 1" is described here. For more information, see this blog post and this article at MDC. [4] [5] [6]
According to bug 539524 comment 22 the standalone PM application will probably not be bundled with future Firefox downloads when it is removed from Firefox and will be a separate, optional download. I thought that we might make a template similar to the above note and add it to the top of all articles about profiles. When the built-in Profile Manager is actually removed (sometime after Firefox 4.0) we could add something to the effect that the article or article section applies to Firefox 4.0 and below. We could then create a new "Profile Manager application" or "Profile Manager utility" article and link to it, just like we have for the MozBackup standalone utility. Alice 14:10, 21 January 2011 (UTC)