Knowledge Base changes: Difference between revisions

From MozillaZine Knowledge Base
Jump to navigationJump to search
Line 114: Line 114:
|}
|}


I've just uploaded the images for the [[Summary of Mozilla products]] article so we can use them, instead of linking them from other locations.   Someone else will need to do the [[Knowledge_Base |KB Main page]] (which now uses images linked from Imageshack) since it's locked.  [[User:Alice Wyman|Alice Wyman]] 23:56, 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 [[Knowledge_Base |KB Main page]] (which now uses images linked from Imageshack) since it's locked.  [[User:Alice Wyman|Alice Wyman]] 23:56, 27 December 2006 (UTC)

Revision as of 00:32, 28 December 2006

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)

Ownership and dispute resolution

Prompted by the comments in this forum thread, I believe we need to some sort of dispute resolution mechanism and general guidelines in the KB. Otherwise, disagreements can easily escalate into edit wars and contributors leaving. The obvious solution is to have the Sysops handle these things, but I don't know if there are enough active Sysops to present a decision ("The Sysops said so, so I'll do it" vs. "Np is crazy, screw him"). Thoughts?--Np 21:43, 6 December 2006 (UTC)

I also noticed that thread and it wasn't a nice read. I've been overrun a few times myself. Usually with an accompanying explanation though. Maybe you need more sysops then. If a policy is made, it should be promptly introduced to new editors to make sure they're aware of it. PS. I wish all KB editors should "watch" this page. Could it be automatically inserted into new editors watchlist? --FatJohn 01:28, 7 December 2006 (UTC)
As of right now, the Sysops don't have the ability to change people's watchlists. Administrators might.--Np 03:23, 7 December 2006 (UTC)
First, what do you mean by "ownership"? Should articles be "owned" by different editors or Sysops who have the final say on edits, for example, give Vectorspace all the plugin articles, Tanstaafl all the Thunderbird articles and you and Unarmed take the preferences articles? Or did I misunderstand?
No, what I mean is that someone or a group of people is "in charge" of the Knowledge Base, to create and modify policy and resolve disputes between members. There would not be anyone in charge of particular articles; members would be free to edit as they currently do (of course, with the exception of the dispute resolution process and any new policy created). --Np 03:23, 7 December 2006 (UTC)
Second, I think that the current system of resolving editing disputes by posting to the article's Talk page should work in 99% or the cases. Hopefully, other editors would add to the discussion but if not, or if the issue still isn't resolved after a reasonable period, I suppose a Request for mediation page might work, something similar to the Pages voted for deletion discussion? Or, maybe one of the involved parties could simply post a "Mediation request" here, on this page? Once such a request is made, further editing of the page by the disputing parties should cease until the editing conflict is resolved. 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. I mentioned in the forum thread that some sort of "KB quality control" process is needed, besides just hoping that errors are caught and fixed as people review the recent changes or happen to read an article and spot a problem. Alice Wyman 01:59, 7 December 2006 (UTC)
Yes, the talk pages are usually sufficient in resolving disputes, though I suspect that many of disputes that arise are dropped by one of the parties to avoid the edit war. With a dispute resolution system, people wouldn't have to fear alienating users or entering an endless argument by asserting their views.
If you don't want people to risk alienating other editors then maybe a Request for quality review of the article (made by either one of the disputing parties OR by anyone else observing the conflict) would be the better route, but first a quality review process should be in place, hopefully similar to the review process taken before deleting an article, where everyone has the opportunity to contribute. I guess what I'm trying to get at is that a mediated compromise is preferable to an arbitrary Sysop decision (in the sense of mediation as opposed to arbitration). Of course it's easier for a Sysop to dictate what the resolution should be but I think that an open process where all editors are free to participate is better in the long term. Alice Wyman 12:00, 7 December 2006 (UTC)

Quality Control

