Talk:Updating the ecosystem of Wikimedia organizations/Recognition and Funding for Movement Organizations/Funding Eligibility

Measuring impact

We at Wiki Med do not use the "Event Registration Tool" but have rather built our own tool to track our work.[1] It allows much more quality control work than the Event Registration Tool. Doc James (talk · contribs · email) 17:30, 8 July 2026 (UTC)

Thought you do permit "Alternative outcome tracking tools will need to be approved by the Community Investment & Partnerships team on a case-by-case basis." Doc James (talk · contribs · email) 17:48, 8 July 2026 (UTC)

Another example is that we are currently using ukbot which also generates reports (w:fi:wikiprojekti:Punaisten linkkien naiset/2026) and for WLM wiki loves stats. --Zache (talk) 18:28, 8 July 2026 (UTC)

I guess we can look into the possibility that when people log into our tool, the backend automatically signs them up to the "Event Registration Tool". Will look at it more. Doc James (talk · contribs · email) 17:57, 13 July 2026 (UTC)

Happy to follow along and loop in the team at the Foundation that maintains Event Registration, as well. If we can build better information bridges between the tools that are already in use, that would be an ideal outcome. RMaung (WMF) (talk) 17:14, 14 July 2026 (UTC)

Multi year grants

I like that we are including mechanism to account for WMF revenue; however, in my opinion it should be based on a fall below prior years revenue rather than some made up "revenue target" per:

"In the case that WMF falls short of its revenue target in a given year, subsequent years of any multiyear funding commitments may be reduced up to an amount proportional to the WMF's revenue shortfall."

Best Doc James (talk · contribs · email) 17:47, 8 July 2026 (UTC)

Just to clarify, the Foundation's revenue target is the same as the operating budget that is established each year as part of the annual plan and reported on annually as well. (I'm making an assumption that your concern is that the Foundation could arbitrarily say that they haven't hit their funding goal as a reason to cut multiyear funding, so if my assumption is incorrect please let me know!) RMaung (WMF) (talk) 01:21, 9 July 2026 (UTC)

Event registration tool

I'm afraid that we're bureaucratizing here for the sake of metrics. When you start to focus on the metrics first and the impact later, organizers will reduce their creativity, and focus on designing their activities to meet the objectives alone, rather than the spirit of them.

I have a few concerns especially with the introduction of the requirement "Grantees seeking to report outcomes related to on-wiki participation—including content created or improved, new and existing contributors engaged, or contributor retention—must use the Event Registration Tool". I would quote the designers of this tool, back in 2022: "No, we have no plans to force campaigns to use the event namespace. It will be the choice of campaign organizers. Overall, it sounds like there's some concern from you that, if we build tools that aren't useful or appropriate for campaigns like WLM, organizers of these campaigns will be forced to use them anyway, since WMF may deprioritize or look down on events that don't use the new tools. This is the last thing we want to do. It would be completely foolish to force successful, highly impactful campaigns like WLM to change how they operate. Instead, we want to help organizers who are struggling now and who have explicitly requested improvements to their tools and workflows. Of course, for mature campaigns (like WLM), the organizers may or may not want to use our tools (and that’s their choice). Ultimately, our goal is to help campaign organizers by providing more options—not by taking options away." ([2]).

Of course I can understand the benefits to grants committees who want to be able to have easy numbers to compare. I have been a member of a grants committee, and especially when I read the motivation for these changes "Changing user trends linked to the rise of generative AI have impacted both our movement funding model and the attraction and retention of contributors to our projects. It is critical to rethink how our funding is allocated and how affiliation structures can clearly define responsibility and measurable impact across the movement."[3], I can imagine how this might seem helpful to make easier decisions. However, metrics are in the end just that: metrics. They are a limited attempt to capture a wide range of proxies for actual success. When I was discussing these successes, I saw that my colleagues realized this as well - I hope this is still the case. As someone who has organized many "events", I know how hard it is to capture the full range into a single tool. I would argue that it is not possible.

However, the new guideline draft states now: "Grantees seeking to report outcomes related to on-wiki participation—including content created or improved, new and existing contributors engaged, or contributor retention—must use the Event Registration Tool". This assumes that all activities that lead to such outcomes, fit the frame of the Event Registration Tool. That is not the case. Even if that were true today, that means that grantees are explicitly discouraged to come up with activities that are outside of the imagination of developers that had to prioritize existing events and activities (and rightfully so). And even if it were always the case, and would always be, the cost to using a tool like this differs greatly. In some workflows it is easier to implement these tools than in others.

I'm confident that there are many events that will benefit from this tool and that the team has worked hard to make it as good as possible for them. But that doesn't mean that adding the extra friction is worth it for all activities that aim for creating these numbers.

For example, a few edge cases I would argue make things already more complicated:

• Events within events - if we organize photo walks within the context of Wiki Loves Monuments... and at the same time have people upload directly through the website: what should people register for?
• Overlapping events: for example, in several national events, there are also subnational events, but not in every region. In some regions, the best way to deal with nationalist feelings is to allow overlapping regions and encourage people to focus on what they are good at: photograph, document, write.
• Events with different categories of registrations, with different languages, with different needs for detailed explanation
• Events where the workflow is focused on something that is already complicated as it is. For example, when we try to make a new contributor upload a photo to Wikimedia Commons, we need to have them create an account, give permission to release the photo, identify the object, create a description, explain why they are the copyright owner and ideally find a category. In Wiki Loves Monuments we worked hard to make this as simple as possible, and that has paid off. Thanks to focusing on self-created photos only, we could make the copyright question a lot easier. By focusing on a specific set of objects, we could get away with only clicking the right link which would then auto-fill the rest. Why would we want to push these people through yet another form?
• Events that take place across multiple projects
• Activities or improvements that explicitly target non-registered accounts (I can't think of examples, but I'm confident someone must have!)
• Activities that organize activities that collect knowledge outside of our typical editing workflows, such as registration of oral knowledge (something I hope will happen some day, which would fit under 'content created or improved', but not fit most workflows)
• Designing custom tools for micro contributions without ever setting foot on the projects.

Yes, we could explain our way around these challenges. We could add workflows, point people in the right direction, make workarounds. But do we want that to be the first experience of our new colleagues?

I realize there's an exception built in - but the way this is phrased, and I'm afraid would play out, it sounds like asking approval in advance which only complicates experimental approaches further.

I would kindly suggest to run an experiment - please suggest the fundraising team to run an A/B test where they require some of the donors to first register through the Event Registration tool. What will be the impact on donations? My hypothesis you can probably guess :) Effeietsanders (talk) 18:37, 8 July 2026 (UTC)

@RMaung (WMF) and Qgil-WMF: courtesy ping. Effeietsanders (talk) 19:20, 8 July 2026 (UTC)

I do not think we have ever used the event registration tool in Estonia (and we run A LOT of events). We have been organizing stuff since 2010 and have therefore always needed alternative solutions. And when we are used to other things, then switching to that tool requires it to be better than the alternatives we are already very much used to. That is not realistic.

And even that focus on numbers has really annoyed me greatly over the years, as I have never had the impression that those numbers are viewed in context. Countries differ by more than 100x in population size (for instance, already meager 30 participants in Estonia would be the same as ca 1,860 participants in Germany on a per capita basis), and local conditions also differ. Even the events differ a lot: I could run something where 5 participants is a good achievement, but at another type of event, I would consider 50 participants to be a clear underperformance. When all of this is mashed together over a wide variety of events into one numbers salad, then good luck making it make sense. There would be no way to deduce impact from that.

Mandatory use of the Event Registration Tool suggests the focus would be even more on meaningless bureaucracy and less on actual impact. If the idea is that Wikimedia should encourage volunteers, then this is kryptonite to volunteering. Kruusamägi (talk) 23:03, 8 July 2026 (UTC)

Thanks Effeietsanders my first thought was also about that earlier commitment to not make the Event Reg tool mandatory. It would be a misfortune to walk that back. The tool itself is still extremely simple, with few features and a couple restrictive anti-features. It hasn't reached a level of simplicity, integration, or maturity that would be needed to capture most or all wiki events. Wasn't it going to be the first simplest part of an Event Center?

I tried to remind myself of how to create an event, and just trying to find out about using the Registration tool was extremely chaotic. It took me five minutes and reading a dozen pages to decide you can just get a flag and create a page in the Event: namespace, with some pitfalls and caveats. I've planned over 100 events; this would not have sufficed for most of them. For the separate goal of tracking / mentoring / supporting editors at events, better to offer a dedicated "cohort-tracking" tool, similar to the outreach dashboard, that can be compatible with any registration tool. –SJ talk  10:17, 10 July 2026 (UTC)

Hi @Effeietsanders, thank you for the detailed feedback.

I'm Benedict, from the Connection Team, the team responsible for the Event Registration Tool.

I wanted to follow up on the documentation point specifically.

I can see how that might be hard to find right now. This is useful to hear, and we will look at improving the documentation and also how to make it easier to find for anyone using the tool, whether they are new to it or already familiar with it.

While we work on that, I also want to share documentation on the collaborative contribution feature as well as some video guides that may be usefull in the meantime. Udehb-WMF (talk) 23:02, 29 July 2026 (UTC)

Thank you for the ping!

The problem that we are trying to solve is this: we don't really understand what happens on-wiki as a result of the Community Fund grants that we make. We have asked for a lot (a lot!) of information from grantees over the years, and we have not been able to use it in a meaningful way. Self-report of outcome metrics puts the burden on grantees (some have capacity and infrastructure for this, many do not); assumes that all grantees define and measure things in a comparable way; and sometimes leads to self-reported numbers that seem implausible. It is a 'garbage in, garbage out' data problem, and the blame for this is on us. We haven't designed a good system for this.

What collecting grantee outcome data through the ERT allows us to do is take on the task of tracking this data centrally, use standardized definitions for metrics, and get a much clearer picture of the effects that grant-funded activities have on the projects. For example, when events use the ERT, we can track retention of newcomers over time and better understand the editing patterns of event participants. These are insights we can share with movement organizers to better understand and even improve the impact of their events on growing editing communities.

That said, I agree that the ERT doesn't meet the needs of every organizer and every type of event. There are tradeoffs in asking grantees to use a single tool, especially after many years of using and building habits and infrastructure around others. Our intention is to move closer to a more centralized event tracking system, working with grantees for whom this shift would be especially burdensome to find ways that we can find or build a bridge to get the information that we need, and continue to share grantee feedback about the ERT with the team that supports and improves it.

I am certainly open to other ideas as to how we might improve the quality of a grantee data system! RMaung (WMF) (talk) 02:01, 9 July 2026 (UTC)

I think that requiring applicants to submit wikimedia usernames of the people participating to the activities is good way because you can derive information like if the user is new user, returning user, if user continues from the username data. It is much better system than self-reported numbers and probaply less cumbersome. --Zache (talk) 03:09, 9 July 2026 (UTC)

Thanks for the responses so far. First of all an apology. I got defensive when I should have been more constructive. The comment above was partially triggered by the fact that this kind of bureaucratization has been going on for many years, and is holding us back.

Let me clearly split my concerns: Specific concerns about the tool from the participant-workflow perspective, concerns about the idea of requiring the tool for all such activities (conceptually), and some leftover thoughts.

Specific concerns about the tool: I am not a heavy user of the tool, as my involvement has increasingly been at the meta level. I have been trying when i encountered the tool last year, and can't even find it right now. The problem I recall was a set of overlapping events that got very confusing. The tool assumes some kind of event-unit that just doesn't always work. I can appreciate the many trade-offs and wouldnt want to expect from the development team to have to be able to deal with every edge case I can dream up.

Even a little bit of extra friction to attendees can be just enough to lose a lot of people. But don't take my word for it: please talk with the fundraising research team, run A/B tests. My suggestion about doing A/B with fundraising is only half-jokingly. The fundraising team has the best infrastructure to test, they know their 'people' relatively well. It would be a good measure of "added friction".

That being said, I can also see why organizers may just find the tool not very convenient. There is also an amount of friction on the organizer side (this is solvable though): outdated and lacking documentation, having to negotiate with editing communities to organize an event, dealing with assumptions on what an event should look like, and how the organizer may want to communicate.

