Talk:Wikimedia Foundation Community Affairs Committee/Procedure for Sibling Project Lifecycle

This page is for discussions related to Wikimedia Foundation Community Affairs Committee/Procedure for Sibling Project Lifecycle.   Please remember to: Sign posts using the four tildes (~~~~) Remain civil and polite during discussions. Place new comments below in existing sections or start a new section.   Discussion navigation: Opening new projects Closing projects Other comments

Review

This is a community review of the procedure for Sibling Project Lifecycle. This review will be open from 13 May to 23 June. Participants are asked to read the information and share thoughts below or in live sessions.

Live sessions

Participants are invited to attend live sessions to provide input into this process. These sessions will be conducted in groups and the language will be English. The calls will be supported by Wikimedia Foundation staff, as well as the Wikimedia Foundation Board of Trustees.

The live sessions will be held on Zoom. All community members in good standing will be able to participate there. Request the Zoom link by emailing askcacwikimedia.org and mention which call you would like to attend. We will send out the links to everyone who has registered via email 24 hours before the call.

Participants are also welcome to request a conversation and share their thoughts during Talking:2024.

Call 1: 23 May 2024 at 02:00 UTC

• --Rosiestep (talk) 17:57, 22 May 2024 (UTC)
• add your name here

Etherpad notes:

Call 2: 30 May 2024 at 16:00 UTC

Etherpad notes:

Comments

Please read the information and share thoughts below.

Opening new projects

• The document does not specify the need for a new sibling project to include only such materials as are free licensed. I the WMF is committed to providing free-licensed knowledge, this ought to be mentioned explicitly. If the focus of the Foundation is to provide free knowledge, then this is a fact I might have missed but such a shift might result in some backlash from long-standing community members. Thus, I suggest stating free licensed content in the Legal and Copyright compliance section. Wojciech Pędzich Talk 06:42, 14 May 2024 (UTC)

  We do have the possibility of a fair use rationale, so technically this is not as clear cut as it seems. I'd be weary to put restrictions on things like this upfront that limit our flexibility and would suggest making a reference to the mission of the foundation instead as well as making one of the project proposal requirements to list the license intended to be used for the content. —TheDJ (talk • contribs) 08:03, 22 May 2024 (UTC)

  Fair Use is a one-land-only-"solution", not an international acceptable one.

  Ditch the monolingual anglophone blinders and work only on real free content. Grüße vom Sänger ♫^(Reden) 12:45, 22 May 2024 (UTC)

wikimed also uses fair use. ditch the license purity, which also sometimes flouts the "that are in the public domain in at least the United States and in the source country of the work." --Slowking4 (talk) 13:54, 22 May 2024 (UTC)

I would expect that to fall under the requirement to "Ensure the project aligns with the Wikimedia Foundation's mission of promoting free knowledge", because a project with no free knowledge isn't promoting free knowledge. But I agree that it should be listed as an explicit condition. Perhaps something like "Produces content under a suitable free license" would work. WhatamIdoing (talk) 19:15, 22 May 2024 (UTC)

Wojciech Pędzich thank you for the comment. There is a mention of a need for a project to align with “Wikimedia's mission and values” in the Introduction section of the procedure. As this is a conversation about the procedure and steps and materials needed to decide on opening or closing of the projects, we did not go into a deeper conversation about this here - “to include only such materials as are free licensed” - as the current status quo allows hosting content contributed under "fair use" or similar exemptions under applicable copyright law, and especially taken into account that the Movement mission and values are being discussed in the context of the Movement Charter process by the MCDC. At the moment, “free licensing only” does not seem to be among the Movement values proposed, and some flexibility is allowed Free_knowledge:

The Wikimedia Movement uses open licensing to share all content it produces, all its software, and access to all its platforms. Some external content is also included under varied licenses. It commits to deepening its mission by expanding the realms of free knowledge and by integrating new and evolving forms of capturing and sharing knowledge as well as a growing diversity of content

(on behalf of the Taskforce) Victoria (talk) 08:55, 23 May 2024 (UTC)

