维基百科:专题委员会/专题指引/专题

维基百科专题是想共同工作改进维基百科者的小组。维基专题页面并非他们作品的遴选处，亦非爱好者的主题区。本页提供关于组织讨论与管理问题的建议，以便团队更高效的协作。

初始设置

创建一个专题页面

当你一旦决定建立新专题后（指引可能指出更好的替代方法），请务必创建一个主页面。维基专题的命名常规为Wikipedia:空间加“xxxx专题”；比如你想创建一个鸟类的维基百科专题，则应当创建“Wikipedia:鸟类专题”。

这里给出了一个新维基百科专题页面的框架；请根据主题需求选择适当的措辞：

{{WikiProject status}}
欢迎来到鸟类专题！

; 目标
* 改善维基百科所含的鸟类条目
* 建立鸟类相关条目的指引。

; 范畴
* 专题涵盖全部鸟类条目，及其饲养与应用的条目。

== 成员 ==
# {{User|我的名字}}（对鸟类的一切皆感兴趣）

== 开放任务 ==
* ……

== 分类 ==
* [[:Category:鸟类]]
* ……

== 模板 ==
* ……

== 相关主题  ==
* [[Wikipedia:花类主题]]

{{Wikipedia policies and guidelines|state=collapsed}}
{{WikiProject Footer}}

[[Category:鸟类专题| ]]

此外亦可使用{{WikiProject}}模板，即通过{{subst:WikiProject|专题名称}}代码建立新页面；这会生成一个较为复杂的排版。最后，还可以选择一个已经活跃的专题——和新专题范畴相似的专题更为理想——将他们专题页的代码结构直接复制过来。不过，这种方式可能需要大幅修剪不需要的章节，以超大型专题当模板时尤甚；大专题往往会有许多结构复杂的功能，而这些对小专题而言显得过为错综复杂。

一般而言，新维基百科专题应该尽可能保持精简，而容许其自然发展。虽然创建含有大量罕用模块的页面显得很有诱惑力，但这是个坏主意；小型专题通常无法一下子关注这么多方面，而过分冗余的结构会将潜在的新成员拒之门外——特别他还是首次加入专题！

在专题名录中登记你的专题

请将你的专题登记于Wikipedia:专题委员会/专题名录。所用模板的使用说明见此。如果你的专题刚刚起步，请注意它仅表示当前的活跃状态。您可以随时更新它。

招募

保持维基百科专题活跃的最基本方法之一就是招募编辑。一个维基百科专题必须招募新成员以弥补流失，任何专题若做不到这一点则终会崩溃。

那么接下来，如何招募这些宝贵的参与者？目前为止，最有效的方法是使用专题横幅模板。对于大型专题，这些模板可通过更复杂的形式，来提供各种附加功能；不过对于一个刚起步的专题，一个简单的横幅应已足够。再次假设你已经开始了“鸟类专题”，你将需要选择一个合适的模板名称（强烈建议您选择Template:WikiProject Project或鸟类专题，因此此例用为Template:WikiProject Birds。您可以将其它便于轻松寻找的标题重定向，比如Template:WPBirds等）并创建一些简单的内容：

<!--wikEdOuterTableStart-->
{| class="wpb collapsible innercollapse tmbox tmbox-notice {{#ifeq:{{{small|}}}|yes|mbox-small}}"
|- class="wpb-header"
! colspan="2" class="mbox-text" | [[WikiProject:鸟类|鸟类专题]]
|-
| class="mbox-image" | [[File:Ruddy-turnstone-icon.png|45px]]
| class="mbox-text" | 本条目屬於維基[[WikiProject:鸟类|鸟类专题]]的範疇，一個旨在改善中文維基百科鸟类专题相關內容的項目。如果您有意參與，請瀏覽专题主頁，參與其討論並完成相應的開放性任務。
|}<noinclude>
[[Category:维基专题模板|Bird]]
</noinclude>

将会生成：

代之您也可以使用维基专题横幅的元模板{{WPBannerMeta}}，随着专题的发展，您可轻松扩展横幅，加入各种模块。以最简单的为例，使用此代码：