The ability to change policy would help with quality control - we could dictate by policy in general terms what an article should or shouldn't be like.--Np 03:23, 7 December 2006 (UTC)
There are already general guidelines given in Rules#Editing_courtesy about documenting controversial changes (the linked Talk page even mentions using the Talk pages to suggest "Possible solutions to edit wars" in the "How to use Talk" section) so maybe that's where dispute resolution should be mentioned, but nothing specifically about quality guidelines, I guess because it's a difficult subject. Alice Wyman 12:00, 7 December 2006 (UTC)
We already have the ability to add a tag stating that the article doesn't meet wikipedia standards. The few times I've seen it used it didn't cause a dispute because it was pretty obvious that it deserved it. Perhaps the real issue is what types of disputes shouldn't be left to the talk pages. I remember the great difficulty several editors had dealing with one person who was basically kidnapping the anti-virus article to evangelize not using anti-virus software. That wasn't just two editors having a dispute, it was a case of whether one of the editors was acting inappropriately. Tanstaafl 15:47, 7 December 2006 (UTC)
The issue isn't messy pages. We have plenty of standards for grammar and formatting, but none about content. For example, 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? 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.
Regarding the dispute you mention, this is exactly where dispute resolution would come in. Right now, the only way to "win" a dispute is to convince the other editor or to be more persistent in implementing your version. With a dispute resolution process, the latter is replaced with an official process that takes less time, is less alienating and frustrating, and is more likely to yield the "correct" solution.--Np 18:18, 7 December 2006 (UTC)
"For example, should support articles present easy information to users to get them going again, or should they explain things in detail?"
Both, but sometimes often there are no easy answers because there are too many variables or unknowns. Sometimes the best that can be done is to explain how things work and suggest a check list or some guidelines for troubleshooting.
"Should solutions be referenced so we know editors aren't just making stuff up?"
Yes and no. What would you reference for the Standard Diagnostic? That's more of a messy consensus than a referenceable procedure. Although it may not be efficacious to reference a procedure, information should usually be referenced unless it's common knowledge and beyond dispute. --AnotherGuest 7 Dec 06
I wasn't intending on actually forming the policy in this discussion. I just want to figure out whether a defined policy would be useful, and who would create it.--Np 20:47, 7 December 2006 (UTC)
I am uncomfortable with the direction you're advocating. I don't mind a honest disagreement with other editors but I've repeatably had problems with what I consider grammar/style guide nazis who don't use any judgement, do their damage, and move on without contributing anything to the article. On the face of it there is nothing wrong with some of the standards you're proposing but based on past history it will just make things worse.
You mention With an official policy on these things, users would be more comfortable changing "other people's" articles. I'm not convinced thats a big problem. What I have noticed is we're not getting enough new articles about users problems (reference articles about a specific preference don't count) and too many cases where a ordinary user writes one article and then decides they've had it with the knowledge base.
I consider our biggest problem to be lack of contributers, not how professional the editors are, or how willing they are to edit somebody elses work. There appears to be a core of about six or seven individuals that do the majority of the work. I find a wiki style of collaboration to be difficult at times since you don't own any articles you write. I've found I usually have no problem when just one editor edits whatever I've written, regardless of how extensive the changes are or the differences in styles (as long as its clear they're not making changes just for the sake of standards). It gets more difficult the more editors are involved because there is no longer one consistent writing style. That can reduce the quality more than any deficiencies in my writing skills. It also creates complications because if you get too aggressive on rewriting an article the other contributers may feel they're being edited out. I can deal with that. However, I have a problem when you combine that with "editors" that don't contribute anything to articles for that application but want to dictate in detail many decisions.
Yes, lack of contributors is a major problem, but I'm not trying to address that with this discussion.--Np 20:54, 8 December 2006 (UTC)
I'm used to collaborating with some of the more prolific helpers in the forums. I'm struggling to find a way to encourage users who don't want to write/edit an article to contribute/pool information that I'll use to write an article. For example, I've been trying to get users that I've been helping with problems with the U3 version of Thunderbird to post background information such as the USB drive layout. However, I basically just want to be left alone by other editors, unless they're going to actually contribute to an article. I've noticed that the "standards" are in practice dictated by a few editors who hold similar views, not by consensus of all of the editors. I don't consider somebody mindlessly editing an article to make it conform to some standard that I didn't agree with in the first place as adding any value. Tanstaafl 04:32, 8 December 2006 (UTC)
The standards would not be arbitrary nitpicky things, much less nitpicky than the current in house style. They would instead be major issues that affect how useful an article is to a user. An example of a standard for an "issue" page could be "Start with a short description of the article. What are the common symptoms of the problem? What other problems are related to this problem, but are covered elsewhere? Then, as plainly as possible, describe the steps to solve the problem. Then, provide technical information for the more advanced users".
Furthermore, this would not be "Let's make Tanstaafl write articles how Np wants". This would be "Let's get all the editors get together, corroboratively decide the standards that would help users, then work on making articles fit those standards."--Np 20:54, 8 December 2006 (UTC)
You haven't convinced me there is a real problem while I am well aware of potential downsides. I prefer the current solution which is to let other editors improve articles as needed and lead by example. Tanstaafl 09:05, 9 December 2006 (UTC)

Including references in articles not only helps the reader but helps anyone reviewing the article verify accuracy. When I suggested a quality control process I meant that a review process should be set up so that articles get updated or corrected systematically. For example, the About:config entries article needs updating for Firefox 2 menu option changes, since right now it is not technically accurate in some instances as menu options are changed, as are prefernce default settings. 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. Maybe some editors could look at the Lost bookmarks article and it's Talk page as a case in point? Alice Wyman 02:23, 9 December 2006 (UTC)

