Wikipedia:ProyekWiki/Pedoman/Gugus tugas

Sebuah gugus tugas adalah, intinya, sebuah sub-kelompok dari suatu ProyekWiki yang meliputi beberapa bagian tertentu dari cakupan ProyekWiki tersebut.

Perbedaan antara sebuah gugus tugas dan sebuah ProyekWiki adalah bahwa gugus tugas bisa mengurangi rumitnya birokrasi: dia bergantung kepada proyek induk untuk menyediakan berbagai infrastruktur teknis dan proseduralnya. Sebuah gugus tugas, misalnya, menggunakan proses ulasan sejawat dan penilaian dari proyek inti ketimbang membuatnya sendiri, sehingga memungkinkannya untuk fokus pada menulis dan menyunting.

Sebuah gugus tugas umumnya diatur di sebuah subhalaman dari halaman proyek induk. Dalam kasus gugus tugas menjadi turunan dari dua proyek (dengan kata lain, jika cakupannya merupakan pertemuan dari dua induknya), subhalaman tersebut dapat ditempatkan di bawah salah satu proyek tersebut secara arbitrasi, dan halaman yang lain menggunakan pengalihan. Halaman gugus tugas tidak terbatas bentuknya, tetapi seharusnya awalnya disusun dengan aturan birokrasi yang minim. Proyek-proyek dengan angka gugus tugas tinggi sering mengadopsi suatu tata letak standar untuk semua gugus tugas, mungkin dengan memasukkan fitur teknis umum.

Gugus tugas biasanya tidak memiliki spanduk halaman pembicaraannya tersendiri; melainkan, disatukan langsung dengan spanduk proyek induk melalui parameter opsional.

Konten gugus tugas

Gugus tugas utamanya adalah sebuah konstruksi sosial, tetapi memiliki butir-butir berikut yang berhubungan dengannya.

Subhalaman miliknya sendiri

Sebuah gugus tugas umumnya diatur di sebuah subhalaman dari halaman proyek induk. Dalam kasus gugus tugas menjadi turunan dari dua proyek (dengan kata lain, jika cakupannya merupakan pertemuan dari dua induknya), subhalaman tersebut dapat ditempatkan di bawah salah satu proyek tersebut secara arbitrasi, dan halaman yang lain menggunakan pengalihan. Halaman gugus tugas tidak terbatas bentuknya, tetapi seharusnya awalnya disusun dengan aturan birokrasi yang minim. Proyek-proyek dengan angka gugus tugas tinggi sering mengadopsi suatu tata letak standar untuk semua gugus tugas, mungkin dengan memasukkan fitur teknis umum.

Bagian-bagian halaman

Masing-masing gugus tugas biasanya memiliki bagian ini di halamannya:

• cakupan
• daftar peserta
• daftar PR

Sebagai tambahan, bisa memiliki:

• pedoman khusus gugus tugas (tidak selalu dinamai pedoman)
• daftar konten pilihan/bagus
• daftar rujukan yang bisa digunakan untuk gugus tugas tersebut

Lain-lain

Butir lain yang biasanya dimiliki gugus tugas adalah:

• setidaknya satu kategori untuk masing-masing gugus tugas
• satu bagian di spanduk halaman pembicaraan dari ProyekWiki; ini bisa dimanfaatkan untuk menyediakan penilaian terpisah

Infrastruktur Proyek Induk

Sebuah gugus tugas biasanya akan bergantung pada proyek induknya untuk struktur birokratis dan administratifnya. Selengkapnya di bawah, di bagian "Mengatur sebuah struktur gugus tugas", tetapi beberapa butir di antaranya adalah:

• penilaian: ini termasuk spanduk halaman pembicaraan (yang biasanya adalah milik proyek induk, tetapi memiliki penanda untuk gugus tugas). Ini tidak berarti bahwa gugus tugas tidak membutuhkan penilaiannya tersendiri; mereka dapat bergantung kepada proyek induknya saja,
• templat navigasi proyek (yaitu templat navigasi internal),
• pengaturan dan integrasi halaman permulaan dengan bagian lain dari proyek,
• kerumitan birokratis lainnya.

Saran-saran lain

Sub-gugus tugas

Beberapa gugus tugas memiliki sub-gugus tugas. Sub-gugus tugas meliputi satu bagian dari cakupan gugus tugas induk, tetapi infrastrukturnya disediakan oleh proyek induk.

Pusatkan percakapan gugus tugas Anda

Seringkali sebuah gugus tugas bermula sebagai sekelompok editor yang telah bekerja sama dan telah memiliki pola komunikasi. Gugus tugas kecil perlu menaruh usaha untuk memusatkan diskusinya di halaman-halaman gugus tugas. Apabila tidak ada kiriman di halaman pembicaraan gugus tugas, beberapa penyunting akan beranggapan bahwa tidak ada yang sedang melakukan pekerjaan. Hal ini mempersulit penyunting baru untuk bergabung ke kelompok Anda. Anda dapat membuat laporan perkembangan Anda, atau mengumumkan artikel yang ingin Anda kerjakan selanjutnya.

Selalu informasikan kepada "orang tua"

Kapan saja kelompok Anda menempuh suatu titik atau memiliki kabar baik yang bisa dibagikan, kirim sebuah catatan di halaman pembicaraan ProyekWiki induk dan ajak yang lain untuk mengikuti Anda di proyek selanjutnya.

Mengatur sebuah struktur gugus tugas

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 join 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.

Membuat subhalaman untuk gugus tugas

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

Menambahkan gugus tugas ke spanduk halaman pembicaraan

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.

Mengatur sebuah daftar PR dengan sub-templat

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.

Membuat batang navigasi internal

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

Mengubah proyek yang ada menjadi gugus tugas

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. 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 you're 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.
3. 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.
4. 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"
5. 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.
6. 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.
7. 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.
8. 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).
9. Update other project space. If they weren't already a subpage, modify any existing Project-class pages from the converted project as needed.
10. Check for pre-existing auto-archiving on talk pages, and update those links as well.
11. Update links and wording to old WikiProject from Special:Whatlinkshere, looking largely at the Wikipedia namespace.
12. Update the converted project's WikiProject Directory entry
13. Replace usage of the moved project's banner with the parent/task force banner
    • Article 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.
    • Article talk pages with only the converted project's banner need to have the parent project's banner added 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:Xenobot Mk V).

14. Redirect the moved project's banner to the parent project's banner. The moved project's previous banner template should not be used on any article talk pages once the banners have been swapped out.
15. 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) criteria for speedy deletion.

Mengubah gugus tugas yang ada menjadi proyek

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.