Wikimedia Foundation Community Affairs Committee/Procedure for Sibling Project Lifecycle

Wikimedia Foundation Community Affairs Committee

REVISED VERSION PUBLISHED, approved by the Community Affairs Committee

edit

Since 2023, a Task Force of Wikimedia Foundation Community Affairs Committee ("CAC") has been working on a procedure for opening and closing projects. This work is directly related to such Movement Strategy Recommendations as "Innovate in Free Knowledge", "Identify Topics for Impact", and "Evaluate, Iterate, and Adapt", to make space for the inflow of innovative ideas while maintaining and continuing support for the existing projects. Understanding the trade-offs in decisions to invest in something new or maintain the current projects is important.

Some new project proposals may require significant new technical work (for example, Wikifunctions), while others can use existing tools with a different content scope, and mainly need maintenance and an active community. Evaluating a new application to validate the concept, and estimate its up-front and maintenance costs, has generally taken both community and staff time.

At the same time, an evaluation of the success and sustainability of existing Sibling Projects would be valuable. We also need models for splitting, merging, and sunsetting Projects, for adopting external projects that come with their own communities,[1] and for preparing Sibling Projects to be merged into or adopted by an external organisation.[2]

Participants are invited to share thoughts on the talk page and sign up to attend live sessions to provide input into this process. Participants are also welcome to request a conversation and share their thoughts during Talking:2024.

Opening new projects

edit

Introduction

edit

This procedure outlines the steps and requirements for opening new Wikimedia projects. Wikimedia projects aim to create, curate, and disseminate free knowledge to the world. Before initiating a new project, the committee will ensure that it aligns with Wikimedia's mission and values, as well as evaluate the financial & technical resources required by the Wikimedia Foundation and communities to support it.

Project proposal

edit

Prepare a formal project proposal that includes the following information:

  1. List the responsible initiative group(s), including those who did not design the proposal but are interested in contributing - usernames, length of involvement in the Wikimedia projects, and extended user rights, if any. It is unlikely that the project proposal by one person will be accepted.
  2. Description: A description of the project, its scope, goals, & objectives. Explain how it aligns with the mission and integrates into existing projects (if possible).
  3. Community Evaluation: Document community activity and assess the number of active editors and editors with extended rights (if any).
  4. Content Scope: Define the scope of the project's content, including formats (e.g., text, media, data), languages (monolingual or multilingual), and topics.
  5. Technical Requirements: Infrastructure and tools required to host and maintain the project.
    1. (optional) Support from an established affiliate or Hub will increase the chances of project opening/adoption.
  6. Link to a working pilot or demo site (if one exists). This can be supported by a Project incubator (such as WikiSpore)
  7. Publish documentation on Meta and submit the proposal on [PAGE].

Evaluation of the new proposal

edit
  • Research and Feasibility Study: Conduct thorough research to ascertain the need and potential impact of the proposed project. Assess whether an existing Wikimedia project can accommodate the proposed content. Assess the main alternative non-Wikimedia projects.
  • Legal and Copyright Compliance: Ensure the proposed project meets legal and copyright requirements. Determine the licensing and copyright status of content to be included.
  • Financial assessment: Assess projected costs for setting it up and projected upkeep for the first few years
  • Engage with Community: Engage with the Wikimedia communities, including editors, volunteers, and stakeholders. Seek input and feedback on the proposed project idea to ensure community support.

If all requirements are met, recommend to the CAC for consideration.

Project pre-approval

edit

Submit the project proposal to the CAC for review and approval based on the following criteria:

  • Alignment with Mission: Ensure the project aligns with the Wikimedia Foundation's mission of promoting free knowledge.
  • Community Support: Assess the level of support and engagement from the Wikimedia community.
  • Legal and Copyright Compliance: Verify that the project complies with legal and copyright requirements.
  • Technical Feasibility: Confirm the technical feasibility of hosting and maintaining the project.
  • Financial Feasibility: Ensure it is financially possible to support the project over time.

Recommend an outcome to the CAC:

  • Decline, the proposed project does not meet the criteria required for a new Sibling Project.
  • Recommend in principle, but propose hosting outside Wikimedia, for indicated reasons.
  • Recommend opening as a new Wikimedia Sibling Project.

If everything above is positive, CAC will recommend the proposal for Board approval.

Closing projects

edit

In general, closing a project will result in its content remaining publicly available (e.g., by making the wiki read-only); no content will disappear unless there are legal concerns (e.g., systematic copyright infringements).

Prepare a formal project proposal that includes the following information:

  1. List the responsible initiative group(s) - usernames, length of involvement in the Wikimedia projects, and user rights. Application by one user may be speedily declined.
  2. Identify the need: Determine the specific reasons for considering the closure of a Wikimedia project. The need to close a project should be based on compelling reasons, such as
    • Lack of impact on other Wikimedia projects and wider Internet infrastructure
    • Severe lack of community activity
    • Legal issues that cannot otherwise be resolved
    • Significant misuse that cannot otherwise be resolved
    • Strong external project to merge with
  3. Community consultation: Before closing a Wikimedia project, extensive consultation with the affected community is crucial. This consultation should be open and transparent, allowing all stakeholders to express their opinions and concerns.

In case of the final decision of the “project closure,” the project can be

  • Merged with a different sibling project
  • Retained with limited access for editing
  • Archived
  • Supported in moving to a different host
  • In extreme cases (close to 100% copyright violation or misleading information) - deleted

Working glossary

edit

This is not en exhausting list, might be improved, expanded or changed based on the feedback received

  • Adoption: Wikimedia Foundation hosts a new project based on MediaWiki software (or not, considering tech support projects: wikistats, wikitech,etc.), with a standalone domain and fully linked with the other projects (i.e. not only in wikilabs).
  • CAC (Community Affairs Committee): a Wikimedia Foundation Board of Trustees committee.
  • Closing/Sunsetting/Archiving: disable the edit function in a project, or restraint it to a very small number of curators/maintainers.
  • Closing checklist: 1. Timeline for transitioning (stop new accounts, stop edits, redirect urls); 2. Choosing target to transition to (closed archive, merge, spin out); 3. Discussion with a potential merge target / maintainer; 4. Migration (technical + social support); 5. Archiving (producing a final archive of our last version).
  • Language Committee: a Board advising committee of volunteer Wikimedians, which makes decisions about opening and closing of the different language variants of the same projects, aka Sister Projects.
  • Project: almost everything is a project. Wikipedia is a project, English Wikipedia is a project, there are wikiprojects in Wikipedia… this word is ambiguous and is not a good way to conceptualize the global scheme.
  • Product : technical projects such as Wikistats or Wikibase are usually considered as products rather than projects.
  • Sibling projects: existing MediaWiki-based projects supported by the Wikimedia Foundation, such as Wikipedia (including en.wikipedia.org, pl.wikipedia.org, de.wikipedia.org, etc.), Wiktionary, Wikisource, and also candidate new projects such as WikiJournal or Vikidia. Other names are Global projects, High-level projects or umbrella identities.
  • Sister projects: wikiprojects in different languages, for example, English Wikipedia and Yoruba Wikipedia.
  • Splitting: Creation of a new space for a new project that was a subproject. English Wiktionary was a part of English Wikipedia at first.
  • Wikistats: example: Wikimedia Statistics - English Wikiquote

References

edit
  1. such as Wikivoyage
  2. such as 911wiki