My best suggestion to the tool's future would be to modularize it as much as possible. On Connection_Team/Registration#Tools_built_for_campaign_tracking it is described quite well: there are workflows where separate registration doesn't make a lot of sense. If tracking metrics is the objective (which has its own problems, but that is another team's problem) then I would argue the objective should be to a) support organizers that need the event registration functionality but b) make it as simple as possible to let the organizers that don't need or want this functionality to plug in their existing workflow without any friction to participants, while still getting the metrics. From what I can deduce from the documentation pages (I dont have permission to try out the tool - this requires community consensus etc) this is not currently the case.

The even higher level concern is that forcing any kind of tool would likely be problematic - especially with the express objective to then plan to cut funds based on those metrics. Unfortunately creative new ideas often don't fit existing workflows. And we need especially now a lot of creative ideas to be flowing again. While encouraging the use of a tool is one thing, and perhaps "expecting" it for known good-fits may be reasonable, I am not a fan of requiring it for all activities under this definition. If the goal is to get metrics, ideally we put that burden on people who are good in getting metrics, rather than on people who are good in running events (by forcing them through a data-driven mold).

@RMaung (WMF) maybe the relevant questions for you would be:

• What kind of support system is in place for this integration?
• What support would you be able to provide to affiliates and individual organizers to rapidly (days? weeks?) integrate new workflows, designs, improve experiences?
• What is the integration plan for the largest family of events (the Wiki Loves photography campaigns) in its full diversity? Note that the announcement says this month (July 2026) the WMF will start requiring the use already. Could you share more about outreach to those communities, pilots with organizers that worked well?
• Is there better documentation available for users?
• Are there any known cases where the tool is not a good fit?

I really appreciate that you acknowledge that the tool may not be a good fit - and that there are specialized workflows. Usually those exist for good reasons, just like you make your design decisions for good reasons. My concern is not with the existance and use of the tool - it is with the fact that it becomes a hard requirement for an incredibly broad set of activities. Given the timeline and ambitions and requirement, I'm afraid that "move closer to a more centralized event tracking system (...) [and] to find ways that we can find or build a bridge to get the information that we need (...)." won't cut it. But in fairness: I don't think your team should be expected to resolve that impossibility. The problem lies in the hard requirement. Effeietsanders (talk) 07:30, 10 July 2026 (UTC)

With respect to fit, we need a tool that:

1) Meshes with OUR version of the content translation tool

2) Collects specific edits from already typically active Wikipedians (translations of health articles from MDWiki)

3) Is able to determine which health articles, that have been improved and are ready to translate, are missing in a target language

4) Our current translation campaign deashboard has been running continuously since 2021 or so. And we would not want to lose the prior data.

We of course already have a tool that does this, as we built what we needed. I guess we could look into how we could automatically mesh it with event registration tool. Doc James (talk · contribs · email) 15:38, 13 July 2026 (UTC)

Thanks for this, @Effeietsanders. I appreciate the constructive input, and I also appreciate the frustration underneath the response. I've been at the Foundation long enough to see a number of missteps and unintended consequences, and I welcome feedback helping the proposal achieve its intent, which is more impactful work and efficiency, not more pointless bureaucracy.

Your points about the ERT are well-taken, and I'll make sure the team that maintains and improves the tool see this feedback. I'm going to answer your questions about the plan for the ERT, but I also have an alternative proposal based on the feedback thus far. First, regarding the ERT:

• [What kind of support system is in place for this integration? What support would you be able to provide to affiliates and individual organizers to rapidly (days? weeks?) integrate new workflows, designs, improve experiences?] For this and all changes to funding in the proposal, a grantee's program officer is the first point of contact, and they will connect grantees with deeper support. For support in learning and using the tool, staff on the Content Enablement team are present to onboard new users and bring feedback about friction to the team that maintains the tool. For support in finding alternative ways to connect event & campaign data with the ERT pipeline, my team (Community Impact & Analytics) is available to grantees.
• [What is the integration plan for the largest family of events (the Wiki Loves photography campaigns) in its full diversity? Note that the announcement says this month (July 2026) the WMF will start requiring the use already. Could you share more about outreach to those communities, pilots with organizers that worked well?] A number of Wiki Loves photography events are already using Event Registration, though as you mention with "its full diversity" I am sure there are barriers (awareness, inertia, friction) to other instances of these campaigns.
• [Is there better documentation available for users?] The answer might be "no" if this is where you have already been, but the best documentation for users of the ERT is here.
• [Are there any known cases where the tool is not a good fit?] Yes! The ERT assumes that participants have an account, and so events that look to register newcomers face an additional hurdle (to your point above). There are also events that are focused more on awareness or advocacy, or that might be primarily in-person and off-wiki, that would be an awkward fit.

Now, an alternative proposal. I wonder-- if instead of mandating grantee use of the tool in July of this year-- a better approach to getting better, more centralized data and reporting would be to work with existing grantees to determine whether a switch to the ERT or collaborating on a pipeline to provide our data team with data to feed into an ERT pipeline would be a better short-term solution, while in the long-run the ERT can be built out to further reduce friction and reduce the need for workarounds.

The reason we led with mandating the tool (with exceptions made on a case-by-case basis) is that these workarounds (we've had to build some already) are inelegant and fragile, and require a lot of work to support. But given the concerns you and others have raised on these talk pages, perhaps that isn't a good enough reason to start with a case-by-case approach, working with grantees. I'd appreciate your thoughts on this as I explore internally how and whether we can resource such an approach. I'd invite others who have shared their ERT-related concerns as well; @Doc James, @Kruusamägi, @Zache, @Sj.

Finally! I agree with your point about A/B testing and the friction it would cause. My own half-joking response is yes, and at least they have a data infrastructure to allow A/B testing! But I would love your thoughts on a better way to get there. RMaung (WMF) (talk) 18:43, 14 July 2026 (UTC)

Will someone be at Wikimania who can walk me through this new ERT? Doc James (talk · contribs · email) 18:52, 14 July 2026 (UTC)

Yes! Send me an email at rmaung@wikimedia.org, and I'll make sure we find some time. RMaung (WMF) (talk) 01:16, 15 July 2026 (UTC)

The Event Registration Tool wouldn't work for our purposes in almost all cases. It's usually not about what a user does within a specific timeframe, but rather which specific content from particular users is marked as supported by us.

Let me give you two examples: (1) For media files on Wikimedia Commons, the uploader uses templates or categories to indicate whether the media file has been supported by us or not. This includes competitions, equipment rentals, travel support, and much more. However, during the same period, the same user also uploads media files that are not supported by us. Therefore, we can only conduct analyses (using PetScan and GLAMorous 2) based on the content, not on user activity.

(2) Wikipedia writing competitions usually involve documentation through manual on-wiki entries by the participants. However, the participants also edit other articles during this time, so the problem is similar to that on Wikimedia Commons.

The second example also highlights a significant cultural issue. We support writing competitions that are organized autonomously by the communities, usually with prizes. These are often competitions steeped in tradition and history, and it's up to the community, not us, how these activities are organized. Aside from the fact that the Event Registration Tool wouldn't work technically/logically as described, it's not being adopted by our communities. I think the main reason is the lack of transparency, since it could be used to allow people to register without other participants seeing who else can register.

We rarely use the Event Registration Tool and wouldn't actually need it at all. If it's helpful to others, that's fine, but it would be a very bad idea to use it to measure affiliate activity. --Raimund Liebert (WMAT) (talk) 14:50, 15 July 2026 (UTC)

I also have some thoughts from the perspective of an affiliate that regularly organizes different types of activities. First, I really like the Event Registration Tool and we use it whenever it makes sense. I think it is a valuable tool, but not every activity naturally fits its workflow (see all the examples on this thread).

My main question is actually about the objective behind making it mandatory. If the goal is to improve the quality and consistency of movement metrics, I think that's a worthwhile discussion. However, I think it would be helpful to clarify who these data are ultimately for. Will the centralized metrics collected through the ERT also be available to affiliates in a meaningful way, allowing us to better understand our own programs and improve them? Or is the primary goal to provide standardized reporting for internal Foundation processes?

I ask because I think these lead to different conversations. If the objective is simply to collect better data for grant reporting, requiring a single tool may not be the only—or the best—approach. There may be other mechanisms that allow affiliates to provide standardized data while preserving workflows that are already working well for different types of activities. But overall, I think making the ERT mandatory is not the solution for the problem that we're having. Best --Carla Toro (WMCL) (talk) 15:25, 15 July 2026 (UTC)

I fully support the concerns raised about making the Event Registration Tool mandatory. Representing a small affiliate that hosted 50 activites of various types and sizes last year, replacing our current systems with the ERT would mean taking a big step back and finding work-arounds that would increase our administrative burden. The ERT would only work for some of our activities, so we would need two separate event calendars and sign-up systems.

For us, the problems with the ERT are:

• It can't be embedded at our website, which is where we primarily communicate with our audiences, not least future Wikimedians.
• It has has much less functionality, and is less suited for visually appealing, smooth and targeted communication, than the tools we currently use.
• We can't collect participants' details that are required for our accounts and for the reports that we're required to submit to national public entities and external grantors.
• We're working hard to grow the number of participants, members and donors, but the tool can't be integrated with 1) the CRM we use to follow up on and communicate with these groups and 2) our payment solutions. Currently event participants can sign up and pay for affiliate membership with their phone number and just one click. We want this functionality to be easily accessible when someone reads about or signs up for our events.
• There are currently no metrics available with the Event Registration Tool that we don't already compile through EduWiki Dashboards and our editing contest bot.

It's great that the ERT is available to organisers that find it useful, but I hope that WMF staff can explore better ways of standardising how editing metrics are compiled. Elisabeth Carrera (WMNO) (talk) 06:01, 19 July 2026 (UTC)

Allow me to add another example of the Event Registration Tool (ERT) not being fit to be used as a metric. I was involved in a cooperation betweent the Wiktionaries in Tyap and Dutch and discoverd that this tool started to register all my edits as being part of this cooperation. Most of them weren't. There was no easy way to indicate when saving an edit whether it should be considered part of the event. If we want to use ERT for meaningful metrics, I suggest we take some time to develop it further for this purpose, before making it a requirement. --MarcoSwart (talk) 11:08, 24 July 2026 (UTC)

Hi @Raimund Liebert (WMAT), hi @MarcoSwart, I think you are describing a similar issue, so I wanted to reply together.

(some context) The ERT has a feature we call Collaborative Contributions. It shows the associated edit contributions made by the event participants. When a participant publishes an edit, they see a small dialog right after. This dialog asks if the edit should be linked to the event. Nothing is linked automatically. There is also a way for an organizer or participant to manually link their edit to an event at any time, if they choose to. Edits made outside the event window (start and end time) are also not associated.

@MarcoSwart, if your edits were linked without seeing that dialog, that is not expected. We would like to look into it. Would it be okay if I follow up on your talk page if we need more details about the event you linked? That would help us figure out if something went wrong.

@Raimund Liebert (WMAT), on the writing competition example, this feature should cover your concern about unrelated edits getting swept in.

On metrics: this feature shows the article edited, the wiki, the participant who made the edit, and bytes added. For a simple competition, you can see totals per participant (edit count, articles created, articles edited, and total bytes). But if your competitions need something like point allocation or weighted scoring, this feature would not cover that on its own. Thank you both for the detailed examples. -Udehb-WMF (talk) 23:39, 29 July 2026 (UTC)

As an editor on Dutch Wiktionary I typically make dozens of edits each day. In earlier parts of our cooperation we simply used categories to register contributions. When I entered the event registration in January 2026, I noticed a dialog box after each of those edits, significantly slowing down my usual workflow. A large majority of these edits had nothing to do with the event. For this reason I chose to deregister. Because my contributions to a project usually come by way of a string of consecutive edits, a practical solution would be a line in the edit screen indicating whether the edit is part of the event or not, and the option to toggle this preference just for this particular edit or all edits following.

A a stimulus we might even add a counter to this line in the edit screen, but that is immaterial to this discussion. MarcoSwart (talk) 16:13, 2 August 2026 (UTC)

No, this doesn’t work, for none of the projects that we support. I’m only going into detail for the Wikipedia competitions here. For de:Wikipedia:WikiCup (similar: de:Wikipedia:Denkmal-Cup and de:Wikipedia:Wiki-Loves-Earth-Cup), the contestants can nominate articles with their contributions reaching more than 3 kB – which is not necessarily related to single edits and can take quite a long time span – or they can earn points also with articles with less than 3 kB, e.g. by winning certain other competitions or tasks. This requires a complex system of nominations and possible disqualifications after manual checks which was developed by volunteers without our involvement and has been running smoothly for a long time. Then we support more quality-focussed competitions like de:Wikipedia:Schreibwettbewerb which rely on using templates in combination with other steps like choosing different content sections. Another quality-focussed competition is the de:Wikipedia:Wartungsbausteinwettbewerb; here, an additional challenge in terms of complexity is that contributions can also come from teams, not individual editors. You could ask the volunteer organizers of competitions like these whether you should provide tools that would make life easier for them, the Event Registration Tool isn’t such a tool unfortunately.

This is only the tip of the iceberg. Just one other example: a Wikipedia article is being changed and hopefully improved by adding a media file supported by us – independently from who adds the media file and independently from the editor even being aware that the media file was supported by us.

I fully support meaningful metrics and evaluation methods (and much needed improvements to existing methods); they just need to stand up to the reality and complexity of our movement. --Raimund Liebert (WMAT) (talk) 17:18, 7 August 2026 (UTC)

Other grant programs

Will following grant programs stay as same or will these funding programs replace them?

• Conference & Event Fund
• Wikimedia Research Fund

--Zache (talk) 19:48, 8 July 2026 (UTC)

Thanks for the question-- these proposed changes won't touch the Conference & Event Fund or the Research Fund. Funding eligibility described here only covers grants made from the Community Fund, which currently comprises the General Support Fund and Rapid Fund grants. RMaung (WMF) (talk) 19:56, 8 July 2026 (UTC)

