Knowledge Base changes: Difference between revisions

From MozillaZine Knowledge Base
Jump to navigationJump to search
Line 154: Line 154:


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)
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, and possibly a more prominent link to the "About" page. This is what is written in the first paragraph of the [[MozillaZine_Knowledge_Base:About | "About MozillaZine Knowledge Base" page]] linked at the bottom of the registration page (looks like the registration page has plenty of room for it) and I like the friendly tone: <p>
: 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>
:''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>
:'''''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)
: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)

Revision as of 21:43, 7 March 2006

Introduction

This page has been created for several reasons.

  • It would be nice to have a place where new editors can introduce themselves and meet existing editors.
  • It would be good to allow new editors to safely propose content changes (minor or major) prior to implementing them.
  • It would be good to have a central location to discuss the style, content and organisation of this Knowledge Base. (Some of the ideas in Talk:Knowledge Base can be migrated here, leaving that page solely for discussion of the front page article itself.
  • This page is an attempt to address recent 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.

We intend to place a link to this page in the "welcome to new editors" paragraphs found on the front page and from the other "entrance" pages such as Firefox and Thunderbird if it is deemed useful.

We anticipate this page being the primary place to announce new suggestions. Please visit it regularly!

Welcome to new editors

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

  • Hello Knowledge Base! FJ reporting to duty! *bows at all* FatJohn 11:30, 3 January 2006 (UTC)

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)

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 category automatically list the articles. There was no opposition to removing the Tips pages.

The suggestion to temove 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)

Hot topic—the new front page

See Knowledge Base and Talk:Knowledge Base.

New proposal—implementing "browse by UI feature" system for Firefox articles

See Firefox components and Talk:Firefox components.

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)

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)

  1. 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)?
  2. If they are to be treated as two distinct products, should we normally refer to them using both product names ("Mozilla Suite and SeaMonkey")?
  3. If we decide to normally use just one product name (either "Mozilla Suite" or "SeaMonkey") to refer to both, which name should we use?
  4. Should any special guidelines apply to the Preferences articles (different from those for the regular user-support articles)?
  5. 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)

  1. 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.
  2. No. Using both names all the time would be awkward (except perhaps in a simple template like this).
  3. SeaMonkey. That will seem the obvious choice two years from now.
  4. Not sure.
  5. No. I can't see any benefit in doing this.

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

  1. In general, as two products, similar to the way Netscape 7.xx and Mozilla Suite are treated.
  2. 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.
  3. ---
  4. 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.
  5. 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—"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)


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


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)