Wikipedia talk:WikiProject Council/Guide

From Wikipedia, the free encyclopedia

You have new messages (last change).

WikiProject Council

General information
Main page talk
   To-do list
   Templates
Contacts talk

Resources
Guide talk
Assessment FAQ
Directory talk
Proposals talk
Newsletters talk
edit · changes

Contents

[edit] Initial Setup

Another approach is to use the template that is there for starting new projects and then comment most of it out. This has the advantage that when you need stuff, it's already there and present in a uniform way. Not sure this is non-contentious enough to include so here it is on talk... ++Lar: t/c 04:26, 16 August 2006 (UTC)

Meh. In my experience, about half of what's on that template is utterly insane and shouldn't be used at all, much less recommended; and much of the other half is redundant with the other features that we're describing further down the page (and is overkill for a new project). But that's just my opinion. ;-) Kirill Lokshin 04:29, 16 August 2006 (UTC)
Maybe this project ought to take a big pruning knife to it? WPBeatles still has parts of it commented out as not having been used... the idea itself seems sound even if there's too much cruft there now. ++Lar: t/c 11:16, 16 August 2006 (UTC)
Not a bad idea. Kirill Lokshin 12:19, 16 August 2006 (UTC)
I've tried my hand at ruthlessly trimming {{WikiProject}} of all the stuff that was outdated or just not useful; hopefully the result is something that will be more approachable for a project that's just starting out. Kirill Lokshin 19:37, 27 August 2006 (UTC)
When creating WikiProject Louisville, I took a similar WikiProject, WikiProject Chicago, and used its project page for a template. That has worked out very well. Of course, I've made many modifications since that point, but it was a great start. Stevie is the man! Talk • Work 17:11, 24 August 2006 (UTC)

[edit] Banner image size

After seeing what WP:Philadelphia and WP:Pennsylvania originally used for their project banners, and seeing that both have now reduced their banner image sizes, I've added a note here about the image size. Anything over 100px is way too big for an image; 50px is currently the preferred image size. Slambo (Speak) 11:29, 30 August 2006 (UTC)

Even with the reduced size, I find the use of banners on articles to indicate they belong to a project, may or may not be a featured article, and other similar stuff irritating. As a reader, I am not interested in stuff like wiki-internal elections. I want to read the text. I already encountered articles with 3 or 4 such banners, making me have to scroll down to start reading.
I suggest we either move these banners to the talk pages, where they - as wiki internal stuff - imho belong, or make them invisible to unregistered visitors, or greatly reduce the size. TeunSpaans 07:20, 27 October 2006 (UTC)
The banners that I was talking about are already restricted to the article talk pages and not the article text. There is discussion elsewhere on other solutions for the quantity and size of talk page banners; the proposed solution that I like best would add a "Metadata" tab to each article where project banners could go, but I don't see this happening in the near future. Slambo (Speak) 10:47, 27 October 2006 (UTC)

[edit] Overlap between projects

Can there be something discussing project overlap? I'm not necessarily talking about descendant projects with obvious overlap, but merely two subjects which have some common topics. Specifically, I'd like to see something written that mentions that it's okay for a given article to "belong" to several WikiProjects. I mention this only because I've seen in the past that sometimes a project banner is removed from an article talk page only because of someone misunderstanding that an article can only be a part of one WikiProject. Thanks! Girolamo Savonarola 21:40, 6 September 2006 (UTC)

WP:BIO is a prime example of overlapping scopes. There are many articles about individuals pertinent to specific projects (such as those listed in Cat:American railroad executives) that clearly fall in the scope of BIO and other projects (such as WP Trains, to continue the example). I think for this page, mention should be made that some articles will overlap seemingly unrelated projects, and that's OK. Slambo (Speak) 01:39, 7 September 2006 (UTC)

[edit] Portals and WikiProjects

WikiProject — Portal dynamics are tricky and require extensive collaboration and could benefit from some central guidance. Please have a look. | 0^#o 21:33, 25 September 2006 (UTC)

[edit] Guidelines

Wasn't sure if this was the place to suggest guidelines for certain things? I worked out with Wikipedia:Manual of Style (writing about fiction) a guideline for writing about fictional characters and fictional TV episodes. It was a tedious process getting feedback, so it'd be a shame to have to make someone go through the same thing.... Thoughts? --plange 23:47, 28 September 2006 (UTC)

