Jump to content

Wikidata:Requests for comment/Notability policy reform

From Wikidata

Wikidata’s current Notability Policy has been drafted in 2013. Since then, the project has grown and the world changed. We understand Wikidata, what it can do and what its place in the Linked Open Data web is, better. All of this led to discussions about what data should be in Wikidata, what should be in the larger Wikibase Ecosystem and what should maybe go somewhere else entirely. This RfC is meant to gather input for an improved Notability Policy. In a first round it will gather input on a number of questions, which will guide the drafting of the new policy.

Context

[edit]

What has changed since the initial drafting of the policy

[edit]
  • Wikidata has grown to 120 Million Items and 16.000 active editors
  • Wikidata has reached social and technical scaling issues (see Wikidata:Requests for comment/Mass-editing policy#Context for additional information)
  • The Wikibase Ecosystem has matured, with Wikibase Cloud and Wikibase Suite now being viable alternatives for hosting knowledge graphs that are tightly interconnected with Wikidata

What can we learn from other projects

[edit]

Looking at other Notability Policies of other Wikimedia Projects, a few things stood out that we might want to take into account:

  • Wikimedia Commons: It clearly calls out the aim of Commons to ground the policy. It also specifically mentions some content not being a good fit for Commons because there are other projects that handle it. It talks very clearly about requiring use of the files or at the very least requires files to be realistically useful for educational purposes.
  • German-language Wikipedia: It has de:Wikipedia:Relevanzcheck where people can ask before creating a new article if it would meet notability criteria.
  • There is a general theme of requiring reliable, independent, secondary sources.
  • There are projects that define notability generally for all topics (like Wikidata does now), while others go deeper into specific notability criteria for specific topics.

The benefits and problems of the current policy

[edit]

Based on previous discussions there are a number of positive and negative points to the current policy.

Benefits:

  • Small number of criteria: makes it easier to understand and to remember
  • Wiggle-room for marginalized knowledge and more: There is benefit to the current vagueness. It gives admins room to make judgement calls.

Problems:

  • Differing interpretations of criteria 2: Some people see it as a card blanche (everything can have an Item); others interpret it much more strictly. Admins report not being able to be consistent even within their own decisions. It is also harder to objectively evaluate than criteria 1 and 3.
  • Level of consideration is mismatched: The policy works at the level of individual Items but issues are also (even more so) caused by collection of Items even if every individual one of them is notable. We don’t have good ways to draw boundaries about what from a class we want in Wikidata and what we don’t.
  • Enforcement burden: Admins spend a lot of time arguing over the interpretation of and enforcing the policy. People not acting in the best interest of the project create Items to promote themselves, their business, etc, causing more clean-up work for admins.
  • Detachment from reuse: Reuse is not really considered in the criteria but reuse is at the core of what Wikidata is about. Additionally, Items get deleted as not notable despite being used in other projects.

Questions to determine changes to current policy

[edit]

Following are a number of questions that need your input to help draft the new policy.

We should require reuse or at least the very real potential for reuse

[edit]

Votes and comments:

Take-away for policy drafting:

  • While reuse is a desirable outcome, a serious evaluation of an actual or potential reuse for each item seems like too much to ask to editors. Maybe there is no reuse case yet for some items, but this opportunity could arrive in the future. This requirement can limit the not-yet-imaged possibilities, and that’s not as desirable.Mariana Fossatti (WK?) (talk) 16:56, 23 January 2026 (UTC)[reply]
@Mariana Fossatti (WK?): Please use the standard ~~~~ signature so that your comments have a timestamp and the reply link. ArthurPSmith (talk) 18:09, 23 January 2026 (UTC)[reply]

We should consider the size of the complete data set when making decisions about individual Items

[edit]

Votes and comments:

  • I think this is intended for cases like "all known stars" or "all the scientific articles ever published", which presently could not go into Wikidata at least for technical reasons; in this sense, I think it makes sense considering this criterium in a future change of the notability policy; however, an item could be considered part of many different datasets, each of a different size (like, for a scientif article: all the articles published in the same volume, or in all the volumes of the same journal, or in all the volumes of the journals treating this topic in language X, or in all journals treating this topic in all languages etc.), so we should be very careful on applying this IMHO. --Epìdosis 18:14, 30 December 2025 (UTC)[reply]
I think you have a point here, but I don't think the carefulness is a hindrance. We just need to be explicit about which set we are talking about and be clear that we don't fall into a scope creep. Ainali (talk) 10:02, 31 December 2025 (UTC)[reply]
  • I think this clause related (somehow) to the reusability clause above. One issue popped in my mind is "when theres only a subset of the data in the Wikidata, what will persuade us to use that instead the complete data in its original source? Does Wikidata will serve as 'short preview' to the complete data set?" but I do agree  Support if we must consider the size of data. —Yamato Shiya大和 士也 (Talk • Contribs) 12:16, 31 December 2025 (UTC)[reply]
  •  Oppose We should fix the wikibase-backend to scale as the community wants instead of limiting creation of new items. See Wikidata:Requests_for_comment/Notability_policy_reform#Is_there_anything_we_missed? below for details about the work on a new wikibase-backend that scales beyond 1bn+ entities.--So9q (talk) 22:29, 1 January 2026 (UTC)[reply]
     Support I agee. Given the current policy lasted over 10 years, making decisions over this scale based on current capacity limitations is the wrong reason. GrimRob (talk) 18:08, 30 January 2026 (UTC)[reply]
  •  Comment I think this is somewhat redundant - the word 'notability' implies that the entity in question stands out from others of its type in some way or other. So inclusion can't be just accepted based on being a member of a (very large) group, there must be some narrower criteria involved. Perhaps the notability text should say something like "member of a reasonably sized class, not one of billions"? ArthurPSmith (talk) 16:48, 3 January 2026 (UTC)[reply]
    I think WD has a clear goal to be comprehensive, more so than an encyclopedia, and we'd not want to use a notability argument to cherry pick members of a class, when the minor members have a structural need to complete the set. But its completeness based on extending current data sideways, so we can say to users that we can only accommodate 200m items with current technology, and our roadmap to that anticipates your item won't make the cut. The problem is our uneven coverage of knowledge, to be hard-nosed we should offload swathes of items already in the system to other projects, but that's technically and socially difficult, and until then someone can always say "but you let X in, why not my Y". And while we can rank notability within a field, its much harder across fields. Our graph system is best for spotty, complicated data sets, uniform ones like stars catalogues are better elsewhere. Vicarage (talk) 19:35, 3 January 2026 (UTC)[reply]
  •  Oppose Jerimee (talk) 20:11, 15 January 2026 (UTC)[reply]

Take-away for policy drafting:

  • This should be carefully considered in light of Wikidata's scope and main goals. One of them is to serve as a general knowledge base, and currently, this is one of the most critical aspects of Wikidata, since the extensive use made by third-party apps and AI models. A general database in which items are highly curated in order to keep only “notable” items from a data set faces the risk of determining an exclusionary selection with potential biases. The risk is greater than on Wikipedia (where this dynamic already exists and creates well-documented biases). An incomplete database can lead to even more biases when it is reused for research and other purposes. Furthermore, bias can spread beyond Wikidata to study results, apps, and more. P.S Lydia Pintscher (WMDE) I know that I'm coming late to the discussion. I'm responding in general to the answers, not directly to your take-away comments (which I really appreciate to read). Mariana Fossatti (WK?) (talk) 17:05, 23 January 2026 (UTC)[reply]

We should change the wording of criteria 2 to say “can be described” to “is described”

[edit]

Votes and comments:

Take-away for policy drafting:

  • Further clarification is needed for this proposal. What is suggested as a small change in wording seems to play a major role in solving an important problem. But what are we solving for? Why is this wording the required solution? In any case, some proposals previously shared, such as limiting notability only to items that have identifiers, will narrow Wikidata scope drastically, putting at risk the capacity of editors to cover marginalized topics. Often, editors who cover such topics can’t find the item's external IDs in mainstream databases, and many identifier properties, especially from Global South institutions, are not yet available on Wikidata. Also, in order to make good descriptions in marginalized topics, we have to navigate across invisibilized, fragile and fragmented sources that are spread across multiple materials. It is fair –and important– to ask for references, but it is also important to admit items with essential statements based on initial research, keeping them open to further improvement. We can do better in signaling where more references and maintenance are needed, in order to refine and improve the existing data (automation could be helpful here). Mariana Fossatti (WK?) (talk) 17:07, 23 January 2026 (UTC)[reply]

Accompanying text: We should require new Items to have at least the statements required to establish notability

[edit]

Votes and comments:

  • Harsh given we have so many items already that don't have that. And in a world of bots and AI, many items might be created in anticipation of waves of bot updates that could be some time away. Scurrying around at creation to find mentions elsewhere would encourage random facts being added, like references being to obscure newspaper articles some are so fond of. Better to consistently back-fill across a class from notable sources. Vicarage (talk) 16:56, 30 December 2025 (UTC)[reply]
  • I agree with Vicarage that this could backfire, but IMHO the pros are more than the cons: after an item has been created, and some time has passed (say one day), the creator should have added to it sufficient data to demonstrate that it is notable. --Epìdosis 18:22, 30 December 2025 (UTC)[reply]
  •  Support But, admins should not delete empty items minutes after they are created (time should be given for the creator to fill the item). Ternera (talk) 19:30, 30 December 2025 (UTC)[reply]
    Agreed. For what it's worth, English Wikipedia's New Page Patrollers are required to wait until an hour after a page has been created before nominating something for deletion unless there are serious content issues, like BLP privacy issues. Perhaps something similar would make sense here. Mcampany (talk) 03:07, 31 December 2025 (UTC)[reply]
    I feel that it is reasonable to expect editors to add a claim within fifteen minutes of item creation, but I normally do not delete empty items until an hour after the last edit. Bovlb (talk) 03:34, 31 December 2025 (UTC)[reply]
    Agreed. 1h is reasonable. So9q (talk) 22:32, 1 January 2026 (UTC)[reply]
  •  Support with the caveat about reasonable time for item enrichment. I find the argument against weak, as empty items are even more of a burden than someone at least trying to add relevant links. (People acting in bad faith is a totally different thing and is a pest regardless if they are creating empty items or adding statements to them.) Ainali (talk) 10:06, 31 December 2025 (UTC)[reply]
  • As a counter example there were 294 Flower-class corvette (Q404394) produced, collectively they won the Battle of the Atlantic, I have created entries for 290odd of them. The class is widely described, but generally collates the members, with individuals featured in random scattering of articles across Wikipedias and other naval sites, but I'd struggle to find a source that mentions them all. There is a structural need to have articles on the class and all its members, but it would be frustrating if when adding the last few members they were challenged because of poor documentation. If WD is to be comprehensive, it is inevitable it might contain results that were merely entries in lists elsewhere, and so not amenable to formal property assignment. I suppose a line in a table in a URL could be used as a reference or qualifier to a instance of (P31) statement, but it feels clumsy. Vicarage (talk) 10:27, 31 December 2025 (UTC)[reply]
  •  Support And we should have a uniform way of reminding users of this requirement. --Matěj Suchánek (talk) 11:38, 2 January 2026 (UTC)[reply]
  •  Strong support This is a very important requirement. I don't see any problems with this as long as we give enough time to add the statements. --Yuriklim (talk) 12:40, 2 January 2026 (UTC)[reply]
  •  Support Sure, with a reasonable time allowed to get those statements in. ArthurPSmith (talk) 16:50, 3 January 2026 (UTC)[reply]
  •  Comment Not just statements. Sitelinks are also very important. It is completely acceptable to have an item with nothing but a sitelink. Midleading (talk) 17:13, 7 January 2026 (UTC)[reply]
  •  Weak support The new item should have at minimum an instance of (P31) or subclass of (P279) with at least one suitable reference that establishes notability. This should be enforced at item creation. Piecesofuk (talk) 10:42, 9 January 2026 (UTC)[reply]
  •  Support Easy improvement. --Lymantria (talk) 10:17, 12 January 2026 (UTC)[reply]
  •  Weak support I agree with many of the caveats above. Jerimee (talk) 20:19, 15 January 2026 (UTC)[reply]
  • Comment: In theory I like the idea, but in practise what would this actually mean?StarTrekker (talk) 09:07, 16 January 2026 (UTC)[reply]
  •  Comment I very much endorse Mariana Fossatti's comment below: we need flexibility and leeway for underrepresented knowledge, for those communities that haven't had and don't have the privileges and resources to create or maintain sources in the first place. It would also be extremely helpful if it would be made easier and more transparent for beginners how they should do this in practice (i.e. what kind of statements are needed as a minimum; what one typically fills in, etc) Spinster 💬 07:39, 27 January 2026 (UTC)[reply]

Take-away for policy drafting:

  • What would these statements be? Who would decide? These decisions are usually not made by marginalized communities that often see their knowledge erased. It is completely reasonable to require that the item have enough statements to be recognized and distinguished from another item. And for sure, empty and barely outlined items, impossible for other users to understand and improve, can simply be removed. But introducing notability checkings at the level of required statements can exclude things we don’t want to exclude from Wikidata, and could create a lot of work in order to establish and assess the particular notability criteria for every knowledge domain. Automated statement suggestions, or tools to signal missing statements, are better routes for the improvement of Wikidata. Existing tools, like Recoin, are already helpful for this and could be expanded. Mariana Fossatti (WK?) (talk) 17:09, 23 January 2026 (UTC)[reply]

Accompanying text: We should give the Wikibase Ecosystem a more prominent place in the text to explain alternatives to adding data to Wikidata outside the notability criteria

[edit]

Votes and comments:

Take-away for policy drafting:

  • The Wikibase ecosystem should not be seen as a repository for the unwanted items. Instead, we should explain its potential to create alternative ontologies and different ways of modeling data for specific needs. It’s great to make Wikibase more prominent and publicize it, not to show to potential editors the Wikidata exit door, but to make them aware about even more exciting possibilities if they want more customization and control over how to collect and organize data communities. Mariana Fossatti (WK?) (talk) 17:10, 23 January 2026 (UTC)[reply]

Accompanying text: We should encourage people to flesh out and improve existing Items over adding a lot of new Items

[edit]

Votes and comments:

Take-away for policy drafting:

  • Encouraging improvements is always good. However, this path should not make it more difficult to create new items. Both the creation and improvement of items should be equally welcome. Nevertheless, it would be great to make it easier to use tools to improve and maintain items. The Wikipedia home page is a good example of this, as it invites editors to make small improvements. This is an opportunity for new editors to gain experience. Mariana Fossatti (WK?) (talk) 17:12, 23 January 2026 (UTC)[reply]

Accompanying text: We should make it explicit that people should not create Items about themselves, their business, etc

[edit]

Votes and comments:

Take-away for policy drafting:

It would be very regrettable if this precluded the authors of scholarly works, or their publishers or employing institutes, from creating items about their works. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:17, 23 January 2026 (UTC)[reply]
  • As long as the article has serious references, creating articles about people's identities or activities does not seem to be a major problem. At least, not to the extent that it is a problem on Wikipedia, where editors who write about themselves can introduce serious biases and imbalances into the article's narrative. The structured nature of Wikidata is less vulnerable (not immune) to the introduction of distorted narratives. Mariana Fossatti (WK?) (talk) 17:14, 23 January 2026 (UTC)[reply]
  • I am late to this discussion, so thanks to Lydia for allowing me a chance to add a comment. I'll disclose that I do communications consulting work on Wikipedia and occasionally on Wikidata, so the matter is of professional interest to me.
My suggestion is that Notability and conflict of interest (COI) are worth considering separately: Notability is about scope; COI is about process. An item either is within scope or it is not, and the identity of who created it should not be a determining factor. Otherwise, we have an arbitrary standard that is exceedingly difficult to enforce. Instead, it's better to focus on requiring disclosure and third-party sources.
I also agree with Mariana that Wikidata is inherently less vulnerable to promotional manipulation: Wikipedia can be subtly promotional through word choice, framing, and emphasis, while Wikidata's structured property-value pairs are more constrained (a statement like Company X → headquarters → City Y is either accurate and sourced or it isn't).
Rather than entangling the two concepts, where COI is concerned I would suggest Wikidata look to how Wikipedia has handled this issue (see: WP:PSCOI) and revisit the RfC about COI from 2015, as well as review the existing policy Wikidata:Disclosure of paid editing and user essay Wikidata:Self-promotion to address this subject with greater care. WWB Too (talk) 21:59, 27 January 2026 (UTC)[reply]
  • In some Wikimedia projects it is allowed to edit COI content as far as it is acknowledged (=white hat editing). So if they create, say a notable Wikipedia article, why couldn't they add the Wikidata item too? Or add a new item for an old Wikipedia article? The statement was about "creating", not "editing". Was it intentional? I'm sure that if the paid/COI Wikidata editing is forbidden, there will be black hat editors. (I'm a paid editor myself which I've disclosed here). Take a look at how new Wikimedia Commons files are added - what kind of things are asked from the downloader.--Jjanhone (talk) 20:02, 2 February 2026 (UTC)[reply]