• The information is clear in that there are a number of requirements that have to be fulfilled in order to start a new sibling project. However, the effects of a sibling can be much huge on our projects. In the past both Commons and Wikidata have proven this point. They brought savings and new opportunities. The problem with some proposed projects are that they may be overly ambitious and/or that they do not consider fully what they may bring to particularly Wikipedia. Wikicite for instance is all about the sum of all scientific papers. When the ambition is tempered to all citations in any Wikipedia, it brings with it the notion that we continuously maintain the linked data to those cited papers, we will know the extend literature progressed from what Wikipedia reflects. It makes for a tool that supports any and all editors of a Wikipedia. My point is that perfection is likely the enemy of what we could achieve when we seek added value in our chain of projects. Thanks, GerardM (talk) 16:29, 21 May 2024 (UTC)
• I would like to see more help for potential new projects with an incubator space, such as wikispore, rather than emphasizing a gatekeeping checklist. I would like to see more tools and help for community incubation, growth and leadership, including soft skills. --Slowking4 (talk) 14:00, 22 May 2024 (UTC)

  Yes, Wikispore was explicitly noted in related notes and discussions, and got reduced to a paranthetical comment in this draft mainly because wikispore itself is still a labs project, and not a sibling project like Incubator. So bootstrapping is required! But we do need Wikispore or equivalent as a standard model for incubation and getting ducks in a row before being evaluated by any onerous gatekeeping. [still reasonable to have an ultra-lightweight filter before something is incubated, as with languages.] Community leadership and soft skills are more complex, we haven't succeeded with about half of the language projects that start and stall. But they are needed in proportion to the difficulty of incubation. –SJ talk  20:57, 23 May 2024 (UTC)

• I have several comments.
  • My overarching comment is that there should be a recommended roadmap and reasonable timeline. For WikiJournal, this is now our 10th year of operation (and 5 years since we submitted our application for recognition as a sister/sibling project). Yet today we still have no clarity on the roadmap of our proposal just like when we submitted that letter back in September 2019. In contrast, Abstract Wikipedia (aka Wikilambda)'s proposal was put forward on Meta in April 2020 and received an extremely quick board approval one month later. While sister project recommendation process has been widely considered to be the "wild wild west", this is not consistent with first in first out principle. There needs to be a general timeline so that expectations can be communicated clearly to everyone participating in the process.
  • Project proposal - I understand that the CAC wants to know interested individuals' "length of involvement in the Wikimedia projects, and extended user rights" and "Document community activity and assess the number of active editors and editors with extended rights", but who is responsible for gathering and summarizing these info? The CAC? Foundation staff? Community volunteers? The initiating group? This needs clarity, and ideally not putting additional burden on the initiating group to gather all these info.
  • Evaluation of new proposal - "Assess whether an existing Wikimedia project can accommodate the proposed content." How is the assessment done? Project proposal letter? Interviews and surveys? What if the proposed project is not an exact fit with an existing Wikimedia project? What if the assessor issues a recommendation that would unilaterally override community consensus and force the proposed project into an existing project? "Assess the main alternative non-Wikimedia projects." Are we really going to assess potential proposals for their possible inclusion into Fandom or other commercial/for-profit sites? Wikivoyage would not have survived this assessment because it was spinning out of Wikitravel at that time and had major content overlap. "Financial assessment: Assess projected costs for setting it up and projected upkeep for the first few years". This appears to penalize projects who have larger scope. If this requirement were put in from the beginning, we would not have seen success projects like Commons or Wikidata being approved because these projects all cost a lot to set up, run and maintain.
  • Project pre-approval - I am not quite sure why "recommend in principle" (propose hosting outside Wikimedia) is there. If the research and feasibility study already identified an alternative non-Wikimedia project being more suitable, the proposal would not have been referred to CAC for consideration. And what impact does this specific recommendation have if the pilot/demo site is already using a Wikimedia environment (incubator or existing Wikimedia project)? Are those contents going to be purged because CAC recommends hosting outside Wikimedia?

OhanaUnited^{Talk page} 21:45, 23 May 2024 (UTC)

Closing projects