Well, this would be the place to propose guidelines for WikiProjects and their organization, but not really for guidelines that deal more directly with article content. That being said, I'm a big fan of WP:WAF and would be glad to help you out even if it doesn't apply to this page. -- Ned Scott 00:28, 29 September 2006 (UTC)
Cool-- it was for WP:FIREFLY and though we've yet to get it applied to all FF articles yet, it's a start. After I got it hammered out with WAF I redid Malcolm Reynolds, but it still needs work. The rest of the FF character articles are still pretty crufty... So much to do! Any feedback you'd like to give on these guidelines would be great. I guess for the purposes of this guide, perhaps we should say they should consult WAF when writing about fiction to determine their guidelines for articles? --plange 00:58, 29 September 2006 (UTC)

[edit] Basic inconsistency

The first topic, What is a WikiProject, beats about the bush and doesn't answer the question: what IS a wikiproject? This should be answered concisely and effectively, as it is a key point. Asking what it is and spouting philisophical verbiage won't help. -Slash-

Holy crap, that whole section needs to be rewritten from scratch. Whenever someone asks me what a WikiProject is I generally say something to the extent of "WikiProjects serve as a centralized place for collaboration on anything from a group of related topics / articles or even general editing efforts." Maybe we should expand on something from that. Less "zomg, what is life, really?" and more .. actually answering the question. -- Ned Scott 06:00, 15 October 2006 (UTC)
Hmm, this guide was meant to be taken in conjunction with Wikipedia:WikiProject, which gives the "concise and effective" (but pretty unhelpful, in my experience) definition you're talking about. When I wrote that section here, I was working under the assumption that the reader would already be familiar with the "official" definition; but if you think it needs to be repeated here... Kirill Lokshin 13:57, 15 October 2006 (UTC)
I've made some changes to the section, quoting the technical definition (which is what you're thinking of); hopefully, the context of the discussion—and the point that's being made—is a bit clearer now. Kirill Lokshin 18:08, 22 October 2006 (UTC)
Much better now :) -- Ned Scott 01:19, 26 October 2006 (UTC)

[edit] Template:WikiProject

When I started both the California WikiProject and the Southern California WikiProject, I was frustrated with many of the features and organization of the {{WikiProject}} template. There were several sections that didn't seem that useful, and when looking at many of the most active WikiProjects, those sections were not used much, and when used, didn't seem to be that useful. I also found very userful sections in some of the most active WikiProjects that were not in the WikiProject template.

I ended up looking through all of the place-related WikiProjects that were running at the time (and quite a few of the other most active WikiProjects), and I tried to incorporated the best features of those WikiProjects in to the two California WikiProjects. I also tried to add most of those features into the WikiProject template.

Since then, the Southern California WikiProject has been extensively reorganized, although I think that it now needs some minor tuneup after experience with the reorganization.

I think that it is time to look again at some of the most active WikiProjects to see what some of their most useful, as well as most innovative features are. Then there should be an extensive overhaul of the WikiProject template. BlankVerse 09:07, 26 October 2006 (UTC)

Mmm, {{WikiProject}} has been significantly changed over the past few months, so I'm not entirely sure which version you had issues with.
In any case, I think we ought to be somewhat careful wehen trying to adopt thing from the "most active WikiProjects" to this template. There are many things which make sense for a project with 300 members, but would be absurdly complicated for a project with 3 members; similarly, there are things which aren't really good approaches in the long run, but which may be preferred for a project that's just starting off because of their simplicity. Stuffing a new project full of bells and whistles—which may, indeed, be brilliant approaches for a larger, more active project, but which a new, small project simply doesn't need (and can't operate smoothly)—probably isn't a good idea. Kirill Lokshin 12:55, 26 October 2006 (UTC)

[edit] Assessments in practice

This section has remained a stub for a while, but I don't know what it is supposed to talk about... what do we want to put in there? Any ideas? Titoxd(?!?) 21:47, 16 November 2006 (UTC)

All of the stub sections, incidentally, contain some notes in HTML comments about what I had thought of putting there. I'm not entirely sure how helpful they'd be here; but maybe they can serve as a starting point. Kirill Lokshin 22:04, 16 November 2006 (UTC)
I think it is important for someone to write the how to handle growth stub because when a Project takes off tasks have to be given to keep the members occupied. This is also important because this stage can be vital to wikiprojects survival.
I have real trouble stopping myself from banging on the keys once I've started, so some serious pruning of the new draft of the section is probably in order. I think it does cover all the relevant points, though. As long as it is, it would probably be hard to imagine almost everything was not mentioned somewhere in all that. :/ Badbilltucker 22:10, 17 November 2006 (UTC)
Looks pretty good, overall. It could use some more "in the field" examples of the things it discusses, and a mention of the more formal assessment processes that have been tried in some projects; I'll see if I can get around to putting in both of those later today. Kirill Lokshin 22:28, 17 November 2006 (UTC)