I periodically browse most of the Thunderbird articles looking for ones that seem out of date. That doesn't mean I'll do something about every one I find (I know the bouncing messages article needs updating for 1.5 for example, but I keep dropping it to the bottom of my list of things to do) but I do make the effort. I assumed other people did the same thing for areas that they concentrated on.
You mention two different reasons - a poorly written article and its out if date. Your example seems more like a poster child for dispute resolution (between three editors) than a quality review process. Yes, there's some overlap but I think we're better off treating dispute resolution as a separate problem.
I suggest we start small and maintain a list of articles that are out of date, that includes a one line description of the problem. Thats less likely to cause disputes or hurt feelings and makes it easier to bring to somebodies attention since they don't have to scan the articles looking for a update tag. If the process works well then we could expand it (in several iterations) to deal with whether its well written or understandable (which is a much trickier issue to deal with since that may involve dispute resolution, standards, how good user feedback is, and political minefields such as the profile folder article) later on. I'm basically arguing for a iterative process (to discover and/or adapt whatever meets our needs), rather than mimicking whatever the Wikipedia does since we have only a few dozen editors while they have over 2.5 million.
The Thunderbird and Firefox support forums have a FAQ sticky thread (I don't know why SeaMonkey doesn't). I (or somebody else) could add a short blurb that links to that page, a similar blurb to the top of http://kb.mozillazine.org/Knowledge_Base and a thread in the general forums about it (mainly to let the more prolific posters know about it and ask them to mention it as needed). Tanstaafl 06:03, 9 December 2006 (UTC)
I'm afraid I didn't understand your point about the FAQ sticky thread... you mean adding a link to the Out of date articles page to alert helpers or users that the information is outdated? I'm all in favor of a page listing articles that need updating, in addition to the update template that belongs on each article (similar to the Pages voted for deletion system). If it works then it can be expanded it to include a "Quality review requested" or "Comments requested" list and associated template for the article or its Talk page. It still doesn't address the question of how these articles get tagged in the first place, but it's a start. Is any one responsible for reviewing all Firefox articles, for example, after a new application version is released, to see which ones are out of date? I was haphazardly updating articles for Firefox 2 as I came across them. I saw no systematic process and none of the articles I updated were tagged. Alice Wyman 16:50, 9 December 2006 (UTC)
Yes. The page isn't as useful if ordinary users and helpers don't know about it, and its only used by editors. Adding a link to it in an existing sticky thread in the forums, and in the main knowledge base page lets ordinary users stumble across information about it. The thread in the general forum was meant to evangelize the idea of that page to helpers, who typically point users to articles that might help them. I'm hoping that if the user they're helping discovers the article was out of date that the helper will suggest the user mention that in the Out of date articles page (or mention it themselves).
I'm not suggesting that anybody is responsible for reviewing any articles though I'm hoping that if we create this page that editors will get in the habit of reviewing articles in whatever area they normally edit/write articles after every major version (perhaps with a little encouragement), and will update the page as needed. Right now there is no incentive for them to review the articles unless they're willing to do the work updating them.
My impression is that editors are reluctant to use the update template, for whatever reason. I'm suggesting that we encourage them to use that template, but as a minimum add the article to the Out of date articles page. If they do both, great. The main problem I see is that you have to sign up for a knowledge base account to edit an article, and thats a lot to ask a ordinary user to do. I'm hoping that we can find a way to let users edit a single dedicated knowledge base page without having to login. That might cause it to get spam, but I think thats an acceptable tradeoff since we're only talking about one page. Worst case I assume we could create a knowledge base account with a public username and password (guest ?) that was limited to only being able to edit that one page. Tanstaafl 23:05, 9 December 2006 (UTC)


Quality control standards