@RMaung (WMF), next confirmation. Grants:Wikimedia Hub Fund will be replaced with these rules? (ie. hubs afaik aren't currently under community fund based on meta pages, but separate funding program) --Zache (talk) 02:57, 9 July 2026 (UTC)

Yes, that is correct. The piloting period for hubs came with additional funding separate from the Community Fund. Following this pilot phase, hubs will be funded through the Community Fund. RMaung (WMF) (talk) 13:09, 9 July 2026 (UTC)

Applying grants from multiple grant programs?

Previously pre 2022 system worked so that if entity such as chapter or user group already had direct grant such as APG or SAPG then they werent elligble to apply project or rapid grants. Would it be possible now to apply project grant if entity already have community grant?

Personally I think that overlapping project and community grants should be only possible conditionally for the cases where funding is needed for self-funding of external grant applications. In these cases funding is transferred to applicant only after the external grant has been is passed. --Zache (talk) 07:17, 9 July 2026 (UTC)

Hello, and thank you for your question.

The same criteria apply here: a recipient can only be a grantee in one program at a time, not two or three. For example, a current project fund grantee cannot simultaneously be a GSF [ General Support Fund] grantee.

We do anticipate cases in which a current project grantee is working to secure GSF funding for their next cycle. However, they cannot hold both grants at the same time. You are exactly right - we want to avoid overlapping funding. This ensures we prevent multiple-dipping and keep opportunities open for others to access these resources. Thank you. VThamaini (WMF) (talk) 08:25, 15 July 2026 (UTC)

New Project Grant Model

Is the new Project Grant model based on the historical Grants:project? What's the intended difference between the new model, the old 'project' model, and the new General Support Fund, in terms of activities, programming, and eligible expenses? Conbene (talk) 13:48, 9 July 2026 (UTC)

Thanks for the question, it is not! The old project grants are more a predecessor of the current rapid grant program.

In this proposed model, the idea is that rapid grants would be available for smaller initiatives and more informal user group activities. A project grant would be intended for user groups who might run a high-impact project (for example, a regional or global editing campaign) that involves more significant expenses, but does not require that user group to become a formalized nonprofit with continuous administrative overhead in order to deliver on their activities. General Support would be relevant for chapters and thematic organizations that function more like smaller nonprofit organizations with ongoing administrative costs. RMaung (WMF) (talk) 17:43, 10 July 2026 (UTC)

Visualization and comparison of proposals

• @RMaung (WMF): sorry if I'm missing this, but is there a single page that outlines the proposed future grant framework for all grant programs, such as general fund grants, project grants, rapid grants, hubs, the research fund, etc? One point of confusion is that Grants:Project is marked as historical but a new "Project Fund" is described on Updating the ecosystem of Wikimedia organizations/Recognition and Funding for Movement Organizations/Funding Eligibility. Also, to reduce confusion, I would suggest not using the name "Community Fund" for a collection of grants programs unless this name includes all WMF grant programs. ↠Pine (✉) 04:43, 12 July 2026 (UTC)

  Good point-- as this is still a proposal, we haven't built out anything like that on the meta space for grant-making. But yes, that is confusing. I'm making a note to clean this up a bit on meta once we have a revised and approved proposal.

  For clarity here: The present proposal concerns only the Community Fund, which as of FY26-27 is made up of Rapid, General Support, and now Hub grants. Other grant programs (Research, Events, Advocacy) are outside the Community Fund and not impacted by the proposal.

  Your points about organization and naming clarity are noted! RMaung (WMF) (talk) 19:02, 14 July 2026 (UTC)

  Hi @RMaung (WMF): It may be preferable to separate 3 different things which seem to be getting lumped into a single large proposal: a restructuring of affiliate tiers, a restructuring of WMF grants for affiliates, and a restructuring of how grant performance is evaluated. I suggest thinking about whether these could be less tightly bundled in a single proposal. Additionally, I would suggest creating a table which shows the current state and proposed state for each element of these plans, and the reasons for the proposed changes, including a comparison with the Global Metrics and the former grant scheme in which there were project grants and simple annual plan grants, and showing how hubs and non-affiliate grants such as Research grants fit into the picture. By loosening the bundling a little and considering one at a time, I think it may be possible to better understand and amend each proposal and build a consensus on each, with the understanding that they will probably eventually have tighter integration once all three elements are ratified. ↠Pine (✉) 03:10, 17 July 2026 (UTC)

  Another request for clarification: why have all of hubs, the Project Fund for organizations, and the General Fund for organizations? Is funding for hubs duplicative and/or complementary for funding through the proposed Project Fund and General Fund grants? Thanks, ↠Pine (✉)

  Please see also the discussion at Talk:Updating_the_ecosystem_of_Wikimedia_organizations/Recognition_and_Funding_for_Movement_Organizations#Clarification_of_mandate_and_approval. Could the visualization(s) include a before-and-after comparison of the grantmaking decision-making groups including the GDRC, AffCom, Hubs, and Grants staff? I am concerned that there are becoming so many groups, committees, and staff that there may be overlap, lack of clarity about who is doing what, and how to align the GDRC's work with this body of work. More separate decision-making bodies is not necessarily better, and I am concerned that there are "too many cooks in the kitchen". Even if the number of "cooks" is appropriate, the growing number of decision-making entities and teams is concerning to me, and I would like to see a visualization of the status quo for these entities, the proposed future state, and the explanation for the proposed changes. Thanks, ↠Pine (✉) 06:12, 23 July 2026 (UTC)

Barriers imposed on genuine projects to access the General Support Fund

I just read the proposal. I find it worrying, given that it would create bureaucratic barriers to genuine community-driven projects.

Let me give you one example. I currently coordinate the project "Strengthening the Latin American Public Domain with Wikidata." It's a regional thematic project that brings together efforts from four countries to improve the representation of the Latin American public domain in Wikimedia projects. The project is particularly interesting because, until its creation, various persons, groups and organizations in each country were carrying out actions and requesting funding to the WMF separately, which duplicated efforts and hindered the possibility of learning from each other. In this sense, the current project serves to bring together those projects, to improve regional capacities and to make more rational use of Wikimedia funds.

We are currently receiving approximately $38,000 USD from the General Support Fund. Due to the nature of the project, it wasn't submitted by a chapter but as an individual grant in my name, as I am the coordinator. While I coordinate the project, there are a total of 12 organizers from 4 countries, belonging to different organizations, none of whom are staff members of the affiliates. All our work, however, is done in close collaboration with the chapters (the chapters are both collaborators and beneficiaries of the project, as they receive training and access to resources on the topic).

The problem is that, according to this Fund Eligibility proposal, the new limit will be USD 10,000 for projects not submitted by affiliates. This puts the project in a difficult position: it would be ironic to have to go back to requesting isolated rapid grants in each of our countries to work on the public domain + Wikidata issue, given that the whole purpose of this project is precisely to stop requesting disconnected rapid grants and instead coordinate efforts at a regional level.

In short, I want to point out that the Fund Eligibility proposal ignores the reality of many local and regional projects that do not fit the proposed rigid and bureaucratic model. Thus, many genuine, successful projects, carried out in full collaboration with affiliates and the community of editors, may be at risk, as they simply do not fit an abstract idea constructed in a centralized manner. Pepe piton (talk) 19:08, 9 July 2026 (UTC)

Why could this not work as a Project grant, with the funds going through one of the participating affiliates? –SJ talk  10:17, 10 July 2026 (UTC)

In theory, if we only think in bureaucratic terms, it could be proposed that way, but:

1) It would not reflect the reality of the project.

2) Probably, the Foundation would ask why the affiliate doesn't include the activities in its annual plan. That would dilute the regional project among many other activities of a single national affiliate. What is more, given recent history, it is almost certain that the Foundation would not authorize an increase in the funding of a LATAM chapter of $40,000 for its annual plan. Pepe piton (talk) 15:33, 13 July 2026 (UTC)

I think a project like this would have a couple of options. The one that seems most clear to me, given the way you describe the work here, would be to pursue recognition as a thematic user group and project funding, or, as suggested above, to fold the work into an affiliate in the region with which you are already collaborating.

I am curious about your concerns regarding diluting the regional project or reflecting its reality-- can you share more about why you think this would happen? RMaung (WMF) (talk) 13:15, 15 July 2026 (UTC)

Thanks for your thoughts. If we only think in bureaucratic categories, this could also be another option.

But if a user group had to be created for every interesting new project, the possibilities for innovation would be severely curtailed. The process to create the user group would add unnecessary time wasted seeking AffCom recognition. Furthermore, the structure of a user group would impose bureaucratic burdens on the people carrying out the project, and, above all, it would add expenses to maintain the bureaucracy required of user groups.

I know, you'll tell me that Rapid Grants of up to $10,000 will be available. But the reality is that many projects require more than $10,000.

What I want to show you is that this won't only be a problem for individuals, groups or networks like us who carry out projects and aren't user groups. It will also be a problem for the Wikimedia Foundation: either a large part of the budget currently dedicated to funding successful projects will be diverted to paying to fulfill formal requirements, or successful projects will be scattered across a collection of isolated Rapid Grants. And, above all, bureaucracy will unnecessarily prevail over innovation.

That's why I ask you to maintain the necessary flexibility to make place for interesting, innovative projects, that emerge from the community. The current flexibility is not a bug, it's a feature. Pepe piton (talk) 15:53, 15 July 2026 (UTC)

@RMaung (WMF), I am not sure forcing projects to create user groups is a good solution. Not just for the reasons already described, but also because Affcom can simply decline to recognize new groups. And if larger funding can only go to affiliates, then affiliates are actually highly motivated to prevent the recognition of future user groups. asilvering (talk) 04:32, 17 July 2026 (UTC)

• I agree that adding a new user groups for a project is probably not a good idea, although this seems consistent with the concept of thematic organizations. The amount of volunteer time spent on creation and maintenance for a new group, both for the groups and for AffCom, would be questionable, and there would also need to be increases for WMF staff time for monitoring and compliance that I would guess would be less efficient than if projects were consolidated among fewer affiliates. ↠Pine (✉) 05:06, 17 July 2026 (UTC)

Hello @RMaung (WMF), I'd like to provide some context here. I think @Pepe piton's answers have covered the basics: 1) creating a new user group for each interesting project is exactly the opposite of what this proposal is aimed towards; 2) I doubt that the Regional Grants Committee would approve an additional extension of 40,000 USD to WDU's grant, particularly considering that we'd already be constrained by the upper limit (100,000 USD) if we can't become a chapter. Additionally, creating a UG for this would likely conflict with the guidance in this proposal regarding avoiding geographic overlap. WDU works on GLAM projects, but we consider this project to be of a different scope than our programmatic agenda on GLAM.

However, I do want to add context regarding the underlying problem: why this project does not currently fit into existing "community funding" categories. In the past, WMF offered distinct funding streams, including Projects & Event Grants and Individual Engagement Grants. Both PEGs and IEGs had a significantly higher funding ceiling than the current proposal, and many impactful community tools were built through IEGs by investing directly in community developers. At some point, these IEGs were also seen as conflicting with the vision that tool development needed to be centralized at WMF. Following the consolidation into the Community Fund, the Rapid Fund became the primary remaining avenue for independent technical contributors, yet Rapid Funds are often too small to support the labor required for sustained tool development that outlives a short-term grant (such as the Rapid Funds).

This creates a clear gap: community-led technical projects that are building interesting applications, and that require medium to long term support, currently lack a dedicated funding track that can support that work without overstretching the definitions of what is acceptable in the Community Fund. This was clearly not a good outcome, and it might be useful to revisit it in this proposal.

An important note to make is that part of that Community Fund consolidation included moving most chapters and user groups into the multi-annual request, as a way to avoid the excess labor that came with developing a full proposal each time and tying the multi-annual request to the presentation of a multi-annual strategic plan. Rather than repeating past oversights, it would be great if we could draw on our collective institutional memory to avoid reinventing the wheel when it comes to funding models. Scann (WDU) (talk) 21:34, 10 August 2026 (UTC)

Reliability and timing of Rapid grant processes

Regarding "Rapid" grants, these should be "Rapid" grants, not "WMF may or may not review or approve these if and when there are staff available to review them". I'm open to the idea of increasing the cap beyond $10K but would prefer that projects which exceed $10K are able to work in $10K increments with WMF doing its work in a rapid manner, such as a turnaround time of 5 calendar days for initial grant reviews and any questions, and a cap on WMF action of 10 calendar days for WMF approvals after those first 5 calendar days for a maximum WMF action window for approval or decline of 15 calendar days, and any WMF delay beyond 15 days automatically triggering a public review of Rapid Grants from the WMF Chief Financial Officer for possible additional staffing needs to get WMF's timelines back on track. ↠Pine (✉) 05:06, 17 July 2026 (UTC)

Hello @Pine,

Thank you for your question. I want to make sure I am fully addressing it, so please let me know if I missed the point.

The implementation of rapid grants in the proposal will remain as is. Over the years, we have made intentional attempts to make this process as rapid as possible. Currently, our timeline is two months from the grant submission deadline to the recommended earliest start date. Please note that factors like international bank transfers and country-specific regulatory checks can sometimes affect exactly when the funding reaches a grantee. You can view the full timeline here: https://meta.wikimedia.org/wiki/Grants:Project/Rapid#Timeline