[edit] WikiProject Banners (and more generally, naming conventions)

Hmmm, I don't think I've seen any standard proposed, but for the sake of consistency, I could support your suggestion. I think we'll hear a lot of objections from projects with long names and short template names (such as Wikipedia:WikiProject Rapid transit and its associated Template:WPRT). Slambo (Speak) 21:35, 28 November 2006 (UTC)
Redirects are good. Beyond that, attempts to impose pedantic standardization across WikiProjects are generally (a) not very useful in practice and (b) generate a lot of ill-will from the projects in question, who feel (quite legitimately) that their work is being needlessly interfered with. In this case, there's really no significance to what the name of the template is; as long as the project members can find it, any name is suitable. (Projects with many templates tend to adopt naming conventions for all of them, incidentally, which results in some of the possible variations here.) Kirill Lokshin 21:38, 28 November 2006 (UTC)
(edit conflict) What is the actual problem here? If it ain't broke... Titoxd(?!?) 21:39, 28 November 2006 (UTC)
  • A reasonable solution would be to create some kind of standard template (preferably based on what most banners already look like) and then ask WikiProjects on their talk page if they would adopt it as well. I suspect that most WikiProjects won't mind. For those that do, well, let them keep their own template, it's not doing any harm. (Radiant) 09:51, 29 November 2006 (UTC)
  • You mean just one big template for all WikiProjects (similar to {{WikiProject|MILHIST}}, {{WikiProject|Meteorology}}, {{WikiProject|Arizona}}</tt>, or something else? The problem with one big template is that many projects already use a lot of custom parameters (e.g. {{hurricane}}) and that in some cases, those parameters conflict with one another. This has been discussed previously, and it was generally thought to be a bad idea. Or do you mean something else? Titoxd(?!?) 16:35, 29 November 2006 (UTC)
  • I recently did a little bit of work on a generic WikiProject template at User:Mike Dillon/WikiProject banner. There is some discussion at User talk:Mike Dillon/WikiProject banner and some demonstrations at User:Mike Dillon/Sandbox#Generic WikiProject template. The demonstrations purposely leave out the all of the parameters since they would end up putting my sandbox into inappropriate categories, but they can be demonstrated by uncommenting the parameters and using "Show preview". As I've said on the discussion page, this is not meant to force projects to accept standardization (just as project don't have to participate in assessment), but is targetted at the majority of WikiProject that I assume don't want to maintain their banners in order to get "standard" parameters like "class", "importance", etc. Mike Dillon 03:29, 30 November 2006 (UTC)

I know at one time there were concerns about the effects upon server loads from having too many template redirects. Now, however, I'm seeing loads of template redirects and the developers seem to be saying that if there are any performance problems from template redirects, meta-templates, etc., that they will try to fix them with their programming.

If that's the case, then I think that it would be helpful to have a series of 'standard' redirects that will lead to whatever the banner template's real name is. I would suggest 1) template:WikiProject Example, 2) template:WPExample, and 3) Template:WPE (that is, whatever the WikiProject's shortcut is). The other alternative would be for WP:COUNCIL to maintain a directory of all the WikiProject banner templates.

The reason that this would be helpful is that I've run into quite a few times when I'm adding a banner for one of the Californai WikiProjects, or just doing an article assessment, and will notice that it should also have a banner from another WikiProject (for example, {{WPSchool}} for Wikipedia:WikiProject Schools). With all the different ways of naming a project banner, it's a real PITA to remember how some of them are named. BlankVerse 20:54, 9 December 2006 (UTC)

[edit] Possible rephrasing

I think we might want to consider rephrasing the heading "Is a project needed?" to something else. As it is currently phrased, I think it might be possible for people to overloook this section entirely. The average person reading the guide is generally already convinced that a project is necessary, or they wouldn't be trying to set one up, and they might either skip it entirely or just quickly skim it. Maybe a heading like "Possible project structuring", which is more ambiguous and thus less likely to be quickly written off by potential readership as irrelevant, might work a bit better. Badbilltucker 15:43, 29 November 2006 (UTC)

  • Good point. We have gotten a few too many projects with extremely narrow scope. (Radiant) 09:04, 30 November 2006 (UTC)

[edit] Many banners are now permprotected

Many of the project banners (and userboxes too, but that's a different process) were protected against moves and edits this morning due to their widespread use on a large number of pages. Should we now add something into the guide that recommends listing the "final" banner template on WP:RPP after the banner has been added to, say, 50 articles? By encouraging the projects to list their banners there, we don't have to wait for someone to count the number of times a template is used and realize that it has since become a "high risk template." Slambo (Speak) 19:15, 10 January 2007 (UTC)

I wasn't aware there was a big problem with project banners being vandalized. If it becomes a problem with a certain banner, then let them request protection, but it seems a bit needless to preemptively request it. Large numbers or not, it's the talk page, and that's not as attractive to vandals. -- Ned Scott 20:19, 10 January 2007 (UTC)
Or it might be a good idea after all.. see Template talk:WikiProject Texas#Protection. -- Ned Scott 19:00, 11 January 2007 (UTC)
Seems like Semi-protection would be better suited for such a task. Not sure why you would go for full protection unless it was a big problem. I've edited many templates and I'm not an admin. Morphh (talk) 19:53, 11 January 2007 (UTC)
Although I do not support most banners being fully perm-protected, I believe that if a banner is on at least, say, 200 talk pages, then semi-protection. Perm-protection (IMO) should only be used for banners on about 1000 pages and has had bad reoccurring vandalism in the past. I would like to remind everyone that this is only my opinion. Greeves (talk • contribs) 17:14, 27 January 2007 (UTC)

When a banner like {{tl|WikiProject California]] is on over 10,000 article talk pages, it makes sense to protect the template from vandal & spammer mischief. There are other banners, like the one for WP:FILM that are also on over 10,000 pages. BlankVerse 11:06, 17 February 2007 (UTC)

[edit] WikiProjects in mainspace category trees

Hi - I believe that per the usual Wikipedia / mainspace separation (see Wikipedia:Categorization#Wikipedia namespace, WikiProjects should not themselves be categorized into the mainspace category trees -- i.e., Wikipedia:WikiProject Science Fiction should not itself be categorized Category:Science fiction. If so, we may need some clarity on the guidelines about that. Thoughts? --lquilter 22:39, 12 January 2007 (UTC)

That has always been my understanding; portals can be added to normal categories, but projects (and project-internal categories) should not. Kirill Lokshin 22:43, 12 January 2007 (UTC)
Are you thinking of any particular difficult cases? - AdelaMae (t - c - wpn) 00:29, 13 January 2007 (UTC)

[edit] Wikiproject neutrality

Are Wikiprojects forbidden to support a particular point of view? If so, this page should state it explicitly. Pcu123456789 02:14, 3 February 2007 (UTC)

[edit] Need help with this

the links on this wikiproject are not working well pl help.WikiProject Pakistan/AssessmentUser talk:Yousaf465


[edit] Membership

What is the official stance by wikipedia about membership in projects? I am interested in doing a little work on a project, but I don't feel that joining the group is a good idea. Officially is there a rule on the books that dictates that only members of a project are supposed to be involved in the project? Thanks66.90.162.101 23:46, 21 March 2007 (UTC)

It depends on what you mean by project, but generally no. Titoxd(?!? - cool stuff) 23:50, 21 March 2007 (UTC)
Yep, membership is mostly for convenience, rather than a requirement for anything. Certainly, one can freely edit articles, participate in discussions, and so forth, without being a member—formal or otherwise—of a project.
(Of course, if you want to make major changes to a project's internal operations, it's considered polite to put yourself down as a member, and you're likely to elicit some surprise from the project's "regulars" if you don't.) Kirill Lokshin 00:54, 22 March 2007 (UTC)
As a quick aside, I've seen one editor leave WP this week (I noticed it from the change in the membership list for WP:TWP) because WikiProject membership is not a requirement before editing articles within the WikiProject's scope. Personally, I think that such a requirement starts us down an instruction creep path that we don't want to follow as it's contrary to the "anyone can edit" nature and basic principles of this site. Slambo (Speak) 10:51, 22 March 2007 (UTC)

By project, I am refering to a Wiki Project. Articles which have been grouped together because they concern a specific topic, and to develop a level of consistency to the included pages (WP:PROJ). Your answers are pretty much what I thought: one is not required to join a "project" in order to participate. I had a recent experience where I was instructed to "join" a particular project, but I am very uneasy about joining. Seems to be a way to regulate who and what can be added to an article or discussion. Whether or not that is the reality, the long term effects could in fact be exclusivity and lack of personal freedom on the Wiki (not to imply anything about WP being a democracy, which it is not, simply that I fear a cliqueish protectivism which could arise from required "membership"). 66.90.162.101 15:27, 22 March 2007 (UTC)

[edit] Page reorg?

[edit] Initial idea

Hi all. I've created a WikiProject recently, and fell into at least one of the Common Pitfalls that were previously noted in the comments in the Common Pitfalls section. So I've turned all those comments into headings; hopefully they're all useful. Also, I think the article is too long, and doesn't talk enough about scope. My proposal for the article is this (which I will hopefully get around to if there are no complaints):

  1. Make subpages for the following
    1. Technical Notes section (almost all of it) to Wikipedia:WikiProject Council/Guide/Technical notes
    2. Some Task Forces stuff at Wikipedia:WikiProject Council/Guide/Task forces; they could be expanded on, but better not here
  2. I think the "Initial considerations" should be renamed "Before you begin...". We need it to talk about:
    1. Identify project's immediate parents
    2. Identify the best size (risks with large scope, risks with small scope, number of participants, etc); this is currently in the Intro section, but it doesn't give any suggested criteria for assessing
    3. Consider a task force (I could incorporate bits of the task force section here)

Actually, I'll start rewriting "Initial considerations" now.

-- TimNelson 04:53, 30 March 2007 (UTC)

Comments, roughly following the order above:
  • The extra headings seem fine; it'd be nice to get some text under them too, eventually. ;-)
  • Yes, the technical notes could be moved off to a subpage with a link left; it's fairly abstruse material. I don't see any real point to trying to retain a summary on this page, though, given that it's mostly instructions that don't really summarize well.
  • I don't see the benefit of trying to break off the task force material; it's short (there really isn't that much to say about task forces, as they're not structure-heavy) and very important to any discussion of scope issues here. (Moving it off will also reduce the prominence of that portion, I think, which would be a mistake given the extent to which getting new task forces versus new independent projects is a good thing.)
  • I've avoided putting too much stock in what a project's "parents" are, mainly because they're not necessarily well-developed themselves; in some cases, trying to build links with them is useful, but in others its a waste of time.
  • Trying to pin down one-size-fits-all criteria for existence-as-project versus existence-as-task-force will be hard; it really depends a lot on the surrounding project "landscape", the degree of intersection with related areas and related editor groups, and so forth. (For example, a task force like WP:USMIL has a much bigger scope—in terms of number of articles covered—than most independent projects.) It'd also be conductive to people trying to push their way past good advice ("My idea passes criterion 3.1a, so you can't make a task force for it!"). I think a general discussion of related issues may be more appropriate than specific criteria here.
  • Task forces are already mentioned as an alternative to full-blown projects in that section, no?
Kirill Lokshin 05:31, 30 March 2007 (UTC)
  • Task forces: I agree that we want to have people creating task forces rather than projects. My personal inclination, though, (when reading) is to skim over anything too lengthy. Also, I notice Wikipedia:WikiProject_Council#To-do mentions helping "sub-projects" (I added the question about task forces there); I was thinking that there were a few things of this nature that could usefully be expanded on. I'm not suggesting that we remove all task force stuff to a separate page (in fact, a lot of it is pertinent here), but just that we have a separate page in which we can write more expansive material. As for task forces already being mentioned as an alternative, true; I only mentioned it to make sure people knew I wasn't throwing that part out.
  • Parents: The main reason I want people to identify the parents is so that they'll have some familiarity with the parents, and hopefully feel more inclined to form a task force at a project they know about, rather than fearing a nebulous "parent project" that they don't know about.
  • Criteria: sure -- I'm only suggesting criteria, not laying them down. I was wrong about the current section not suggesting any criteria -- it did, just not the one I was thinking of :). So I've redone it a bit.
Basically, I think we agree on pretty much everything, except possibly:
  • Task forces: do they need a separate page? (I still say "yes", but see my idea below)
  • Is the stuff I've written better than what was there (you haven't suggested any disagreement, but that may show up).
-- TimNelson 07:01, 30 March 2007 (UTC)
Comments on your additions:
  • "Parent identification" - we should probably explain what we mean by "parent" here, and how to deal with inactive or dysfunctional parent projects.
  • "Identify the best size" - lots of problems with this material:
    • Too many articles - I'm not sure what you mean by "graveyard effect" here, but it's perfectly normal that a WikiProject is unable to actively work on more than a small fraction of its overall scope at any time; this doesn't mean that the project should be cut down until that's no longer the case.
    • Annoying people - this needs to be explained in more detail if it's really a significant problem; but I'm not convinced it is, frankly.
    • Various discussions of Dutchmen, etc. - this is both extremely far-fetched hypotheticals—we don't have any projects with a thousand members, let alone ten thousand—and actually a pretty bad idea as far as the chosen example is concerned. There's a bit more to scopes than just the question of large versus small; the key concept is whether the scope is a "natural" one. By this I mean that certain scopes are structured such that subsets of those scopes intersect heavily in their editor base; for example, projects on each species of tulip would all be attracting the same editors: the tulip-lovers (who tend to be interested in tulips as a whole, rather than on a per-species basis). Having separate projects here is thus counterproductive; you wind up with multiple projects that have the same membership.
    • Risks of a narrow scope - see the comments above about natural scopes; you don't want to wind up creating one of the overlapping sub-projects, either. Also, the current text focuses too much on why the project might fail, which sort of assumes that we would want such a project to succeed in the first place.
    • Estimating numbers of people - this doesn't actually work in practice. It may have been a worthwhile estimate if there were lists of everyone editing in a particular area; but, since WikiProjects are self-selected groups, the size of a parent typically has no relation to the size of a child project.
    • Estimating numbers of pages - this only works for very simple topics; anything more complicated won't necessarily all link to the same article, or will have lots of false-positive links in.
You need to keep in mind that WikiProjects don't always work the way theory might dictate that they do; the idea of this guide has been to document what's done by successful projects, rather than producing a theoretical underpinning that doesn't actually match what occurs in practice. ;-) Kirill Lokshin 13:15, 30 March 2007 (UTC)
Ouch. Thanks for working with me on this.
  • Parents: Ok, I've made a note about ignoring inactive parents, but I don't know anything about dysfunctional WikiProjects; feel free to add something if you know about it
  • Best size:
    • Check Wikipedia_talk:WikiProject_Calvinism#Talk page claims to see about annoying people. My question is, is Doc (on that page) correct, or was I correct in my initial tagging of hundreds of articles. Or is there some middle path :).
    • Discussions of Dutchmen. Yes, I realise that it's far-fetched, I was merely trying to work with the example already used on the page (and inject a little humour at the same time :).
    • Natural scopes: point noted; I copied your text almost verbatim to the main page, because it said what we wanted.
    • Project failure: Well, in a way we want projects to succeed; failures, while good learning experiences, can also be a waste of time
    • Estimating number of people: fair enough. I guess I assumed that the amount of people from the parent project who could have been interested but weren't was probably equal to the number of people who weren't interested in the parent project, but were in the child. I agree we should only be describing what works, but it's nice to have an estimator. How about we suggest looking for categories like "Wikipedians interested in X", and using that as the number? Again on the assumption about the number of people not interested from the category being equal to the number of people interested, but not in the category. That's what I've observed with Wikipedia:WikiProject Calvinism, but maybe we should wait a while to see if that continues to be true.
    • Estimating number of pages: true. My intent here is that, since this will probably be a large number, it may dissuade some from doing their own separate WikiProject :)
Theory vs. Practise: True -- thanks for the reality check.
-- TimNelson 14:22, 30 March 2007 (UTC)
Let's see:
  • A single person complaining (on the talk page, even!) is generally not an indication of anything unless that person is Jimbo. More to the point, there's nothing wrong with large-scale tagging in and of itself; see, e.g. WP:WPBIO. The legitimate concern that the project isn't doing anything besides tagging is one that can be resolved by becoming more productive; once you reach a certain level of usefulness as a project, people will be much more likely to allow you to do whatever you want in this regard. (It is, though, a good idea to assess as you tag until that point; that will help avoid the impression that you're merely tagging for the sake of tagging.)
  • The problem is that WikiProject size is more an indication of how effective the project's recruitment is rather than of how many editors are interested in the topic. You're likely to get wild variation of the numbers in that respect. The category system is pretty useless as well, as most editors aren't aware of it and don't use it even if they are. More significant, though, is the fact that most of your new members will be new(er) editors rather than established ones, and wouldn't have factored into any existing listing at the time you start even if they would have added themselves to it otherwise.
  • There's still the problem of projects that (could) "succeed", but which would have been more effective as task forces.
  • Actually, (reasonably) large WikiProjects tend to be a good thing, so I'm not sure we ought to be discouraging them.
Kirill Lokshin 15:52, 30 March 2007 (UTC)
  • Large scope: Ok, the Common Pitfalls section talks about "Overly broad scope". Have you any idea what this was on about if it's not what I suggested? Or should that just be scrapped? Btw, I added "over-tagging" to the Common Pitfalls section (with an HTML comment so people know what I mean)
  • Size: Hmm :). I'll have to keep up my recruitment then :). But I've removed the stuff about estimating the number of people.
-- TimNelson 16:13, 30 March 2007 (UTC)
The issue of "overly broad scope" was (originally) intended to relate to the abject failure of broad topic-area projects (e.g. History, Culture, etc.) to actually do anything useful. It may not be that important, though; I suspect all the mistakes to be made in this regard have already been made. Kirill Lokshin 04:53, 31 March 2007 (UTC)
Ok, it's gone, both deleted from the intro, and commented out in the Common Pitfalls section. NB: I'd still welcome more comments in the section "Another Reorg idea", below.
-- TimNelson 05:10, 31 March 2007 (UTC)

[edit] Another reorg idea

Ok, here's my new idea. We restructure the guide like this:

  • Wikipedia talk:WikiProject Council/Guide: How to decide what size Project you need
    • Wikipedia talk:WikiProject Council/Guide/Inter-WikiProject and Super-WikiProject communication
    • Wikipedia talk:WikiProject Council/Guide/WikiProject: The Full-blown WikiProject stuff (most of the current Guide page goes here)
    • Wikipedia talk:WikiProject Council/Guide/Task force: A separate page documenting how to do that
    • Wikipedia talk:WikiProject Council/Guide/Collaboration: Links out to that sort of stuff, and some ideas as to how you can go about doing that sort of thing

Here's another idea; we could make people start at the bottom (Collaboration), and work their way up :).

Here's how it would go:

Guide
The current "Before you Begin..." section
WikiProject
Most of the stuff from the current "Guide" page
Task force
Some of the current Task force stuff, and a bunch of new stuff advising how to set up a task force
Collaboration
Advice on what to do with projects that are multi-page, but too small for a task force; the idea is that this would all be done through Talk pages.

-- TimNelson 08:06, 30 March 2007 (UTC)

The last two aren't really good ideas, I think:
  • We can explain the general concept of task forces and how they work, but providing explicit instructions on how to set them up is likely to be a recipe for disaster. The general approach here is to consult with the presumptive parent project about how they set up their task forces; doing it a different way ("That's what the guide says!") and then expecting the parent to adapt will almost certainly provoke rather heated responses.
  • Normal collaboration on an article is already covered by a variety of other guidelines; I don't see the benefit of rehashing it here (certainly not to the extent of having a full-blown subpage covering it).
Kirill Lokshin 13:20, 30 March 2007 (UTC)
  • Task forces: I guess my idea was to consolidate a lot of the information that's floating around into one place. Eg. I've started a new WikiProject, and some people want a task force (the first one). How do I do it? I'm not recommending that this be a policy, or even a guideline, but merely a collection of tips, hints, and the like, about Task Forces
  • Collaboration: Well, we could probably leave this stuff in the main article. I don't want to create any policies on it or anything, just tips again (ie. "what have we observed that works"?). Maybe Collaborations was the wrong name for it; most (if not all) of the current Collaborations document covers how to collaborate around a single page. I'm talking multi-page collaboration here. The point is to stop people forming WikiProjects and Task Forces :).
-- TimNelson 14:28, 30 March 2007 (UTC)
On the topic of the "collaboration" I suggested here, after investigation, it looks like what I mean is not a Wikipedia Collaboration, but something else. In order to avoid confusion, let's call it a "Topic Co-ordination". So what I'm suggesting now would be the following:
  • Guide: the current "Before you begin" section
  • WikiProject: Most of the current content
  • Task force: tips, tricks, and descriptions of how others have done them (especially Biography, Mil hist, and Islam)
  • Topic co-ordination: tips on how to co-ordinate on multiple articles without establishing a task force
-- TimNelson 07:45, 3 April 2007 (UTC)
Now I'm replying to myself for the second time :). I decided to start roughing out my ideas, so that you can see what I mean. I created Wikipedia:WikiProject Council/Guide/Task forces which is an outline of my idea. Maybe I should've created it at User:TimNelson/whatever, but too late now. We can move it later if we want. Note that this page is far from finished, and I'm not intending to link to it from anywhere except here.
After doing that, I realised that, probably as much as anything, what I need is a task force template, so that when I start creating task forces, even if I create my own template, I have something to start with. So I started work on that at Template:Task force. When I got half-way through, I realised that Kirill must already have something like this for the military history WP, and so I was wondering if he'd be kind enough to mention where it is so that I can pilliage it for ideas more easily. I wonder if WPBiography don't have something too, but if so, I have no idea who to contact.
Thoughts?
-- TimNelson 11:44, 3 April 2007 (UTC)
You will probably find the "Creating a new task force" bit here to be useful reading, then. ;-)
(Keep in mind, though, that it's very structure-heavy due to the structural complexity of MILHIST itself. A smaller project probably won't need quite as much work here.) Kirill Lokshin 13:25, 3 April 2007 (UTC)
Great! I've pillaged some ideas, and worked on Wikipedia:WikiProject Council/Guide/Task forces. Can some people take a look at it? If I hear no complaints, I'll link to it from the main article. It's not complete yet, but neither's the main article :). OTOH, I expect to receive complaints :).
-- TimNelson 06:26, 4 April 2007 (UTC)
Well, since you asked... ;-)
  • The headings could use quite a bit of shortening, I think.
  • "WikiProject Biography Work Groups (ie. task forces) have sub-Work Groups" - this doesn't seem like a useful thing to focus on, as it happens with other projects as well; e.g. WP:ACW is a "sub-task force" of WP:USMIL. The relationship isn't very important, though, as the technical infrastructure used is still the main parent project's, not the "immediate" parent task force's.
  • The setup of {{task force}} seems a bit artificial; I'm not sure how useful a subst:able boilerplate will actually be here, given that the technical chunks are likely to be set up quite differently depending on the parent WikiProject.
