A task force is, essentially, a non-independent subgroup of a larger WikiProject that covers some defined part of the WikiProject's scope. For example, the United States military history task force of the Military history WikiProject deals with the military history of that specific country; and the Nintendo task force of the Video games WikiProject covers a particular game creator.

The distinction between a task force and a WikiProject is that the task force minimizes bureaucratic overhead: It relies on the parent project to provide much of the procedural and technical infrastructure. A task force, for example, uses the core project's peer-review and assessment processes rather than creating its own, thereby allowing it to focus on writing and editing.

A task force is generally set up on a subpage of the parent project page. In cases where the task force is a child of two projects (in other words, where its scope is the intersection of that of its two parents), the subpage can be arbitrarily placed under either of the projects, and a redirect can be created from the equivalent subpage in the other; see, for example, the Korean military history task force, run jointly by the Military history and Korea WikiProjects. The task force page can take any form, but should be initially constructed with minimal bureaucratic fluff. Projects with large numbers of task forces will often adopt a more-or-less standard layout for all of them, perhaps including common technical features; for example, each of the task forces of the Military history WikiProject has a standardized template for listing open tasks.

Task forces will generally not have their own talk page banners; instead, they are integrated directly into the parent project's banner via an optional parameter. For example, {{WPMILHIST}} includes a large number of task force parameters. It is possible to use this integration to automatically generate assessment data for a task force based on the assessments entered for the main project; this ensures that task forces don't need to conduct assessments independently.

Task forces are primarily a social construct, but each usually has the following items associated with it.

A task force is generally set up on a subpage of the parent project page. In cases where the task force is a child of two projects (in other words, where its scope is the intersection of that of its two parents), the subpage can be arbitrarily placed under either of the projects, and a redirect can be created from the equivalent subpage in the other; see, for example, the Korean military history task force, run jointly by the Military history and Korea WikiProjects. The task force page can take any form, but should be initially constructed with minimal bureaucratic fluff. Projects with large numbers of task forces will often adopt a more-or-less standard layout for all of them, perhaps including common technical features; for example, each of the task forces of the Military history WikiProject has a standardized template for listing open tasks.

Each task force usually has the following sections on its page:

• A scope
• A list of participants
• A to do list

Additionally, it may have these:

• Task force specific guidelines (not always called guidelines, but that's what they'd be called if they were in a WikiProject)
• Lists of Featured/Good content
• List of resources that will be useful to that task force

The other items a task force usually has are:

• At least one category for each task force; for an example of this, see Category:Military history articles by task force.
• A section in the talk page banner of the WikiProject; this can be used to provide separate assessments

A task force will usually rely on its parent project for some of the administrative and bureaucratic structure. More detail is below, in the section "Setting up a task force structure", but some of the items are:

• Assessment: This includes the Talk page banner (which usually belongs to the parent project, but has a marker for the task force). This does mean that task forces don't need to do their own separate assessment; they can rely on the parent project for that.
• Project Navigation templates (i.e. Internal navigation templates)
• Initial page setup and integration with rest of project
• Other bureaucratic overheads

Sometimes it helps to see actual task forces in action. The projects that currently have the most task forces are (counts as of 5 October 2020):

• WikiProject India (77 workgroups)
• Wikiproject U.S. Roads (62 task forces)
• WikiProject Military history (55 task forces)
• WikiProject Philosophy (21 task forces)
• WikiProject Novels (19 task forces)
• WikiProject Biography (14 active workgroups, 1 inactive workgroup)
• WikiProject Islam (11 task forces)

Sub-task forces

Some task forces have sub-task forces. These cover a section of the parent task force's scope, but the infrastructure is also provided by the parent project.

Centralize your task force conversations

Often, a task force starts as a group of editors that are already working together and already have communication patterns in place. Small task forces need to make a particular effort to centralize their discussions on the task force's pages. When no one posts to the task force's talk page, some editors will assume that no one is doing anything. This makes it hard for new editors to participate in your group. You can create a critical mass of conversation by sharing information and ideas that might interest task force participants on the group's talk page. If nothing else, report on your progress, or announce the article that you want to work on next.

Keep your "parent" informed

Whenever your group achieves a milestone or has good news to share, post a note at the parent WikiProject's talk page, and invite others to participate in the next project.

If you want to create a task force for an existing project, you should gather consensus from the other project participants before bothering to read the next sections; they're designed for an existing WikiProject that wants to create task forces, especially the first one.

The first question to ask is whether your project is of sufficient size to warrant having task forces. The advice given by Kirill Lokshin of WikiProject Military history is that task forces are something to get serious about when there are 50-100 participants in your WikiProject. Additionally, a good number to start a task force with is five people; it may not be effective until it reaches 10 or so people, but having the task force there enables them to recruit. An additional thought is that creating task forces encourages people to participate in those rather than creating their own WikiProject which again incurs a lot of bureaucratic overhead.

Since this section is quite incomplete, it may be useful to read Wikipedia_talk:WikiProject Military history/Coordinators#How to... (you'll need to expand the "Creating a new task force" section).

It may also be useful to have a "New task force proposals page" attached to your project.

1. Open up the new subpage in your browser
2. Use Template:Task force to fill in the content (preview it with the parameters, and when you want to finalise it, use subst, e.g. {{subst:Task force}} )
3. Fill in some content, especially the scope

Task forces will generally not have their own talk page banners; instead, they are integrated directly into the parent project's banner via an optional parameter. For example, {{WPMILHIST}} includes a large number of task force parameters. It is possible to use this integration to automatically generate assessment data for a task force based on the assessments entered for the main project; this ensures that task forces don't need to conduct assessments independently.

