Knowledge Base changes

From MozillaZine Knowledge Base
Jump to navigationJump to search

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 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 is the primary place to announce new suggestions. Whenever possible, issues should be discussed in a more appropriate place, such as the discussion page of the article or category that the suggestion affects.

Once suggestions are resolved, they are moved to Knowledge Base changes/Archive.

Welcome to new editors

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)
  • I guess I'm new, I am "name already taken" from the forums, hello to everyone! --Lethargy 21:34, 10 May 2006 (UTC)


Punctuation or other symbols in article names

I just came across a link on the forums to a KB article that included a contraction in the name (Images or animations don't load) and the link was cut off before the apostrophe. That article has already been renamed but the problem with using punctuation or other typographic symbols in article names has been brought up before, just recently on this article's Talk page. I was wondering if we should set a rule that article names should not contain certain punctuation marks or symbols such as apostrophes or parentheses, since it causes link problems. For example, instead of Video or audio doesn't play the article should be named Video or audio does not play (I just moved it). I was going to suggest this in Talk:Article naming conventions but thought I should bring it up here. If there are no objections, I would like to add a short paragraph to Article naming conventions on "Use of punctuation marks or symbols" stating that parentheses and apostrophes should not be used in article names and that other punctuation should be avoided, if possible (the exception, of course, would be about:protocol, file name or preference name articles). I could use the "Images or animations don't load" article as example. Alice 12:48, 4 March 2007 (UTC)

Thats a good idea. We need to be conservative in what characters are allowed in the article name or we run the risk that this type of problem will reoccur every time the Wiki software is updated. Tanstaafl 16:39, 4 March 2007 (UTC)
The issue isn't with the Wiki software, it's with the forum software.--Np 06:48, 5 March 2007 (UTC)
I'd say we create a list of characters that shouldn't be used rather than discourage all punctuation. We actually currently encourage hyphens.--Np 06:48, 5 March 2007 (UTC)
Instead of listing all symbols not to use, we could simply say something like:
Punctuation marks or symbols
Avoid using punctuation marks or typographical symbols in article names such as exclamation points, parentheses, apostrophes, quotation marks, etc., because it can result in broken links when posting the article URL in mail or newsgroup messages or on webpage forums. Exceptions include article names consisting of filenames, about:protocols and preference articles, or when adding a dash (hyphen) followed by the application name to the end of the article name, as noted above.
*Bad: [[Yahoo! Music videos don't work]]
*Bad: [[Standard diagnostic (Thunderbird)]]
I would be fine with a list, whatever people decide. Alice 21:37, 5 March 2007 (UTC)
I prefer Alice's latest text (rather than a list). She states when hyphens are appropriate etc. Tanstaafl 20:04, 6 March 2007 (UTC)
My preference would be not using a list and using the above (edited) text, if only because I wouldn't be sure whether any list would be complete or not. Alice 20:21, 7 March 2007 (UTC)
The text proposed is good. I didn't mean an exhaustive list, just some common examples of titles with discouraged characters. An example using parenthesis would be a good addition.--Np 20:43, 7 March 2007 (UTC)
OK, I edited the sample paragraph again. If no one objects I'll add it, or someone else can. Alice 02:55, 8 March 2007 (UTC)
Added Article naming conventions#Punctuation marks or symbols. Alice 23:57, 9 March 2007 (UTC)
Found a link in my collection that needs moving Image_tooltips_don't_work--Dickvl 20:26, 11 March 2007 (UTC)
I just moved it, thanks. The problem is, when you get redirected to the new article, it comes up with the old article's URL and people keep bookmarking and linking the old URLS. I've been updating those links in the Issues and Faqs articles and in other articles, when I notice them. I see you've been doing that, too. Alice 15:32, 12 March 2007 (UTC)
I had updated my links and changed the links with single quotes and to be sure I tested them. I also did a KB search to see if any links needed to be modified (hmm: "don't" doesn't work on its own; lol, that's two of them).
I just noticed another one in my collection: Flash#Flash_files_don.E2.80.99t_play. How to deal with those? --Dickvl 17:23, 12 March 2007 (UTC)
You make a good point, that article sections containing certain characters (such as Extensions.* files in the Unable to install themes or extensions - Firefox article?) might also cause link problems. You can edit existing articles to eliminate the special characters (I just changed "Extensions.* files" to "Extensions.xxx files" in that article) but existing links will no longer go to the specific article section. I could add something about avoiding punctuation marks or symbols in section headings to In-house style, if no one objects. Alice 21:22, 12 March 2007 (UTC)

Plugin warning

We have various pages on plug-ins that include "Security alert" sections. These sections specifically mention noteworthy vulnerabilities for the plug-in in question. In my opinion, we shouldn't discuss specific plug-in vulnerabilities. There are few reasons for this:

  • We're not close to the plug-in vendors. It's very likely we could be very late in discussing a severe vulnerability, or might not even hear about it at all. For example, the page on Flash doesn't discuss any vulnerabilities, though undoubtedly there have been a few big ones over the years.
  • We're not experts on the workings of plug-ins, and we shouldn't be viewed as such or as being in any way responsible to disclose their problems to our users.
  • We have no data on plug-in usage, so it's difficult to tell when a warning about a specific version should be taken down due to the fact that no one uses it any more.
  • Beyond "Make sure you're using the latest version", few users care about the specifics of the vulnerabilities.

Instead, I recommend that we include a template on the top of each plug-in's page that states a few things:

  • Plug-ins are not created by Mozilla.
  • Plug-ins are not updated as part of Mozilla products' updates.
  • Mozilla products do not provide protection against vulnerabilities in plug-ins.
  • Instructions (or a link to instructions) on how to check for and/or update to the latest version of the plug-in.

Comments? --Np 05:20, 1 May 2007 (UTC)

For example, the page on Flash doesn't discuss any vulnerabilities..... It used to but Flash had three security updates last year and we weren't keeping up. I thought it best to remove the section and, instead, link to the Adobe page on security vulnerabilites under "External links". A template for each article, like you suggested, may or may not be helpful and maybe I should have at least added a note to the Flash article about keeping up to date for secutity reasons, I don't know. I wouldn't be against removing the security warnings in other plugin articles like Quicktime and Java if a link to a page that discusses security vulnerabilites in these programs could be likewise added. Regarding the Windows Media Player article's security alert, see my reply here. I think it would be fine to add some general information about plugin updates and security to the Category:Plugins page, whether or not we add templates to each plugin article. Alice 13:24, 1 May 2007 (UTC)
I didn't see any risks in the WMP and Quicktime pages. I don't buy the argument that any security information is useless since we're supposed to always run Windows update. There are sometimes good reasons not to run update (or not to update certain software if you do a custom update). Pointing to other web sites for detailed information about security vulnerabilities seems a good way to limit our involvement, and set peoples expectations. I think most users have realistic expectations about how up to date any information is.
The main thing I have against the proposed template is it seems like a Mozilla lawyers instinctive response and spoils the impression that this is a independent community web site. As an aside, the proposed wording helps mislead users into thinking we're part of Mozilla. Tanstaafl 00:49, 2 May 2007 (UTC)
My comment wasn't meant to be the actual wording; it was just some bases that I felt we should cover.--Np 00:59, 2 May 2007 (UTC)
  • Plug-ins are not created by Mozilla.
  • Plug-ins are not updated as part of Mozilla products' updates.
  • Mozilla products do not provide protection against vulnerabilities in plug-ins.
  • Instructions (or a link to instructions) on how to check for and/or update to the latest version of the plug-in.
Excellent idea. And please add a reference to bug 271559, "Countermeasures for Java/plugin/extension vulnerabilities (disable, warn)".
AnotherGuest. 8 May 07

First shot (example, may not be the actual instructions we give):

--Np 16:41, 8 May 2007 (UTC)

That template seems innocuous. Tanstaafl 21:26, 8 May 2007 (UTC)
Is that good or bad?--Np 01:42, 9 May 2007 (UTC)
Good (it addressed most of my concerns) Tanstaafl 08:27, 9 May 2007 (UTC)
"Windows Media Player" isn't really a plugin, though, it's an application that includes a browser plugin. Same with the Quicktime Player and Adobe Reader. Also the term "third-party" may be confusing, and most plugin articles already include a link to download the application/plugin so another download link is unnecessary. If you do want some sort of template, why not just say something like, What I see missing, though, is a link to a page with security information, similar to what's in the Flash "External links" section (or in the WMP article intro) but I guess that could remain part of the content of the article itself. Alice 23:59, 8 May 2007 (UTC)
Saying that WMP, Quicktime, and Adobe aren't plugins is just semantics. We call them plug-ins all over the KB, and in the context of Firefox, that's what they are. I actually think linking to a security info page would be better than a download page because they will usually contain info on how to upgrade anyway. I made the template to allow whatever text you want to put, whether it's "use Windows Update" or "read this article".--Np 01:42, 9 May 2007 (UTC)
Saying that WMP, Quicktime, and Adobe aren't plugins is just semantics. We call them plug-ins all over the KB, Maybe so but I don't think we should perpetuate the confusion between a browser plugin and the associated application. Windows users missing the WMP plugin ran head-on into this when they couldn't figure out why updating to or reinstalling Windows Media Player 11 didn't add the missing WMP plugin (bug 360336). Alice 12:06, 10 May 2007 (UTC)
I think this warning misses some of the essential points in your bullets, in particular that Fx provides no protection against vulnerabilities, and does not update them. But beyond that, there are two other problems with the warning as stated:
(1) can up-to-date plugins cause problems? (certainly).
(2) what does "not supported" mean? To some people that's a pejorative. It means it might not work right, when what we actually mean is that Moz can't fix it. --AnotherGuest. 9 May 07
How about something like this: Alice 12:58, 10 May 2007 (UTC)
Edited for ...er, grammar and punctuation.
Other changes: About compatibility. Does that mean that Firefox should just be made "compatible"? And why is WMP singled out in this message? Should there not be a reference to all plugin issues? --AnotherGuest. 10 May 07
See my re-edited version above. I removed "outdated or incompatible". I also re-edited my proposed template to allow for multiple page links. Alice 10:01, 12 May 2007 (UTC)
I also removed the "Security alerts" from the Java Quicktime and Adobe Reader articles and replaced them with more general information on security updates and links to current advisories. Alice 10:01, 12 May 2007 (UTC)
Looks good. Shouldn't this be put at the highest level to which it applies? It would go nicely in Issues related to plugins, minus the last sentence. --AnotherGuest. 14 May 07
I think the point is to put it where most users will see it, on the plug-in pages themselves.--Np 18:09, 14 May 2007 (UTC)
The first sentence is a little clunky and long. There's also a few words in there that could be snipped, namely "installed" and "specific". How about "Mozilla applications are regularly updated for security and stability; however, Mozilla does not provide updates for plug-ins. Plug-ins can cause crashes and hangs and may contain security vulnerabilities. Information on security and stability issues affecting <insert plugin article name> is available here."--Np 18:09, 14 May 2007 (UTC)
That's fine with me. Alice 12:22, 18 May 2007 (UTC)

Good?--Np 17:04, 18 May 2007 (UTC)

That's maybe a little choppy but it's OK. Keep in mind, Java is a special case since updates don't remove older versions. It's also going to need multiple links on security issues, if you think that will work out OK in the template. I haven't found any good Sun link for security issues specific to the JRE... all I could find was this page and the "Sun Alert Notifications" link for issues after 11/19/02 gets you this. Best I could come up with was linking to separate Secunia pages based on JRE version, which I placed under "External links" and dealt with it like this. Alice 20:48, 18 May 2007 (UTC)

Knowledge Base changes

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, here. Alice 12:34, 8 May 2007 (UTC)

Update: Minutes of the end-user support meetings were posted to the mozilla.support.planning newsgroup, along with an announcement linking to drafts of a Firefox Support Overview and 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. Alice 10:57, 18 May 2007 (UTC)

Resolving logjams

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 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 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 Mail content types which overlaps some of that article, and has more of a end user focus. There seem to be two process problems:

  1. 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.
  1. The two authors agree it would make sense to merge the two articles but can't agree on a process to do that.
Note: The 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? Tanstaafl 09:57, 9 May 2007 (UTC)

You said that, The proposed 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 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 page for proposed articles, as discussed in Talk:Error_loading_websites. 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.--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. 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. 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.--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. 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.--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 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 "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 here:

Correct me if I'm wrong but right now, articles are only updated or reviewed if someone comes across it and notices something amiss, or if it comes up in the recent changes list. That's why I mentioned a feedback process for non-editors, so that errors or problems get noticed. On way that articles get reviewed as a part of a group effort right now is if someone nominates it for deletion. I would at least like to see a system set up so that articles can be nominated for quality review. Nominating an article for quality review or requesting comments from other editors about article content could also be part of a dispute resolution process in the case of conflicting opinions about what information should be included or removed from an article or how the article content should be organized.

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. Alice 13:36, 11 May 2007 (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. 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. 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 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!) 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. 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). 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. 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. Alice 21:11, 13 May 2007 (UTC)
  • What guidelines would you suggest on whether a "request for comment" is appropiate? 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. 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. 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 "Peer review" and "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. 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. 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. Alice 22:16, 14 May 2007 (UTC)
I just wanted to add that your idea to not 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. 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:

(Looking at how the "Cleanup" template is made, I guess you would also add [[Category:Request for comments |{{PAGENAME}}]] to the template to automatically add the category). 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 . 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?--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 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? 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. 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 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.--Np 01:41, 19 May 2007 (UTC)

"What's stopping you" feedback

I made a post on the forums and the 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.--Np 16:41, 5 June 2007 (UTC)

Don't have an account [1]

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 ConfirmEdit to stop bots with captchas.--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. 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.--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 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. 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.--Np 01:53, 6 June 2007 (UTC)
I've edited the login screen, but I can't edit the sticky because it's locked.--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. Tanstaafl 06:09, 6 June 2007 (UTC)

Don't know how to write articles[2][3]

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.--Np 16:41, 5 June 2007 (UTC)

That seems like a good idea. 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.--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. Tanstaafl 00:36, 6 June 2007 (UTC)

I've made changes to that page. Let me know what you think.--Np 17:14, 6 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.--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. 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.--Np 23:14, 5 June 2007 (UTC)

The interface sucks[4][5][6]

Maybe look into getting a new skin?--Np 16:41, 5 June 2007 (UTC)

No one talks about it[7]

See "Not seen as important".--Np 16:41, 5 June 2007 (UTC)

Don't think changes would be accepted[8]

Possibly related to not having an account, not knowing what to do, and "previous altercations".--Np 16:41, 5 June 2007 (UTC)

Previous altercations between members make it look unwelcoming[9][10]

Should we really be discussing changes to articles anywhere other than on the KB itself?--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_(Thunderbird) . On the other hand, I agree we shouldn't wash our dirty laundry in public. Tanstaafl 21:25, 5 June 2007 (UTC)

"Attitudes towards volunteers"[11]

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.--Np 16:41, 5 June 2007 (UTC)

Poor organization[12]

This is more likely "Don't think changes would be accepted".--Np 16:41, 5 June 2007 (UTC)

Not seen as important[13]

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?--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. 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.--Np 23:22, 5 June 2007 (UTC)