For context, all other funding programs typically take four months, largely due to the additional levels of review required for those specific programs.

I hope this sheds some light on our current timelines. Let me know if you have any further questions, proposals, or if there is an aspect of your initial question I didn't quite capture. VThamaini (WMF) (talk) 14:06, 21 July 2026 (UTC)

• @VThamaini (WMF): Thanks for the information about current practice. In my opinion, two months seems long for a "rapid" grant timeline from submission date to proposed project start date, but has there been any feedback in the past year or two from people who are interested in Rapid Grants that the current two-month window makes things difficult for them, or makes applying for a grant too risky or impractical? At the same time, increasing the ceiling to $10K may help with some of these cases if people and groups are allowed to apply for somewhat generous contingency amounts, such as if a user group is requesting 6 months of funding through a Rapid Grant and they have $4K of projected needs and would be allowed to get $2K of contingency on top of that. As an aside, it may be advisable to have way of designating but holding and releasing contingency funding in cases like this so that there is not $2K of uncommitted funding granted to an affiliate, but there would be an approximately 3 workday turnaround time for approving a contingency request and another very short turnaround such as 1 week for the money to be transferred. This would be more work for both the grantee and WMF, but may provide a path for more generous approvals and fast disbursal of contingency amounts, all while staying under the $10K cap and having some risk management practices that involve lightweight WMF involvement for contingency using contingency funding. ↠Pine (✉) 05:43, 23 July 2026 (UTC)
• I've thought about this more, and I continue to believe that two-thirds of a quarter, or two months, seems long for a "rapid" grant to progress from submission to disbursement. It could be difficult to plan small projects that far in advance, including planning by people who aren't being paid for their planning time and need to get scheduling and budgets coordinated with their internal group and partners such as vendors and venues. I would suggest the window to be narrowed from 2 months to 1 month, but I would be interested in hearing from potential grantees if they think that narrowing this window would be helpful for their goals before asking WMF to commit the required staff time to accelerate Rapid Grant processing. This could be a good question for a survey of affiliates and previous Rapid Grant recipients, and a small consultation with AffCom. ↠Pine (✉) 18:29, 25 July 2026 (UTC)

Project Fund eligibility

Hello, it appears that the Project Fund may provide a good intermediate layer between rapid grants and general fund grants, but I'm concerned that there are some heavy prerequisites for getting a first Project Grant, particularly "Have an annual plan to fulfill their mission informed by a clear theory of change." Annual plans can be a lot of work to organize, and also require a degree of foresee-ability about the availability of people, who are likely to be volunteers or at most part-time staff, for an entire year. This is a large lift for a group without full-time staff. I would encourage a decrease in expectations and administrative burden especially for a first-time project fund grant for a user group that doesn't have full-time staff. An increase in expectations for planning and reporting seems more reasonable to me when there is at least one full-time staff member, or multiple paid staff members whose work adds up to 1 full-time staff member. Perhaps the requirements for project grants could be split into a lower set of requirements for groups that don't have a combined 1 FTE from 1 or more people, and a higher set of requirements for groups that have at least a combined equivalent of 1 FTE. ↠Pine (✉) 04:56, 12 July 2026 (UTC)

Thanks for this-- the way we have been thinking about annual plan and theory of change at the project fund level is a much smaller scale than would require an FTE equivalent. This is the basic structure that we tend to ask for in even rapid grant proposals ("If we do X, then Y will happen, which will lead to Z. Here's our plan to do X, when it will happen, who we will try to involve, etc.")

This is a good call out, and we can make this more clear. Something anywhere close to the scale (and labor intensity) of say, WMF's annual plan would be unreasonable to ask of a project grant recipient. RMaung (WMF) (talk) 13:06, 15 July 2026 (UTC)

Hi @RMaung (WMF): suggestion: change the requirement from an annual plan to "Have a six-month or 12-month plan to fulfill their mission informed by a clear theory of change". Six-month plans seem more reasonable to me for groups which are all volunteers and have no staff. By the way, WMF could offer or require (I would suggest require) quarterly checkpoint meetings with each organization which receives project grants and/or general fund grants, and the degree of scrutiny and support in those check-ins could be tiered according to the amount of funding and number of FTEs. ↠Pine (✉) 03:00, 17 July 2026 (UTC)

General Support Fund upper limit

Hello, I believe that some large chapters have historically received more than $600K annually. What is the plan for affiliates who have enough impact to justify $600K+ in annual budget? ↠Pine (✉) 04:58, 12 July 2026 (UTC)

Looks like WM FR is the only one coming close at 1.57 million over 3 years.[4] I think Germany and Kiwix have separate arrangements but not certain. Doc James (talk · contribs · email) 16:06, 13 July 2026 (UTC)

WM Brazil is the ONLY one that is actually slightly over at 1.86 million.[5] Doc James (talk · contribs · email) 16:08, 13 July 2026 (UTC)

Also just discovered that for North American a max of 500K per year was already in place "As of December 2024, the maximum annual funding amount for the North America region is 500,000 USD. Please contact the Regional Program Officer for details."[6] So the move to 600K is actually an increase there. Doc James (talk · contribs · email) 16:20, 13 July 2026 (UTC)

Some regional funds committees (North America and Northern & Western Europe, specifically) have set their own funding limits for their region in order to make room for smaller or newer grantees. This limit wouldn't necessarily replace any limit the RFC wants to set for their region, but would also establish a global ceiling.

Larger chapters that are closer to the $500K+ annual grant amount have greater capacity and opportunity to supplement their general support funding with funding sources other than the Wikimedia Foundation Community Fund (and some already do). RMaung (WMF) (talk) 12:57, 15 July 2026 (UTC)

Audits

The proposal is that audits will be required for 250K and above. It appears these audits cost 10K to 50K. How many grants / organizations does this look like it will apply to? Looks like only a handful, but would be useful to clarify the movement cost. Doc James (talk · contribs · email) 16:00, 13 July 2026 (UTC)

Decided to calculate it myself. The answer is 11 organizations will need to do formal audits at the 250K cut off.[7] Doc James (talk · contribs · email) 17:23, 13 July 2026 (UTC)

Adding to Doc James:

Speaking as someone who has served on about a dozen non-profit boards over time in the United States, the requirement for an audit at a $250,000 grant threshold in the U.S. seems very onerous as a percentage of a budget given the costs those tend to have ($10,000-$20,000) and are incredibly time consuming for the  staff (executive directors will disappear for long stretches of time to deal, time which they are not working on programming for the nonprofit).  

In the U.S. we generally start to see requirements for full audits at $1 million annual budget, though some foundations will ask for audits if they are giving multiyear grants even if each annual grant amount is less.

A lighter weight but directionally similar equipment in the U.S. would be a Financial Review, which can costs $3,000-$8,000 and is basically making sure everything is financially hygienic, the organization seems healthy, and root out inconsistencies. It is not designed to look for fraud.

I could see requiring an audit if the WMF annual grant amount is at least $500,000 over multiple years and the total budget for the organization is $1 million. This may also make sense if the foundation is willing to fund those audits separately from the grants. But looking at the size of the organizations in the United States, only Wiki Education makes sense as an organization (and not even technically an affiliate) to undergo an audit.

I understand the intention, but was a bit startled by how that $250,000 threshold was set, because wherever it came from, it is not reflective of people who are familiar with on-the-ground US non-profit operational governance.

Jenny8lee (talk) 22:49, 18 July 2026 (UTC)

Thank you for this input, @Jenny8lee! We are workshopping this to better balance financial health and transparency with realistic asks for affiliate organizations. RMaung (WMF) (talk) 16:40, 10 August 2026 (UTC)

I would agree that "For annual grants equal to or exceeding $250,000, have a financial audit report for the last year with an unqualified audit opinion, where compliant with applicable law." sounds potentially burdensome, but I would like to know more about exactly what type of audit is planned here. To Jenny8lee's point, there are different types of what could be called "audits", with varying degrees of time and money involved. ↠Pine (✉) 05:50, 23 July 2026 (UTC)

Support these reforms

