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 Google Meet. All community members in good standing will be able to participate there. Request the Google Meet 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.

Extended content
Call 1 23 May 2024 at 02:00 UTC --Rosiestep (talk) 17:57, 22 May 2024 (UTC) add your name here Etherpad link for collaborative notes:

Call 2: 9 June 2024 at 02:00 UTC

Extended content
02:00 UTC is 10:00 in Singapore. Joining info Google Meet joining info Or dial: (IL) +972 73-359-9899 PIN: 947 603 756 4089 # More phone numbers Etherpad link for collaborative notes: SPTF-call2 Participants Alhassan Mohammed Awal (talk) 03:28, 27 May 2024 (UTC) Rosiestep (talk) 14:16, 27 May 2024 (UTC) Fexpr (talk) 13:36, 31 May 2024 (UTC) Exec8 (talk) 05:48, 7 June 2024 (UTC) @Alhassan Mohammed Awal, Fexpr, and Exec8: hello all, thanks for signing up. I have sent a link to your email --NTymkiv (WMF) (talk) 07:25, 7 June 2024 (UTC) Kunokuno (talk) 14:03, 8 June 2024 (UTC) @Kunokuno: hello, thanks for signing up. I have sent a link to your email --NTymkiv (WMF) (talk) 16:49, 8 June 2024 (UTC) add your name here

Call 3: 9 June 2024 at 16:00 UTC

• 16:00 UTC is 18:00 in Paris.
• Joining info
  • Google Meet joining info
  • Or dial: ‪(IL) +972 73-359-9899‬ PIN: ‪820 902 390 0561‬#
  • More phone numbers
• Etherpad link for collaborative notes: SPTF-call3

Participants

1. Alhassan Mohammed Awal (talk) 03:29, 27 May 2024 (UTC)
2. Rosiestep (talk) 14:16, 27 May 2024 (UTC)
3. Laurentius (talk) 06:42, 28 May 2024 (UTC)
4. Mervat --Mervat (talk) 19:07, 5 June 2024 (UTC)
5. Tesleemah (talk) 03:48, 7 June 2024 (UTC)
6. --NANöR (talk) 05:19, 7 June 2024 (UTC)

   @Alhassan Mohammed Awal, Mervat, Tesleemah, and NANöR: hello all, thanks for signing up. I have sent a link to your email --NTymkiv (WMF) (talk) 07:25, 7 June 2024 (UTC)

   Thank you, I got that already Tesleemah (talk) 13:38, 8 June 2024 (UTC)

   I have used the link sent to my email to join but no one is letting me in Alhassan Mohammed Awal (talk) 14:34, 9 June 2024 (UTC)

   @Alhassan Mohammed Awal: hello here. as i have explained in the reply to your email -- you have registered to *both* calls, so you have received joining details to both calls. also, the second call starts only in ~30 min (and i resent the details on how to join) --NTymkiv (WMF) (talk) 15:25, 9 June 2024 (UTC)

7. Nehaoua (talk) 07:37, 8 June 2024 (UTC)

   @Nehaoua: hello, thanks for signing up. I have sent a link to your email --NTymkiv (WMF) (talk) 11:34, 9 June 2024 (UTC)

8. add your name here

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)

This seems to be the wrong location to advocate for overturning existing policies. In any case, as a user who has been indefinitely blocked by five different Wikimedia project communities (including Commons), you should be aware that Wikimedians do not always agree with your strongly held views. Regards, HaeB (talk) 04:49, 23 June 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 current status quo allows hosting content contributed under "fair use" or similar exemptions under applicable copyright law - that is a rather misleading summary. The Wikimedia Licensing Policy (linked from that section of the ToU) only allows such content under rather stringent additional conditions, namely a project-specific "Exemption Doctrine Policy" (EDP) (e.g. Such EDPs must be minimal. Their use, with limited exception, should be to illustrate historically significant events, to include identifying protected works such as logos, or to complement (within narrow limits) articles about copyrighted contemporary works. An EDP may not allow material where we can reasonably expect someone to upload a freely licensed file for the same purpose ...).

To avoid costly misunderstandings among those conceiving proposals for new projects, I recommend linking Wikimedia Licensing Policy directly in the advice about preparing formal proposals. and advising to include a draft EDP in the proposal already in case the use of non-free content is considered essential for the proposal. This might also go some way to assuage User:Wojciech Pędzich's concern above (which I think is valid - e.g. some people have been floating ideas to start a project dedicated to hosting of CC BY-NC licensed media, in such cases it is helpful for everyone to clarify early on this is not a possibility under current policy).

