Knowledge Base changes: Difference between revisions

From MozillaZine Knowledge Base
Jump to navigationJump to search
 
(164 intermediate revisions by 9 users not shown)
Line 4: Line 4:
*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. 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.
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]].


Once suggestions are resolved, they are moved to [[Knowledge Base changes/Archive]].
You can request somebody create an article at [[Requested articles]] .


==Welcome to new editors==
==Copyright/License problems==
Hello! Great to have you here. Please add a comment here :-)
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)


* Hello Knowledge Base! FJ reporting to duty! *bows at all* [[User:FatJohn|FatJohn]] 11:30, 3 January 2006 (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.
* 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)


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)


==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]] [[User:Alice Wyman|Alice]] 14:36, 9 February 2009 (UTC)


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


==Knowledge Base changes==
==Replacement of Profile Manager==
A discussion by interested parties regarding the MozillaZine Knowledge Base, in the context of planning for improved Mozilla end-user support, is taking place. Details at http://groups.google.com/group/mozilla.support.planning
<snip>
Forum discussion of end user support, including the KB, [http://forums.mozillazine.org/viewtopic.php?t=494282&start=75 here]. [[User:Alice Wyman|Alice]] 12:34, 8 May 2007 (UTC)


'''Update:''' Minutes of the end-user support meetings were posted to the [http://groups.google.com/group/mozilla.support.planning mozilla.support.planning newsgroup], along with an announcement linking to drafts of a [http://wiki.mozilla.org/Support:Overview Firefox Support Overview] and [http://wiki.mozilla.org/Support:PRD  Support Product Requirements Document].  Proposals related to the KB include one log-in for forums and knowledge base management, account levels (admin, senior moderator, moderator, senior editor, editor, volunteer) as well as analysis and metrics to include top viewed articles (problems).  Division of articles into  "How To’s" (tutorials or best practices initially populated with content from “Firefox Help”) and "Troubleshooting" (“support” that helps users solve problems) was proposed, with the troubleshooting section being initially populated with ''MozillaZine Knowledge Base content that will be organized in a tagging structure that incorporated most frequently accessed questions''. Creation of ''KB style guides'' and ''editorial approval processes'' for content and style were also proposed. See http://wiki.mozilla.org/Support:PRD#Knowledge_base_requirements for details. [[User:Alice Wyman|Alice]] 10:57, 18 May 2007 (UTC)
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.


==Resolving logjams==
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.
We seem to be doing a good job of avoiding editing wars but not having a process to resolve logjams prevents us from improving some articles quality. The proposed [http://kb.mozillazine.org/Dispute_resolution_process dispute resolution process] is not the right vehicle to do that since its basically a way to deal with people behaving badly. Nobody is behaving badly with a logjam, they're just not making any progress and there is no obvious way to resolve the issue.  


A good example is [http://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird Plain text e-mail - Thunderbird], written by Guanxi . It basically redefines plain text messages as non-MIME ASCII messages, which doesn't meet the needs of most of our users. Rod Whiteley wrote [http://kb.mozillazine.org/Mail_content_types Mail content types] which overlaps some of that article, and has more of a end user focus. There seem to be two process problems:
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?


# We don't have any recourse if a author strongly disagrees with feedback in the talk pages without running the risk of editing wars and/or needless aggravation.  
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)


# The two authors agree it would make sense to merge the two articles but can't agree on a process to do that.
:I've already added this note to the top of the [[Profile Manager]] article:<br>
 
:{| {{prettytable}}
:''Note: The [http://kb.mozillazine.org/Talk:Mail_content_types talk page for mail content types] has most of the discussion about merging the articles and issues with the plain text article. I'm clearly biased, but that helps make my point. I originally gave up trying to get Guanxi to make some changes when it just seemed to pointlessly aggravate him, over a year ago''.
 
If we can find a good way to resolve logjams (that doesn't run roughshod over peoples feelings or get abused to force one point of view) that might make it easier to make some progress on quality control and user feedback issues. Suggestions? [[User:Tanstaafl|Tanstaafl]] 09:57, 9 May 2007 (UTC)
 
: You said that, ''The proposed [http://kb.mozillazine.org/Dispute_resolution_process dispute resolution process] is not the right vehicle to do that since its basically a way to deal with people behaving badly.''  I never thought of it that way.  I said [[Knowledge_Base_changes/Archive#Ownership_and_dispute_resolution |here]] that, ''Such a mediation request could also be looked at as a request for "quality review" of the article, since after all, what we really want is for the article to be well written, understandable by the intended reader and technically accurate.'' The same conflict resolution process applies. 
:You also said, ''The two authors agree it would make sense to merge the two articles but can't agree on a process to do that.''  In this specific case where two articles overlap,  if I were mediating the dispute I would suggest that the overlapping content be removed from the more recent article ([[Mail content types]] created by Rod Whiteley on 28 January 2007)  and added to the original article ([[Plain text e-mail - Thunderbird]] first edited by  Guanxi 2 February 2005).  If the more recent article contains enough information to justify a new article it could be rewritten with just the new content; alternately,  the two articles could be fully merged into the original article, whatever works best.  A draft of the merged article could be worked out on the original article's discussion page or either user's page, whichever works for both parties, similar to the way the [[Error loading websites]] article was merged on my [[ User:Alice Wyman/Proposed article |user page for proposed articles]], as discussed in [[Talk:Error_loading_websites]].  [[User:Alice Wyman|Alice]] 18:21, 9 May 2007 (UTC)
Without having any guidelines or someone in charge, the way to resolve these issues is through compromise and majority rule. I'm sure you've already tried compromise, so all that's left is majority rule. Majority rule is more palatable the more people concur. I'll read up on the subject and throw in my opinion to see if that helps to resolve things.--[[User:Np|Np]] 19:58, 9 May 2007 (UTC)
 
The point I was trying to make about the dispute resolution process was that if the authors were behaving badly you can force them to let somebody mediate the dispute etc. or suffer the consequences. However, nobody is behaving badly, and if they're not interested in the dispute being mediated (which carries a certain stigma , is a unpleasant process, and assumes there is a neutral mediator available they both can agree on) or can't agree on a compromise then we need other mechanisms. That seems to leave either organized social pressure or some form of majority rule. [[User:Tanstaafl|Tanstaafl]] 22:11, 9 May 2007 (UTC)
 
:I see your point, you want a quality review process, as you said,... ''not having a process to resolve logjams prevents us from improving some articles quality.'' You don't necessarily want social pressure or majority rule unless the individuals exerting the pressure are known to have the technical expertise in the subject area.  Ideally, you would have a quality control  committee that will review an article, find deficiencies (factual, in-house style, etc) and then make a decision that includes references to back up disputed information.  The reviewer(s) can either fix the article or issue a recommendation for a rewrite that carries weight.  Hopefully, if or when Mozilla takes over the KB such a process can be put into effect.  [[User:Alice Wyman|Alice]] 22:44, 9 May 2007 (UTC)
 
:If user A and user B don't want the dispute mediated, then tough on them, they can fight continue to fight each other until one gives up. If people don't want to get the dispute resolved, I don't really care to force a resolution on them. If user C came along and said "hey, I agree with user A, I'm going to go through the process to get the changes done", then we go through the process and whatever is decided, user A and user B have to live with.--[[User:Np|Np]] 15:48, 10 May 2007 (UTC)
 
::While a "quality control committee" might make sense for Mozilla (who have more resources, direct access to the developers, and are a corporation) I'm leery of a bureaucratic approach. It centralizes power, and imposes their judgment (even down to small details) on what a good article is. Given our current situation I think a more appropriate approach might be one focused on breaking up logjams by forcing a resolution of the key issues (rather than trying to improve everything in the article) or bringing attention and resources on articles that either need significant rework (based on evaluating user or editors feedback) or updating (due to changes in the application) and then get out of the way and let the author(s) do their stuff. If something like that works then later on we can always try ratcheting it up another notch. We might eventually wind up with a "quality control committee" thats reviews articles and makes detailed judgments about how to improve them, or we might not.
 
::Continuing Np's example, I'm user C. I see a logjam that serious enough that I want somebody to force a resolution, one way or another. Hopefully logjams will be much rarer than articles that need significant rework/updating, so I could identify a potential logjam using this page (which gets more scrutiny). While we might not have experts in that area we do have experienced editors with the right general background. I would hope that if we get a large enough group to deal with the problem that people aren't worried about bias, retribution (if you don't agree with me I'll get my friends to nominate lots of your articles) or lack of specific expertise. We'd need some sort of screening to push back on frivolous or inappropriate requests, some way to form the group when needed, a simple process to make a decision, and the ability to appeal to the sysops if you think the process was abused. Another issue would be how does the group discuss what to do without interference from the authors. Most of the tools for blocking and protecting a page seem too coarse. [[User:Tanstaafl|Tanstaafl]] 00:16, 11 May 2007 (UTC)
 
:::A fairly good criteria to weed out frivolous requests would be to simply see if there was any discussion about the problem on the talk page. That way, if someone wanted to get "retribution" by nominating a lot of someone's articles, they would have to write and defend critiques of each and every article, which is actually a good thing.--[[User:Np|Np]] 14:57, 14 May 2007 (UTC)
 
===Article review process===
Tanstaafl, you said, ''While a "quality control committee" might make sense for Mozilla (who have more resources, direct access to the developers, and are a corporation) I'm leery of a bureaucratic approach.  It centralizes power, and imposes their judgment (even down to small details) on what a good article is''.    I suppose you're right,  an "arbitration by committee" approach might be better when "people are behaving badly", as the [[Dispute_resolution_process#Steps |final step in the dispute resolution process]].  Still, I'm in favor of a structured quality review process, as I've said before, not only to systematically review articles when major changes occur, such as happened when Firefox 2 came out, but to see if the quality of all articles can be improved.  My thinking was that a Quality Control  committee would ideally have members that are technical experts in Mozilla applications but, as you said, ''While we might not have experts in that area we do have experienced editors with the right general background.''  I see your point  how nominations of articles for quality review by a QC committee might be used as a threat by editors with "friends on the committee".  Instead of a "commitee", we could use an open forum, such as we use when articles are nominated for deletion.  I guess we could tag the article with  a "[http://en.wikipedia.org/wiki/Wikipedia:Request_for_comments Request for comments]" template (from the wikipedia article:  
''An RfC on article content is for helping to develop consensus or for gaining an outside perspective to help settle a deadlocked disagreement or make a better decision'') as I mentioned [[Knowledge_Base_changes/Archive#Quality_Control |here]]:
{| {{prettytable}}
|-
|-
|Correct me if I'm wrong but right now,  articles are only updated or reviewed if someone comes across it and notices something amiss, or if it comes up in the recent changes list. That's why I mentioned a feedback process for non-editors, so that errors or problems get noticed. On way that articles  get reviewed as a part of a group effort right now is if someone nominates it for deletion. I would at least like to see a system set up so that articles can be nominated for quality review. Nominating an article for quality review or [http://en.wikipedia.org/wiki/Wikipedia:Request_for_comments requesting comments from other editors] about article content could also be part of a dispute resolution process in the case of conflicting opinions about what information should be included or removed from an article  or how the article content should be organized.
|'''''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]''
|-  
|-  
|}
|}
The downside of that approach would be that each "voter" might not have the same level of expertise as the persons who wrote the article, compared to review by a committee of experts.  I'm just trying to come up with a process that everyone can respect as fair.  We don't need to alienate editors, goodness knows we need all the help here we can get.  [[User:Alice Wyman|Alice]] 13:36, 11 May 2007 (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)
 
:A "quality control committee" approach seems to tacitly assume the "real" problem is authors making poor decisions (lack of technical expertise, poor writing skills, lack of feedback, poor process control, don't know how to properly analyze user feedback etc.). I don't think we're that successful yet, we're still being held back by lack of resources and not being able to make good use of those we have.
 
:The request for comment tag approach is interesting. However, I think it suffers from the same problem we have with the update tag and whatever the tag is for saying that a article doesn't meet Wikipedia quality standards. In practice, somebody needs to look at the article to notice the tag.
 
:While it would be great to have a system of feedback from ordinary users (other than the discussion page) I think we can do a lot without it. How about something as simple as a page devoted to nominating articles that need rework or updating? Anybody adding an article to that list would add a short paragraph specifying why you're listing it and maybe give it a severity rating. There would be no guarantee that when you nominate an article that whoever fixed it really did what you wanted, but it could be a quick and easy way to bring attention and resources to bear.
 
:I'm aware of a couple of Thunderbird articles that need updating but I keep procrastinating since they're not about something I'm interested in and would also require me to do an hour or so of research. Its so much more tempting to write a new article or do a quick fix on an existing article instead. However, if I added them to the list somebody else who felt differently might do the work. I assume I'm not the only one in that situation. It might also help if somebody tried to organize a review of all of a applications articles after a major upgrade. Its a lot easier to ask somebody to read an article and make a note of any problems (they don't have to be problems due to the update) if they're not on the hook for making any of the changes.
 
:I suspect this approach would work best for out of date or broken pages, logjams, or ineffective pages than identifying how to improve so-so pages. But it would be a start, and a lot easier to implement. [[User:Tanstaafl|Tanstaafl]] 00:34, 12 May 2007 (UTC)
 
::: ''How about something as simple as a page devoted to nominating articles that need rework or updating?'' That's kind of what I had in mind, a "Pages that need revision" (or whatever you want to call it) page, in addition to the article tag asking for comments that links there,  just the way we do it for [[Pages voted for deletion]].  Discussion could be kept on the  "Pages that need revision" page and, once a certain time period has elapsed to allow for comments, either the person initiating the request or another interested editor can go ahead and update the article.  Any comments would then be copied to that article's Talk page before clearing the discussion.  [[User:Alice Wyman|Alice]] 01:08, 12 May 2007 (UTC)
 
::: It sounds like I was reading something into "quality control committee" that you didn't intend. Sorry about that. A couple of questions.
::::OK but before we get too far on this,  I just want to say that I never thought that any "articles needing revision" list or waiting period is needed for anyone wanting to do a major article revision.  When I see something that needs fixing, I just go ahead and do it and document it on the discussion page if it may be controversial.  I just figured someone who noticed a problem with a page might prefer bringing it to everyone's attention if he wanted more input before revising it or if he was too busy or did't want to do the revision  himself.  (There was also some talk on the [http://groups.google.com/group/mozilla.support.planning mozilla.support.planning] newsgroup about getting an inventory of KB articles, including those that needed fixing, so I thought maybe our own list would be helpful!) [[User:Alice Wyman|Alice]] 21:11, 13 May 2007 (UTC)
 
::::* Why do you prefer to have the discussion in the "Pages that need revision" page rather than the articles discussion page? I had been thinking of deliberately keeping a short list in that page to make it easier to scan for articles that a person might be interested in helping out on. Either approach would work, I just want to understand your thinking.
:::::**On where to discuss proposed revisions,  I was simply trying to keep the analogy going with the "Pages voted for deletion" approach.  Just  a short paragraph outlining what needs revision with a link to the particular article's own discussion page would be fine. [[User:Alice Wyman|Alice]] 21:11, 13 May 2007 (UTC) 
 
::::* I can see the benefit of waiting for comments when trying to improve a ineffective page or when there are conflicting opinions. Are you suggesting we should do that too when an article is out of date or is just a stub?
:::::**I would prefer this to be a separate page for articles that have quality issues or need major revision, and tag them with a "request for comments" template (and possibly a "needs revision" category?) so we can keep track, then wait a reasonable  time before someone that wants to fix the article goes ahead with the revision.  This isn't "asking for permission", it's gathering input so that the article can be improved.  Articles that need to be cleaned up for style and formatting or those that need some updating but don't need major revision wouldn't get a "request for comments" tag,  just the "cleanup"or  "update" tags and categories we already use.  Stub articles should already be tagged as stubs and  don't need to be listed here either.  Maybe a  "stub category" can be used as a way to keep track of stubs (if that is what we want to do)  and if no one expands them they can  be  nominated for deletion (that's what [[Stub articles]] says).  [[User:Alice Wyman|Alice]] 21:11, 13 May 2007 (UTC)
 
::::* Based on the quote for a "Request for comments" template I assume that covers logjams too. Are you suggesting that I could nominate the plain text article, wait a week for comments and then just do what I think is right (merge the two articles etc.) as long as there is a token appearance of a consensus? That doesn't seem right. Could you elaborate on how you think a decision should be made? Please include the possibility that one of the authors doesn't notice (for whatever reason) that their article has that template.
:::::**That's exactly what I'm suggesting, just ask for comments, then do what you think is right.  If you indicate that you propose merging the articles and if  no one responds to a request for comments, I see no reason why you or any author couldn't just go ahead and merge the articles or make other changes.  [[User:Alice Wyman|Alice]] 21:11, 13 May 2007 (UTC)
 
::::* You'd prefer just one template? An alternative would be one for updates, one for articles that somebody thinks are substandard but there is no "real" conflict (a good example would be somebody just wrote a stub), and those where there definitely are conflicting opinions.
:::::**Just one "request for comments" template (which possibly adds it to a category list) that  states that someone is requesting or proposing major revision of the article, with a link to the "Articles needing revison" page.  We already have "cleanup" "update" and "stub" templates.  I would rather keep this list for articles that need major revision with an eye on improving quality.  [[User:Alice Wyman|Alice]] 21:11, 13 May 2007 (UTC)
 
::::* What guidelines would you suggest on whether a "request for comment" is appropiate? [[User:Tanstaafl|Tanstaafl]] 11:59, 12 May 2007 (UTC)
:::::**I don't think we need any guidelines, do we?  We're just asking for comments about an article that someone feels needs revision.  We could maybe just add a short description of the new template in the [[Rules/Templates]] article. [[User:Alice Wyman|Alice]] 21:11, 13 May 2007 (UTC)
 
:We have cleanup, update, and stub templates but they don't seem to be widely used and unless you browse the article there doesn't appear to be a convenient way to find them (there is no page listed in http://kb.mozillazine.org/Special:Specialpages for example).  I think a lot of this discussion has been because I keep trying to mingle making it easy to find articles that need work with the rfc template, which is what you're proposing for article reviews.
:: We have [[:Category:Articles to clean up]] and [[:Category:Articles to update]] (adding either of these templates to an article also places the article in the associated category) so those category pages can be used to find those articles.  I don't see a category for stub articles, though. [[User:Alice Wyman|Alice]] 22:16, 14 May 2007 (UTC)
 
:One of your answers states the rfc template is meant for gathering information, and not getting permission to do something that another author objects to. That would make the article review process very simple. However, another answer states that logjams are part of article reviews. The two answers contradict each other. From my viewpoint I have the information necessary to merge the plain text and mime content types articles. So I'd have no need to add a rfc template though I could do so. But I don't think its appropriate for me to do that unless there is a clear consensus. That the reason why I asked the question about guidelines.
::We can use a  "request for comments" template  for a number of purposes, including gathering input from other editors to settle disputes among active editors, "kick-starting" a logjam and eliciting ideas to improve articles that are perceived to have quality issues.  Wikipedia uses separate processes such as "[http://en.wikipedia.org/wiki/Wikipedia:Peer_review Peer review]" and "[http://en.wikipedia.org/wiki/Wikipedia:Pages_needing_attention Pages needing attention]" for different situations but I think we can use one simple "Request for comments" (or whateer you want to call it) category since we're a small group. [[User:Alice Wyman|Alice]] 22:51, 14 May 2007 (UTC)
:I suggest we
::* Create Cleanup, Update, Stub, and Request for comments categories.
::* Don't create a "Articles needing revision" page since if somebody wants to be notified when somebody is requesting comments they can just navigate to "Request for comments" category and click on Watch.
::* Create a "rfc" template, mention it in http://kb.mozillazine.org/Rules/Templates, and also state which templates have categories.
::* Add a paragraph to http://kb.mozillazine.org/Rules about article review.
::* Plan on all of the article review taking place in the articles discussion pages.
::* Deal with the issue of logjams in the logjam discussion. [[User:Tanstaafl|Tanstaafl]] 10:44, 14 May 2007 (UTC)
 
:: I agree with all of the above, except as I mentioned,  we already have categories for [[:Category:Articles to clean up]] and [[:Category:Articles to update]].  [[User:Alice Wyman|Alice]] 22:16, 14 May 2007 (UTC)
 
:: I just wanted to add that your idea to <u>not</u> create a separate  "Articles needing revision" page to keep track of  articles, and instead, to use a "Request for comments" category page, makes sense.  When we do create the "Request for Comments"  category, it might be a good idea to add a paragraph to the category page, along the lines of explaining that these articles need input from other editors to settle disputes or resolve logjams about article content and to gather ideas to improve article quality, just to clarify what the category includes.  [[User:Alice Wyman|Alice]] 22:33, 14 May 2007 (UTC)
 
I see that a new [[:Category:Request for comments]] has been created.  Is a template also in the works, similar to [[Template:Cleanup]]? I would suggest something like this:
<div class="boilerplate metadata" id="cleanup" style="background: #f7fbff; margin: .5em 2.5%; padding: 0 1em; border: 1px solid #79b">
Comments are being requested to either resolve a deadlocked disagreement or to help develop a consensus for improving the quality of this article.  Please add your comments to the discussion page.  Once all issues are resolved and the article has been revised you may remove this message.
</div>
(Looking at how the "Cleanup" template is made, I guess you would also add <nowiki>[[Category:Request for comments |{{PAGENAME}}]]</nowiki> to the template to automatically add the category).  [[User:Alice Wyman|Alice]] 20:56, 17 May 2007 (UTC)
 
:I created the Request for comments template and modified the Stub template. I just need to update http://kb.mozillazine.org/Rules/Templates . [[User:Tanstaafl|Tanstaafl]] 11:09, 18 May 2007 (UTC)
 
==Screenshots - confusion?==
I'm worried about us posting screenshots of dialogs to describe how to do something and some poor granny trying to actually click on buttons in the screenshot. What can we do about this?--[[User:Np|Np]] 16:59, 18 May 2007 (UTC)
: I don't think there is much we can do to prevent people from making silly mistakes, except maybe to add something like  "Sample image: do not click" to each screenshot ..... it's funny, because I've tried using scroll bars on screenshots myself, on occasion :-D [[User:Alice Wyman|Alice]] 19:44, 18 May 2007 (UTC)
 
==Application specific articles==
I've noticed a recent trend towards having more articles be application specific. My first impression is that this seems to be due to
 
* Recent awareness that you can include screen shots in the article. [[Creating_a_new_Firefox_profile_on_Windows]] and [[Corrupt_localstore.rdf]] for example are articles that at one time would have at least been written to cover both Firefox and SeaMonkey, and might have also covered Thunderbird.
* Frustration over the density and problems in navigating an article that cover many applications, such as [[Profile_folder]]
* Mozilla's plans to create their own knowledge base, using migrated Firefox articles from mozillaZine.
 
I've frequently pushed for Thunderbird specific versions of some articles, including one for [[Profile_folder]] but I have mixed feelings about this trend. There are some cases where it makes a lot of sense to address multiple applications in one article. I'm also concerned over what effect this has on whether editors who tend to focus on browser specific articles will continue working on the mozillaZine knowledge base after Mozilla creates their own for just Firefox. Thoughts?
 
As an aside, does anybody object to my creating a calendar category?  [[User:Tanstaafl|Tanstaafl]] 22:28, 18 May 2007 (UTC)
 
:I can see advantages in combined application articles such as [[Profile Folder]].  One reason being, the same files may be used in different application profiles (in some cases they can be copied over directly, as with mimeTypes.rdf and bookmarks.html).  Firefox users are in the majority, though,  and it's hard for editors  who don't have  experience with Mozilla Suite or SeaMonkey to include it in articles.  I use SeaMonkey about as often as I use Firefox (and I still have Mozilla Suite installed as well) so I try to include SeaMonkey where possible,  such as in plugin articles.  In the case of [[Changing media handling behaviour]] I've included screenshots for both Firefox and SeaMonkey.  Regarding ''Mozilla's plans to create their own knowledge base, using migrated Firefox articles from mozillaZine'',  when that happens and if my contributions are no longer needed for Firefox articles because Mozilla folks have taken them over and restrict new articles to selected editors, I can always go over to SeaMonkey and start fixing up that KB a bit.  [[User:Alice Wyman|Alice]] 00:39, 19 May 2007 (UTC)
 
:I think combined application articles are good when the info provided only differs slightly, for example by a [[Object has been blocked|single menu sequence]]. In [[profile folder]], about half the article doesn't apply to any given user. [[Creating a new Firefox profile on Windows]] was created not to avoid mentioning SeaMonkey, but to avoid the "but if"s, "except if"s , and "you can also"s that plague the profile manager article.--[[User:Np|Np]] 01:41, 19 May 2007 (UTC)
 
=="What's stopping you" feedback==
I made a post on the [http://forums.mozillazine.org/viewtopic.php?t=555200 forums] and the [http://groups.google.com/group/mozilla.support.planning/browse_frm/thread/417c48909b8d17ed support planning newsgroup] asking why people who have the knowledge don't contribute to the KB. I'm going to post here the results, and we can discuss what can be done about it.--[[User:Np|Np]] 16:41, 5 June 2007 (UTC)
 
===Don't have an account [http://forums.mozillazine.org/viewtopic.php?p=2912094#2912094][http://forums.mozillazine.org/viewtopic.php?p=2915425#2915425]===
We should turn user account back on. We had turned it off a while ago because of bot spam. Now that we run MediaWiki 1.6, we can use [http://www.mediawiki.org/wiki/Extension:ConfirmEdit ConfirmEdit] to stop bots with captchas.--[[User:Np|Np]] 16:41, 5 June 2007 (UTC)
: I filled in for you for a while as the contact point to get accounts and have watched the log file to see how often they contributed. My impression is they typically made a few minor edits and then disappear. I'm not as comfortable as you are that the capthca will do a decent job. So I don't buy the argument that the hassle of having to send a email message is causing a major problem, especially since there is a disproportionate amount of contributions from a few editors. I've also had to jump through similar hoops to join many forums. I'm far more concerned about what discourages a editor from contributing more often, or writing an article. [[User:Tanstaafl|Tanstaafl]] 21:25, 5 June 2007 (UTC)
:: ''I'm not as comfortable as you are that the capthca will do a decent job.'' A decent job of doing what? I don't think we want to limit who can edit the articles. That's actually the impression that we're putting out there by requiring an e-mail. I've had quite a few people mail me their requests with credentials, as if trying to prove that they're worthy.  The current system:
::* Wastes my time
::* Wastes the users' time writing me an e-mail and waiting for my response
::* Possibly dissuades new editors (because they think they need credentials)
::* Possibly dissuades users from posting comments on articles
:: The only downside I can see to going to the captcha would be we wouldn't prevent the clueless who try to edit the pref articles and the like. That wasn't that big of a problem before we disabled creation, though.--[[User:Np|Np]] 23:09, 5 June 2007 (UTC)
::: "A decent job of doing what? " - A decent job of preventing spammers from vandalizing our articles. I've read several articles about how how spammers get around image based captchas, it appears to mainly be a question of is it worth their effort. This [http://www.silicon.com/research/specialreports/thespamreport/0,39025001,39120541,00.htm article] is just one example of the ingenuity that some sites need to deal with. I would feel much more comfortable if you had some data from other wiki's about that captcha's effectiveness rather than just speculation that we need this to get more editors.
 
:::I averaged one account request every two days. Our welcome mat isn't out, I suggest we change the text at http://kb.mozillazine.org/MediaWiki:Loginprompt and the thread in the mozillaZine site discussion post to make it explicit that anybody can have an account, while discussing this issue. [[User:Tanstaafl|Tanstaafl]] 00:22, 6 June 2007 (UTC)
::::Yes, spammers can get around captchas. They can get around pretty much anything. It's a case of  how hard they're willing to try. I'm thinking that the spam we were getting was spambots set up to do that to any MediaWiki installation, not specifically us. We could set up the captcha system, and if it works, good, and if it doesn't, then we can go back to what we use today.--[[User:Np|Np]] 01:53, 6 June 2007 (UTC)
::::I've edited the login screen, but I can't edit the sticky because it's locked.--[[User:Np|Np]] 03:52, 6 June 2007 (UTC)
::::I edited it for you, using the same sentence you used in the login screen. If you want something different, send me a private message when you want it unlocked, and then again when you want it locked. [[User:Tanstaafl|Tanstaafl]] 06:09, 6 June 2007 (UTC)
 
===Don't know how to write articles[http://forums.mozillazine.org/viewtopic.php?p=2912094#2912094][http://forums.mozillazine.org/viewtopic.php?p=2913895#2913895]===
Perhaps we should add a basic intro on how to do it? I know we have all the rules and style guidelines and stuff, but I think we need something aimed at new users to encourage them to do it. Perhaps we can create some sort of comprehensive "Here's how to work the KB" with appropriate levels of detail that includes many of the articles in [[:Category:MozillaZine Knowledge Base organization]].--[[User:Np|Np]] 16:41, 5 June 2007 (UTC)
: That seems like a good idea. [[User:Tanstaafl|Tanstaafl]] 21:25, 5 June 2007 (UTC)
:: We could improve [[MozillaZine Knowledge Base:About]]. It seems to have the beginnings of what I'm talking about. We could also make it more prominent, like putting it on the registration page.--[[User:Np|Np]] 23:14, 5 June 2007 (UTC)
:::Sounds good. I'd also suggest something like a link to a guide for new editors that actually points to that article in the paragraph at the top of [[Knowledge_Base]]. Having a link labeled "About" is too easily ignored. [[User:Tanstaafl|Tanstaafl]] 00:36, 6 June 2007 (UTC)
I've made changes to that page. Let me know what you think.--[[User:Np|Np]] 17:14, 6 June 2007 (UTC)
 
: Looks good, useful. Some minor comments:
:* Its a Discussion link, not a button.
:* It says to "press the Signature button on top of the text box (the second one from the right)". It took me a while to figure out you meant the next to the last of the blue icons above the edit window, "text box" didn't mean anything to me until after I had figured out which icon you meant. I don't know whether "text box" is a better or worse description than "edit window", but I had nothing to give me the right context. I don't know whether I mis-interpreted a "signature button" as meaning a standalone button (not a button in the toolbar), and whether I got that "the second one from the right" was talking about the signature button instead of which text box. All I know is that for a good while I just didn't get it. In fact I initially started to write a comment that I never heard of a signature button and couldn't find it (I always type <nowiki>~~~~</nowiki> and usually use just the two leftmost buttons/icons).
:* You might suggest that one way to learn how to do things is to look at the source of another article. I never read the article on tables for example, I just copied and pasted a table from another article and modified it.
:* I suggest "Making big changes" be rewritten to lower the bar for what should be mentioned in Knowledge Base changes to be anything that effects other editors or might cause arguments, such as adding a new category. The example of a "a new categorization system" implies it would be okay if I decided on my own to move everything in the Preferences category into lots of child categories.
:If I have any further comments I'll make them in the articles talk page. [[User:Tanstaafl|Tanstaafl]] 03:12, 7 June 2007 (UTC)
::I've made changes to address all your comments, thanks.--[[User:Np|Np]] 08:15, 7 June 2007 (UTC)
A further theme seems to be that users don't want to do something wrong so they don't do anything at all. We should explicitly encourage users to post content even if it's not formatted properly or categorized correctly. As long as the content is accurate, I'd rather have it poorly formatted than not posted at all.--[[User:Np|Np]] 19:59, 5 June 2007 (UTC)
 
: I think we try to do that. Part of the problem might be the wiki itself. I remember when I first started editing articles how cautious I was because there was no place to get advice and I didn't want to embarrass myself with repeated failed attempts to do certain things showing up in the log. It also wasn't initially clear to me how you created a new article, or where it should be stored. I remember looking in the Wikipedia help and getting frustrated due to information overload, and it assuming you knew too much. I wasn't even aware that the Mediawiki help might be a slightly better resource. Perhaps we should consider something like the sticky  Moderation / Spam / Registration / Login Activation Requests thread as a place to ask for help/advice? It might be less threatening than asking in a dedicated article. It would also have more visibility. [[User:Tanstaafl|Tanstaafl]] 21:25, 5 June 2007 (UTC)
::Yes, kind of like a "KB Embassy" on the forums. We could include links to the intro and accept requests for (changes to) articles.--[[User:Np|Np]] 23:14, 5 June 2007 (UTC)
::[http://forums.mozillazine.org/viewtopic.php?t=556178]--[[User:Np|Np]] 08:15, 7 June 2007 (UTC)
 
===The interface sucks[http://forums.mozillazine.org/viewtopic.php?p=2912076#2912076][http://forums.mozillazine.org/viewtopic.php?p=2913000#2913000][http://forums.mozillazine.org/viewtopic.php?p=2913108#2913108]===
Maybe look into getting a new skin?--[[User:Np|Np]] 16:41, 5 June 2007 (UTC)
 
===No one talks about it[http://forums.mozillazine.org/viewtopic.php?p=2912413#2912413]===
See "Not seen as important".--[[User:Np|Np]] 16:41, 5 June 2007 (UTC)
 
===Don't think changes would be accepted[http://forums.mozillazine.org/viewtopic.php?p=2912413#2912413]===
Possibly related to not having an account, not knowing what to do, and "previous altercations".--[[User:Np|Np]] 16:41, 5 June 2007 (UTC)
 
===Previous altercations between members make it look unwelcoming[http://forums.mozillazine.org/viewtopic.php?p=2912435#2912435][http://forums.mozillazine.org/viewtopic.php?p=2913635#2913635]===
Should we really be discussing changes to articles anywhere other than on the KB itself?--[[User:Np|Np]] 16:41, 5 June 2007 (UTC)
 
:Yes. I've found it very useful to occasionally create threads seeking input for new articles that I'm going to write, or to ask for help getting the info needed to update an article. For whatever reason, many of the most frequent posters in the forum don't want to be editors but are very willing to help this way, especially if its on a topic they might have strong opinions on. For example, [[Keep_it_working_%28Thunderbird%29]] . On the other hand, I agree we shouldn't wash our dirty laundry in public. [[User:Tanstaafl|Tanstaafl]] 21:25, 5 June 2007 (UTC)
 
==="Attitudes towards volunteers"[http://forums.mozillazine.org/viewtopic.php?p=2912551#2912551][http://forums.mozillazine.org/viewtopic.php?p=2915173#2915173]===
Not sure what this means, considering AFAIK all KB editors are volunteers. There seems to be some animosity between the different support channels and towards Mozilla itself. Not sure any changes to the KB would help this.--[[User:Np|Np]] 16:41, 5 June 2007 (UTC)
 
===Poor organization[http://forums.mozillazine.org/viewtopic.php?p=2913108#2913108]===
This is more likely "Don't think changes would be accepted".--[[User:Np|Np]] 16:41, 5 June 2007 (UTC)
 
===Not seen as important[http://forums.mozillazine.org/viewtopic.php?p=2913108#2913108][http://forums.mozillazine.org/viewtopic.php?p=2914798#2914798]===
It's certainly important from Mozilla's perspective. Possibly not important to certain support channels because they have other methods of posting content (sticky threads, external websites, etc.) Should we make an effort to identify and migrate this external content?--[[User:Np|Np]] 16:41, 5 June 2007 (UTC)
 
: What external content are you talking about? My impression is that we try (perhaps not successfully) to port any information about profile folders and FAQs such as http://ilias.ca/netscape/profilefaq/ , and link to any tutorials we find.
 
:I interpret Nitin's comment as mainly saying we're not that useful because we're not the first support link, we force users to deal with information about multiple applications, and its too hard to find information. I have low expectations about most new users looking for answers in the knowledge base, especially when Mozilla starts their own knowledge base. What I think is more realistic is to make it a good tool for frequent posters in the forum to use as canned answers when helping somebody, and to make it useful for advanced users.
 
:I'm not saying we shouldn't try to make it more useful for new users, I just believe due to human nature and factors outside our control we're going to have limited success getting new users to look and find answers in the knowledge base. We've learned the hard way that many new users ignore a prominent sticky thread about their problem, and the knowledge base isn't organized like a traditional FAQ, so getting a new user to search categories for answers (especially when some have problems keeping straight the name of the application) can be a stretch. [[User:Tanstaafl|Tanstaafl]] 21:25, 5 June 2007 (UTC)
 
::I agree with your assessment of Nitin's  comments. I think his point of view is limited to what he sees in the forum. Other sources than the forum use the KB. Mozilla's support site already features KB content prominently.  And as you said, it's useful for helpers to look up information. If someone only sees the forum and the KB, then having content in stickies is just as good or even better than having content in the KB. Looking at the whole picture, though, it isn't. We need to encourage having the content in the KB, and having stickies in the forums just be links to that content.--[[User:Np|Np]] 23:22, 5 June 2007 (UTC)
 
::There's two issues here - one is importing useful external content, the other is encouraging the makers of that content to bring it to the KB themselves.--[[User:Np|Np]] 08:24, 7 June 2007 (UTC)
 
===Don't want contributions edited mercilessly[http://forums.mozillazine.org/viewtopic.php?p=2914798#2914798]===
Not sure we can do much about this one...--[[User:Np|Np]] 08:24, 7 June 2007 (UTC)
 
===Lack of guidelines[http://forums.mozillazine.org/viewtopic.php?p=2915425#2915425]===
Need elaboration.--[[User:Np|Np]] 08:24, 7 June 2007 (UTC)
 
===Do not contribute directly, provide feedback via other channels[http://forums.mozillazine.org/viewtopic.php?p=2916254#2916254]===
We should encourage this, like in the "KB Embassy" idea above. What would work for other channels?--[[User:Np|Np]] 08:24, 7 June 2007 (UTC)
 
===Think it's already being covered adequately[http://groups.google.com/group/mozilla.support.firefox/browse_frm/thread/b238d4ed22273279/57d80b320975d91e#57d80b320975d91e]===
 
=="The KB is too technical"==
One of the complaints I've heard many times about KB content is that it's too technical and complex. I think we should flesh out some guidelines regarding how technical we can be in the articles. The goal here is not to remove technical information, but to make it so non-technical users can read the KB without having to understand the technical bits. Some ideas:
# Don't assume that everyone knows how to do semi-complex tasks, such as setting a preference in about:config or finding the profile folder. When we need to tell people to do these things, either include step-by-step instructions on how to do them if it's short (setting a pref) or link to an article that explains it (finding the profile folder).
# Where multiple ways of doing something exist, present the easiest first. Present others if they have some sort of advantage over the easiest way. If certain options have no advantage over other options already presented, do not include them. Some examples:
##To kill a zombie process, the easiest thing to do is to restart the computer. Using the Task Manager requires more skill, but is quicker for those who already know how to use it.
##To set a pref, the easiest thing to do is use the UI if it exists. Next easiest is about:config, then editing user.js. Does user.js have any advantage?
# Where multiple options are given, present the information based on the type of person who would choose that option. Everyone knows how to restart their computer, so don't explain it. Everyone who would pick to use Task Manager instead already knows how Task Manager works.
# Where a technical process exists for doing something and a non-technical process doesn't, mark the process is "Technical" or "Advanced".
# Any choices we need the user to make that end with different results should include the pros and cons as it relates to the user. We don't need to give the pros and cons of restarting versus Task Manager because those give the same result. We do need to give the pros and cons of FooPlugin 2.1 versus FooPlugin 3.0, should we provide users the option.
# Keep technical "background" or "overview" information to a minimum, or keep it in a separate section labeled as "Technical" or "Advanced".
--[[User:Np|Np]] 20:45, 11 June 2007 (UTC)
 
:Nice ideas.  Can you show us the format you wish to use when marking something technical or advanced?
 
::I don't have any set format in mind. In a few of my recent edits, I just put (Advanced) in the section name.--[[User:Np|Np]] 02:45, 12 June 2007 (UTC)
 
:I have to say, though, that I like overviews, especially for troubleshooting.  Sometimes a little understanding is worth much more than someone blindly following the wrong procedure.  I agree, though, that an overview should be brief and nontechnical if possible.  --[[User:AnotherGuest.|AnotherGuest.]] 22:18, 11 June 2007 (UTC)
 
::I agree in general, but disagree with two recommendations. While we need to do a better job of deciding when and where to present technical information, not every article is written for the same audience. We need to be careful not to overreact to the real problems a non-technical user has in an article such as backing up your profile (where we push solutions that require you to find where your profile is, rather than recommending Mozbackup as the first choice) by dumbing down articles such as session logging.  --[[User:Tanstaafl|Tanstaafl]] 23:51, 11 June 2007 (UTC)  [signature added by AnotherGuest.  -- I think I got this right -- this article is getting shuffled]
 
:::It could say:
:::* Here (link) is where your profile is.  Keep a copy in a safe place.
:::or...
:::* Use the Mozbackup extension.
 
:::I don't like the idea of recommending extensions for what can be done without -- especially as the first or only alternative.  We don't want people to be dependent on third-party software, especially if they have a problem installing extensions, or they have to run in safe mode, etc.  The other software could also develop a problem. If users are intimidated by the first alternative, they can choose to install the extension.--[[User:AnotherGuest.|AnotherGuest.]] 19:12, 12 June 2007 (UTC)
 
::::Not having to be dependent on third party software is a valid reason to include information on how to do it manually, but I don't like the concept of "If users are intimidated by the first alternative, they can choose (the other)." If people are intimidated by the first option, they might stop reading the article completely, or post in the forums that they can't understand what it's saying, or try to do it anyway and get it wrong.--[[User:Np|Np]] 19:33, 12 June 2007 (UTC)
 
:::::Users should know how to copy a directory, although some will fail at ANY task.  Pictures help.  Nevertheless, which way do you want to do it wrong?  Give them something they might get wrong, or give them something else that they might get wrong, and that might fail for another reason?  Or just reverse the two alternatives?
 
:::::Truth be told, almost everything in the KB is too advanced for many users, and we risk overusing the label.  Is everything that's off the menu to be labeled as "advanced"?  Maybe backing up a profile is advanced.--[[User:AnotherGuest.|AnotherGuest.]] 20:45, 12 June 2007 (UTC)
 
::::::I'd prefer to give them the option that they're least likely to get wrong.--[[User:Np|Np]] 03:19, 13 June 2007 (UTC)
 
:::That's kind of what I was saying "present the information based on the type of person who would choose that option". I was applying it to options, but the same concept should be applied to articles. Non-technical users may want to back up their profile, but they're not likely to have even heard "session logging" and so are unlikely to even reach that article. A session logging article could still have an easy to understand intro and a notice that it's an advanced topic.--[[User:Np|Np]] 02:45, 12 June 2007 (UTC)
 
:::: It does have a easy to understand intro, and a notice that its an advanced topic. The very first sentence is "This article is about troubleshooting techniques for advanced users who are investigating problems with servers." It then goes on to explain when this is useful. '''I looking for some re-assurance that the current [[Session_logging_for_mail/news]] article is not an issue.''' That tells me that we both mean the same thing when talking about ''present the information based on the type of person who would choose that option''. [[User:Tanstaafl|Tanstaafl]] 08:36, 12 June 2007 (UTC)
 
:::::I've been trying to avoid talking about specific articles... I have no problem with the current [[Session_logging_for_mail/news]] article. The first sentence tells me exactly what I'm in for, and the subject is not something that can likely be simplified. The only change I would suggest would be to provide a link in the intro for people who are looking for general troubleshooting information, like "My Thunderbird can't connect to the server!", to read should they mistakenly think this is the article for them.--[[User:Np|Np]] 19:33, 12 June 2007 (UTC)
 
::Part of my concern is that most guidelines are actually treated as hard and fast rules.  I'm sure whoever drove the statement that pathnames should be in <nowiki><tt></nowiki> tags meant well, but if you try to make a document more readable by omitting them when it doesn't make sense some grammar nazi edits them. Thats the least of our problems, but its that type of reaction that worries me when certain statements are made.
 
:::I think my suggestions give a fair bit of leeway. In any case, if a valid reason is given on why to ignore one of the suggestions, that's fine. But in a dispute, reasons have to be given why these things should be ignored, otherwise there's no point in having suggestions at all.--[[User:Np|Np]] 02:45, 12 June 2007 (UTC)
 
::I try to advocate using the GUI, then about:config/config editor, and only then modifying prefs.js. I don't agree with some articles bias towards modifying user.js rather than prefs.js. All of the supposed advantages are frequently irrelevant since that type of person shouldn't be modifying a config file in the first place. If they are modifying a config file, the last thing you want to do is make the situation more complex by adding yet another file whose whole purpose is to modify prefs.js for you. My experience is that unless you're in an environment where somebody else deploys your profile you're better off not having a user.js.
 
::However, I don't think we should ignore prefs.js/users.js. Depending upon what you're doing sometimes it much easier/safer to modify related preferences in prefs.js than to use about:config/config editor. Especially if you're troubleshooting a problem or making wholesale changes to multiple accounts. [[User:Tanstaafl|Tanstaafl]] 23:51, 11 June 2007 (UTC)
 
:::You're explaining an advantage setting prefs.js/user.js has over about:config. If it's a valid statement, I see no reason why it couldn't be included. But the focus of the article would be more on UI or about:config. For such a common thing like setting prefs, we could figure out some format that works for most cases.--[[User:Np|Np]] 02:45, 12 June 2007 (UTC)
 
::::You misunderstand my intent. I think we agree that the normal focus should be on using the GUI / about:config. I was replying to your speculation about does user.js have any advantage, and also arguing that while editing prefs.js should be discouraged for normal users, it does have its place. Most articles that mention a preference would have no reason to even mention that you could edit prefs.js or user.js, but it should be mentioned in articles such as [[Editing_configuration]] and [[Modify_Thunderbird_settings]] and the occasional advanced section or technical article (which is not suitable for most users due to its subject).
 
::::I am trying to support your overall goal of making things less technical while making certain it doesn't go overboard. The basic problem seems to be that I don't see enough support for people using their best judgment (and talking about it if there is a disagreement), there seems too much stress on guilty until proven innocent. A lot of this is due to statements such as ''"In any case, if a valid reason is given on why to ignore one of the suggestions, that's fine. But in a dispute, reasons have to be given why these things should be ignored, otherwise there's no point in having suggestions at all"''. That quote makes it sound like you advocate slapping a cleanup template on every half-way technical article until somebody successfully defends it being written for a technical audience in the talk page. Most definitions of suggestion talk about influencing or mentioning something for people to consider, not mandating something must occur unless you can prove otherwise. [[User:Tanstaafl|Tanstaafl]] 08:36, 12 June 2007 (UTC)
 
:::::In the current state, when people have a disagreement, each side has to give reasons on why they believe something should be the way they're suggesting it be. If one side doesn't, they "lose" the argument. Do you understand the current state differently? What I'm proposing is a set of suggestions that anyone can point to in a disagreement as reasoning behind their point of view. The person who is more on the side of "non-technicality" doesn't automatically win, because there may be valid reasons to not follow the suggestions in that particular case. But if it comes down to "I think this article is too technical" vs. "I don't see any reason to not be technical", then that's different.--[[User:Np|Np]] 15:52, 12 June 2007 (UTC)
 
:''One of the complaints I've heard many times about KB content is that it's too technical and complex''.....'' make it so non-technical users can read the KB without having to understand the technical bits''  We really need more information about the skill level of the "non-technical users"  or which articles are being described as being too difficult.  A feedback mechanism built into each article would be helpful or, short of that,  a request for feedback as a support forum "sticky"  topic which would say something to the efffect that..... " If you are linked to a KB article which is too difficult for you to understand, please post the article name here and describe the problems you had"...... or something similar.  I doubt many people would respond but it's worth a shot.  We could then get a feel for the scope of the problem.  [[User:Alice Wyman|Alice]] 01:05, 13 June 2007 (UTC)
 
::Yes, a feedback mechanism would be very helpful, but would require technical changes that just aren't going to happen here. We do have a sticky in the site discussion forum, an addition to a support sticky might be useful as well.--[[User:Np|Np]] 03:19, 13 June 2007 (UTC)
 
:As to which articles should fall under any guidelines we might set up, I would suggest starting off by limiting these to "Issues" articles and possibly a few others.  I dislike the idea of a general guideline that applies to all articles, such as suggesting that we include a label to KB articles such as  "Advanced" or "Technical".  What I would prefer is to start with a limited set of articles that fall under a set of guidelines and  add to these a  "Tutorial" or "Support issue" label.  "Support issue" articles should be aimed at non-technical users, unless the article or article section is specifically tagged as "for Advanced users".  For example,  [[Creating a new Firefox profile on Windows]] would be considered a "Tutorial" and  [[Lost bookmarks]] would be a "Support issue" article.  The "Tutorial" articles should offer even more basic help, with step-by-step instructions and screenshots, if possible, for common tasks, compared to the Support issue articles.  These "Tutorials" could be linked from the "Support issue" articles or from other KB articles with an "If you need extra help" heading.    [[User:Alice Wyman|Alice]] 01:05, 13 June 2007 (UTC)
 
::Yes, this would apply mostly to support articles because those who want to read non-support articles are generally more technically inclined. I don't suggest labeling entire articles as being "technical", I intended that to be applied to necessary technical sections in otherwise non-technical, support articles. Technical articles just need something in the intro that describes what and who the article is for.--[[User:Np|Np]] 03:19, 13 June 2007 (UTC)
 
:''Where multiple ways of doing something exist, present the easiest first. Present others if they have some sort of advantage over the easiest way. If certain options have no advantage over other options already presented, do not include them''.  This seems to be overly rigid.  I like to present multiple methods even if one doesn't have an obvious advantage, and let the reader decide which he prefers or which he finds easier. [[User:Alice Wyman|Alice]] 01:05, 13 June 2007 (UTC)
 
::I disagree, I think that presenting options where one way works unnecessarily complicates things. We've been over this, so I don't think we need to rehash it.--[[User:Np|Np]] 03:19, 13 June 2007 (UTC)
 
::: You don't think we need to rehash it? You started off saying, ''I think we should flesh out some guidelines regarding how technical we can be in the articles. The goal here is not to remove technical information ...<snip>''.  I think we ''should'' rehash it if your goal is to come to a consensus on KB guidelines.  If majority rules, then where was a "vote" taken?  Even so, I think it should be "rehashed" again, since opinions change.    [[User:Alice Wyman|Alice]] 09:48, 13 June 2007 (UTC)
 
::::I just meant that I know I'm not going to convince you, and I don't think you're going to convince me... But you're right, I should put forward an argument so that others can decide.--[[User:Np|Np]] 14:54, 13 June 2007 (UTC)
 
::: Here's an example of an article offering multiple methods: [[Corrupt localstore.rdf]].  On the surface, you might be tempted to remove the "Alternate method" which involves finding the profile folder and manually deleting the localstore.rdf file, and keep the [[Safe Mode]] method, since it appears easier.  However, assuming this article also applies to MacOS,  starting Firefox in Safe Mode on a Mac involves using the terminal utility, which is likely more complicated than manual deletion of the localstore.rdf file.  I would let the user decide.  In any case, I think that a [[KB guidelines]] "draft" should be set up and discussion continued on its Talk page.  [[User:Alice Wyman|Alice]] 10:19, 13 June 2007 (UTC)
 
:::: I think that if manual deletion of localstore.rdf is easier for Mac users, then only that option should be presented to them. It's a tautology, but someone who is not familiar with the terminal or with finding the profile folder will not be familiar with the terminal or with finding the profile folder, and therefore has no knowledge to base a choice on.--[[User:Np|Np]] 14:54, 13 June 2007 (UTC)
:::::And I think that both options should be presented.  Who are we to decide for all users, which is the easier or better method?  I'm a novice Mac user and I'm somewhat familiar with the terminal and also minimally familiar with using OSX 10.2 to find files and folders.  Let me decide which method I want to use, not you. [[User:Alice Wyman|Alice]] 03:23, 14 June 2007 (UTC)
::::::"Who are we"? We're the experts, here to tell them how to fix whatever's wrong with their systems. The point I'm trying to make is that providing choice where the options are not understood and where the result is the same brings confusion.[http://www.joelonsoftware.com/items/2006/11/21.html]--[[User:Np|Np]] 04:58, 14 June 2007 (UTC)
 
:::: I'm against yet another document. I'd prefer to see fewer guidelines and that they are added to a short "Write for the appropriate audience" section in [[rules]]. I'd prefer Np didn't draft that. I suggest Alice draft that. Anything from Np's list that doesn't get added to that section (in one shape or another) could be proposed as an addition to [[In-house_style]] , and discussed in its talk page. I've taken the liberty of editing Np's list to have numbers so that I can refer to particular items. I think the topics brought up in 1 , 2 and 3 might be appropriate for "Writing for the appropriate audience" [[User:Tanstaafl|Tanstaafl]] 01:45, 14 June 2007 (UTC)
 
::::: I just assumed that np was going to draft some guidelines no matter who objected here, which is why I suggested he go ahead and do so, at which point we can comment on the proposal once it's "down on paper".  Even though np said that he's '''... been trying to avoid talking about specific articles..''  I think we do have to get down to specifics since that's the best way to see if "standards" or "guidelines" actually work.  I was going to then suggest that we nominate specific articles that np could edit in a sandbox and see whether the proposed guidelines "work".  I was going to nominate [[Lost bookmarks]]  [[Profile in use]] and [[Error loading websites]].  I mentioned these last two articles [[Knowledge_Base_changes/Archive#Quality_control_standards | here]] in the Archive; at the risk of rehashing:<br>
:::::* In his 7 December 2006 comment, np asked, ''... should support articles present easy information to users to get them going again, or should they explain things in detail? In what order should solutions be posted - easiest first or most likely first? Should solutions be referenced so we know editors aren't just making stuff up?'' then concluded, '' This is the type of policy we don't have that I think we desperately need. With an official policy on these things, users would be more comfortable changing "other people's" articles.''
:::::*  In reply, I said that I ''wouldn't want to set any specific standards for what to include in articles <snip> since you can't really generalize. Like I said before, what we really want is for the article to be well written, understandable by the intended reader and technically accurate.''
:::::* To which Majken asked me, ''I'm not sure why you're opposed to setting a standard of how an article's content should be arranged. I feel this is incredibly necessary. Not only does it make it easier for those wanting to contribute information to compose the article, having a standard format makes it much easier for users to find the information they need.'' 
:::::* To which  I  said, ''.. maybe you want to give an example of a standard for arranging the content that would apply to all these articles <snip> and we can discuss it from there:'' <list of articles>  at which point she stopped responding . [[User:Alice Wyman|Alice]] 03:23, 14 June 2007 (UTC)
 
::::: ''I'm against yet another document. I'd prefer to see fewer guidelines and that they are added to a short "Write for the appropriate audience" section in [[rules]]. I'd prefer Np didn't draft that. I suggest Alice draft that.'' Nah,  I'm getting KB burn-out.  I was going to edit a few more articles and then take the summer off.  [[User:Alice Wyman|Alice]] 03:23, 14 June 2007 (UTC)
 
:::::I was going to draft something up based on the feedback I got here, and then try to get feedback from a wider audience by posting it to the forum, newsgroups, IRC etc. I'd really like to get more than four people's opinions on this. A lot of people have been complaining about the quality around here, so I think at least some of them would be willing to provide input. Regarding "yet another document", I would like it if we could integrate whatever we come up with in existing documents, but I'm not sure how well it fits in with "Rules", which makes it sound like something editors ''must'' do, and only #4 seems to concern style.--[[User:Np|Np]] 04:58, 14 June 2007 (UTC)
::::::Thats called shopping for votes where I come from.  I suggest you lead by example, editing several of the most popular articles to make them less technical. That will provide something concrete that people can react to in the talk pages or the sticky thread (which nobody has posted in yet), and perhaps get other editors to experiment with similar changes. Than later on, discuss whats been learned. Think "iterative design". We keep talking about improving quality and reviewing articles for quality, but without experimenting with different changes where do we get the data to decide what really works? I'll take a stab tomorrow at restructuring [[Transferring data to a new profile]] which I think is still way too technical. I can hardly make it worse.
 
::::::Perhaps we should rename the rules document to guidelines. It really has only three "rules" (no edit wars, don't share your username/password, and use common sense), with the remainder of the document being guidelines that we explicitly state you don't have to follow. [[User:Tanstaafl|Tanstaafl]] 06:09, 14 June 2007 (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)