Stronger transparency in financial disbursement helps to ensure donor confidence. There has been no shortage of concern in recent years that the Foundation is disbursing money handsomely yet without really knowing its impact, and I think these rules are an important step towards greater transparency and efficacy. CaptainEek ^{Edits Ho Cap'n!}⚓ 08:38, 15 July 2026 (UTC)

Those who work for us at Wiki Med invoice us monthly with the work they have done, for example[8],[9], [10], [11] and we list how much we pay them. Much of this is technical / programming work and thus has no editor numbers associated with it. Doc James (talk · contribs · email) 13:52, 15 July 2026 (UTC)

@Doc James you're not going to like what I'm about to say. WikiProjMed is a POV fork that is draining resources from the Wikis. After you were topic banned from including drug prices on EnWP articles, you somehow managed to make the #2 difference of WikiProjectMed Costs of medications are not only permitted but encouraged. We also include medication doses. You got banned from talking about it on EnWiki, and somehow you managed to get your own personal medicine price fiefdom, which is being paid over 500 thousand US dollars to further your POV. In my mind, that is exactly the kind of spending the Foundation should be scrutinizing. CaptainEek ^{Edits Ho Cap'n!}⚓ 18:25, 15 July 2026 (UTC)

Indeed. Donor money should not be going to vanity pov forks of existing projects. WikiMed is my go-to example of graft when I am asked for my opinion on affilates. -- Guerillero ^{Parlez Moi} 18:50, 15 July 2026 (UTC)

Perfect. Scrutinize away. Some at EnWP also do not wish it to be used as a starting point for translation to other languages and do not want to see it written at around a grade 12 reading level. EN WP is also fairly friendly to undisclosed paid editors. Yes we include medication doses, something our offline app users have repeated requested. And we also include medication prices, as they are fairly critical to understanding medication policy and use.

Most of our support is going to none EN Wikipedias and to Commons, examples include the hardware donation program and our health translation efforts as well supporting the crop tool for Commons. Doc James (talk · contribs · email) 13:50, 16 July 2026 (UTC)

Agreed. These reforms are desperately needed. We don't need more atrocious wastes of money like CapX or self-righteous affiliate members who couldn't find the edit button to save their life. HouseBlaster (talk • he/they) 15:17, 15 July 2026 (UTC)

Co-signing. Including the "affiliate funding should not be used as an end-run around topic bans" bit above. asilvering (talk) 19:21, 15 July 2026 (UTC)

I am not totally sure if these are way to go to "towards greater transparency and efficacy" per se. The current Affiliate Health Criteria system which was adopted to in use at autumn 2024 is working so that it steered affiliates towards open and participatory governance by making it as community grant review criteria and thing what was reported. Not all of the health criteria requirements needed to be implemented at once but affiliates needs work towards these goals and show progress to be successful. The new proposed system is more like that there is formal minimum criteria which needs to be fulfilled to get a grant and requirements will increase when affiliate steps up on the grant ladders. This probaply creates formally compliant, financially stable and professionally staffed affliates which are able to set their plans strategically and get the results. However, proposal doesn't require that these affiliates would have open or participatory governance. It doesn't for example require that their decision-making or documentation would be open and there is not much on how wider community could affect on the priorities what the affiliates are doing. --Zache (talk) 19:27, 15 July 2026 (UTC)

Comment from Wikimedia Brasil

We thank you, on behalf of Wikimedia Brasil, for the opportunity to comment on the document "Updating the ecosystem of Wikimedia organizations/Recognition and Funding for Movement Organizations/Funding Eligibility". This is an official message, approved by Wikimedia Brasil's Chair.

We recognize the general lines of the diagnosis presented in this proposal regarding the need for greater clarity in the roles, expectations, and funding criteria for organizations across the Wikimedia Movement. We also consider the concern about the moment of uncertainty facing the Wikimedia Foundation and the movement as a whole to be pertinent, given the changing contribution patterns associated with the rise of generative artificial intelligence and its effects on the funding model and on the attraction and retention of contributors, a topic we have also examined in our own strategic plan. In this sense, we understand the effort to rethink resource allocation and to establish affiliation structures that more precisely define responsibilities and measurable impact across the movement, in line with each affiliate's and project's organizational maturity, to be both necessary and timely.

We note, first, that members of Wikimedia Brasil are directly involved in Wikimedia Movement governance bodies: our volunteers and staff members serve on the GRDC, PTAC, AffCom, and the Regional Funds Committee, among other spaces, and we have also taken part in the focus group on the Wikimedia ecosystem. This involvement is independent and does not inform the present statement by Wikimedia Brasil, nor is it informed by it, although we do maintain ongoing internal discussions about Wikimedia governance within our own community spaces. We remain available and willing to contribute to the consolidation of the Wikimedia Movement, bringing to it the perspective of a large, mature affiliate from the Global South, one that has grown organically through years of organizational learning, and that has direct, practical experience with the very funding lines, recognition processes, and impact-measurement challenges this proposal seeks to address.

Despite recognizing the need for greater clarity on roles and responsibilities within the movement ecosystem, as well as the need to better understand our collective impact, we have serious misgivings about the recommendations in this proposal as well as the process of developing the new funding model, as this response goes on to detail. Given the weaknesses regarding impact measurement and institutional design oriented toward impact, we recommend that the Board of Trustees reject the current proposal and convene a process that first builds shared agreement on the vision and definitions this proposal ultimately depends on, before any decision on institutional design, funding restrictions, or mandatory tools is brought forward for approval. Wikimedia Brasil looks forward to continuing to contribute to this discussion, and, in the coming weeks, will be in touch with stakeholders to share our reading of this proposal.

Measuring impact

Any change related to updating the ecosystem of Wikimedia organizations, from the standpoint of impact measurement, should be oriented toward expanding and improving the quality and quantity of our impact. To do so, we need a strategic direction (a shared agenda), operational definitions, recurring spaces for communication, quantitative and qualitative methodologies for systematizing data, and shared indicators that allow us to assess this impact and learn from our work consistently across different regional and organizational contexts. We know that the Wikimedia Movement has bravely advanced in formulating a strategic direction through the Movement Strategy. What is missing is consensus on consolidating the other steps needed to expand and improve the quality of our impact.

Wikimedia Brasil maintains a robust system for monitoring and reporting impact, which allows us to build historical data series and plan our actions based on evidence. Recently, for example, we published a Diff post on the evolution of our community impact over the past decade.

We note that the proposal under discussion appears to start from the end: before methodologically defining what is to be measured, it already determines which tool should collect that measurement. The practical consequence of this is significant: affiliates will have to adjust their reporting practices to a new tool, migrate workflows, and abandon their own established infrastructures, all with limited resources, and without even having defined what we actually want to measure. The diagnosis that WMF lacks a consistent data analysis system seems reasonable, but the proposal, as formulated, shifts onto those who report activities the cost of solving an internal problem, without this transfer resolving WMF's own limited analytical capacity. Mandating a specific tool, such as the Event Registration Tool, which we in fact already use for some activities, does not substitute for the absence of clear, consensual methodological definitions about the indicators it collects; that definition should necessarily precede any requirement for mandatory use.

We suggest that, instead of a single mandatory tool:

• operational definitions for measuring our impact be agreed upon collectively, starting with seemingly simple decisions. For instance, we currently lack even a shared language for basic notions in our work, such as retention;
• an interoperable architecture be built, a constellation of tools (Event Registration Tool, OutreachDashboard, Wiki Loves stats, GLAM impact tools, and others developed by affiliates) feeding into a common database, with open export/import standards, preserving communities' methodological freedom without compromising WMF's ability to aggregate and compare data;
• an effort be made to migrate consolidated data, so that the continuity of historical series collected through affiliates' own tools over the years is not lost;
• the apparent tension between the current proposal and PTAC's recommendation, according to which tool development should remain a space for affiliate action, be addressed, given that the decision to rely on a specific tool to measure impact was not made by affiliates themselves;
• the Event Registration Tool's fit for this new role be reconsidered. The tool was originally developed to support editor retention, as an early step in the editor engagement pipeline, and its team has been notably open and responsive to community feedback within that scope. Repurposing it as the mandatory infrastructure for movement-wide impact measurement is a significant expansion of its original mandate, and one that deserves its own dedicated discussion, rather than being folded into this proposal as a given;
• the concrete side effects be properly assessed on volunteers who already use other tools for registering and tracking activities, on volunteers supported by affiliates but without a formal relationship to them, and on its coverage across projects, since activities are often not limited to Wikipedia alone, sometimes gathering data simultaneously from more than one project.

Institutionalizing impact

Any change related to updating the ecosystem of Wikimedia organizations, from the standpoint of institutional design, should be oriented toward expanding and improving the quality and quantity of our impact. Institutional changes to affiliate recognition and funding should be made with the care of first reaching consensus on a vision of the kind of ecosystem we want to build, rather than simply reacting against a system we already have in place and deem inefficient. What the Wikimedia Movement lacks is precisely that positive vision, oriented toward expanding and improving the quality of our impact, including strategic recommendations on funding priorities, which we had understood to be within the remit of the GRDC rather than something this proposal should preempt.

We recognize and celebrate that the affiliate ecosystem is a living system, built organically over more than two decades, and that institutional interventions in systems of this nature can produce unintended negative consequences, including effects opposite to those intended. Changes to recognition and funding criteria can destabilize delicate local balances, discourage legitimate forms of community organization that do not fit neatly into the newly proposed categories, or produce cumulative, long-term effects that are not visible at the moment the proposal is designed. For this reason, we believe any institutional change should be accompanied by mechanisms for monitoring, evaluation, and course correction throughout implementation, rather than a single, centralizing design applied once and for all.

That said, we also recognize that there are concrete problems to be solved, and that inaction has its own costs. We have identified at least three:

• growth in the number of affiliates that has not been matched by clear recognition criteria, leading to scope overlaps, fragmented efforts, and difficulty for WMF and the movement itself in understanding each organization's specific role within the ecosystem;
• the absence of a consistent model for handling different levels of organizational maturity, treating affiliates at very different stages of institutional development as equivalent, which hinders both adequate support for emerging organizations and appropriate recognition for more established ones; and
• the lack of an organizational growth model that reconciles affiliates' progressive maturity with geographic and resource-access equity, risking that stricter eligibility criteria reproduce or deepen historical inequalities between regions of the movement, especially those that have historically been underrepresented.

The proposal, by establishing a single cap for the General Support Fund, risks producing an effect opposite to the one intended: rather than consolidating strong, efficient organizations, it incentivizes the splintering of large affiliates into multiple smaller groups with a more localized, linguistic, or thematic focus. This is because, whenever the portion of an affiliate's budget that depends specifically on Wikimedia global funding exceeds the proposed cap, whether due to legitimate organizational growth leading to greater impact, or simply to currency exchange fluctuations that reduce the local value of a fixed dollar amount, that affiliate has a structural incentive to fragment into separate entities, each applying for funds through different funding lines. This is not a matter of bad faith on the part of affiliates, but a rational response to the incentive structure the cap itself creates: in the end, a fragmented organization obtains, in aggregate, a total amount of resources that a single organization could never have obtained under the very cap meant to limit it. Even the limit tied to focus areas can be easily circumvented, since an affiliate can simply define narrower or more granular thematic or linguistic focuses for each of the entities it splits into, allowing several such narrowly defined organizations to operate within the same territory.

A tighter recognition process alone would not resolve this, because the deeper issue is that the proposal keeps the entire affiliate ecosystem intact –linguistic, thematic, and geographic organizations of every scale coexisting side by side– without any framework for weighing their relative relevance to the movement. Under the criteria as written, what matters is procedural compliance, not the scope or stakes of what an affiliate actually serves. This is not a hypothetical concern for us: Wikimedia Brasil serves both the largest population in Latin America and one of the ten most-spoken languages in the world, and a framework that treats that scale as equivalent to any narrowly defined splinter group is one that has not yet grappled with the question of relevance at all.

The affiliate splitting scenario eventually creates redundant structures competing for the same community and the same limited resources, and increases the potential for conflict among organizations that, under a single-affiliate model, would otherwise coordinate internally rather than dispute space publicly. The result is the opposite of what we consider desirable for the ecosystem: instead of a large-affiliate model capable of generating efficiency gains and acting as a backbone for territorialization and local impact, meaningfully support our global governance, we would see the multiplication of smaller structures, with redundant staff, higher coordination costs, and a more fragmented, contentious environment. To give a concrete sense of this risk, we note that the proposed cap is below the amount Wikimedia Brasil itself currently receives to sustain its operations, already operating at the limit of its capacity.

We also note that the proposal creates confusion among the different available funding lines (affiliate microgrants, the Rapid Fund, and the Project Fund), due to the absence of a clear parameter to help applicants decide which modality is appropriate for the scope of their project, or whether they should instead turn to a local microgrant program, or wait for the initiative to mature before applying to larger lines. This articulation between the three modalities needs to be better established, and, specifically with regard to the Rapid Fund, we suggest that its definition stop being centralized at WMF and instead be handled by affiliates themselves or hubs, based on the volume of resources WMF makes available for this modality in each context. This change would acknowledge a pattern we already observe in practice: in the Brazilian case, most Rapid Grant applicants in recent cycles were initially trained within the context of our own microgrant program, and, once these projects deservedly moved on to the Rapid Grant, we lost precisely the capacity for mentorship and follow-up on initiatives we had helped incubate. Delegating the operational definition of this line to affiliates would make use of this accumulated local knowledge, rather than discarding it the moment a project matures.

Likewise, instead of a single cap for each line, the proposal should establish minimum thresholds for applications: without this, there is a risk of overlap between the Rapid Fund and the microgrant programs already offered by affiliates, which typically operate in the lower value range, and of a group applying, through the Project Fund, for amounts close to or even below the Rapid Fund cap, blurring the distinction between the two modalities in that intermediate range. For the same reason, the US$100,000 cap on the Project Fund should be replaced by a tiered structure tied to organizational maturity rather than to fixed dollar amounts, since the resources needed to achieve comparable outcomes vary widely across different countries and contexts. Such tiers should have considerable overlap, reflecting the fact that organizational growth is gradual and non-linear rather than a series of clean jumps between stages. Within this structure, we suggest creating an intermediate path for emerging groups, combining a Rapid Grant with an additional organizational-building grant, still far from the maximum cap, possibly with mandatory mentorship and follow-up from the program officer and the community throughout this maturation process.

Regarding the name of the Rapid Fund, we note that the proposal names speed without defining it: there is no objective timeframe, either for an initial response or a final decision, and we know, in practice, that requests of this kind tend to take significantly longer than the term suggests, sometimes many months; if this speed cannot be operationally guaranteed, it might be more honest to reconsider the program's name itself. Finally, just as it is necessary to define who can apply for these funds, it is also necessary to define who should not apply: the statement that any individual or group can apply for a Rapid Grant, regardless of affiliation status, lacks explicit exclusion criteria, including the case of globally locked accounts.

We note that several operational decisions listed in the proposal do not specify who will be responsible for overseeing them, such as the type of onboarding and training required for staff and volunteers, the frequency of reporting, legal compliance and salary benchmarking, leadership criteria –that should actually be designed or at least co-designed by the community it should serve and not impose top down–, or the measurement of community engagement and quality content added to projects; we recommend replacing these granular requirements with a general statement about impact and compliance expectations, making clear the body responsible for oversight and the concrete expected outcomes, which will likely be context-dependent. The level of granularity established may suggest that compliance with these criteria would be centrally verified by WMF, which does not reflect the institutional practice we work within. We also consider the proposed model inefficient in that it prevents, under any circumstance, user groups from accessing multi-year funding and General Support Fund: Wikimedia Brasil itself was, until recently, a user group, precisely because recognition mechanisms within Wikimedia are slow, and even then we already had organizational capacity superior to that of many chapters; it would not make sense for groups in that same situation, and there are several others across the movement, to be left without access to this kind of continued funding, including UGs that currently receive this kind of support and do excellent programmatic work.

Beyond these specific points, what we feel this proposal is missing is precisely what should come before any institutional design: this proposal lacks the dream, the utopia, the freedom of movement that this design is meant to serve. We are a plural, self-coordinated ecosystem, not an operation under a centralist model, and this discussion should begin with the question of what kind of movement we want to build, not with the creation of yet another layer of bureaucracy meant to fix problems created by previous layers of bureaucracy, in an incremental cycle that repeats itself without ever revisiting the ends it should be serving.

On behalf of Wikimedia Brasil. –JPeschanski (WMB) (talk) 18:33, 15 July 2026 (UTC)

I want a movement that is focused on wikis, not affiliates. Preventing Wikimedia Brasil from working on boondoggles like CapX is one of the reason that the utterly minimal guardrails in this proposal are essential to the health of the projects. HouseBlaster (talk • he/they) 18:46, 15 July 2026 (UTC)

I want a movement that is focused on wikis, not affiliates., what this in practice means? (ie. what should be done, who should be doing it and how to get there? give some example) --Zache (talk) 21:07, 15 July 2026 (UTC)

The chief one is that we should measure affiliate success by how much they return to the projects. That can be accomplished by adopting this proposal. Best, HouseBlaster (talk • he/they) 21:20, 15 July 2026 (UTC)

Ok, next question: How we should measure how much they return to the projects? --Zache (talk) 22:36, 15 July 2026 (UTC)

It would depend on the nature of the grant. If hosting an edit-a-thon, I'd measure impact in terms of edits and editors who stick around after the event—one of the reasons adopting the Event Registration Tool would be quite helpful. If it is a new software feature, I'd measure it in terms of its approval among its target audience—such as the general editor population or readers at large. Best, HouseBlaster (talk • he/they) 00:36, 16 July 2026 (UTC)

• @JPeschanski (WMB): thanks for the detailed statement. I won't take a position on the entire statement, but worth noting is that some elements in the statement are aligned with comments and questions that others have also raised. Personally I am not opposing the momentum for the proposal in general, but I think it needs additional clarification and amendments, and I think the clarification and amendment process would be made easier by separating this one large proposal into three separate proposals regarding the affiliate structure, the grants structure, and the evaluation structure, each of which could then be discussed and amended separately and possibly ratified separately, but eventually work with each other. Regards, ↠Pine (✉) 04:42, 17 July 2026 (UTC)

an interoperable architecture be built, a constellation of tools (Event Registration Tool, OutreachDashboard, Wiki Loves stats, GLAM impact tools, and others developed by affiliates) feeding into a common database, with open export/import standards, preserving communities' methodological freedom without compromising WMF's ability to aggregate and compare data; --- Yes, this is good idea. It would be good idea to have somekind of specificiation what we want to try to get out from the data and what data to collect and then give method to transfer it in machinereadable way. For example, most of the editing/new user events are combination of following rules: start/end time, username list, some criteria to filter edits so not all edits are included (ie. say SPARQL-query, Petscan-query, SQL-query, hashtag, linked from page etc) --Zache (talk) 09:44, 17 July 2026 (UTC)

Thank you for pulling this out, @Zache, and thanks to @JPeschanski (WMB) for the suggestion. We are exploring our capacity to support something like this on the Foundation's side, but I do think a suggestion like this could be a way forward if we can build something robust. The problem with diverse data sources and diverse, often volunteer-maintained tools is that it introduces greater fragility into a data pipeline, so that is something we'll need to be able to solve for. But you are right that those basic parameters (["start/end time, username list, some criteria to filter edits so not all edits are included"]) are broadly what is needed by the Foundation for this purpose. RMaung (WMF) (talk) 13:34, 21 July 2026 (UTC)

@RMaung (WMF), also one case is that there is edits by users in userlist to any wikimedia wiki is included. One such example was Memory of the World challenge 2025/Participants/Results, others would be International Roma Day Edit-a-thon 2026/Results or w:fi:Wikiprojekti:Suomi 100/International Challenge The tricky part for counting participants and their edits is that you cannot know which wiki they were editing so one need to check them all using code instead of doing simpe SQL queries. --Zache (talk) 14:50, 21 July 2026 (UTC)

Hello @JPeschanski (WMB) and Wikimedia Brasil!

Thank you for sharing your thoughts on this. I want to respond to a few of the points raised here.

Firstly, the General Support cap should not incentivize large groups to fracture-- it should incentivize our largest and most mature affiliates to find additional funding outside of direct support from the Wikimedia Foundation Community Fund, as some already do, if they find that their annual operational costs exceed the cap. Organizations of this size and maturity are generally well-positioned to do this. Diversifying an organization's funding base reduces dependence on any single funder and supports the long-term sustainability of the movement. Limits on affiliate geographic and scope overlap will also serve to disincentivize fracturing for the purpose of accessing funds.

I also want to challenge the idea of procedural and bureaucratic compliance, a point brought up here and elsewhere on these talk pages. I bring it up here because of the points you raised about organizational maturity. That is what these organizational requirements are meant for-- basic indicators of different levels of organizational maturity. We appreciate that maturity can look very different across movement organizations in our ecosystem, but we need a shared baseline. The intent here is also for any affiliate that wants to become a chapter or thematic org to know exactly what is required of them in terms of organizational maturity and outcomes to make the process for recognition more transparent.

Finally, impact and vision for the ecosystem. I want to draw your attention to the proposed purposes of affiliates. These are the three areas that we are setting outcome expectations for (see: "In consultation with the Global Resources Distribution Committee (GRDC), WMF will publish preliminary benchmarks for outcome expectations for new and existing editors engaged, content added to Wikimedia projects, and a rubric for expectations about movement context building activities.") No, this is not a utopian vision (we already have one!), but we need practical direction for affiliates to move toward this vision in a way that demonstrably serves the Wikimedia projects. How an affiliate builds community, content, or context is up to them. RMaung (WMF) (talk) 13:29, 21 July 2026 (UTC)

Concern about General Support Fund only for Chapters

This proposal in its current form states that General Support Fund (GSF) will only be available for chapters and thematic organizations. This is profoundly unfair towards well established user groups, who are sometimes operating more than chapters. For example, our user group in Morocco exists since 11 years and has been receiving GSF for over 4 years now, and has several employees and projects that cannot work with only a rapid or project grant. We understand that part of this proposal is that it wants to restructure the affiliates also, meaning that we will need to be obliged to become a chapter to continue our current activities. This situation is against equity that we claim to have in Wikimedia because:

1. Processes with Affcom are not transparent neither straightforward. Historically in the Wikimedia movement, it is not because you apply to be a chapter and fullfil the requirements that you will become one. There is no guarantee about that and I see a big risk in that.
2. Being a chapter requires a legal status, which not as easy in some countries than in others, puting volunteers sometimes at risk, and making an imbalance by favoring those living in more democratic countries.
3. Those already having a chapter start with a huge distance ahead, compared with those who need to apply to become one, which is again not very fair.

For these reasons, I personnaly reject this proposal and would like the general support fund to be open to all affiliates irrespective of their type. -- Anass Sedrati (talk) 06:34, 21 July 2026 (UTC)

Statement by foto.wiki.br on the proposed Recognition and Funding Eligibility framework

foto.wiki.br welcomes the decision to rethink how Wikimedia organisations are recognised and funded.

This is an important conversation. The Movement has grown, its organisations have changed, new communities have appeared, and old structures no longer answer every new question. A funding system should be able to grow with this complexity. It should be transparent, sustainable and accountable, but it should also remain open enough for new ideas, new communities and new organisations to emerge.

For these reasons, we do not support the proposal in its current form and believe that substantial revision is needed before implementation.

Our concern is not with one rule in isolation. It is with the path the proposal takes.

Before deciding who may enter each door, we should first ask how the house itself is organised. Before making access more restrictive, we should understand how resources are already distributed, what they produce, where capacity is growing, where it is still missing, and whether the Movement is investing its next dollar where it can make the greatest difference.

Our intention is not to question the good faith of organisations, funding committees or Wikimedia Foundation staff. On the contrary, this proposal opens an opportunity to look at the system as a whole and ask whether it is producing the kind of Movement we want to build.

For foto.wiki.br, equity is not the same as giving everyone the same ladder. It also means asking who is already standing on the roof, who is still on the ground, and what each person actually needs in order to climb.

That principle is consistent with our commitments to diversity, equity and inclusion, evidence-based action, responsible use of resources, continuous learning and organisational sustainability.

So, before making the system more restrictive, we believe one simple question should guide the discussion:

Is the current funding model directing resources to where they can generate the greatest additional value for the Movement?

1. Before redefining eligibility, we should look again at where the money goes

The conversation about eligibility should begin one step earlier: with the distribution of resources itself.

For FY2025/26, the Wikimedia Community Fund allocates approximately US$2.75 million to the region called North America, which in this funding structure means the United States and Canada.

The whole of Latin America and the Caribbean receives approximately US$2.963 million.

In other words, two countries receive a regional allocation equivalent to about 93% of the entire budget for Latin America and the Caribbean.

Fiscal year	United States and Canada	Latin America and the Caribbean
FY2021/22	US$1.755 million	US$1.211 million
FY2022/23	US$2.000 million	US$1.940 million
FY2023/24	US$2.340 million	US$2.480 million
FY2024/25	US$2.595 million	US$2.803 million
FY2025/26	US$2.750 million	US$2.963 million

There has been progress, and it should be recognised. Latin America and the Caribbean have grown faster over this period and now receive slightly more than the United States and Canada.

But the scale still deserves attention.

The United States and Canada budget grew from US$1.755 million to US$2.75 million in four funding cycles, an increase of roughly 57%.

The most recent figures are even more striking. For FY2025/26, approximately US$154,815 was added to the United States and Canada allocation, while approximately US$160,224 was added to the allocation for the whole of Latin America and the Caribbean.

The increase for two countries was therefore about 97% of the increase given to an entire region of dozens of countries and territories.

We are not suggesting that organisations in the United States or Canada should receive less simply because of where they are located.

The question is different.

What evidence tells us that adding almost the same amount of new funding to two already well-funded countries creates more Movement value than using part of that growth to build capacity where very little institutional infrastructure yet exists?

This matters because funding has memory.

An organisation funded for many years accumulates staff, equipment, procedures, contacts and experience. All of this is valuable. It also makes the next grant easier to request, justify and manage.

A region that starts with less does not simply have less money. It has had fewer opportunities to accumulate the very capacity that later becomes evidence of maturity.

If similar growth rates are repeatedly applied to very different historical bases, yesterday's inequality can quietly become tomorrow's baseline.

A funding system committed to equity should therefore look not only at whether access is formally open, but also at whether historical allocation patterns continue to reproduce unequal capacity.

Before making eligibility more restrictive, we should first understand whether the map of funding itself is the map we want to keep reproducing.

2. WMCA and WMBR show why we need to compare more than budgets

The comparison between Wikimedia Canada, WMCA, and WMBR is not intended as a contest between affiliates.

It is useful because it exposes a simple problem: we can compare their funding down to the cent, but we cannot compare their impact with the same confidence.

Neither organisation should be judged solely through the figures presented below. Their different reporting structures are themselves part of the problem we are trying to describe.

WMCA received US$812,561.23 for 2025 to 2027, corresponding to the full approval of CAD1,091,800. Its annual funding rises from CAD343,000 in the first year to CAD363,500 in the second and CAD385,300 in the third. Its application also planned an increase from three to four full-time staff members.

WMBR received US$1,511,109 for 2023 to 2025.

In 2025, WMBR published a consolidated set of targets and results:

WMBR indicator, 2025	Result	Target
Participants	5,287	4,214
Editors	2,063	1,960
Editors retained after activities	534	144
Wikipedia pages created or improved	6,470	5,880
Files uploaded to Wikimedia Commons	108,709	64,800
Wikidata items created or improved	34,506	33,800

These figures are consolidated in WMBR's 2025 report.

For WMCA, three different layers of reporting need to be distinguished.

The original grant application tells us what was requested, what staffing assumptions were made and what targets were proposed.

The 2025 Yearly Report is the formal report linked to the General Support Fund grant, through which the organisation reports to the Wikimedia Foundation on delivery, organisational development, learning and the use of resources.

The organisation's separate Annual Report gives additional public information about individual activities.

These documents show that work was done. That is not in question.

The issue is whether a reader can easily move from the original targets to the formal Yearly Report and answer a few basic questions:

What did the investment produce?

How many people did it activate?

How many remained engaged?

How much content was created or improved?

What changed because the additional funding existed?

And how much did those outcomes cost?

In the original application, WMCA set targets of 175 editors, 80 organisers, 3,300 Wikipedia contributions, 10,000 Commons contributions and 15,000 Wikidata contributions. It did not set targets for total participants, new editors or retained editors, and stated that it did not distinguish between content created and content improved.

Its Annual Report adds useful activity-level results, including:

• 369 articles edited and 662 references added through #1Lib1Ref;
• 26 articles created and more than 160 improved through a Francophone campaign;
• 432 submissions to Wiki Loves Earth;
• 445 images uploaded through activities in Nunavut and the Northwest Territories;
• more than 600 photographs uploaded through WikiPortraits at TIFF, with 250 used across more than 100 wikis and 1,370 pages.

These are real results, but they use different units and describe different kinds of activity. They should not simply be added together and presented as one annual output.

And that is exactly the point.

A reader should be able to move from the grant application to the formal Yearly Report and understand, with reasonable clarity, what was achieved against the approved targets, at what cost and with what additional effect.

When that reconciliation is difficult, the problem is larger than reporting style.

It becomes a portfolio-management problem.

We can say precisely how much money was invested, but we cannot yet answer with the same precision:

• how much was produced;
• how many people were activated;
• how many stayed;
• how durable the results were;
• what can reasonably be attributed to the funded organisation;
• and what additional impact came from the additional funding.

This does not prove that one organisation is efficient and another is not.

It proves that the Movement still lacks the common measurement architecture needed to know.

And the larger the investment, the more important that knowledge becomes.

An investment exceeding US$800,000 should come with evidence strong enough to show not only that money was properly spent, but that the scale of investment continues to make sense.

A clean financial audit tells us that resources were handled correctly.

It does not tell us whether an operating model is efficient, whether a new staff position produced additional impact, or whether the same resources might create greater value elsewhere.

Those are different questions, and we need the tools to answer them.

3. Emerging organisations need space to grow, not only permission to survive

The case of Mais Teoria da História na Wiki offers another window into the same issue.

In 2024, Mais Teoria received BRL258,139.74, with the requested amount fully approved.

For the next cycle, it requested BRL306,243.46, an increase of approximately 18.6%.

The initial recommendation was BRL245,000, less than the previous year's funding.

After reconsideration, the Committee explicitly recognised the quality of the work, the extensive documentation and the organisation's growth, and increased the amount to BRL268,724. This represented growth of about 4.1% over the previous grant.

Mais Teoria	Amount
Previous funding	BRL258,139.74
Requested amount	BRL306,243.46
Requested growth	18.6%
Final amount after reconsideration	BRL268,724
Effective funded growth	4.1%

Approximately 78% of the requested growth was therefore not incorporated.

There may be perfectly legitimate reasons to reduce a budget. Committees should scrutinise proposals.

The interesting question is what happens when we step back and compare patterns.

A project still building its structure had its growth effectively limited to around inflation.

At the same time, WMCA received a fully approved multi-year grant that grows from CAD343,000 to CAD385,300 and includes staff expansion.

At regional level, the United States and Canada also continue receiving an absolute increase almost equal to that of the whole of Latin America and the Caribbean.

There is nothing inherently wrong with funding the growth of a mature organisation.

Growth is often healthy.

But growth should also be possible where capacity is still being born.

An organisation that has received sustained funding for many years accumulates more than money. It accumulates memory.

People learn how the system works. Procedures become routine. Equipment remains available. Partnerships mature. Reports become easier to prepare. A professional structure begins to reinforce itself.

A newer organisation starts from another place.

If we ask emerging organisations to demonstrate mature capacity before allowing them to fund the process of becoming mature, we create a circle that is difficult to enter.

An equitable funding system should therefore do more than keep organisations alive.

It should create room for new capacity to grow.

4. Administrative maturity is useful, but it is not the same as impact

The proposal rightly values financial controls, governance, planning, reporting and experience.

These things matter.

Money should be managed responsibly.

But administration and impact are not the same thing.

An organisation may have excellent policies, professional staff and flawless paperwork while producing limited additional impact for the resources invested.

Another may still be developing its administrative structure while already producing remarkable work.

The funding system should therefore keep two questions separate:

Can this organisation manage the money responsibly?

and

Is this a good investment for the Movement?

They are related, but they are not identical.

Mature organisations will naturally find it easier to satisfy complex administrative requirements. That is partly because years of previous funding helped them build the systems needed to satisfy those requirements.

This should be recognised, not mistaken for neutral starting conditions.

Large recurring grants should therefore receive periodic operational assessment, not as punishment, but as good stewardship.

The question is not whether an established organisation deserves to exist.

The question is whether its next increase still produces strong additional value.

Yesterday's budget should be useful context.

It should not automatically become tomorrow's entitlement.

5. First agree on the language of measurement, then choose the tool

The proposal requires grantees reporting participation, content or retention outcomes to use the Event Registration Tool, ERT, unless an alternative is approved.

The desire for better data is welcome.

We share it.

But a tool cannot solve a problem of meaning.

If two organisations use different definitions of “participant”, putting both numbers into the same database does not suddenly make them comparable.

The same applies to:

• attendance;
• editor;
• retention;
• content created;
• content improved;
• and impact.

The Movement first needs a common vocabulary.

What counts as a participant?

When does someone become an activated contributor?

How long must someone remain active to count as retained?

When can an organisation reasonably attribute an edit or upload to its programme?

What is the difference between creating one new article and making one minor improvement to an existing article?

These questions come before software.

ERT may be an important part of the answer.

It should not be mistaken for the answer itself.

The best sequence would be simple:

First define the concepts.

Then define the data.

Then allow interoperable tools to collect them.

Standardise the meaning, not necessarily the interface.

That gives us comparability without closing the door to experimentation.

6. Equal metrics do not require identical expectations

Comparability is important.

Uniformity is something else.

An organisation receiving US$1 million per year, with professional staff, stable infrastructure and years of accumulated equipment, cannot reasonably be assessed only through the same raw output expectations as an organisation receiving US$30,000 and operating with one part-time employee in a difficult context.

The definitions should be common.

The expectations should be intelligent.

A good evaluation should look at at least three things:

• performance against the organisation's own history;
• performance against genuinely comparable peers;
• and the conditions under which the work was done.

We should also be careful with the idea that money automatically goes further in the Global South.

Sometimes it does.

Sometimes it does not.

A salary may be lower, while a camera costs more.

A local service may be inexpensive, while importing a computer requires freight, duties, currency conversion and long waits.

A journey that looks short on a map may require expensive transport, unreliable roads or complex logistics.

Connectivity, electricity, storage, security and maintenance can all reshape the real cost of a programme.

Equity begins with reality.

It means looking at what it actually costs to produce meaningful work in a specific place, rather than assuming that the same dollar behaves the same way everywhere.

7. Rapid Funds should feel rapid

We welcome the idea of strengthening locally administered funding.

People closer to a place often understand its costs, risks and opportunities better.

They know whether a transport estimate is realistic.

They know whether an equipment price is normal.

They may know the institutions, the communities and the tensions that do not appear in a spreadsheet.

This can make funding decisions smarter and faster.

And speed matters.

The current Rapid Fund process provides roughly two months of processing time and one round every two months.

For many opportunities, that is simply not rapid.

A museum may open a collection for a short period.

A field expedition may depend on weather.

A partnership may appear suddenly.

A specialist may be available now and not six months from now.

The world does not organise itself around grant calendars.

Local mechanisms may help.

But local should not mean exclusive.

A local affiliate may have its own priorities, conflicts or programmes. A minority community, thematic network or dissenting group may need an independent route.

The best system is therefore not one gate replacing another.

It is a system with more doors.

There is also a process problem.

Breaking one coherent programme into several small grants creates more paperwork for everyone.

More applications.

More reviews.

More contracts.

More payments.

More reports.

More time spent managing the machinery instead of producing the work.

Rapid Funds are excellent for experiments, small opportunities and genuinely rapid action.

They should not become the only bridge available to organisations that need something larger than a microgrant but are not yet eligible for institutional funding.

8. The space between US$10,000 and US$100,000 should not be a canyon

The proposed model makes Rapid Funds available regardless of recognition status.

Project Funds of up to US$100,000 would require recognition as a user group plus additional organisational requirements.

General Support would mainly be available to recognised chapters and thematic organisations.

This creates a difficult transition.

A group may begin with a small Rapid Fund.

The project works.

People join.

Partnerships emerge.

The group is ready for something larger, perhaps US$30,000, US$50,000 or US$80,000.

At that moment, it meets a wall.

To obtain the next level of funding, it first needs formal recognition and a range of institutional systems.

But those systems often require exactly the kind of resources the group is trying to obtain.

This creates a familiar paradox:

to receive the resources needed to build capacity, the group must first prove that it already has that capacity.

There is another question too.

Not every good idea needs to become an organisation.

Sometimes the right unit is a project.

Sometimes it is a network.

Sometimes it is a coalition that exists for three years, does excellent work and then ends because its work is complete.

The Movement should make room for that.

Recognition and project funding can be connected without becoming inseparable.

Fiscal sponsorship, milestone payments, accountable project leads and proportionate controls can manage risk without forcing every promising initiative to become a permanent institution.

A healthy ecosystem needs more than a first step and a top floor.

It needs stairs.

9. Multi-year funding should allow organisations to plan for more than one year

Multi-year funding is valuable because it allows organisations to think beyond the next grant cycle.

It allows people to be hired.

Partnerships to mature.

Programmes to grow roots.

But a multi-year promise only works if organisations can reasonably rely on it.

The proposal allows future years of multi-year commitments to be reduced if WMF revenue falls below target.

Some flexibility is understandable.

No institution can promise that the future will never change.

But risk should sit where it can best be managed.

A local organisation cannot control WMF revenue.

It usually has fewer reserves, fewer revenue streams and less room to absorb sudden changes.

At the same time, it may already have hired staff or signed contracts based on an approved multi-year plan.

A reduction of 10% does not mean the same thing everywhere.

For a large organisation, it may postpone an expansion.

For a small one, it may remove the only salaried position keeping the organisation running.

Multi-year funding should therefore offer real predictability, especially for commitments already made.

Flexibility is necessary.

So is trust.

10. The whole portfolio deserves attention

The proposal is trying to solve a real problem: resources are finite.

But scarcity can be addressed in more than one way.

One way is to make the doors narrower.

Another is to look at the whole portfolio and ask whether the money already inside the system is producing the best possible results.

We believe the second question must come first.

Large recurring grants should be periodically examined for marginal return.

Emerging organisations should have a real path towards sustainable capacity.

Successful programmes should not be broken into pieces merely to fit administrative categories.

Regional growth should respond to opportunity and need, not only to historical baselines.

And metrics should allow us to compare investments before those metrics are used to justify restrictions.

There is another part of organisational maturity that deserves more attention: the ability to diversify funding.

As an organisation develops legal status, paid staff, professional financial management, audited accounts, recognised partnerships and years of institutional experience, it usually becomes better equipped to approach funders beyond the Wikimedia Foundation.

Depending on the country and context, this may include public grants, philanthropic foundations, universities and cultural institutions, individual giving, membership programmes, corporate or institutional partnerships, and other forms of co-funding.

This does not mean that mature organisations should stop receiving Wikimedia funding.

Nor does it mean that fundraising opportunities are equal everywhere. They clearly are not.

But institutional growth should gradually open more doors, not make an organisation increasingly dependent on only one.

Otherwise, the funding system may create an unintended incentive: the more infrastructure an organisation builds with Wikimedia resources, the better equipped it becomes to request an even larger share of those same resources, year after year.

Meanwhile, emerging groups often stand on the opposite side of the door.

They may not yet have legal personality.

They may not have an institutional bank account, audited financial history, paid administrative staff or the legal structure required by many public agencies and foundations.

They may have excellent people, strong ideas and a community ready to work, but still be unable to approach many of the partners available to mature organisations.

That asymmetry matters.

Wikimedia funding can play a particularly valuable role at precisely this stage: helping an emerging group build the minimum legal, administrative and operational capacity that will eventually allow it to reach other sources of support.

A healthy ecosystem should therefore create a virtuous movement.

As organisations become stronger, they should become better able to diversify their resources. As some organisations become less dependent on a single funder, more room can open for new communities to build the capacity they do not yet have.

This is not about pushing successful organisations away.

It is about allowing success to create more success around it.

The proposed US$600,000 General Support ceiling may be a useful reference point.

But a ceiling is not a strategy.

The most useful question is still the simplest:

What does the Movement gain from the next US$100,000 invested here, and what might it gain if those same resources were invested somewhere else?

That question is not hostile.

It is the question any organisation committed to impact should be happy to ask.

Conclusion

foto.wiki.br believes this reform is necessary.

We also believe it is an opportunity.

The Movement can build a funding system that is more accountable without becoming less open, more rigorous without becoming rigid, and more sustainable without freezing today's inequalities into tomorrow's rules.

But we believe the current proposal starts one step too late.

Before restricting eligibility, we should review how resources are distributed.

Before increasing or preserving major investments, we should be able to compare what they produce.

Before mandating one tool, we should agree on what our metrics mean.

Before asking emerging groups to demonstrate maturity, we should give them a realistic path to build it.

Before requiring formal recognition for medium-sized projects, we should ask whether every good project needs to become an organisation.

As organisations become mature enough to access other funders, we should encourage them to diversify rather than assume that institutional growth must always be financed primarily through larger Wikimedia grants.

And before offering multi-year funding, we should make sure that “multi-year” carries enough predictability to allow people to plan with confidence.

The comparison between WMCA and WMBR shows how difficult it still is to connect investment and results across organisations.

The Mais Teoria case shows how easily emerging capacity can be held close to inflation while established structures continue to grow.

And the regional numbers show something even larger: in FY2025/26, the additional funding allocated to the United States and Canada alone was almost the same as the increase allocated to the whole of Latin America and the Caribbean.

None of these examples, by themselves, proves that a particular funding decision was wrong.

Together, however, they show why the system needs better questions before it creates harder rules.

For these reasons, foto.wiki.br does not support the proposal in its current form and recommends substantial revision before implementation.

We believe a better model is possible.

One that preserves what already works, looks honestly at what could work better, gives emerging communities room to grow, encourages mature organisations to become more resilient and financially diverse, and treats every grant not simply as an expense to approve, but as an opportunity to build a richer, more diverse and more resilient Wikimedia Movement.

foto.wiki.br remains ready to contribute constructively to that work, together with the Wikimedia Foundation, affiliates, organisers and emerging communities.

The goal, after all, should not be merely to manage scarcity.

It should be to help more good things become possible.

References

This statement was collectively discussed, reviewed and approved by the foto.wiki.br team, and represents our shared institutional position and our commitment to contributing constructively to a fairer, more diverse and more sustainable Wikimedia Movement.The foto.wiki.br team Rodrigo Tetsuo Argenton ^m 18:04, 21 July 2026 (UTC)

List of affected affliates

I made a list of affliates which would be affected on the proposal. TLDR is that user groups would get the biggest hit as they would lose core funding and would rely project based rapid and project grants, which are more unpredictable. This is important change no matter how big the grant was.

Then there is also external partners and unrecognised groups where some of these are quite big and important (for expample wikiportraits which is poster child project for wikimedia) and they would require recognition as affliate to continue. One pretty obvious thing is that there is so many affliates which would require update from user group to chapter or thematic group that is hard to see that affcoms recognition system could handle it without mass approvals. --Zache (talk) 16:39, 23 July 2026 (UTC)

Graphs

I tried to understand how grants are currently distributed (ie. how many groups there are, where they are, what kind of groups) so I made some graphs. Data is parsed from grant applications so it is approximate and likely off by 5-15% from real numbers depending on the year from various errors ( parsing errors, missing data, grant application differences etc ...) In any case it should be good enough to get the general idea.

Also, source data is here if somebody wants to do own graphs.

Grant distribution in number of grantees

• 
  Number of Wikimedia affiliates, hubs and other orgs 2009 - 2026
• 
  Number of Wikimedia affiliates, hubs and other orgs with grants highlighted 2009 - 2026.
• 
  Wikimedia affiliates, hubs and groups grouped by region

Grant distribution in USD

• 
  Wikimedia affiliates, groups and hubs yearly grant amounts stacked 2009 - 2026
• 
  Wikimedia grant amounts for groups by region 2009 - 2026
• 
  Wikimedia grant amounts by applicant annual total size grouped to six-bands 2009 - 2026
• 
  Wikimedia grant distribution grouped to six-bands 100% graph 2009 - 2026

Some notes about what i noticed. One is that the funding change would limit about 45% of current GSF funding if it is looked as USD (ie. chapters = 8.6M USD and user groups + unreconized/registered groups = 4.8M USD + 2.3M USD in 2026). Other notes, most of the chapters were formed 2009-2013 and user groups 2013 - 2020. It is little bit unknown for me why forming new user groups were stopped already in 2020, but probaply there some new requirements. However, there have been always unregistered/unaffliated groups who got grants and their number has not been increased that much, but after 2022 change the funding increased for unregistered/unaffliated and user groups. Also, about 50% hubs and user groups didn't get any funding, but it is also expected that some of these are genuinely inactive too. Another note is also that rapid grants are quite popular. --Zache (talk) 04:15, 11 August 2026 (UTC)

General concern

I'm not sure where to put this comment, so I'll put it here and hope it is read.

I agree with the need for clarity around expectations. But I think this plan feels like a move backward, erasing so much progress and innovation the Foundation has made. I feel like the past 3-5 years the Foundation has made leaps of progress in creating space for alternative entry into the movement. I believe this change will impede, and regress this progress.

- I also want to be careful about how this clarity manifests via reporting. We have learned that impact looks different for different Affiliates/User Groups. A lot of what is beautiful about the movement's progress is less easily measured by data. It is obvious, reading the Wiki blogs and reports, that numbers and data is not the only way to measure impact.

- the administrative labor is not what most editors/volunteers come to engage with. Moving to require Affiliates/User Groups to apply and report each year will increase the labor on these projects and create instability. There is a question as to who has the capacity to do this labor, which, to me, parallels the work the Foundation has been doing to create a more representative archive -- those who can afford this change in funding are not the ones who need as much support. Instead of focusing on the programming, they will focus a large amount of their time on the administration, and without the security of the sustainability of their project being funded for the next year. It is difficult to get momentum, excitement, and relationships built when they are not guaranteed to be there the following year or two. This will undoubtedly sunset lots of these Affiliates due to the shift in focus of the work.

- Am I seeing that the financial ceiling of funding would impact only 18 Affiliates? It seems when an Affiliate is so reliant on the Foundation for funding, perhaps the move, if this change will happen, would be to do it more slowly (reducing all Affiliates by a percentage or reducing over years)? So the projects can find other funding, remodel their structure and programming over time instead of in a couple of months? These Affilates/User Groups have spent years building a following, making strategic plans and building relationships. I worry this change will tank some of these projects with a cap like this.

Thanks Heathart (talk) 20:14, 5 August 2026 (UTC)

@Heathart Am I seeing that the financial ceiling of funding would impact only 18 Affiliates? --- 24 as total if we think that project grant can replace GSF yearly grant. However, I do not think that the ceiling is the main issue, but that the rapid or project grants is not designed to be yearly infrastructure support grant so one may or may not to get it. It is much more limited on how it can be used, for example in rapid fund grants there limit No funding for travel scholarships or conference participation. which is little bit bummer as least in Finland one of the main things what WMFI does to community side is to cover travel costs and i somewhat think that it would be useful for smaller user groups too. (WMFI is chapter) --Zache (talk) 04:49, 11 August 2026 (UTC)

Rapid Fund limit

I would appreciate some clarification regarding the new Rapid Fund limit. Under the current rules, the maximum amount per Rapid Fund grant is USD 5,000, while an individual, group, or organization may receive up to USD 10,000 in total per fiscal year. This effectively allows, for example, max two separate grants of up to USD 5,000 each during the same fiscal year, subject to the other eligibility requirements. The proposal states that the Rapid Fund limit would increase from USD 5,000 to USD 10,000, but it does not specify whether this refers to the maximum amount per individual grant or to the total amount available per applicant per fiscal year. Could you please clarify whether applicants would be able to request up to USD 10,000 per grant while remaining subject to the existing annual limit of USD 10,000, or whether the annual limit would also be increased? It would be helpful if the proposal explicitly distinguished between the per-grant limit and the total amount available per fiscal year. MikyM (talk) 21:35, 19 August 2026 (UTC)

Feedback from the Volunteer Supporters Network Hub pilot / Funding

The following feedback has been put together by the Volunteer Supporters Network Hub Pilot Management team and Advisory group, with the exception of those individuals who felt that they had a COI due to other commitments and connections in the movement.  

Our main concerns centre around the proposals for funding, and we have also posted on the Affiliation talk page with our comments for that section.  

Under the current proposals, Hubs would be required to produce a multi-year strategy, but would only be able to access single-year funding.  Sustainability thus will become a significant challenge:

• This would reduce the ability of a Hub to succeed with regard to achieving long term goals
• This would increase the precarity of the employment of Hub staff / management
• This adds an additional administrative burden on Hub staff / management

We would like therefore to emphasise that we would strongly support a multi-year approach to funding for Hubs.  This is especially important given the coordination role which Hubs currently - and can in future - play in the movement.  The effectiveness of the kind of cross-organisational and partnership work in which Hubs engage would be severely limited by a single-year approach.  

We would also like to stress that we would strongly support a funding structure which allocated funds to Hubs separate from that which is allocated for Chapters and User groups.  We are concerned that putting us in a position of direct competition would have the following effects:

• Putting Hubs in the position of competing with those organisations which we are specifically looking to support, therefore decreasing the effectiveness of said support and collaboration.  
• Increasing the potential of COI for those involved both with Hubs and with a local chapter or user group.

Sara Thomas (WMUK) (talk) 13:42, 24 August 2026 (UTC)

Feedback from Projeto Mais Teoria da História na Wiki

On behalf of Projeto Mais Teoria da História na Wiki, I thank the Wikimedia Foundation for the time and effort invested in developing the proposal to update the ecosystem of Wikimedia organizations. We agree that establishing clear affiliation guidelines and expectations for affiliates is an important step toward strengthening the community and expanding its impact.

After consulting with our internal team and our community, we would like to highlight a few points that, in our view, should be reconsidered. In particular, we believe that implementing the current proposal would bring risks that warrant more careful assessment. Such risks stem both from the required changes in how teams and groups plan, carry out, and measure the impact of their activities, and from the likely exclusion of projects and initiatives that have long contributed to the Wikimedia Movement.

Impact on non-affiliated groups

By conditioning the main funding opportunities on formal recognition by the Wikimedia Foundation, the current proposal threatens the future of non-affiliated groups with significant regional, linguistic, and thematic relevance. This would affect our project directly.

Despite lacking official affiliation status, Projeto Mais Teoria da História na Wiki has regularly received General Support Fund grants since 2022. In 2026, we started our first multi-year grant, which runs through December 2028. The total amount awarded to the project this year was US$49,246. From the very beginning, we have built a broad and meaningful community, in partnership with several other on-wiki and off-wiki initiatives (see the data and reports available on our Meta-Wiki page). It is worth noting that our work focuses on topics and demographic groups that are underrepresented in the Wikimedia Movement, centering on areas such as gender, sexualities, and ethnic-racial issues. This emphasis is reflected both in the content we address and in the profile of the editors whose integration into the Wikimedia Movement we seek to foster. Our deep engagement with education, particularly at the university level, means that our impact is not always adequately captured by metrics. The outcomes of our activities include qualitative dimensions such as raising awareness of how Wikimedia platforms work among audiences that are sometimes reluctant to engage with them, and the gradual training of educators so that they can go on to develop their own initiatives independently.

Under the terms of the proposal, the only funding option available to us going forward would be the Rapid Funds, which are incompatible with our current structure. This form of sporadic funding, capped at US$10,000 per request, would jeopardize the livelihood of our ongoing team and make some of our long-term activities unfeasible, such as supporting activities organized by university professors. Put bluntly and pragmatically, this would represent a waste of the resources invested in our initiative since 2022. We have worked not only on organizing activities focused on creating and editing content on Wikimedia platforms, but, above all, on building a team capable of supporting members of our community as they develop their own projects.

This problem could potentially be mitigated by our intention to seek recognition as a User Group, which we have not yet been able to pursue because the acceptance of new applications has long been suspended. Even if we obtain this status, however, we would be limited to the Project Fund, a new funding modality whose features remain unclear. While this would offer a funding ceiling (US$100,000 per year) that exceeds what we currently receive, it would limit our long-term planning and our ability to sustain the team. Since the multi-year funding option is restricted to recognized chapters and thematic organizations, the Project Fund would require the team to prepare and write a new funding application every year. This runs counter to the favorable assessment we received in the last funding cycle, the effects of which we have already noticed, especially in our ability to develop more ambitious actions. We conceived this three-year period as a continuous, rising strategic trajectory: first, the consolidation of the networks we have established (2026), then the expansion and strengthening of our community (2027), culminating in the broader recognition and institutionalization of the community, as well as its internationalization (2028). This kind of vision, which goes beyond the immediacy of a single year, would become unfeasible under the current proposal.

The new funding criteria thus discourage non-affiliated groups seeking greater reach, since long-term planning and the availability of resources are preconditions for cohesive organizational development and sustainable growth. We take our own case as an example, but we know the same applies to many other significant groups within the Wikimedia ecosystem, such as Wikimedistas de la Universidad Nacional de La Plata (one of the initiatives most similar to ours in the Latin American and Caribbean region, given its ties to academic environments and the fact that it received a multi-year grant), Wiki Editoras Lx, and Foto.Wiki.Br. We believe that the dismantling of these initiatives would be deeply harmful to the Wikimedia Movement, not least because it would compromise its ability to uphold the values of diversity and inclusion.

Uncertainty regarding affiliation prospects

Regarding the affiliation process, we would also ask: did the proposal take into account the high demand that AffCom would face in a scenario where various initiatives are forced to apply for affiliation in order to obtain adequate funding? The process as it currently stands is already long, bureaucratic, and uncertain. With increased demand, this situation could worsen.

As noted in previous comments, another concern is the requirement that only one group focused on a given theme may operate in a given territory. This could unduly hinder the approval of applications by AffCom and, once again, harm initiatives aimed at equity and inclusion. Groups whose work overlaps in some respects may reach and attract different audiences, whether because of their language or because of the structure of their activities. Each group has its own calendar and undertakes specific actions, offering different opportunities for collaboration and contribution to the Wikimedia community. When it comes to marginalized or underrepresented geographic, linguistic, and thematic contexts, choosing one group over another for affiliation or funding could have an especially negative impact.

Consider the example of Wikimedistas de la Universidad Nacional de La Plata and Projeto Mais Teoria da História na Wiki, two groups that would be significantly affected by the new proposal. Both serve as intermediaries between academic environments and the Wikimedia community. There is a thematic overlap, but not a geographic or linguistic one. While WikiUNLP works across a wide variety of fields of knowledge, we focus on the humanities. At the same time, the nature of our activities differs considerably: the Argentine initiative prioritizes edit-a-thons and workshops, while our main focus is on training new editors and using Wikimedia projects as teaching and learning tools.

How does the ecosystem update proposal seek to improve the affiliation process while also taking into account overlaps and differences in activities, without harming high-impact groups?

Use of the Event Registration tool

Another issue that raises questions is the requirement that groups seeking funding adopt the Event Registration tool. In line with many of the responses shared here, we believe this decision would constrain groups and teams.

We understand that the Foundation needs access to standardized metrics so that it can observe, compare, and assess the impact of different groups' work within our community. However, making the use of the Event Registration tool mandatory forces groups like Projeto Mais Teoria da História na Wiki to abandon feedback-gathering practices, both qualitative and quantitative, that they have built and refined over time. This could require us to reorganize, almost from scratch, mechanisms for internally evaluating activities that have already been tested and proven effective.

The Event Registration tool does not capture all the qualitative dimensions of impact we rely on to rethink and improve our actions, and it also reduces our ability to assess audience reception. This requirement would hinder, in particular, the evaluation of contributions from specific activities that do not fit the platform.

Based on our experience as a project team, we believe that, before making the use of a specific tool mandatory, it would be important to clearly define the metrics expected by the Wikimedia Foundation. This would allow each initiative to take its specific context into account when establishing the set of tools best suited to achieving those results, without limiting or discarding the strategies already used by the teams.

On behalf of Projeto Mais Teoria da História na Wiki, its team, and its community, Ana Vitória Farion (Projeto Mais+) (talk) 16:27, 30 September 2026 (UTC)