Regards, HaeB (talk) 05:04, 23 June 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)

  thanks, I agree - bootstrapping or investment to increase an upward spiral, rather than barriers to entry, that leads to burnout and stalling. A lifecycle roadmap would be helpful, or case studies such as Requests for new languages/Wikipedia Atikamekw. from that case, it is unclear that wiki-knowledge is necessary, rather a community is, with some wiki facilitation, and the ability to build trust with the community. Stalling is not necessarily a downward spiral to closure. as we saw with Scottish: failure can lead to an intervention by a language community. We need to build a toolkit to match communities with the wiki ambassadors and wiki tools to do the mission. A sandbox or wikiproject in incubator, would be helpful as a rallying point. --Slowking4 (talk) 23:57, 28 May 2024 (UTC)

  Yes, I hope we can develop a place for sibling projects in-fruition, since not every concept will be immediately ready for a full proposal. Pharos (talk) 02:53, 24 June 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)

• While I'm a member of the CAC and its SBTF, I'm writing here in my "Rosiestep" capacity. Components to consider in the cost/benefit analysis of opening a new sibling project include (a) production (who is doing what), (b) maintenance, (c) consumption, and (d) potential re-use. The application could have sections related to each component. In turn, each component would be included in the review procedure. --Rosiestep (talk) 20:19, 31 May 2024 (UTC)

• At some point I think it might make sense to have a grant program specifically for opening new projects, or related areas of innovation.--Pharos (talk) 02:54, 24 June 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)

The different language versions are independent and should be treated individually Marek Mazurkiewicz (talk) 23:47, 7 June 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)

  Wikimedia.org 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)

• Is there any reason not to avoid this wishy-washy PR-speak altogether by simply calling them "Wikimedia projects"? AP295 (talk) 16:32, 9 June 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)

Although I dislike changing pages after translations have started, you could perhaps add two short sentences: "This process is for current and future public content wikis. It is not for technical, outreach, or administration projects." If placed as a separate translation unit at the end of a paragraph, it would not interfere with any existing translations. WhatamIdoing (talk) 20:11, 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)

"Severe lack of community activity"

Regarding the clause about the 'severe lack of community activity,' perhaps we should establish a specific, objective measurement. For example, Miraheze uses this specific threshold to decide when to close an inactive wiki : an inactivity banner notice appears after 60 days of inactivity, the wiki becomes read-only after 120 days, the adoption phase begins on the 134th day, the wiki is marked for deletion after 365 days of inactivity, and deletion occurs after 365 days of inactivity. Rtnf (talk) 04:42, 4 June 2024 (UTC)

Putting an inactive wiki into read-only mode will only contribute towards an inevitably death spiral and offers almost no avenue to turn it back. OhanaUnited^{Talk page} 20:04, 21 June 2024 (UTC)

Current closing projects policy to be replaced?

Is the proposal intended to replace the current closing projects policy? Honestly, I didn't like making inactivity an insufficient reason to nominate a project for closure. George Ho (talk) 00:26, 23 June 2024 (UTC)

Indeed, it is a bit astonishing that the Task Force as a whole does not seem to be aware of this existing policy, considering that it is proclaiming that We also need models for [...] sunsetting Projects without mentioning that such a model has already existed for at least thirteen years. I guess that some individual members are at least somewhat aware of it (like Victoria above). But it seems quite clear that a big opportunity was missed here to evaluate how this existing process has worked over such a long time (Proposals for closing projects lists no less than 42 resolved closing proposals since 2011), and to find out what we can learn from that for the future.

Regards, HaeB (talk) 05:22, 23 June 2024 (UTC)

That policy is for closing language projects, and indeed it notes in the introduction paragraph that "Requests to close an entire sister project rarely happen, and there is no formal process for handling them." - here we have that formal process. Thanks. Mike Peel (talk) 00:56, 24 June 2024 (UTC)

I'm pretty sure that George Ho was already aware that the policy he linked is for closing language projects (considering e.g. that he voted on such proposals before).

And in the aforementioned thread, your fellow task force member had asserted above that Of course, all the [language] versions will be assessed and only if there's no viable communities among them, the [entire] project will be proposed for the suspension. In fact, this is what already happening: [...]. In other words, assessing individual language projects - what that existing policy covers - will be an integral part of that planned new formal process.

Regards, HaeB (talk) 06:41, 24 June 2024 (UTC)

I think what Victoria was saying above and what I'm saying here is equivalent. If we have en.wikicats, de.wikicats, and fr.wikicats, and en.wikicats was inactive, then that would fall under the closing projects policy and the work of the language committee. If all of en, de, and fr.wikicats are inactive, then it may be time to close wikicats, which is then this procedure. The grey area is in the middle, say, if only de.wikicats was active out of all wikicats projects. Thanks. Mike Peel (talk) 06:47, 24 June 2024 (UTC)

open, close, where is change, where is social?