[edit]

Votes and comments:

Take-away for policy drafting:

Accompanying text: We should encourage people to ask if they are unsure if the Item they want to create is notable, especially if they want to create a lot of new Items.

[edit]

Votes and comments:

  •  Support but where? I would guess a subpage of Wikidata:Notability, like Wikidata:Notability/Questions; please not directly in the Project chat to avoid flooding it even more. --Epìdosis 18:30, 30 December 2025 (UTC)[reply]
  •  Support but are we prepared to answer them promptly? Unlike Relevanzcheck in dewiki, Relevance Check in WIkidata could be flooded in minutes. I think we need to limit the check to item that related to series or datasets, or generational data. I suggest we make something like basic checklist for notability criteria, yet how do we limit the interpretation? —Yamato Shiya大和 士也 (Talk • Contribs) 12:22, 31 December 2025 (UTC)[reply]
    Yeah we probably don't want people asking about every single Item. But if they are doing larger sets etc I think it'd be good to make it as easy as we can to get a check on them before creation instead of cleaning up afterwards. Lydia Pintscher (WMDE) (talk) 15:12, 8 January 2026 (UTC)[reply]
  •  Support Sometimes I wish Wikidata had a centralized “big document” that clearly explains what kinds of data are currently allowed to be entered, specifically what “niches” exist, along with a “model item (P5869)” for each niche. For example: humans, books, stars, species, sports clubs, historical events, wars, accidents, disasters, diseases, anatomical structures, and so on. Ideally, this document would also allow users to revise it by proposing new kinds of data they want to add to Wikidata, perhaps while streamlining the process of proposing the important properties required so that such data can be properly integrated into the Wikidata ecosystem. With this approach, Wikidata would not be built by endlessly adding new properties, but by developing it niche by niche as the smallest “working unit”. For instance, a region is sometimes well known for specializing in producing “something”, whether natural resources or a concentration of a specific industry producing particular goods. People might want to add this connection to Wikidata, such as region X being known for producing apples, while region Y is known for producing movies. Instead of guessing which property to use to add this relationship, they could consult this “big document” to see whether the current Wikidata model already supports such a relationship, and if not, propose it. I imagine this would require an “active duty” maintainer of the document who has a strong understanding of the current Wikidata ontology and can respond to new proposals and questions. Niryhpr (talk) 09:42, 6 January 2026 (UTC)[reply]
  •  Support A separate subpage for these sorts of requests, also for merge requests and maybe a place to ask whether items should be deleted before they're added to WD:RFD Piecesofuk (talk) 10:58, 9 January 2026 (UTC)[reply]
  •  Weak support Only if they want to create hundreds of new item. I worry that policies like this, as gentle and reasonable as they sound, can potentially be a real barrier to entry to conscientious new folks. A potential new user might think to herself "ok, I'm not sure, let me think about it some more" and never come back. Jerimee (talk) 20:38, 15 January 2026 (UTC)[reply]
  •  Support per Piecesofuk. --Wolverène (talk) 08:21, 16 January 2026 (UTC)[reply]