As to how to actually implement this, you'll need to investigate the examples of {{WPMILHIST}} and {{WPBiography}}, although it may also help to review Advanced project banners; this doesn't cover that topic, but does cover a number of others.

One way to help keep a task force co-ordinated with the main project is to set up a method of incorporating all the todo lists into one master todo list. More information can be found on this at Wikipedia:WikiProject Council/Guide/Technical notes#Task list templates. Note also that Template:Task force (probably used to create the initial page) also links to a todo list; this would be a good name to use in conjunction with this.

If you're adding task forces to your project, it's probably time to add an internal navigation bar if you don't have one already. How to do so is really outside the scope of this document, but more information on doing this is at Wikipedia:WikiProject Council/Guide/Technical notes#Internal navigation templates

1. Establish consensus for a merger: Post notices on the talk pages of the parent project and the project you are proposing to convert. Please don't surprise another group of editors by moving their pages without any notice. Keep the discussion in one of the two talk pages, with one of the notices being a link to the discussion on the other. Allow ample time for participants in a less-active group to object.

   Things to consider are:

   • Is the project being considered still active?
   • How many participants are there?
   • What overlap is there in article scope? (This can be determined using the category intersection tool)

2. Move the project page, instead of creating a new task force page, move the project and its talk page to "Wikipedia:WikiProject Parent/name task force"
   1. Check for subpages and move them as well. Use Special:PrefixIndex to check for pages. Common subpages include /Assessment, /Userbox, and /Participants. Be sure to update links that point to those pages.
   2. Change converted project's page layout, if your parent project has a standardized layout for task forces then rearrange the newly converted project's page to match.
   3. Redirect redundant subpages. For processes which are going to be handled by the parent project (assessment, review, etc.) redirect the new task force's subpages to the parent project's.
   4. Update other project space. If they weren't already a subpage, modify any existing Project-class pages from the converted project as needed.
   5. Check for pre-existing auto-archiving on talk pages, and update those links as well.
3. Modify the parent project's banner to include task force parameters to match project being converted. Template:WPBannerMeta has examples on how to specify this for projects which use the meta banner. If your project doesn't use WPBannerMeta, it may help to review Advanced project banners; this doesn't cover that topic, but does cover a number of others.
   1. Redirect the moved project's banner to the parent project's banner or make it a wrapper template for the parent project's banner with appropriate pre-filled parameters
   2. Replace usage of the moved project's banner with the parent/task force banner. The moved project's previous banner template should not be used on any article talk pages once the banners have been swapped out.
      • Talk pages with both the converted project's banner and parent project's banner need to have the moved project's banner removed, and the task force's parameters added to the parent project's banner.
      • Talk pages with only the converted project's banner need to have it replaced by parent project's banner with the task force parameters.

        These steps can be performed manually, or for larger projects, with the help of a bot. A bot request can be placed (existing bots include User:AnomieBOT and User:PrimeBOT).

   3. Add the new redirects to the relevant entry at User:Magioladitis/WikiProjects so bots can handle future usages.
4. Create task force article categories, if the project performed article assessments, some categories may already exist. If WPBannerMeta is being used it should suggest any missing categories and provide links with preloaded templates to create the categories.
   1. Request renaming categories if there is no need to create a separate one. Simply go to Wikipedia:Categories for discussion for instructions.
   2. Delete any renamed categories. Any categories from the converted project which have been renamed and emptied should now be eligible for speedy deletion under either the empty category(C1) or renaming(C2) or template redirection(G6) criteria for speedy deletion.
   3. Make sure that automated quality assessment statistics are being generated correctly. If |TF_n_ASSESSMENT_CAT = Foobar articles is set for the task force, then categories of the type Category:FA-Class Foobar articles will be generated. Bring all these categories into a parent category Category:Foobar articles by quality, and categorise it under Category:Wikipedia 1.0 assessments. Assessments will be logged at Wikipedia:Version 1.0 Editorial Team/Foobar articles by quality log and overall statistics at User:WP 1.0 bot/Tables/Project/Foobar which is trancluded on Wikipedia:Version 1.0 Editorial Team/Foobar articles by quality statistics. See Wikipedia:Version 1.0 Editorial Team/Using the bot for more information.
5. Update links and wording to old WikiProject from Special:Whatlinkshere, looking largely at the Wikipedia namespace.
   1. Update the converted project's WikiProject Directory entry
   2. Update the converted project's Article Alerts entry (if it exists).
   3. Update the converted project's Hot Articles entry (if it exists).
   4. Update the converted project's Popular pages config (if it exists).
6. Update other project templates. If you haven't already, modify existing userboxes, welcome and invitation message templates, and other project related templates (if they weren't already a subpage).

1. Find a reason. When thinking about converting existing task force to a WikiProject, consider the following:

• Number of participants. If there are not enough participants, the project may become inactive because of administrative overload.
• Scope.WikiProject format is best for topics with thousands, or at least several hundred, of pages in the proposed scope. A WikiProject with a narrow scope may become inactive because of administrative overload – participants will quickly complete the work and get bored.
• Too much overlap. If the scope is too closely related to an existing project, then having separate projects is usually inefficient and counterproductive, because you wind up dividing the few interested editors across multiple projects. This approach maximizes administrative hassles and minimizes collaboration. However, there is no rule that prohibits two separate groups of editors from being interested in the same articles.