Knowledge Base changes: Difference between revisions

From MozillaZine Knowledge Base
Jump to navigationJump to search
(added comments on less daunting for new editors)
Line 62: Line 62:
:::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)
:::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)
::::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)


==New proposal—"Startup and performance" category==
==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]]. --[[User:Wintogreen|wintogreen]] 11:15, 5 January 2006 (UTC)
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)

Revision as of 11:54, 16 January 2006

Temporary 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'll look into these suggestions soon! --Mozcerize 17:50, 10 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.

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.

I don't think creating a thread will help attract new editors. 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).

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)

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

Discussion of this proposal can be found on Talk:Rules/Categories). Some editors were not aware of this discussion (see Talk:Issues with Firefox and Talk:Rules/Categories#Flattening the Thunderbird categories). This was the main motivation for creating this page.

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.

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)

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)

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)