Overall, though, it looks quite good. Kirill Lokshin 01:31, 5 April 2007 (UTC)
  • Ok, I've shortened the headings somewhat, but I guess I like people to know what they're in for :).
  • I've put the sub-Work Groups bit in as sub-task forces, in the Misc tips section, and noted what you said there
  • Sure {{task force}} seems a bit artificial. It's meant as boilerplate to create boilerplate for your own WikiProject's task force. So, say I at WikiProject Calvinism want to create task forces, I could either use it as is, or create Wikipedia:WikiProject Calvinism/Task Force boilerplate based upon it. Also, I included everything I could understand from the parent projects, except the AfD section from Biography. I figure it's easier for people to delete stuff that they don't want.
Glad you like it though.
-- TimNelson 02:09, 5 April 2007 (UTC)

[edit] Task Force question

How many people do you usually need to form a task force? I have a few ideas for task forces at Wikipedia:WikiProject Calvinism, but I've shied away from creating any until we get at least 10 people that look like they might be interested in forming a task force. Is 10 a reasonable number?

Incidentally, this is the sort of question I want to answer on a separate Task Forces page :).

-- TimNelson 09:02, 30 March 2007 (UTC)

Ten is probably a bit too large a number; but keep in mind that task forces are very low-maintenance as far as the parent project is concerned, so having inactive and under-active task forces is not necessarily a significant problem. Kirill Lokshin 13:22, 30 March 2007 (UTC)
Any tips? Is 2 too small? How about 5?
Also, what's a good number of people to have in the whole project before we consider task forces? I was going to say 30 (remember, this project is one week old); is 30 too many, or not enough?
-- TimNelson 14:30, 30 March 2007 (UTC)
Around five is probably a good number. A task force likely won't be effective until it gathers 10+ active members; but, as the overhead is minimal, there's nothing wrong with creating them under-strength, provided that the scope is a good one in the long run. (Task force that don't exist yet tend to have trouble recruiting, so waiting too long to create them tends to produce a chicken-and-egg problem.)
I'd suggest having 50–100 members before getting serious about task forces; but, again, the costs of doing so beforehand are minimal. Kirill Lokshin 15:41, 30 March 2007 (UTC)
Great! Thanks for the tips. I created a slightly unusual participants list at Wikipedia:WikiProject Calvinism#Participants; tabular, and a specific space for describing interests. That means that I have a reasonable idea of how many people are interested in what, and can create task forces at appropriate points. It might not be good for all projects, but I think it's working for us; the only problem is, automatic numbering doesn't work in tables :). I tried tricking MediaWiki into doing what I wanted, but no dice, unfortunately.
-- TimNelson 15:56, 30 March 2007 (UTC)
Retrieved from "http://en.wikipedia.org../../../w/i/k/Wikipedia_talk%7EWikiProject_Council_Guide_3221.html"