User:Jeff02/The purpose of WikiProjects
From Wikipedia, the free encyclopedia
 |
This is an essay; it contains the advice and/or opinions of one or more Wikipedia contributors. It is not a policy or guideline, and editors are not obliged to follow it. |
- Please note that this essay is currently under construction, if you have any concerns about its content, please post them on the talk page
Over the course of Wikipedia's existence, groups of editors with related interests have come together to create WikiProjects, places where they can coordinate their efforts, discuss editing, share resourses, and make decisions regarding stylistic issues. I, myself started two such projects: WikiProject Maryland and WikiProject Roads in Maryland. In my experience working on the later, I have come across the U.S. Roads WikiProject. While it would seem that, since the U.S. Roads project (USRD) is a separate project from the Maryland roads one (MDRD), MDRD would be relatively independent from USRD, much the same way that WikiProject Maryland is separate from WikiProject United States. In my experience however, this has not been the case. I feel that this is because the views of some of the "core" members of USRD on WikiProjects are drastically different from those of other Wikipedians, and these same views have led to conflicts between editors. I think we can all agree that these conflicts waste precious time that could be better spent editing articles.
Contents |
[edit] The WikiProject hierarchy
A hierarchy of sorts exists between WikiProjects. From my point of view, the purpose of this hierarchy of parent and child projects serves to help take the burden off of the parent projects. An example of this is the relationship between MDRD and WikiProject Maryland. WikiProject Maryland members need not worry about articles about roads in Maryland (unless the road is sufficiently notable to Maryland as a whole) since there is already a project for such articles. Instead, they can focus their efforts and discussions on other topics. This becomes important as a project gets large. A large project can be impractical to maintain as a single unit, some of its task forces have likely began functioning as separate units and would be better off working on their own. When this happens, splitting these task forces into separate projects can help simplify the structure of the main project and allow the new projects to work on their own, making work simpler and less stressful for both projects.
USRD's viewpoint is apparently that child projects actually increase the burden on the parent project. For a while now, they have been discouraging the creation of new child projects. The reason for this seems to be the idea that USRD owns its subprojects and is responsible for the maintenance of the project pages and articles within their scope. Recent actions by USRD members, such as the merging of all child project participants lists into USRD's list without allowing them to have their own lists and the gradual replacing of child project banners with the USRD one, support this belief. This is especially true when one considers that such actions need not be taken by the parent project if it simply lets the subprojects function on their own. For example, there would be no need to replace subproject banners with that of the parent project in order to streamline assessments if the members of the subproject assessed articles themselves. Only in the case that a project is not capable of running itself should its parent project change the way it operates (such as making it into a task force). Most WikiProjects are capable of running themselves, which is why they are WikiProjects and not task forces.
The now-infamous SRNC provides a more historic example of USRD considering all child projects to be one and the same with USRD, and what's wrong with this thinking. Before the final debate broke out I started an open discussion at WT:MDRD on the naming of articles and we peacefully decided on a naming convention. All throughout the SRNC debates, I stressed that the decisions should be made at a subproject level, but instead one large process involving all state subprojects began. The process was multi-stepped and complex and the last part of it involved multiple discussions all being made on one page, when the entire task could have been split up between the states and it could have become as easy as MDRD made it.
[edit] Leadership of WikiProjects
My view on who leads a WikiProject is that no one leads them. Instead, WikiProjects should be run by their members. Instead of one person or a small group of people making decisions in a sort of walled garden and enforcing those decisions on other members, or even members of a subproject, they should be open and discuss things on the project page, or in the case that the results of a discussion will affect subprojects, post a notice on the subproject page directing members to the main discussion. While it may seem impractical for a parent project, especially one with as many child projects as USRD has, to post a notice on the talk pages of each subproject, the reality is that ideally, this should not have to occur often. Aside from determining general style guidelines, there isn't much a parent project should decide that impacts all child projects directly and simultaneously.
It is the opinion of myself and at least one other involved Wikipedian that USRD's core members have in fact formed a walled garden, and if anyone tries to dispute their decisions, they claim that they have a consensus which cannot be changed.
[edit] The purpose of WikiProjects
What this all comes down to is the question "What are WikiProjects for?" My personal opinion is that a WikiProject is just a place for editors to come together and not a bureaucracy. WikiProjects should not be used to create rules that all members have to follow, they should not be used to pick a fight, and they should definitely not be used to form a structure of people who have "power" over others. If certain projects which are determined to be subprojects based on their scope exist, it is not the purpose of their parent project to control them. For example, the parent project is not responsible for managing the creation and deletion of subprojects. Deletion should be handled by editors either through the Wikipedia:WikiProject Council, a Wikipedia-wide process (such as MfD) or through a direct discussion between the two projects. Creation should be done either through the WikiProject Council or completely on a whim by an individual editor, however it is probably a good idea to gauge the opinion of the parent project first. Each WikiProject is an individual unit that is able to stand on its own. If projects are not treated as such and are instead treated as hierarchical components of a large project, the large project will become a complex system of pages and a bureaucracy. This has the potential to happen to any large WikiProject no matter how it is formed.
While not a WikiProject, Esperanza provides an example of what goes wrong with a bureaucracy on Wikipedia. It started as a simple effort, but grew into a huge hierarchical organization with several subpages. Leaders were elected, and made binding decisions on IRC. Esperanza was eventually decentralized and the subpages that started there are now their own individual pages. This shows that when a project becomes large, it is best to split it up instead of allowing the whole project to continue running as a single organization.
[edit] Conclusion
USRD has sparked two arbitration cases (1 and 2) and taken actions that have upset me and other members of its subprojects, including the removing of participants lists and project banners from those projects. MDRD on the other hand has sorted out disputes peacefully, including naming convention, and what type of Interstate highway signs to use in articles.
Perhaps USRD can be a more peaceful place if its members' general behavior changed to be more "wiki-like" and they worked together through consensus, and realize that even if they have already formed a consensus, it can still change. Also USRD should acknowledge that subprojects are there to narrow the scope of the parent project as opposed to adding complexity to it. If that is considered, it can result in less stress for USRD members since they need to worry about less. This can be achieved by simply letting subprojects run themselves; this includes letting them, among other things, have their own lists of participants, tag articles within their scope with their own banner, and handle their own article assessments. Hopefully this change in attitude can help end the seemingly endless bickering that has been seen within USRD.
