Wikidata talk:Property creation

For previous discussions, see Wikidata talk:Property creators.

Tackling the backlog

I have made a suggestion at Wikidata:Project chat#Why haven't new properties been created since Monday? on something we could do to improve the speed of property creation. You are invited to comment! — Martin (MSGJ · talk) 07:27, 23 January 2022 (UTC)

Require at least 3 support votes for property creation

Moved from Wikidata talk:Property creators

Lately I've seen properties being created with only 1 support vote. I think this is too-little for property creation. We should require at least 3 in order to guarantee the property is needed and useful. Imagine if a property like of (P642) was created with 1 support vote. That would be pretty bad. Lectrician1 (talk) 01:24, 23 January 2024 (UTC)

For a external-id property I think that one support is ok. For the other type, I will be ok for the one week and 3 supports threshold. Fralambert (talk) 01:36, 23 January 2024 (UTC)

•  Support A minimum requirement is a good idea in my opinion. A property must be useful for the community, not by a single person. So, I agree with the idea of waiting for at least a week and 3 support votes. --Luca.favorido (talk) 06:04, 23 January 2024 (UTC)

 Support, fully agree with the proposal and three votes should be enough imo. Sjoerd de Bruin (talk) 07:49, 23 January 2024 (UTC)

 Support only for data types other than external-id. Midleading (talk) 17:27, 23 January 2024 (UTC)

• I agree with Fralambert, it's not a problem that properties for IDs are created with only one supporting vote and it can be difficult for a proposal to get noticed and get votes so I don't think we should raise the bar for IDs. I do however agree that the bar should be somewhat higher for generic properties, 3 supporting votes sounds ok. Infrastruktur (talk) 18:23, 23 January 2024 (UTC)

I would say something along the lines of "At least three votes of autoconfirmed users or one property creator who isn't the person who proposed the property or the person who created it. ChristianKl ❪✉❫ 22:32, 23 January 2024 (UTC)

 Oppose for external-id property and  Neutral for non-external-id property: this may encourage users to close ill-attended property proposals with potentials. "For a external-id property I think that one support is ok" - how to deal with proposals like Wikidata:Property proposal/Barnivore ID? some proposals may be in a niche topic that is understandable by few people. See Wikidata:Project_chat/Archive/2023/01#Is_no_quorum_valid_reason_for_closing_property_proposals?--GZWDer (talk) 15:09, 24 January 2024 (UTC)

I understand that some proposals might be in a niche topic, but that doesn't mean they wouldn't be understandable to people outside of that topic. Wikidata:Property proposal/Barnivore ID doesn't even have a description so I wouldn't expect it to receive attention.

This proposed requirement could also possibly improve the quality of property proposals as proposers would need to meet a standard of quality in order to ensure their proposal receives enough support and passes. Lectrician1 (talk) 15:21, 24 January 2024 (UTC)

Yeah, but property creators should point out the issues in order to encourage proposers to improve their property proposals (or even try to improve them themselves, since nobody owns proposals), instead of closing them as not done, which will disappoint the proposer. GZWDer (talk) 15:38, 24 January 2024 (UTC)

I don't think that is the problem we're trying to tackle here. It's about how easy it can be to have a property added without wide community support which might end up not being used. Sjoerd de Bruin (talk) 15:43, 24 January 2024 (UTC)

For ID, this is less a concern (as long as the ID is mostly stable and the website contains something meaningful). For non-ID, the major concern is (1) can the information be expressed using other properties? and (2) why is it better than other potential way (such as existing properties, if point 1 is true, and competing proposals) to express the same information? and instead of requiring specific number of votes, this should be something proerty creator more focused on. Note thing may obvious until they are being used. If Wikidata does not have of (P642) and no one propose an alternative proposal, it will be created, but issues will be arisen once it is being used (which can be handled and does not mean the original decision is bad). Anyway I am not a fan of number of vote (more than one) based criterion, since property proposal is not a vote, but a discussion. GZWDer (talk) 16:03, 24 January 2024 (UTC)

Some other users may think properties not being used is a concern, but I don't think so (as long as the property is potentially useful and non-redundant). Being misused is a concern, and that is why I think we should focus on discussing pros and cons of potential alternative proposals; Simply requiring a specific number of votes does not solve it. Note property proposal does not solve all misusage issue, as property may be used or changed in unexpected ways after creation.--GZWDer (talk) 16:26, 24 January 2024 (UTC)

•  Support Per Luca.favorido --DannyS712 (talk) 17:13, 24 January 2024 (UTC)
•  Oppose No need to add rules here. Are there any examples where it would have mattered? It seems standard practice not to create properties with little feedback. And of (P642) was created with exactly three support votes, so it wouldn’t necessarily help. Karl Oblique (talk) 13:30, 25 January 2024 (UTC)

I remember one proposal I was involved with, where I considered the modelling could be done in a better way, which I suggested. The proposal ended up more or less abandoned. Which is a shame, because the proposal was essentially fine, just not as "optimal" as I would have liked.

I'm not a fan of "design by committee". It seems a better way to handle proposals for properties (that are not IDs) would be to split the process in two, the first stage where people vote on whether they want to be able to model the thing in question and a second stage where the modelling is decided. I'm happy if the latter part is left to people who ostensibly have good taste when it comes to modelling data. Infrastruktur (talk) 17:41, 25 January 2024 (UTC)

•  Oppose Three is too high as a hard rule. And do oppose votes cancel out support? In any case, if there's exactly one support vote, then the proposer, the supporter, and another distinct person either setting status to "ready" or actually creating it is indeed 3 separate people judging that a property should be created, so I think we generally meet the standard of 3 involved people one way or another as long as there's at least one support vote. I do agree with other comments here that the criterion is lower for identifier properties (but still at least 1 support vote by somebody other than the proposer). For properties with other data-types, and particularly entity (item, property, lexeme etc.) datatypes which have a structural impact, I'd hope for a stronger showing of support before creation. Also note that some properties are discussed elsewhere (for example in RFC's) and so the level of support might not show directly on the proposal page. In any case I'm opposed to a hard-and-fast rule on this, if the threshold is more than 1 support vote. ArthurPSmith (talk) 19:05, 26 January 2024 (UTC)

  Meh, we need to differentiate properties that will potentially replace or duplicate existing property such as Wikidata:Property proposal/event arguments and types, which definitely requires a higher level of support. GZWDer (talk) 08:44, 28 January 2024 (UTC)