User:Pfctdayelise/WikiProjects community
How can Commons continue to grow and yet keep the feeling of a community -- how can Commons avoid harmful fragmenting?
How can Commons avoid the mistakes of en.wp?
This proposal is my attempt to answers these questions and find a positive future for Commons. pfctdayelise (说什么?) 06:51, 4 July 2007 (UTC)
I am reminded of Arnomane's mantra - "just do things, then promote them; not the other way around". So perhaps I will implement this plan more by stealth than by design, by creating some of the projects I suggest, and especially by creating skeleton documents and tips for new project-starters, to make that process easier.
For this, I think we first need a strong Aims/goals statement. So probably I will work on creating a formal aims/goals policy accepted first before seriously pushing for the 'project model'. --pfctdayelise (说什么?) 06:17, 7 July 2007 (UTC)
This is a proposal to reform Commons activity into multiple Wikiprojects or simply projects. All activities conceivably belong to one or more projects.
The main motivation for this is to solve the problem of community fragmentation. Commons is starting to reach a size where it's no longer possible for an active user to be aware of all the other active users. People get 'lost' in the bureaucracy and the feeling of a cohesive community is lost.
Why does this happen? It seems to happen when a wiki reaches a certain size. Relegating all activities to projects remakes those projects as the communit/ies. The feeling of a cohesive community united by a common goal can be regained.
At the moment projects are 'ad-hoc' according to the interests of some very dedicated users. However projects mirror the experience of users in smaller wikis. They are like a mini-wiki in themselves. Projects could potentially endorse admin candidates for example.
I envisage abolishing the village pump. Keeping the Help desk (Helping others), introducing 'Discussion announcements' where discussions being held within specific projects are announced centrally.
There are also dangers in such an action, see 'Problems' below.
Proposed projects[edit]
Top level:
- Uploading
- Categories (Organisation?)
- Topic-based (this is more an umbrella project rather than an active one)
- Quality control
- Helping others
- Translation coordination
- Reachout (links within Wikimedia)
- Awareness (publicity outside Wikimedia)
- Vandalism?
- Copyright?
- Bots?
(comments to follow)
Lower level:
- Images for cleanup (falls under Illustration, Quality control)
- Quality images (falls under Photography, Quality control)
- Featured pictures (falls under Quality control, Awareness)
- Photography (falls under Uploading, Categories)
- Illustrations (falls under Uploading, Categories)
- Audio (falls under Uploading, Categories)
- Video (falls under Uploading, Categories)
- Reuse (falls under Awareness, or same as it?)
- CJK Stroke project (falls under Illustration)
Topic-specific project such as Museums, Tree of Life, place-specific ones etc.
Could have a project like "Project English Wikipedia". Falls under Reachout, Uploading [transferring files], Helping others.
What does a project look like?[edit]
- Front page: goals, aims, why?, scope, parent/child/related projects)
- Members list, possibly badge + category members can use
- FAQ
- Useful tools and websites
- (Relevant bugs)
- Instructions on tasks
- Method of evaluating progress?
- Discussion page
- Awards for members?
Policy and guidelines[edit]
Commons has broad policies. Projects are encouraged to develop guidelines appropriate to their activities. The guidelines can only act within the bounds of the policies - they can't override them. (If a policy says 'Using a category or a gallery is fine', guidelines can't say 'Everyone must only use categories'.)
The key to projects is to pay attention to overlap. If a topic-specific project wants to make a guideline about file names, for example, they should develop the guideline while consulting with Project Uploading. If a topic-specific project wants to make a guideline about categories/galleries, they should consult with Project Categories. If they want to develop a quality control method, they should consult with Project Quality Control.
Guidelines for projects[edit]
Probably need a policy for this. Things like
- Be friendly, be helpful
- Welcome newcomers
- Explain well
- Integrate, don't isolate - strongly encourage collaboration with other projects
- Educate, don't penalise - how to treat non-members
- Prize content-building editing
- Limit bureaucracy
- Limit rules
Possibly:
- Advise one ideal method, but accept many methods (Project guidelines are advice, not law)
Project Council[edit]
(added later)
Thinking more about this I think perhaps there is a need for an overall Project Council. This would be an extremely "meta" committee that oversees all other projects, possibly rules on inter-project disputes and most importantly evaluates projects' status. The Project Council makes sure that no project oversteps its bounds by ruling over Commons-wide policy, for example. The Project Council would also have the ability to, for example, dismantle an existing project and force it to start again from the ground up (if something went horribly wrong).
Status:
- Umbrella
- Inactive
- Semi-active
- Active
Status would be determined by a mix of completeness, membership and activity. (Has the project completed a FAQ and other guidelines? How many members are there? Is the discussion page being used - are questions answered promptly?)
Each project would then have a banner (template) delaring it inactive, semi-active or active. Any user can change a project from inactive to semi-active simply by adding themselves to the membership list and beginning work, but only the Council can decide when a project can be declared Active.
'Umbrella' status is for high-level projects that are conceptually necessary for lower-level projects to exist. For example, you might want to start a project on Flags of Europe. This would be a child of a project on flags and a project on locations/Europe. If those projects aren't actually active yet, they would become inactive umbrella projects.
Membership of the Council:
- 5-10 general members
- 1 project representative from each Active project
Project reps are elected within the project and can change as often as the project wishes. They don't even have to offer someone, but the seat is always available. Project reps are welcome to take part in discussion about that project, but are automatically excluded from making decisions about that project. (Other Council members can exclude themselves from discussion if they feel they have a conflict of interest in a particular decision.)
General members are elected by the wider community and don't necessarily reflect the interests of any particular project. (term 6-12 months, lost if inactive during that time)
Problems[edit]
- Radical change - lot of work to explain and implement, need to gain wide acceptance
- Decentralising power - but will it just create dozens of mini cabals? How can this be discouraged?
- How can projects be discouraged from isolationism?
- What about admins?
- project on admins? or ask admins to attach themselves to various projects? could have admins for specific projects.
- What about deletion?
- Make this the Copyright project?
- Vandalism? I would prefer not to have such a project, since it has such a negative focus. Instead incorporate anti-vandal activities into all other projects.
- Where does new images/recent changes patrol fit in?