維基百科:專題委員會/專題指引/專題

維基百科專題是想共同工作改進維基百科者的小組。維基專題頁面並非他們作品的遴選處，亦非愛好者的主題區。本頁提供關於組織討論與管理問題的建議，以便團隊更高效的協作。

初始設置

創建一個專題頁面

當你一旦決定建立新專題後（指引可能指出更好的替代方法），請務必創建一個主頁面。維基專題的命名常規為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.

維基百科專題列表

維基百科專題委員會

維基百科專題指引