It would be good to clarify how the closing procedure should work for projects with multiple language versions. Will each language version be assessed on its own merits, or could it happen that the whole sibling project is shut down and merged if some of its language versions are not up to the standard? The latter option is clearly undesirable, at least from the perspective of the small communities. --Alexander (talk) 17:09, 22 May 2024 (UTC)

Of course, all the versions will be assessed and only if there's no viable communities among them, the project will be proposed for the suspension. In fact, this is what already happening: the Language Committee is not only opening but suspending and closing sister i.e. language variants of the existing projects. Victoria (talk) 08:57, 23 May 2024 (UTC)

I do have a totally different understanding of the intended committee. For example, if, say, the WMF does loose interest in maintaining all 35 or so language versions of Wikinews (dunno the actual count) it's more convenient to bypass the language committe at all by killing all Wikinewses in one step. Well, not that they could't do it anyway as they like it. It's not about closing a particular language version at one time, it is about shutting down all of them at once.

For me, the proposal is against all of my understanding how things should work. Basically it is a Trumpization of the Wikimedia communities as they are. Matthiasb (talk) 19:28, 24 May 2024 (UTC)

Other comments

• I think the terms "sibling projects" and "sister projects" are not very universal. For example in Chinese "sibling" would be a combination word from "big-brother little-brother big-sister little-sister" which is somewhat annoying. Also I wonder how this would work in languages which disamguate sisters and brothers through grammatical gender. Also, currently "sister projects" seems to mean "other WMF projects" which this document refers to as "sibling projects." This de facto name change would be confusing. --魔琴 (talk) 09:44, 21 May 2024 (UTC)

  You might need a term in Chinese that is not a literal translation. I don't see that as a problem, as long as it ends up with the same meaning vis a vis projects. I do agree with you, though, that we have long used "sister" and if we are changing to "sibling" there ought at least to be a clear rationale for that. - Jmabel (talk) 17:35, 22 May 2024 (UTC)

  The "sibling projects" defined here are in fact called "sister projects" on the English Wikipeda, where the most common way of referring to localisations is "language projects" (>1000 instances, unambiguously in this context). A search for "sibling projects" on the same project reveals barely over 100 instances, many from a single transcluded text, and with more ambiguity. A search for "sister projects" reveals >10,000 instances, but with the highest ambiguity. May I recommend sister projects (Wikipedia, Wikisource, Wikidata et cetera) and the more specific language projects (en, de, fr et cetera)? The procedure page should be moved to Wikimedia Foundation Community Affairs Committee/Procedure for Sister Project Lifecycle, leaving a redirect. Иованъ (talk) 18:12, 22 May 2024 (UTC)

  @Jmabel, I believe the rationale is only to avoid using gendered language in English. Translators should probably use whatever terminology is common in the Wikipedia for that language (see the end of d:Q10823887 for some options). WhatamIdoing (talk) 19:06, 22 May 2024 (UTC)

  If the rationale is indeed to avoid using gendered language, then it ought to be pointed out that the feminine construction is already exponentially more common in English than the collective construction. That is why you see "sister projects" >10,000 separate times, "sibling projects" <100 separate times, and "brother projects" exactly 0 times. Иованъ (talk) 20:03, 22 May 2024 (UTC)

  The main rationale has nothing to do with the gendered language, but to distinguish between the "sister projects" language variants of the same project, for example, English and Catalan Wikipedia from the separate projects under Wikimedia umbrella, for example, Wikipedia and Wikisource. In fact, even in this discussion not all people understand that we are talking about the latter.

  We are aware that the term doesn't translate into many languages, so you are welcome to find an alternative that will make the distinction clear. Victoria (talk) 09:01, 23 May 2024 (UTC)

  The alternative I proposed was to use sister projects in place of "sibling projects" and language projects in place of "sister projects. This is based on frequency data from the English Wikipedia. See above for detail. Иованъ (talk) 10:46, 23 May 2024 (UTC)

  That was also my initial instinct, most communities refer to the "language projects" of their Project. I would prefer not to use "sister project" to refer to language variants. The question then is simply whether to call them "sister projects" or "sibling projects" in English. Each language can translate this as seems clearest. –SJ talk  20:53, 23 May 2024 (UTC)