Take-away for policy drafting:

  • It sounds reasonable to offer better orientation for newcomers to Wikidata and also for more long-term users exploring new knowledge domains. Wikiprojects are a great space for that, and would be good to have access to them from the Notability page. For a single item or just a few, guidelines and resources should be enough. For a bulk upload of new items, it would be desirable to get community insights. Mariana Fossatti (WK?) (talk) 17:16, 23 January 2026 (UTC)[reply]

Process: We should only let registered users create Items

[edit]

Votes and comments (see also Wikidata talk:Requests for comment/Mass-editing policy#Restrict entity creation to logged-in users):

Take-away for policy drafting:

  • I will not incorporate it into the policy draft. I will do some more research with the developers to see what we can do about throttling the creation of new Items by new accounts while not breaking Item creation from Wikipedia and co. Lydia Pintscher (WMDE) (talk) 11:27, 23 January 2026 (UTC)[reply]
  •  Oppose Attribution of edits is now managed with temporary accounts across Wikimedia projects, in order to mitigate privacy concerns. Let’s continue with this general privacy-friendly Wikimedia approach, especially to protect those who need a safer edit environment. Mariana Fossatti (WK?) (talk) 17:18, 23 January 2026 (UTC)[reply]

Process: We should take the intent of the Item creator into account when making decisions about notability

[edit]

Example: Someone gaming the system by creating several Items and connecting them in order to fulfil notability criteria 3, even if the Items would otherwise not be notable

Votes and comments:

  • Establishing intent could become so bureaucratic. Assume good faith for members in good standing. Do we record statistics of how many items each user had has deleted, to trigger different levels of oversight? Vicarage (talk) 16:47, 30 December 2025 (UTC)[reply]
  • the intent of this is good, but it could also be difficult to apply, as Vicarage says; anyway, probably we should probably try to enlarge a bit "structural need" in order to make it more difficult to game it. --Epìdosis 18:35, 30 December 2025 (UTC)[reply]
  •  Oppose If someone creates multiple items or redirects the same item to itself, we can already check that and delete/unlink all of the items. Checking their intent seems like a lot of unnecessary work. Ternera (talk) 19:35, 30 December 2025 (UTC)[reply]
  • This seems to conflate two points.
    • While it is often easy to classify a contribution as promotional, we should avoid going down the path of mind reading and doxxing.
    • We routinely bulk delete groups of items that connect to each other, as not a valid case of N3, but it is harder to investigate. Bovlb (talk) 20:08, 30 December 2025 (UTC)[reply]
  • I support the idea of this, but am not sure how we implement this in a good way. Perhaps this kid of gaming can be mentioned as an example of bad faith editing? Ainali (talk) 10:34, 31 December 2025 (UTC)[reply]
  •  Support Like Ainali, I support the idea of this, but am not sure how we might implement it. Jerimee (talk) 20:46, 15 January 2026 (UTC)[reply]

Take-away for policy drafting:

Process: We should let WikiProjects narrow down (but not expand) the general notability guidelines for their area

[edit]

Votes and comments:

  • Notability so depends on the specifics and data volumes a project is designed for, and seeking agreement could stultify things, so let each project have its own criteria. Vicarage (talk) 16:43, 30 December 2025 (UTC)[reply]
  • I would specify some minimal criteria for notability criteria established by specific WikiProjects, specifically: they should be easy to find (i.e. at least all linked from one place), easy to read (some kind of standard structure), and they should be established by at least 10 users (to avoid important decisions being taken by too few users). I agree that these thematic guidelines by WikiProjects should be only restrictive in comparison with the general ones. --Epìdosis 18:39, 30 December 2025 (UTC)[reply]
  •  Support I think this is a great idea, but I think we need to figure out a way to be able to point from the general criteria to WikiProjects that have found consensus for narrower ones in their field. (We don't want to spring this as a surprise on someone who went to the general page and read it.) Ainali (talk) 10:45, 31 December 2025 (UTC)[reply]
  • We should be wary of letting one wikiproject declare that something is not notable, when another wikiproject considers that it is. Conversely, we should be wary of a wikiproject existing just to declare that everything in a given field (Wikiproject SEO Experts? WikiProject YouTube Influencers?) is notable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:02, 31 December 2025 (UTC)[reply]
    • The point of multiple WikiProject viewpoints are a good one. And I think that it can be solved by not allowing a WikiProject restrict another one. That is, if one WikiProject finds some type of concept notable, but not another, the second WikiProject can abstain from creating items, but not stop the first one. Ainali (talk) 20:01, 31 December 2025 (UTC)[reply]
    • Regarding the point of declaring everything notable, they still shouldn't be able to expand the general notability policy. Ainali (talk) 20:01, 31 December 2025 (UTC)[reply]
  • I have always liked the ideas of WikiProjects, or in general, associations by topics (music, Sweden, influencers, ...) as place to gather all sorts of resources (showcase items, list of properties, do's and dont's, ...). But now I am a little reserved because this could introduce sort of a backdoor to the general policy (i.e., a possibility to overrule what we are trying to reform right now). --Matěj Suchánek (talk) 12:20, 2 January 2026 (UTC)[reply]
    Do you even have this worry if we only allow them to narrow the general criteria? Do you have an example of something that could be problematic? Lydia Pintscher (WMDE) (talk) 15:18, 8 January 2026 (UTC)[reply]
    For example, in far-off foreign lands over there (OpenStreetMap), there are several cases where local-specific groups create and enforce their own local rules that actually contradict the global rules agreed upon earlier. Normal unaffiliated users might get confused by these conflicting rules, but in most cases, local groups enforce them more strictly than the “global police” do, and they can even band together to push back against site-wide moderators. Rtnf (talk) 06:52, 9 January 2026 (UTC)[reply]
    It can still be source of disagreement between admins and regular community members with a field of interest ("we consider this notable regardless"). I'd prefer if we had rules that the whole community agreed upon. Scoped guidelines could be handled by appendices/addenda. --Matěj Suchánek (talk) 10:05, 17 January 2026 (UTC)[reply]
  •  Comment I don't see the need for notability policy expansion. The two benefits listed at The benefits and problems... are truly valuable benefits. Problems should be addressed without sacrificing ease of use. Jerimee (talk) 21:02, 15 January 2026 (UTC)[reply]
  •  Oppose. Sounds like an attempt to implement something for which I would criticize Wikipedia the most -- like the decisions on what is notable made by some certain group of people (who are BTW not experts in their area IRL and not obligated to be), can be more valuable than the general notability policy. No, it is wrong. --Wolverène (talk) 08:56, 16 January 2026 (UTC)[reply]
  •  Oppose Inclined to agree with Wolverène here.StarTrekker (talk) 09:06, 16 January 2026 (UTC)[reply]
  •  Question From what I've gathered from my work here at Wikidata, there are already subject areas with modified notability criteria. As far as I know, schools are considered notable per se. Such per se notability would no longer be possible under these new rules, would it? --Gymnicus (talk) 10:57, 16 January 2026 (UTC)[reply]
  •  Oppose per Wolverène. --Prototyperspective (talk) 18:06, 27 January 2026 (UTC)[reply]
  •  Oppose This would compound systemic bias against minoritised knowledge. — OwenBlacker (talk; please {{ping}} me in replies) 13:55, 2 February 2026 (UTC)[reply]

Take-away for policy drafting:

Other questions and discussion

[edit]

How can we rely more on tooling and automation for notability checking and processing?

[edit]

Do you have additional suggestions for how to tighten/clarify criteria 2?

[edit]

Is there anything we missed?

[edit]
  • When we will discuss the draft of the new notability policy, in the same discussion we will also necessarily have to discuss about the items already existing that will be outside the revised notability criteria, and specifically: 1) how to find them; 2) what to do with them (keep them for some reason; simply delete them; delete them and move them elsewhere [where specifically?]). --Epìdosis 18:42, 30 December 2025 (UTC)[reply]
  • Maybe we should consider somewhere the case of items which met criterium 2 at the time of their creation and does not meet it anymore (i.e. they are based on a reliable online source which has perished in the meanwhile and has not been archived, or only partially); do we want to keep them? Probably not. Cf. Wikidata:External identifiers/Obsolescence (draft) for more context. --Epìdosis 18:54, 30 December 2025 (UTC)[reply]
  • The Wikibase Ecosystem has matured, with Wikibase Cloud and Wikibase Suite now being viable alternatives for hosting knowledge graphs that are tightly interconnected with Wikidata
    Is this based on the needs of the Wikidata community or is it a pipe dream? From what I have understood talking to the Scholia team and knowledge experts this idea about ontologic federation is currently an unknown thing.
    The Scholia team decided to ABANDON WDQS after the graph split of scholarly items because the federation in SPARQL did not work (timeouts, hard to know where the items reside, etc.). I consider the Scholia team to be SPARQL experts and if they can't get it to work I very much doubt anyone else will. Wikibase Suite in it's current state is NOT able to reliably integrate with Wikidata in my opinion. I tried setting up a Wikibase.cloud wiki multiple times and get it integrated, but the federation UX is nowhere to be found.
    My current conclusion is thus: the "ecosystem of connected Wikibases" is not a feasible idea that has gained any mentionable traction. Even if the federated properties + values were to gain adoption it would result in a split of the community and Wikibase Suite does not support RDF streaming so the triples cannot be integrated e.g. by combining multiple streams in a single QLever instance.--So9q (talk) 22:08, 1 January 2026 (UTC)[reply]
  • I don't see scaling Wikibase anywhere above. I recently started to work on wikibase-backend (built using Python, FastAPI) which scales to 1bn+ items and it is as of writing nearing MVP state and already capable of:
    • CRUD entity operations
    • scaling the metadata database to 1bn+ entities (using sharding in Vitess)
    • scaling to 10bn+ revisions (S3 compatible backend based on Ceph)
    • scaling to 1 trillion statements (S3, deduplicated)
    • entity locking and archiving is supported
    • entity redirects are supported
    • full RDF output is supported (98% complete as of today 🥳)