{{WPBannerMeta
| PROJECT = 鸟类
| BANNER_NAME = {{subst:FULLPAGENAME}}
| small = {{{small|}}}
| category={{{category|¬}}}
| listas = {{{listas|}}}
| IMAGE_LEFT = Ruddy-turnstone-icon.png
| MAIN_TEXT = 本条目屬於維基[[WikiProject:鸟类|鸟类专题]]的範疇，一個旨在改善中文維基百科鸟类专题相關內容的項目。如果您有意參與，請瀏覽专题主頁，參與其討論並完成相應的開放性任務。
}}

生成:

因为专题横幅会添加在巨量的条目讨论页中，请尽可能使用小分辨率图像，以免页面横幅铺天盖地；图片尺寸最常见的惯例为45px或50px。图像必须为自由内容——禁止加入合理使用图像。

横幅应该加入任何属于专题范畴之条目的讨论页。（但请见下方关于过度标记的警告）如果条目正好被另一个因素——比如一个分类或小作品类型——良好定义，则可请一些机器人协助放置横幅。（见WP:BOTREQ）

招募成员的另一有效方式为直接邀请。如果其他编辑在专题覆盖条目中高度活跃，则应该能在条目历史记录或讨论页看到他们的身影；礼貌的给他们留下信息，请他们来看看新创立的专题，这往往会让新成员大量涌入。不过实践表明，这种方式无法企及讨论页横幅的新成员引入效果，而更适合吸引对此特别有兴趣的编者加入专题，如主题专家。

英文维基百科的乐器专题使用了参与者名单和留言板的策略，可以让有兴趣但时间有限的编辑登记名字。这似乎吸引了不少人以各种方式做出协助，不过也有没有登记名字册参与者。

界定范畴

维基专题有唯一而绝对的权力定义他们的范畴：不能强迫一组编辑支持他们不想支持的条目，或是禁止他们支持他们想支持的条目。

不过，成功维基专题多使用表述简单且易理解的自然范畴。在专题主页表明范畴可吸引新成员，可当作活跃成员的使命宣言，也可通过明确表示哪些条目由什么专题支持，来简化跨专题协作问题。范畴的描述无需复杂或详细，不过应让能潜在成员和其他编辑确定，任何给定的条目是否可能术语专题工作范畴之内。

开始工作

一旦专题已经开始吸纳成员，则寻找需要去做的事就变成紧迫的问题。维持用户比招募他们更困难；编辑一旦厌倦就会立刻离开。

任务清单

The most common—and simplest—approach to focusing the attention of project members on particular articles is the creation of a central list of open tasks. For smaller projects, this will often take the form of a simple section on the project page (sometimes using the {{todo}} template, although this creates additional subpages which may not be needed); larger projects will usually create a special template (which may be arbitrarily complex).

There are a number of different items which are usually included on project task lists:

Announcements

General announcements of important discussions and major tasks being undertaken. This may not be necessary for a small project—where such points can be better raised on the project's talk page—but becomes more important as the project grows and the traffic on the discussion page increases.

FACs and FARs

One of the most important items to announce to the project; particularly for a younger and smaller project, a successful FAC can be a great morale booster—but will often require the assistance of multiple project members to succeed.

Peer reviews

Requests for peer reviews; these can be project-specific peer reviews, if the project has adopted such a process, or selected entries from the main peer review page if it has not.

Requested articles

Articles which do not yet exist, but which should be created. These can often be culled from existing lists or navigational templates related to the project's scope.

Cleanup and expansion requests

These can be added manually, or collected from existing cleanup categories.

Unlike the first three categories—the size of which is generally limited—the last two can grow very quickly. It is usual, in this case, to create "overflow" lists from which entries may be rotated onto the main list as needed, and to limit the central lists to a dozen or two entries of each type. For example, a complete list of articles which need to be created may be collected on a subpage (such as Wikipedia:WikiProject Trains/Todo/Write); this list may grow to include hundreds of entries, which would be impossible to place in a reasonably-sized template. In this case, a selection of entries from this list—as well as a link to the list itself—is placed on the project's task list, to avoid overwhelming viewers.

Assessment

Quality

典范级

甲级

优良级

乙级

丙级

初级

小作品级

Quality

特色列表

列表级

重定向

消歧义

请求

模板

分类

文件

主题

非条目

For a more basic overview of article assessment, please see the Assessment FAQ.

