Knowledge Base changes

From MozillaZine Knowledge Base
Revision as of 18:36, 9 May 2007 by Alice Wyman (talk | contribs) (→‎Resolving logjams: added more thoughts about merge process)
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)

Upload file enabled

Copied from Np's Talk page:

Special:Log/upload - I see that the "Upload file" feature is now enabled, or was this just for testing? I uploaded Image:Fx15safe.png just now for the Safe Mode article and was wondering if it would be OK to do the same for other articles for which we have images that are now linked from other locations such as Summary of Mozilla products. Alice Wyman 13:10, 27 December 2006 (UTC)

It's enabled now. Go ahead and use it, I have already. Gray bar below status bar--Np 15:32, 27 December 2006 (UTC)

I just uploaded the images used in the Summary of Mozilla products and Live Bookmarks - Firefox articles and replaced the external links with the new kb.mozillazine.org links. A SysOp will need to do the KB Main page (which now uses images linked from Imageshack) since it's locked. Alice Wyman 23:56, 27 December 2006 (UTC)

I've created Template:Right-pic which floats an image off to the right. See it in action at Gray bar below status bar--Np 01:47, 28 December 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)
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

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 today. I copied the following from the announcement at http://groups.google.com/group/mozilla.support.planning

Subject: First End-User Support Meeting Tomorrow!

Date: 7 May 2007 16:58:18 -0700
From: Samuel Sidler <samuel.sidler@gmail.com>
Organization: http://groups.google.com
Newsgroups: mozilla.support.planning
We'll be posting minutes of the meeting to the newsgroup so if you're unable to call in, feel free to reply to that post with any comments you might have.

  • Tuesday, May 8, 10:00 am PDT
  • 650-903-0800 x91 Conf #284
  • 1-800-707-2533 (pin 369) Conf #284 (US)
  • Join #customersupport on irc.mozilla.org for the IRC back-channel


Agenda
1. General overview of Firefox support efforts

2. Current state of knowledge base (mozillazine)

  • Process for adding content, any learnings, any shortcomings

3. New Ideas and Solution Brainstorm

4. Action Items/Next Steps

  • Take inventory of KB (plus analyzing data)
  • Organizing KB (tagging, etc)
  • Who can post/edit (change control)
  • KB best practices and style guide
  • Discussion of module owner; who resolves questions?
  • Vendors and Infrastructure research

Forum discussion of end user support, including the KB, here. Alice 12:34, 8 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)