User:Jeff02/The purpose of WikiProjects

The U.S. Roads WikiProject
New user orientation
General
Project home (WP:USRD) talk
Portal (P:USRD) talk
Project category
Discord (WP:DISCORD) talk
Popular pages (WP:USRD/PP)  
Recognized content (WP:USRD/RC)  
Departments
Assessment
Assessment home (WP:USRD/A)
 → Statistics table  
 → Log  
 → Category  
 → Visual aids  
By-state assessment (WP:USRD/A/S) talk
 → Live table (WP:USRD/A/L) talk
 → WikiWork (WP:USRD/A/WW) talk
 → State audits (WP:USRD/A/SA) talk
A-Class review (WP:HWY/ACR) talk
Maps
Maps home (WP:USRD/MTF) talk
 → Requests (WP:USRD/MTF/R) talk
 → Tutorial (WP:USRD/MTF/T)  
Newsletter
Newsletter home (WP:USRD/N) talk
 → Newsroom (WP:USRD/NR) talk
 → Past issues (WP:USRD/N/I)  
 → Subscribe (WP:USRD/N/S)  
Resources
Resources (WP:USRD/RES) talk
AASHTO minutes (WP:USRD/AASHTO)
Lengths (WP:USRD/L) talk
Maps (WP:USRD/MDB) talk
Periodicals (WP:USRD/PER) talk
Shields
Shields home (WP:USRD/S) talk
 → Requests (WP:USRD/S/R) talk
 → Tutorial talk
 → Research  
 → Database  
Task forces
National task forces
State task forces
Portals
Editing guidelines
Article standards (WP:USRD/STDS)  
Naming conventions (WP:USSH) talk
Road junction lists (WP:RJL) talk
Notability (WP:USRD/NT)  
Rockland County Scenario (WP:USRD/RCS) talk
Michigan Plan (WP:USRD/MP) talk
Route Lists (WP:USRD/STDS/L) talk
Project resources
Participants (WP:USRD/PAR)  
Article alerts (WP:USRD/AA) arch.
Essays (WP:USRD/E) talk
Precedents (WP:USRD/P) talk
Things to do
To-do list
General stubs  
Project maintenance categories  
Articles needing attention  
Articles needing maps  
Articles needing shields  
Interstate RJL compliance talk
Systems and lists
Redirect lists
Templates
{{WikiProject U.S. Roads}} (doc) {{USRD}} talk
Article templates (WP:USRD/AT)
Barnstar list (WP:USRD/BS)
{{Infobox road}} talk
{{Infobox road small}} talk
{{Jctint}} talk
{{Jct}} talk
Stub templates (WP:USRD/STUB)
Userbox list (WP:USRD/UBX)
{{HWY Announcements}} talk
{{Welcome-roads}} talk
related changesv · d · e

Notice: Although this essay is outdated and was mostly me venting at USRD, I'm keeping it in this form as a historical archive. I feel that there is still some helpful advice here, and this essay also explains my opinion on how USRD was treating its subprojects. Because I have ceased to maintain this essay, its content may not necessarily reflect my current opinion.

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

The WikiProject hierarchy edit

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. The idea that subprojects are intended to relieve burden from the parent project is especially true when one considers that the above 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.

Leadership of WikiProjects edit

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.

The purpose of WikiProjects edit

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.

Conclusion edit

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.

See also edit