One of the most common methods used by WikiProjects to monitor and prioritize their work is that of assessing the articles within their scope. The de facto standard for these assessments is the Version 1.0 Editorial Team's assessment scale (shown at left). A number of other classes have become de facto additions to the 1.0 assessment scale, coveringlists, redirects, portals, disambiguation pages and more. The full list of these additional classes is shown to the right. Some projects, such as The Beatles WikiProject, have added additional levels to account for more unusual circumstances.

A very small or less-active project can keep a hand-compiled table of assessments; as the number of articles increases, however, a specialized process becomes necessary. The first stage of this is the creation of a subpage (sometimes known as an "assessment department") for the assessment work (this is conventionally at Wikipedia:WikiProject Project/Assessment, although there is no hard-and-fast rule); these can take a number of different forms, some more formal than others (see, for example, the Military history and Tropical cyclones pages). However, the essential limitation—that of the hand-compiled list—requires a more sophisticated approach: bot-assisted assessments.

Bot-assisted assessment

The bot-assisted assessment scheme works by embedding assessments in a WikiProject's talk page banner. Using the WikiProject Birds example from above, the last line in the template's code, which closes the table, can be replaced by a substitution call to the {{class parameter}}template:

{| class="wpb collapsible innercollapse tmbox tmbox-notice {{#ifeq:{{{small|}}}|yes|mbox-small}}"
|- class="wpb-header"
! colspan="2" class="mbox-text" | [[Wikipedia:WikiProject Birds|WikiProject Birds]]
|-
| class="mbox-image" | [[File:Ruddy-turnstone-icon.png|45px]]
| class="mbox-text" | This article is within the scope of the '''[[Wikipedia:WikiProject Birds|Birds WikiProject]]''',
a collaborative effort to improve Wikipedia's coverage of Birds.  If you would like to participate,
you can visit the project page, where you can join the project and see a list of open tasks.
{{subst:class parameter|category = Birds}}<noinclude>
[[Category:WikiProject banners|Birds]]
</noinclude>

Alternatively, the addition of a few extra lines to a banner using {{WPBannerMeta}} will have the same effect; adding the code:

|QUALITY_SCALE       = yes
|class={{{class|}}}
|FULL_QUALITY_SCALE  =

to the banner example above will produce the banner:

Either option will produce template code which allows the project banner to take a "class" parameter (e.g. {{WikiProject Birds|class=B}}) to indicate the assessment rating; inserting the parameter does two things:

• Display the corresponding rating in the banner itself ("FA" class in this example)
• Place the talk page into a category corresponding to the rating (in this example, it would be Category:FA-Class bird articles

The key to the process are these latter categories. A full description of their structure is given below; essentially, a bot monitors categories of a certain structure (such as Category:Military history articles by quality), and produces a comprehensive index of assessments for every participating project. This includes a worklist,overview statistics, and a log of changes.

"Importance"

Importance

極高

高

中

低

不适用

Some projects also make importance assessments. It should be noted, however, that these tend to be more controversial (since calling articles "unimportant" may upset inexperienced editors); as a result, some projects (such as Military history) do not assess importance, while others (such as Biography) only undertake importance assessments for a limited set of articles and use the term "priority" to decrease perception problems.

If a project is to engage in assessments of importance, it may well be a good idea to make them a community decision. For example, theBiography and Novels projects have started processes in which the various members collaboratively determine the comparative importance of a given article to the project, and then use those final results as a guideline in determining which articles are most deserving of the project's attention in the short term.

Importance ratings are usually integrated into the WikiProject banner in the same fashion as quality assessments described above. Adding the code

|IMPORTANCE_SCALE    = yes
|importance={{{importance|}}}

to a banner using {{WPBannerMeta}} will enable the importance scale for that banner, producing something like:

In order for the importance assessments to be recognised by the assessment bot, you will need to create a category like Category:Project articles by importance and a number of subcategories. If you are an administrator, you can use an automated script found here to automatically create all the necessary categories for both the importance and quality scales for any particular project. Just make sure to replace "Foobar" by the exact name of your project (in this case, "Birds", with an uppercase "T"), and to reset the tool when you're done.

Assessments in practice

See Category:WikiProject assessments for a full list of active assessment departments.

In general, projects first engaging in assessments will face one problem almost immediately: getting the articles which fall within the scope of the project assessed. There are a number of automated tools available to assist in assessing the stub articles that fall within a project's scope, but project members will still need to go over the assessed stubs to ensure that they are assessed correctly. Often, it is the case that an article will have been expanded beyond stub level, or been incorrectly classified as a stub in the beginning, resulting in the tools incorrectly assessing the article.

Because of the potential importance of assessments to the success of the project, it is vital for the project to get as many members as possible interested in performing assessments. Clearly, it helps the project to have a member already familiar with the system (most often through another project), and for that member to step forward to assist in the initial assessments. Beyond that, it's helpful if, as one of the early tasks of the new project, members go through the articles of the project and assess those whose status they are sure of, while simply adding the banner to those articles about which they are unsure; then, when all the less-controversial assessments are done, the members of the project can focus on assessing the remaining less easily-definable articles.

Article assessment is not an exact science, and there will be a number of judgment calls made by the assessor when an article is on the borderline between two classes. At times like these, it is perfectly proper to request a separate assessment by a different editor, or if the article was previously assessed, to file a reconsideration of the first assessment. Because of this, there should be a place within the WikiProject—generally on the main assessment page—where editors can file requests for re-assessment. In addition, a number of WikiProjects have adopted more formal methods, such as formal group reviews or more explicit criteria, for assigning at least some of the assessment levels; other levels may be based entirely on external validation processes, such as peer review, good article candidacy, and featured article candidacy.

Once assessments have been started, and a WikiProject has assessed a large enough number of articles within its scope, the assessments can become very valuable, both to advance the encyclopedic purpose of the project, as well as to ensure comparatively high morale by fostering a sense of accomplishment of the members of the project. Generally, a given project will focus the majority of its attention in bringing up the articles of greatest priority to the project to a high standard of quality. As a result, its members usually remain with the project if they see that they are really accomplishing something via the project, by increasing the quality of these most important articles.

Peer review

See Category:WikiProject peer reviews for a full list of active WikiProject peer review departments.

Another very common process for a WikiProject to undertake is the peer review of articles. This is usually not a true peer review in the academic sense, but is instead a review by project members; such peer reviews are invaluable in obtaining constructive commentary on an article, and are particularly helpful for articles which are headed towards featured article candidacies. Project peer reviews are usually more helpful than Wikipedia-wide ones, both because there is a greater chance of encountering a reviewer with some knowledge of the topic, and because it is much easier for project members to notice new requests without the need to filter out the vast majority of ones not related to their area of interest.

For very small projects, an informal system of requesting reviews on the project's primary talk page may suffice; as a project grows, however, it is usually appropriate to create a dedicated page for the peer review process (such as the military history or biography ones). This page typically includes a brief section of instructions, followed by transcluded subpages for the individual reviews; these subpages are also linked from the project banners, where the presence of a link is controlled by a template parameter (often peer_review=yes). A{{WPBannerMeta}} banner can easily add this functionality by using {{WPBannerMeta/hooks/peerreview}}.

There is no easy way to add the functionality to a non-WPBannerMeta banner — you will need to copy the code from another non-WPBannerMeta banner like {{WPBiography}}. Once this functionality has been installed, editors will request a peer review by following a three-step process:

1. Add the appropriate parameter to the article's project banner.
2. Follow the displayed link to a new subpage—having the same name as the article—and add a link to the article (usually in a third-level header) along with any remarks or special requests.
3. Add a transclusion of the newly created subpage to the list of requests on the main peer review page.

Functionality exists to automatically copy such WikiProject peer review requests to the central peer review listing; to enable it, add {{WikiProject peer review}}to the WikiProject peer review page.

The amount of time an article will spend being reviewed will vary, both according to the initial condition of the article—articles which are judged to be ready for FAC may be quickly nominated there, ending the review—and the attention the request receives; for moderately active peer review pages, archiving older reviews after a few weeks is usually a good approach.

One useful convention which has been adopted by many WikiProjects' peer review departments is that of having reviewers create a sub-section with their name to use for their comments. This allows extensive commentary and back-and-forth discussion to take place without the need for complicated indentation tricks to keep multiple reviewers' comments identifiable, and provides a ready indication of the level of feedback a request has received.

Collaboration

更多信息：Wikipedia:Collaborations

Developing recommendations

主页面：Wikipedia:WikiProject Council/Guide § Advice pages

A good example of some advice is Wikipedia:WikiProject Bibliographies#Recommended structure. You may also be interested inWikipedia:WikiProject Biography's Structure section, as well as their guidelines.

Auxiliary features

Member communication

With luck, any project will expand over time, as the number of articles and contributors expand. Growth can itself be a problem, however, as the greater number of members and articles reduces the likelihood for individual group members to have contact with each other, and could potentially lead to factions within a project. For this reason, and others, projects are encouraged to develop a variety of regular communications. These might include newsletters, meetups, active conversation between members working in the same area of the project, and the like. Collaborations can also serve as an effective way to try to bring unity to the members, if they are successful.

One way of getting news to everyone is to put all the news on one page, and then ask people to either include the page on their own user page, or add it to their watchlist.

Newsletters

See WikiProject Council/Newsletters for a list of circulating newsletters. They can be freely used as a foundation for a new one.

Welcoming templates

Welcoming templates can encourage new members by recognizing their decision to join the project. Some examples of welcoming templates:

• WP:India
• WP:Films
• WP:Novels

User banners and boxes

Many WikiProjects have their own userboxes which participants put in their own userpage. An example is Wikipedia awards. For more information on making a userbox, see Wikipedia:Userboxes.

Recognition and awards

更多信息：Wikipedia:Awards by WikiProject

A WikiProject award is awarded for work on a WikiProject, or work of substantial interest to those members of that WikiProject.

Control and organization

Coordinators

While Wikipedia in general, and WikiProjects in particular, are usually very egalitarian with no clearly-defined chain of command, some projects have benefited from instituting a certain hierarchy within their membership. This is achieved by appointing "coordinators", users who have agreed to take on an increased role in their project's activities. Coordinators are not usually endowed by their project with any special executive powers; while some projects reserve certain functions or duties to its coordinators (such as closing A-Class reviews), in other cases, coordinators have no inherent authority whatsoever.

The primary responsibility of any project's coordinators is the maintenance and housekeeping work involved in keeping their project and its internal processes running smoothly. In a large project it is easy for people to assume that someone else is doing whatever maintenance tasks (circulating and updating newsletters, maintaining templates, updating todo lists and tasks, etc.) need to be done, and in this confusion things can easily be neglected unless a specific group has been tasked with ensuring that these tasks are completed. Coordinators are often listed as the main points of contact within a project, for both external and internal queries. A coordinator's voice is often, by virtue of their position, granted considerable weight in internal discussions, enabling coordinators to take the lead in drafting project guidelines and visions, and overseeing the implementation of those decisions; however coordinators are not arbitrators or 'leaders' of a WikiProject — all such decisions are still made by community consensus.

Coordinators cannot be 'forced' on an unwilling WikiProject — there must be consensus amongst its membership that the introduction of a coordination system will benefit the project. There are several factors to consider:

• Size of the project: Larger projects that deal with a broad topic, or projects that have grown enough to warrant the creation of task forces, may have a need for coordinators to ensure that everyone is operating toward the same general goal.
• Potential for growth: Some projects are so small the potential for their growth is slim at best, and as a result the articles within the scope can be managed effectively by the project members with no need for coordinators. Other projects are so large that they rely on satellite projects to help reduce the overall workload, as a result may not need coordinators since the more vigorious editing done by the project is through its associated projects.
• Membership: Projects that have a small membership may lack the contributors to effectively run a coordinator department.

Coordinators are typically elected by simple approval vote and serve in coordinator capacity for a period of time determined by the project (usually six months). The number of coordinators may grow or shrink depending on the size of the project and the addition of any task forces to the project. If a project is very large and has a large number of coordinators, they may appoint a 'Lead Coordinator', a position commanding considerable respect throughout the project. The user who receives the most votes during an election cycle typically becomes the project's Lead Coordinator, while those who occupy the remaining coordinator positions are known as Assistant Coordinators or simply Coordinators. Projects that have implemented a coordinator system usually list the users serving as coordinators on the main project page or on a dedicated subpage, to allow easy recognition of these users around the project.

Inter-WikiProject relations

主页面：Wikipedia:WikiProject Council/Guide/Inter-WikiProject

Common pitfalls

Trying to do too much too quickly

The most critical task for a new project is figuring out how to work together. As part of this, editors need to learn how to edit articles together, which involves identifying both content and non-content strengths (e.g., someone with easy access to excellent sources, and someone that knows how to format citations correctly). Editors also need to learn to communicate with each other on the project's talk page. To facilitate this process, it helps to propose a short series of achievable tasks early in the group's existence. By focusing the efforts, the group is more likely to work together, and to feel afterwards like the group successfully achieved a shared goal.

Depending on the project's focus, initial tasks might be article-related (e.g., clean up a key article, create a navigation template to connect a series of articles, find and nominate potential good articles) or infrastructure-related (e.g., make a list of the ten most important articles to the project, clean out an overburdened category, design a project banner, list categories of particular interest to the project) or some of both, but they should be concrete, specific, measurable, clearly articulated and, taken together, not too complex or too time-consuming. To encourage other members to stay on task, individual editors can provide a short status report every few days about what they have accomplished and how it relates to the initial goals.

Trying to solve every problem at once, however, leads to fragmentation of effort and leaves editors feeling isolated. Taking on complicated tasks results in editors feeling like they have failed. Taking on enormous or lengthy projects leads editors to conclude that the project is unable to complete anything (as will a failure to report what individual editors are doing and ultimately what the group has achieved).

Having an overly narrow scope

A WikiProject needs to be broad enough to maintain interest and keep members active. If the scope is too narrow, there will be very few articles within its scope. After those are brought up to a reasonable standard, the members will quickly get bored with polishing a small number of articles. Bored editors leave.

It may also be difficult to attract enough members to a project with a very narrow scope. While a project dedicated solely to tulips may interest some editors, a project with a broader scope, such as the Lily family (Birds plus many kinds of lilies), or even all flowering bulbs (expanding the scope to include amaryllis, daffodils, irises, and more) might be more likely to attract a sustainable number of members.

Most projects need at least 100 articles to work on; the largest and most active projects each have more than 10,000.

Not recruiting enough members

更多信息：WP:INACTIVEWP

Getting into fights

Two particular kinds of fights destroy WikiProjects: fights among members, and fights with other projects. Either kind of fight alienates editors and reduces the capacity for productive work.

• Fighting between members. WikiProjects are fundamentally social endeavors. If your group doesn't work well together, then the project is likely to fail. Fights between members may start on an article's talk page and spill over to the project's pages. It is helpful to address these problems promptly, calmly, and consistently.
• Fighting with other WikiProjects or unaffiliated editors. No project can control another project or other editor: No project can demand that another project support an article, change its scope, quit working on an article, or otherwise do what you want. Disputes may arise between projects or outside editors over formatting, such as the preferred system for organizing an article or the contents of a template. Disputes may also arise over quality standards. For example, WikiProject Medicine has higher standards for sources than WikiProject Alternative medicine, which uses the normal standards for reliable sources. WikiProject Military History has long had much higher standards for article assessment than the average project. In disputes with another project or with editors outside your project, your only effective tool is negotiation. If you need the cooperation of another project, approach them in a spirit of cooperation and look for appropriate compromises.

Violating policies

更多信息：WP:CONLIMITED

Policies, guidelines, and articles belong to the whole community, not to WikiProjects or individual editors. WikiProjects may not demand that editors abide by the project's "local consensus" when that conflicts with the community-wide consensus.

If a project chooses to write an advice page, such advice should not directly conflict with the site-wide advice pages.

Over-tagging

参见：Wikipedia:WikiProject Council/Guide § Article_tagging

Many WikiProjects use banner templates to label the talk pages of articles that are within the scope of their projects. Project banners advertise the project to potential members, and, in some cases, adding a project banner to a new article's talk page can also have the effect of alerting the project to the existence of the new article.

New projects do best when they focus on identifying the Top- and High- priority articles. Assess them (if your project participates in the assessment project) and start improving those articles. Tagging articles can distract new projects from more important tasks. Please consider these common-sense issues when deciding whether to place a project banner on a page:

1. The article must be related to the scope of the WikiProject. Please consider adding a message on the talk page or using the |explanation=parameter if the connection is not obvious.
2. Project banners on the talk page should not be substitute for, or simply duplicate, Wikipedia's categorization system. To correctly identify an article as being related to a topic, place the correct category in the article itself.
3. The presence of a project banner indicates to readers that the article has been, or will be, developed by members of the project, and that questions about the article can be directed to members of the project. When the project does not expect to support an article's improvement, it should not add the project's banner to that page.
4. While all editors are invited to tag articles for any active project, the project has the right to remove its banner from any article that it does not intend to support.

The Wikipedia 1.0 Editorial Team uses the assessments provided through project banners to do an automated screening of articles for possible inclusion. For the purposes of the Wikipedia 1.0 Editorial Team, the number of projects that tag an article has no effect on whether an article is selected.

Inappropriate exclusivity

Nearly all projects maintain a list of "members" or "participants", and the definition of a "real" member is occasionally a source of contention in some poorly run projects. Broadly speaking, neither those members whose names are on a project's list nor those "charter members" that supported its initial creation have any special powers or rights compared to other editors. In fact, in nearly all projects that elect coordinators, editors that have participated in some small way, but haven't yet placed their names on the formal membership list, are even allowed to vote on an equal basis with listed members.

In part, this is due to the fact that nearly all membership lists are inaccurate. Rather than dramatically increasing bureaucratic overhead to maintain current lists, and then trying to restrict participation to those editors that list their names in a particular place, most projects simply assume that any editor currently involved in its work is a member. This highly practical approach prevents the inappropriate inclusion of editors that listed their names but have since left Wikipedia entirely or have moved on to other areas, as well as preventing rejection of valuable participants that didn't bother to sign the list, didn't know that such a list exists, or weren't yet sure that they wanted to publicly commit to the project.

All editors that approach a project with comments, questions, or suggestions should be welcome and treated courteously, as valuable potential members or real members that simply haven't taken the step of signing a designated page. To make your project a welcoming, friendly, and ultimately successful group, avoid saying things that will be received as excluding these editors, such as "Thank you for adding your thoughts for the project members to consider" or "We should keep this discussion among existing project members."

Technical notes

There's lots of useful information about creating different templates at Wikipedia:WikiProject Council/Guide/Technical notes. That page discusses:

• Advanced project banners
• Internal navigation templates
• Task list templates (e.g. {{todo}} and custom versions thereof

Some of these also include information about Task Forces

Project categories

As WikiProjects have become more common, the need for a standard system of categories for the projects' internal use has become apparent. WikiProjects usually expand their category namespace as they grow; but (using the example of WikiProject Birds again) there are several possible categories that can be created:

• A top-level category for the project; it should have the same name as the project itself, known as an eponymous category—in this case Category:WikiProject Birds. The category should be placed under one ofCategory:WikiProjects's subcategories (e.g. Category:Science WikiProjects) instead of under Category:WikiProjects directly. Some WikiProjects may be found within a "parent" WikiProject's enpoymous category (e.g. Category:WikiProject Fauna), although this is not required and may make finding the "child" project more difficult within the Category:WikiProjects hierarchy. It is generally not a good idea to place mainspace articles directly into a project's eponymous category; for all but the smallest projects, they will quickly overwhelm the internal pages, making them quite difficult to locate.
  • Once the project begins to develop article-related processes, such as assessment or peer review, it is appropriate to create a subcategory for the various articles being tagged into them; the conventional name for this is formed by appending "articles" to the project name (e.g. Category:WikiProject Birds articles). This can have a number of different subcategories:
    • Article assessment requires a Category:Bird articles by quality (and, optionally, a Category:Bird articles by importance), which must also be a subcategory of Category:Wikipedia 1.0 assessments. These will have further subcategories that follow the levels of the assessment scales, such as Category:A-Class bird articles and Category:B-Class bird articles for quality assessments.
  • Peer reviews and collaborations will usually require pairs of categories for current and archived articles (e.g.Category:Requests for Birds peer review and Category:Old requests for Birds peer review).
  • Task forces usually have at least one category for each task force; for an example of this, seeCategory:Military history articles by task force.
  • The articles category might have other subcategories containing such things as stubs, merged articles, articles needing attention, and so forth; an example of this type of management can be seen at Category:WikiProject The Beatles articles.
• Many projects also create a category for the project's members; this would generally be named either Category:WikiProject Birds participants orCategory:WikiProject Birds members. The category should be a subcategory of both the eponymous category and Category:Wikipedians by WikiProject, and may sometimes be populated through a userbox.
• The largest WikiProjects will often acquire a number of other categories for organizing things such as templates or archives.

Further examples of category trees in actual use can be found by browsing Category:WikiProjects; a few examples showing many of the features described above are Category:WikiProject The Beatles, Category:WikiProject Biography, and Category:WikiProject Military history.

维基百科專題列表

維基百科专题委员会

維基百科專題指引