I added cost estimates to the repo and they are looking very promising. The current monolithic Wikidata architecture cannot scale to 10x the current number of revisions. It has reached end of life a number of years ago and neither WMDE nor WMF has done anything about fixing the root cause (band-aids, investigations and disaster plans don't count 😉).
This new backend if finished and implemented may very well be a game-changer for the future of Wikidata and notably not one that break current tools like the "ontological federation" effectively would. It most probably also be easier for the new Wikidata Platform team to operate in a sustainable way compared to the current legacy architecture where manual pooling and installation of servers is needed.--So9q (talk) 22:08, 1 January 2026 (UTC)[reply]
One pattern is to upload photos to Commons, create a category there, and then use the existence of that category to justify a Wikidata item. In some cases, the existence of the Wikidata item is in turn cited on Commons as a reason not to delete the category, creating circular notability between projects.
Another pattern is to create articles (often machine-translated) on smaller Wikipedias. These projects often have limited administrative capacity, and cleanup can take a long time, during which the article’s existence is used to satisfy N1.
These approaches are inexpensive for the creator but time-consuming for communities to resolve.
I’m not sure what the best long-term fix is, but one small improvement might be to change N1.4 by dropping the first word, so that it applies to all items rather than only category items.Bovlb (talk) 16:17, 4 January 2026 (UTC)[reply]
Can't items with a commons category can still be deleted under N1:4? Also, spam articles from small projects can be added to meta:GSR for global sysops to delete if there are no active admins. The request page is closely monitored and spam is deleted within hours usually. Ternera (talk) 03:38, 6 January 2026 (UTC)[reply]
No. Only category items can be deleted under N1.4.
Not all smaller projects are handled by global sysops. There's a middle group of projects that choose to be independent, but unfortunately struggle to handle backlogs. Bovlb (talk) 05:21, 6 January 2026 (UTC)[reply]
  • I see that the reuse criterion does not seem to go through. I do not know myself whether this is good or bad, but probably the most known / the biggest case of reuse is Open Street Map which uses Wikidata to translate all features it shows into many languages (which is important because it uses the native language for every country - I have just been one week in Cairo, and it is difficult to use without fluent command of the Arabic alphabet). We probably should have a position on which entities are important for us and which ones we want to host. Note that the vast majority are not related to self-promotion, though some (like shops) can be.--Ymblanter (talk) 20:24, 5 January 2026 (UTC)[reply]
  • I didn't see any mention of unpatrolled edits. There are now so many unpatrolled new items that even blatant spam or vandalism can survive a month and then just sit there for years until someone stumbles across it. My preference would be for these items to remain tagged as unpatrolled permanently until someone actually checks them. —Xezbeth (talk) 09:48, 6 January 2026 (UTC)[reply]
    I would  Support this. Epìdosis 11:23, 6 January 2026 (UTC)[reply]
    This is a technical limitation that cannot be lifted. But there are bots taking snapshots, like User:Pasleim/notability. --Matěj Suchánek (talk) 19:01, 7 January 2026 (UTC)[reply]
  • How the Wikidata community should assess, assure, and support the notability of editing activities that are part of projects funded by the Wikimedia Foundation. When there is less clear explanation or visibility of the project context, such editing activities may be misinterpreted as spam or non-notable, despite being carried out within an approved project. Example of such happenings are here and here. We should be able to "guide" or "advise" those projects, like how to filter data that are notable enough, or to help them create proper attribute. Usually what happens are only request for deletions or questions of notability in user talks. I think we should enforce that such projects need to have clear plan on the method they used, the data, the source, and perhaps example plan of final result that they want to achieve.Happy New Year 2026!Yamato Shiya大和 士也 (Talk • Contribs) 09:08, 8 January 2026 (UTC)[reply]
  • How Wikidata should allow sufficient wiggle room for items originating from countries or regions with limited access to standardized reference infrastructures, such as Indonesia or other Global South countries. In the absence of widely used authority identifiers or centralized reference systems, for example VIAF, ISNI, national libraries, or the Library of Congress, data that are locally valid in context may still fail to meet Wikidata’s notability criteria, which can affect items such as Indonesian landmarks, for example, religious structures.Happy New Year 2026!Yamato Shiya大和 士也 (Talk • Contribs) 09:08, 8 January 2026 (UTC)[reply]
  • In this and the mass-editing RfC, and the underlying move towards federated Wikibases, I am extremely concerned about knowledge equity, and about the sustainability of underrepresented knowledge. We risk to even further replicate existing biases in knowledge production, to continue to keep communities with less or no resources out of the picture, and to deprioritize knowledge and data that has been left out of the historical record due to structures of power and privilege. How many Wikibases with underrepresented knowledge will still be up and active, will still have resources and critical mass in, say, 10-15 years? Spinster 💬 10:31, 8 January 2026 (UTC)[reply]
  • Barriers to contribution for those who actually have valuable stuff to contribute. In my work (on cultural subjects, even in well-resourced countries), I see all the time that Wikidata is seen as a difficult and high-barrier project to contribute to. The current RfCs risk to result in even more barriers. It would be helpful to focus: create very strict and punitive barriers to those who actually actively undermine Wikimedia goals; and on the other hand aim to become much more welcoming to more contributors who have Wikimedia-aligned knowledge to contribute. Spinster 💬 10:31, 8 January 2026 (UTC)[reply]
  • With the increase of Wikidata items create for solely SEO purposes, we should create an essay to explain Wikidata policies regarding this so admin could just refer to them when deleting items. Happy New Year 2026!Yamato Shiya大和 士也 (Talk • Contribs) 15:24, 8 January 2026 (UTC)[reply]
  • I think this needs to be considered alongside criteria 1 and 3 and also what "serious and publicly available references" means. Also how do changes affect external projects: https://www.wikidata.org/wiki/Wikidata:For_developers/Showcase Integration with Open Street Map https://wiki.openstreetmap.org/wiki/Wikidata and small academic projects like https://www.wikidata.org/wiki/Wikidata:WikiProject_Scotland%27s_Accused_Witches and on focus list of Wikimedia project (P5008) There should also be clarity at other sources of item creation, for example Open Refine, QuickStatements, https://meta.wikimedia.org/wiki/WikiShootMe#Create_new_items and https://mix-n-match.toolforge.org/#/ Piecesofuk (talk) 11:13, 9 January 2026 (UTC)[reply]
  • I think there is a larger impact on GLAM work that I can't see yet in the discussion above: 1) my perspective is that I used to work at a museum in the UK where the collection was catalogued, but there was no online collection and it was very little published. With closer constraints on notability objects it sounds like parts of this collection couldn't be integrated. I imagine this would be an issue for others outside of the UK. 2) I have another concern, which relates to the short-term state of GLAM funding in the UK - say an organisation wanted to do some Wikidata work, and got a 1 year grant to do so, and set up a Wikibase, in my experience once the 1 year post holder is gone it's unlikely that anyone in the organisation would either have the skills or interest to continue. I would strongly question whether this policy change would be sustainable for collaborators. Lajmmoore (talk) 14:19, 27 January 2026 (UTC)[reply]
    & a general point, what happened to wanting to represent the sum of all human knowledge? It feels like this is a contraction of purpose Lajmmoore (talk) 14:21, 27 January 2026 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Requests_for_comment/Notability_policy_reform&oldid=2460158982"