I wouldn't want to set any specific standards for what to include in articles such as should support articles present easy information to users to get them going again, or should they explain things in detail, or whether to place the easiest versus the more common solutions first 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. Alice Wyman 02:23, 9 December 2006 (UTC)

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. How the information is presented does have a giant role in making it easy to understand and easy to use. Take our bookmarks article for example. You feel strongly that the instructions for restoring bookmarks should be at the top. I feel strongly that the steps to triage the issue need to come first. This is something that should be set in policy. Someone who knows what they're doing in regards to user support should step in and tell us how best to present the information to get it to the users that need it, and then it should be done that way. --Majken 16:29, 17 December 2006 (UTC)
I'm not opposed to setting standards, but they should be general ones such as readability and accuracy. As I saidm I'm opposed to setting specific rules for article layout that would apply to all "support" articles, such as support articles should present easy information to users first, or explain things in detail, or place the more common solutions first and similar guidelines. I did prefer a speciic layout in ONE article, placing all sections on "how to recover lost bookmarks" solutions at the top of the Lost bookmarks article, and go into possible causes and prevention in later sections, because I thought that most users would be primarily looking for how to recover lost bookmarks first, when going to that article. Alice Wyman 17:57, 17 December 2006 (UTC)
Do you have a suggested format for presenting all KB "support" article content? You first need to define what is a "support" article, since we don't have a "support" category. Lost bookmarks, for example, is in both the "Firefox Issues" and the "Bookmarks" category. The Import bookmarks article is also a "support" article, as is the Flash article from the "Plugins" category, and there are many many other articles that could be considered "support" articles. Only the "Preferences" articles have a specified format, set forth on the Category_talk:Preferences talk page. If you want to stick with "Issues" article, here are a few taken from the Issues with Firefox article ... maybe you want to give an example of a standard for arranging the content that would apply to all these articles as well as to the Flash Import bookmarks and and we can discuss it from there:
P.S. I don't have preferences any longer regarding the Lost bookmarks article. I'm no longer actively editing it, as I mentioned in the discussion page, since I thought it would be better for others to have a turn at it. Alice Wyman 17:57, 17 December 2006 (UTC)

Dispute resolution process

I've moved the discussion to the discussion page of a draft Dispute resolution process article that Alice and I wrote. Tanstaafl 01:57, 12 December 2006 (UTC)

I've made a few last edits to the article. It would be great if there were some other contributions besides mine and Tanstaafl's, or at least some new comments on the article's Talk page. In any case, just going through the process of writing a draft on how KB disputes should be settled and getting it down "on paper" has some value, I think. Alice Wyman 03:54, 15 December 2006 (UTC).

KB user feedback

The forum thread mentioned above also included comments about quality control and feedback regarding user support documentation in general and in KB articles. I suggested something here awhile back on a feedback process, when problems are found in KB articles (a "bad link" in the specific case I brought up) but got no response. I ended up adding a section on Feedback to the "About" article, but it brings up an important point. Maybe the concept of "KB feedback" should be expanded to include a process by which people on the forums (both helpers and people asking for help) who use a KB article can have a way of giving some feedback on how the article did or didn't help solve a problem? The process should not require the individual to set up a KB account just to post a comment on the article talk page, for obvious reasons. One option is to post a comment to the forum, but maybe a link at the bottom of every KB article to a Feedback form is another possibility (I don't have the technical ability myself to come up with such a page but I'm sure others here do!). Unfortunately, quality control and KB feedback is always going to result in potential alienation of editors if an error they've made is pointed out or if their contributions are rewritten or removed from an article, but that's the price you pay for trying to improve the quality of articles. Alice Wyman 12:00, 7 December 2006 (UTC)

How is that better than using the associated discussion page? The discussion of the tradeoffs of alienating an editor seems to make the assumption there was only one editor for that article. Maybe I have too thin a skin, but if somebody writes an article and does most of the maintenance of it (i.e. they have an emotional investment) I'm concerned about their reaction if it gets publicly criticized and they think its due to changes made by somebody else. The collaborative style of a wiki is the not the type of collaboration most people are used to. I think there is a tradeoff in how much of a big deal you make of any feedback when you don't have many editors and the most common "feedback" nowadays is somebody trying to misuse the article to ask a question that should be asked in the forum. Tanstaafl 15:47, 7 December 2006 (UTC)
There are two types of feedback - that from other editors and that from users. I think the talk pages are fine for editors to post feedback. For users, we really need a "did this help?" feature like many other documentation sites have. Unfortunately, I doubt this is something that "comes with" MediaWiki - it would have to be built.--Np 18:18, 7 December 2006 (UTC)
Don't expect much from users. You will get two kinds of answers: "yes" and "no, it's written for geeks". I don't think you will get much useful information from people who had trouble understanding it, and you are even less likely to get useful technical suggestions. I don't know, you may not even get useful information on what is confusing them. I doubt that it will be worth the trouble.
Also, if they write "no", you might not be able to tell whether it's because the article doesn't apply or whether they just didn't understand. If they don't understand, you can dumb it down, but I think there will be a large fraction of users who won't get it no matter what. I think the best you can do is just write as clearly and as simply as you can, right from the beginning, but keep the information in the article. Feedback won't do anything but waste your time. --AnotherGuest. 8 Dec 06
While I agree that some users won't understand regardless of how it's worded, I still think it would be useful to have feedback on the articles. For example, if 75% of people find one solution helpful, and 30% find another solution helpful, that would say to me that we should talk about the 75% first. If no one found a suggestion helpful, we could remove it.--Np 03:40, 9 December 2006 (UTC)
If you structure it to get what you want, maybe. --AnotherGuest. 9 Dec. 06


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)