• Not that I think it's planned, but since it was given as an example: as a representative of the Wikibase Community User Group, terminating or significantly altering a product like Wikibase or (perhaps more likely, since it has issues with use of unsupported technology) the associated Wikidata Query Service could have a similar impact to closing a project, even though this impact may be more diffuse. Efforts should be made to reach out in a similar way to external stakeholders, rather than just thinking about Wikimedia's use of the technology. It may also be worth considering where technology-based services run by affiliates like Wikibase.cloud fall within this procedure. What would happen if an affiliate disagreed with the CAC? GreenReaper (talk) 22:16, 21 May 2024 (UTC)

  [1] believes MediaWiki and Incubator to be sibling projects. In that sense I'd say Wikibase right now is part of MediaWiki, and WDQS is part of Wikidata. This seems on a spectrum with a sibling project deciding to substantively change its scope. Like Wikiversity deciding to include (or not include) initiatives like WikiJournal; Wikipedia deciding not to include dictionary definitions (historically: forked Wiktionary) or species entries (historically: didn't happen; but Wikispecies started up as the adoption of an existing project). Agreed that those decisions are comparable to, and sometimes might give rise to, sibling project changes. This is not currently covered in this draft process, but that shouldn't keep people from raising such issues or proposing a similar "major technical projects" channel. –SJ talk  20:53, 23 May 2024 (UTC)

• The majority of languages do not have a single word for "sibling", employing "brother or sister" instead. Even larger languages tend to lack such a term. For example, among Slavic languages only two neologisms are universally understood: Czech/Slovak (sourozenec/súrodenec) and Polish (rodzeństwo). If you look at the translations section of the English Wiktionary article, you will quickly notice the inexact nature of many translations, typically coded for gender and/or age. Иованъ (talk) 11:27, 22 May 2024 (UTC)

  Yet, the Czech term for "sister project" is nevertheless a calque "sesterský projekt". --Matěj Suchánek (talk) 13:15, 25 May 2024 (UTC)

Structural question

In the section on closing projects, under "Identify the need", is it deliberate that the last three bullet points are subordinate to "Severe lack of community activity" or were they intended to be at the same level? If this was deliberate, I don't understand why only if there is a severe lack of community activity would unresolvable legal issues be a reason to shut down a project. - Jmabel (talk) 03:28, 22 May 2024 (UTC)

Jmabel you are right, corrected, thank you for noticing! -- NTymkiv (WMF) (talk) 09:35, 22 May 2024 (UTC)

Scope

Overall, my mental model for this is to imagine that someone wants to open a Wiki Oral History (for the new project creation process) or to close Wikinews or Wikispecies (for the closing process). That is, looking at the projects listed at the bottom of the Meta-Wiki Main Page, I assume that this is about the "Content projects specialized by linguistic edition" and "Multilingual content projects" and not about the "Outreach and administration projects" or "Technical and development projects". It might be appropriate for this to be clarified. If this process is supposed to be used for everything, then that should be made clear, and the stakeholders (e.g., WMF Tech, which is replacing the existing Phabricator project with something else) notified. WhatamIdoing (talk) 19:17, 22 May 2024 (UTC)

The scope is as you phrase it: "Content projects specialized by linguistic edition" and "Multilingual content projects" and not about the "Outreach and administration projects" or "Technical and development projects". + candidates to become new projects of the first kind. We had long debates about terminology and how to name those limits. Any idea to make this distinction clearer are welcome! Noé (talk) 09:10, 25 May 2024 (UTC)

Closing procedures

In the event of a project closure (except perhaps in extreme cases), i think it would maybe make sense to have a probationary period. After a need to close has been identified, and sufficient support for closing has been gathered, instead of closing immediately, I would suggest putting the project on probation for some period of time (e.g. Something in the neighbourhood of six months). With the idea being, any existing community has that long to turn it around. After the time period passes, the broader wikimedia community assess whether we still want to close the project. Bawolff (talk) 13:18, 25 May 2024 (UTC)