a little short sighted i find the proposal. i am missing a policy to change a project. say, if there is less than 500 active editors, more than 50 edits a year or so. what i am missing also is something which makes staying with wikipedians appealing. the "social" in wikipedia got lost by people getting older, and always the same people making the same proposals. more text, more rules, nothing for young. no sharing, no meeting, no rating, no counting of friends or clicks, no chatting, no modern tech in meeting points like 3d-printing, no errors allowed, is "boring" the right word? whoever has kids, try to ask them to contribute, and try to find out why they don't. ThurnerRupert (talk) ThurnerRupert (talk) 06:18, 23 June 2024 (UTC)

I'm not sure if I understand this comment entirely beyond the first two sentences, but I agree that the option to change a project fundamentally, perhaps to regenerate, should be a possibility. For example, maybe someone makes a compelling proposal for an alternative way to present current events on Wikinews, and that co-exists with or perhaps eventually takes the place of the existing Wikinews content. And maybe even a co-existing paradigm on Wikipedia could be attempted. Pharos (talk) 02:45, 24 June 2024 (UTC)

Aligned (infrastructural) organizations and communities

I would like us to recognize the need for doing development work with Aligned (infrastructural) organizations and communities.

MiraHeze.org is an example MediaWiki farm some of us would like to be recognized as Aligned organization supporting experimental and demo versions of Wikimedia-wanna-be-sibling projects. This has been discussed among WIKISPORE contributors few times and I think others should look it up also.

Best -- Zblace (talk) 18:02, 23 June 2024 (UTC)

I agree, open culture is really good when it is "We do our own things and it benefits each other", but it is much much better when it is "We also regularly communicate and take into account each others' wants and needs." MiraHeze would really benefit from Wikimedians' attention and Wikimedians would definitely benefit from organising around MiraHeze. Egezort (talk) 23:40, 23 June 2024 (UTC)

I agree, it makes sense to build relationships with non-profit wikis beyond, to develop a sort of wiki farm farm team. Pharos (talk) 02:48, 24 June 2024 (UTC)

I think collaboration is the best way to move forward and projects like MiraHeze.org are a very good option. I support your proposal for it to be recognized as Aligned organization. Is there anything else we can do to make this reality? Irdiism (talk) 06:20, 30 June 2024 (UTC)

Project incubators

This seems to focus on how to evaluate and accept a mature project proposal, which is definitely useful and important, and it will be good to have a well-defined and resourced process for it. But I don't think that's where the main bottleneck is. I think the main problem is that it's hard currently to turn something from an idea to a pilot project. Ideas can be hard to express, and hard to evaluate - the main question with a new wiki project idea is almost always "will there be contributors?" and that's very hard to tell just from reading a project proposal.

The draft does say "Link to a working pilot or demo site (if one exists). This can be supported by a Project incubator (such as WikiSpore)" but I think this undersells the importance of a pilot - not only is an idea much easier to understand when you see it implemented, but requiring a pilot period before judging a proposal would mean that you could assess whether the project is successful at actually gathering contributors. But Wikispore is built on very shaky technical foundations (due to lack of time and resources) and there are no other project incubators today; "pilot project" is a huge gap in the WMF infrastructure, with Wikimedia Cloud lacking stability guarantees (it's fine for a pilot to be down occasionally but it's not fine to lose all the data) and the framework to easily add new wikis, and production being too risky as there is very little security and performance boundary between projects, so an experimental new project could easily affect much more important mature projects in bad ways.

I think Wikimedia badly needs a better project incubator, maybe something like the Beta cluster. It's not in theory impossible to build that kind of thing on a largely volunteer basis (the Beta cluster itself is just a normal Wikimedia Cloud VPS project, if a huge one) but so far the volunteer capacity does not seem to be there. Maybe that's just a coordination problem that can be solved by directing attention to the issue, but I think this is a bottleneck where a modest initial investment from the WMF could be very valuable. Tgr (talk) 11:05, 24 June 2024 (UTC)

@Tgr indeed I fully agree accept for the modesty, as there is already piled up technical debt and historically was not addressed. Maybe for a change this needs to change and IMHO it would good to extend this so that Wikimedia Foundation gets better at reflecting and planing in/on existing infrastructural efforts including how to support both INCUBATOR and WIKISPORE (but also other FLOSS software that we lost like Mattermost instance of Wikiemdia Chat) with own staff's hours! Volunteers should not have to be pushed to fundraise with WMF to be able to learn and do work that is critical and fundamental technical for basic running of these services. It needs to be built in and only amended by extra resources when plans expand beyond basic running of service (like customization and/or development). Zblace (talk) 04:17, 27 June 2024 (UTC)

Revised version published

REVISED VERSION PUBLISHED, subject to evaluation by the Community Affairs Committee.Victoria (talk) 08:44, 30 June 2024 (UTC)