Wikidata:Requests for comment/Clarifying the requirements for property creation

From Wikidata
Jump to navigation Jump to search
An editor has requested the community to provide input on "Clarifying the requirements for property creation" via the Requests for comment (RFC) process. This is the discussion page regarding the issue.

If you have an opinion regarding this issue, feel free to comment below. Thank you!


THIS RFC IS CLOSED. Please do NOT vote nor add comments.

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

This is an easy close tbh. There is no consensus for any of the suggestions. Therefore the current statement remains and property creators should use discretion when considering requests. John F. Lewis (talk) 17:22, 12 May 2014 (UTC)[reply]

The Property Proposal page is again brimming with open proposals and lack of attention, besides it is not always clear when a property creator can create a property. The unclear sentences in the "property creators" page are:

  • Property creators should not create new properties unless consensus exists. The period before a property can be created should be no less than one week.

Proposals[edit]

The proposed modifications (you can support or oppose any or all) are:

Relaxed[edit]

Relaxed - 2 weeks without opposes[edit]

  • Property creators can create any property that has been proposed by anyone if it didn't have opposition during 2 weeks or >75% support after one month.
  •  Oppose Consensus is a non-negotiable requirement, in my opinion.--Jasper Deng (talk) 20:38, 26 April 2014 (UTC)[reply]
  •  Neutral In my opinion, one month without opposes is enough.--GZWDer (talk) 05:06, 27 April 2014 (UTC)[reply]
  •  Support, This makes an opponent at least obliged to make the effort to formulate its opposition. If he is not motivated enough to make a comment, then the creator is right. TomT0m (talk) 12:52, 27 April 2014 (UTC)[reply]
  •  Support, per the silence and consensus principle. The whole property discussion process is about to prevent the creation of unnecessary properties and unless there is someone opposing it there is absolutely no reason not to create it. Waiting for meaningless "{{support}} ~~~~" comments is pretty pointless, in my opinion. Vogone talk 18:34, 27 April 2014 (UTC)[reply]
  •  Support the first part, but  Oppose ">75%". This is discussion, not voting. The last part must be replaced to something like ... or consensus is reached after one month. — Ivan A. Krestinin (talk) 20:04, 27 April 2014 (UTC)[reply]
  •  Support the first part per TomT0m.  Neutral about the second. Thryduulf (talk: local | en.wp | en.wikt) 23:18, 27 April 2014 (UTC)[reply]
  •  Support For the first part  Oppose for the ">75%", because the opponent should debate and not simply vote. --Fralambert (talk) 00:03, 28 April 2014 (UTC)[reply]
  •  Oppose No opposition is not sufficient: we need some support. Snipre (talk) 11:10, 28 April 2014 (UTC)[reply]
    Why ? TomT0m (talk) 15:26, 28 April 2014 (UTC)[reply]
  •  Strong oppose I agree with Snipre, and I recommend taking a look to the archived proposals to get an idea of what properties would get approved under this system. The only thing that this option would do is to increase the opposition to new proposals since now there would be a strong incentive to filter them out, when before the proposal would die out just by ignoring it.--Micru (talk) 11:41, 28 April 2014 (UTC)[reply]
    @Micru: That's nonsense, the proposer has no clue of why his proposal is ignored and it's problem remains unsolved without a comment. Nobody wins, why would someone make another proposal if ha has no clue of what went wrong ? The truth is that we got a ridiculously small number of properties compared to the number of infoboxes parameters. Any clue why ? TomT0m (talk) 15:26, 28 April 2014 (UTC)[reply]
    @TomT0m: Most of the time, some proposals are ignored because there field of application is very reduced, or because they don't awaken the interest of property reviewers. As discussed in other occasions, Wikidata's mission is not to collect *all* data, and *all* identifiers, just the ones that are relevant. How can we say that a property is relevant and that will help to fulfill our mission if it doesn't manage to collect not even a single support? I think that is the real nonsense. In my understanding WD has a ridiculously small number of properties compared to infobox parameters for several reasons: 1) we are acting as a black-box, just sucking data and not worrying about using it on Wikipedias, 2) the technical infrastructure to do that easily is not there yet (one of the blockers for the Visual Editor is this RFC on mediawiki, which takes some time to solve, but there are some more), 3) numbers with units are not there yet, 4) not all data is easily importable/usable because it was not created as structured data. I don't think we ever rejected any property proposal that was meant for importing a field from a Wikipedia template, unless it could be inferred from other properties, so it cannot be said that lowering the property creation requirements will result in more properties for infobox parameters.--Micru (talk) 17:05, 28 April 2014 (UTC)[reply]
    Mmm I don't see how a small field does not deserve the right to get a property. Relevance in not really big numbers ... And this does not change the fact that the proposer deserves an answer. Most voters would simply not knowing what they are talking about or just not interested, which just make their (un)vote not so relevant. Building structured data means beeing able to express the relationship beetween concepts. How does structuring datas in a small field is a problem in that scheme ? If we compare to ubilding infoboxes, people just create infoboxes as they want, they never had to ask support from the whole community. TomT0m (talk) 17:18, 28 April 2014 (UTC)[reply]
    That is like the eternal discussion "why cannot X have a Wikipedia page?" and the answer is always provided by some sort of agreement about what is relevant. Same should happen with properties, we should create properties that are agreed on, and for an agreement to happen you always need more than one opinion.--Micru (talk) 18:25, 28 April 2014 (UTC)[reply]
    @Micru: No it's not. You compare pages creation (= item creation) with infobox parameter creation. The first one is open even on Wikipedia with postmoderation and request for admissibility post creation, the second one is event easier ... Here we have to ask to create an infobox parameter, this is way harder than anything comparable is on Wikipedia. And a total paradigm reversal I don't understand. TomT0m (talk) 18:35, 28 April 2014 (UTC)[reply]
    @TomT0m: We are not talking here about infobox parameter creation either, we are talking about properties that may or may not correspond with an infobox parameter, and as said before, most of the rejected proposals don't have a correspondence within any infobox or template. Maybe we should do that? Have a lighter requirement for parameters that are widely use on Wikipedias and a peer reviewed requirement for proposals that are not being used in any Wikimedia project?--Micru (talk) 18:56, 28 April 2014 (UTC)[reply]
    @Micru: Well, it does not solve the problems in my mind, the problem is that we don't have (enough) peers to review or care in a number of cases and that the proposal stays in the pipe for months. Even some with one approval stays. Whereas in the Infobox case anybody can create simply, even without support, and work. Considering Wikidata is not an infobox and has problems to solve on its own, beeing more powerful, I say we should support inovation, not endlessly search support without being able to do something productive. TomT0m (talk) 19:07, 28 April 2014 (UTC)[reply]
    @TomT0m: Engaging in RfD of properties that were not properly reviewed is also time consuming and it also affects negatively the productivity. I am all in for supporting innovation, and I would make a distinction between properties that are for internal use (any Wikimedia project, including WD) and external identifiers not used yet in any Wikimedia project. For the first I support relaxed creation requirements, but for the second I think it is necessary some peer review.--Micru (talk) 20:05, 28 April 2014 (UTC)[reply]
    @Micru: Relaxed/no opposition seems a good compromise in any case, the property publication is public, there is not so much proposition, with a system where the announces are managed correctly we should not miss any proposition (probably one centralized page with announces of proposals is the way to go to help with that). If somebody has a problem with a property, he just has to leave a message to raise its opposition, really easy, then the discusion is launched, an the proposer can explain himself, or beeing given a solution for his problem. Not really time consuming, just having to put his thought on a message. Otherwise, if anybody did not make the effort to do that, we should leave the proposer doing what he have in mind. TomT0m (talk) 20:36, 28 April 2014 (UTC)[reply]
    @TomT0m: When I look at the archive and I see some of the properties would have been approved under this system, I shiver, so no, I cannot see it as a good compromise. In any case if anyone could manage to do a table like Wikidata:Requests_for_permissions/Bot with extra columns for number of s/o/cmt that would be a real advantadge no matter which system we settle for in the end.--Micru (talk) 21:24, 28 April 2014 (UTC)[reply]
    This does not mean anything, the acceptance condition were different. You or someone else would have opposed if they are so awful if we change the rules. And maybe it would have helped guiding the proposer on what he should have done and we would have a guideline. TomT0m (talk) 21:39, 28 April 2014 (UTC)[reply]
    It means that oppose votes will be more likely, and to compensate them more support votes will be needed. Result: properties get harder to approve.--Micru (talk) 21:52, 28 April 2014 (UTC)[reply]
    It does not matter if a solution is proposed and found. I see a lot of not really constructive or with poor arguments comments, that's true, but a per principle opposition should be always asked to be a little argumented. I hate no, we won't do that because we won't do that. TomT0m (talk) 22:08, 28 April 2014 (UTC)[reply]
    Even if argumented, sometimes it is just a matter of opinion, since each one has a different opinion on what is relevant.--Micru (talk) 22:19, 28 April 2014 (UTC)[reply]
    Hard to answer to an argument of that king ? sometimes each one has a different opinion. Ok, mmm. Then what ? It's fine if someone does not express his opinion to the proposer and we can find a concensus, better to leave thing die themselves and generate frustration ? TomT0m (talk) 07:09, 29 April 2014 (UTC)[reply]
    Hell no, but if what you want with this proposal is to get more properties approved, it might not work as expected. If you want to reduce long waiting times, then better to have a time limit. --Micru (talk) 07:41, 29 April 2014 (UTC)[reply]
    It's not to make thingd personal (although of course I'm myself :) ) but I have a couple of properties in property proposal/Generic who have just one supporter who answered useful. The current criteria left this out of scope and the property would be rejected. Imho it's an uncontroversial one, and I don't want to advertise the whole world to add more votes, so things just stay as it is. This is the kind of corner cases with useless frustration I want to avoid. see the valid in period proposal. I think nobody supports this because they did not had the usecase yet or are not working a lot on historical datas or don't consult property proposals. Nobody is against yet. TomT0m (talk) 11:33, 29 April 2014 (UTC)[reply]
    I left a comment, but it is a controversial proposal and it makes me worried about how well it will work with queries of qualified statements.--Micru (talk) 12:34, 29 April 2014 (UTC)[reply]
    And I forced you to express your concerns, after that we can discuss, Otherwise with just a time limit you just would have ignored the property and it would have been rejected with no explanation (lack of concensus is not an explanation). TomT0m (talk) 12:48, 29 April 2014 (UTC)[reply]
    You seem to think that everyone has enough time or the will to engange in lengthy discussions, but most do not, and it is not a "must", specially if we want to increase participation. "Lack of consensus" means that there was a discussion and that it didn't reach any outcome.--Micru (talk) 13:14, 29 April 2014 (UTC)[reply]
    You seem to fear the property proposals ... It seem esaier to assume a proposal do not hav problems and create it without lenghty discussion or vote if they are nothing to say. If there is a problem, leave a message and the no opposition condition is done. How is that decreasing participation ? I feel in a reverse world in mediawiki universe, assume good faith :) TomT0m (talk) 13:21, 29 April 2014 (UTC)[reply]
    Actually I fear more increasing the data more that we can manage with the current participation numbers. Growth should be organic, not based on lowering standards.--Micru (talk) 13:41, 29 April 2014 (UTC)[reply]
    I don't know how you come to those conclusions. The main growth is in item and statements, not in properties, which there is a small number. This do not absolutely proves it would increase the number of properties, as it is simple to oppose. Last, organic about what ? Infoboxes ? Soon we will create a parameter in the property after we create the corresponding property, which make much more sense as Wikidata is a central point. What is there to fear ? TomT0m (talk) 13:49, 29 April 2014 (UTC)[reply]
    Every new property adds a workload: sorting, organizing, adding constraints and checking them, plus the effort of knowing which properties are used for each case and documenting those uses, which not always happens. Property creation is not just that, it is all what it comes after it. If you could create 5000 properties at once, it would mean nothing, because what it takes effort is assimilating them. --Micru (talk) 14:40, 29 April 2014 (UTC)[reply]
    The problem is not digesting properties, then, it's our whole organisation, templates dispatched everywhere, poor granularity of our model units. The constraint system is quite poor and tedious to maintain. We fail to produce documentation, which should be part of the modeling process. Plus is not this on the creator ? It's not a problem depending on the number of properties, whe already have way more properties than we have doc pages, and the only way we really document their usage is the property documentation template. This is not a function of the number of properties and does not scale, you seems to think. TomT0m (talk) 15:22, 29 April 2014 (UTC)[reply]
  •  Oppose at least one support is desiderable --Paperoastro (talk) 21:46, 3 May 2014 (UTC)[reply]

Peer reviewed - no time limit[edit]

Peer reviewed - with time limit[edit]

Peer reviewed – two users[edit]

Addendum: Wikiprojects/Task forces[edit]

  • A wikiproject/task force can request to a property creator the approval of property batches that have been agreed on the context of the wikiproject.
  •  Oppose. If a wikiproject agrees a batch of properties then they should still go to the "Proposed Properties" page for comment by the rest of the project. There can easily be cases where a project team agree properties which are near duplicates of other existing properties or which could with very little tweaking be used outside their project and review by folks outside that project will pick up these issues. Filceolaire (talk) 19:33, 26 April 2014 (UTC)[reply]
    I think he was talking of batch approval. We can still discuss details on the way. TomT0m (talk) 19:39, 26 April 2014 (UTC)[reply]
  •  Oppose but with no preference against batch approval in general.--Jasper Deng (talk) 20:38, 26 April 2014 (UTC)[reply]
  •  Oppose, but  Support batch approval for related properties. Mushroom (talk) 21:56, 26 April 2014 (UTC)[reply]
  •  Comment The task force is often a better place to discuss which properties are needed and how they should be used. But I guess we still need a final review in a more public place like PP. -- Innocent bystander (talk) (The user previously known as Lavallen) 08:16, 27 April 2014 (UTC)[reply]
    I agree, the properties could first be discussed on task forces and then be batch approved on PP. Mushroom (talk) 13:18, 27 April 2014 (UTC)[reply]
  •  Oppose, Wikiprojects alone can't decide which properties should be created. All properties need to go via the process. Of course wikiprojects are a good place to think about properties. --Stryn (talk) 19:45, 27 April 2014 (UTC)[reply]

Addendum: Conflict of interest[edit]

  • The property creator who closes the proposal must not have been involved in the discussion.
  •  Support. Mushroom (talk) 21:56, 26 April 2014 (UTC)[reply]
  •  Oppose: If we have a consensus and a long enough time period for the proprosition. I don't see the problem of create a property I proposed or participated. And property creator involve automatically imself in the discussion if he decide to create a property. --Fralambert (talk) 02:45, 27 April 2014 (UTC)[reply]
    If you are able to stay neutral and judge consensus objectively I don't see a problem with it. But not everyone can do so when they care about a proposal. They might see consensus where there is none, or the opposite. If they don't care much about the property they will probably be more objective. Mushroom (talk) 13:17, 27 April 2014 (UTC)[reply]
  •  Oppose: We do not want people to stay silent in order to circumvent this. Conflict of interest is not involvement.. When a property is created, the person who does so does it with his reputation anyway. GerardM (talk) 05:21, 27 April 2014 (UTC)[reply]
    I agree that forcing people to stay silent would be bad. However, we currently have 97 administrators and 17 property creators. I think people would keep expressing they opinions, knowing that there are many others who can close the proposals. Mushroom (talk) 13:17, 27 April 2014 (UTC)[reply]
  •  Support This is common sense, as it is often the case with property creation that the consensus is ambiguous enough to really warrant a neutral uninvolved closer.--Jasper Deng (talk) 07:24, 27 April 2014 (UTC)[reply]
  •  Starkt emot Do we really think people with no interest and knowledge in a subject have the best judgement? -- Innocent bystander (talk) (The user previously known as Lavallen) 07:29, 27 April 2014 (UTC)[reply]
    So should they judge consensus based on the merit of the proposal? What if they are biased and see consensus where there is none? Mushroom (talk) 13:17, 27 April 2014 (UTC)[reply]
    That can happen anyhow. We will never fully understand every aspect of how everybody talk here, since most of us are forced to talk and listen in a language that isn't our own. WMF does not even recognize my home language, as a language of it's own. Another problem is that not all objections makes sense to everybody. For example is often proposals still opposed, based on that there is an inverse property describing the relation. Still, I have not seen any description of how the inverse relation is of any help on Wikipedia. How are we supposed to go further in such cases?
    We will always have the possibility to review our propertys after they have been created, even if it's more convenient to agree about propertys before they are created. -- Innocent bystander (talk) (The user previously known as Lavallen) 14:32, 27 April 2014 (UTC)[reply]
  •  Oppose This doesn't make sense. There is no point in having to wait for "uninvolved" users who probably don't even have a clue what the property which is to be approved is about. This just slows down the process unnecessarily even more than it already is. Vogone talk 18:34, 27 April 2014 (UTC)[reply]
  •  Oppose. I always hate too much bureaucracy. Of course property creator can create the property even if s/he has participated in the property process. --Stryn (talk) 19:45, 27 April 2014 (UTC)[reply]
  •  Weak oppose The property creator who closes the proposal can have been involved in the discussion iff there're consensus.--GZWDer (talk) 15:32, 28 April 2014 (UTC)[reply]
  •  Comment @GZWDer, Vogone: Involved users cannot judge consensus. And if it's really a problem that we have a shortage of people involved in property creation, we need to fix that instead.--Jasper Deng (talk) 00:50, 29 April 2014 (UTC)[reply]
    What is an "involved user"? I both proposed and created Swedish Open Cultural Heritage URI (P1260), but I do not intend to work heavily with this property (I do not have the time), I am not employed by either Riksantikvarieämbetet or any of the museums involved and I have worked very limited with articles on WP with links to this database. I proposed it because I thought my idea for a solution would fit this database and Wikidata, and I knew other users on svwp would like to have links to this database through Wikidata. I created the property after almost a month because nobody else did it or could not do it. If people do not have judgement, maybe they shouldn't be here at all. -- Innocent bystander (talk) (The user previously known as Lavallen) 03:37, 29 April 2014 (UTC)[reply]
    Please note that I was referring to Jasper's comment (sorry if that was unclear) and that I didn't define the term "involved" myself. I merely pointed out that making this distinction at all is counterproductive for the anyway slow process. There is not always someone who is "neutral" and "uninvolved" and in case there isn't (like it was with the property you proposed) disallowing the creator/participator/"involved" users to create it at the end would get us to nowhere. Vogone talk 05:48, 29 April 2014 (UTC)[reply]
    It seems like I misread this section (sorry for that) and Innocent bystander's comment was an answer to Jasper Deng's which I previously didn't notice. Regarding the shortage of people involved in property creation, I am curious how you think you can fix that. We are all volunteers and it is impossible to force volunteers doing a particular task. Vogone talk 06:09, 29 April 2014 (UTC)[reply]
    Swedish Open Cultural Heritage URI (P1260) is a good example of a property which can have problems finding interested users today. I am aware of only 3 Swedish users working with properties. -- Innocent bystander (talk) (The user previously known as Lavallen) 06:28, 29 April 2014 (UTC)[reply]
  •  Oppose if there is a clear consensus, why not? --Paperoastro (talk) 21:56, 3 May 2014 (UTC)[reply]

Comments[edit]

  • Personally I would prefer "peer review with time limit", because that would keep the number of properties down to a manageable size, and I would add the addendum for task forces, so the discussions are centralized and contextualized wherever they are relevant without flooding the property proposal page.--Micru (talk) 18:27, 26 April 2014 (UTC)[reply]
  • To be honest I work off the 'no oppose after a week = create' system. John F. Lewis (talk) 18:33, 26 April 2014 (UTC)[reply]
  • One equally important thing to think of, but maybe we'll wait statements on properties, in to think of the guidelines for the usage of the property and the documentation. Something like at least a showcase item per property would be cool, at least integration in a textual description on a project page or the inclusion of a textual description of one showcase item in a page which is not a simple list of proerties or the property talk page would be a must. We need more documentation, and more help to newcomers, more example, and consistency. I support any no opposition proposition. I'm not sure counting the nummber of votes is a good options, we have not really a lot of votes. TomT0m (talk) 18:41, 26 April 2014 (UTC)[reply]
  • If there are going to have these time limits then can we please move all the property proposals on to one page so I can track new comments and proposals. The current system was needed a year ago when we were creating a lot of properties but these days the number of new properties added each week is way down - it just looks like a lot because proposals are not being cleared from the pages. Filceolaire (talk) 19:26, 26 April 2014 (UTC)[reply]
    It could and probably will top again when we'll actually start mass infoboxes migration. I feel like there is a lot of work to be done. But only one status page with one line per recently closed and opened discussion is a good idea. TomT0m (talk) 19:38, 26 April 2014 (UTC)[reply]
    To have an idea, I went to dbpedia mapping server, as they are doing a similar work. There seem to be a lot of infobos parameters, more than we have properties, but there is unrelevant parameters in Wikidatas (and dbpedia) contexts. Unconclusive at that point. TomT0m (talk) 19:50, 26 April 2014 (UTC)[reply]
  • This should be an RfC, project chat alone is not enough for consensus.--Jasper Deng (talk) 20:38, 26 April 2014 (UTC)[reply]

Please don't start RFC's in the project chat. Please move this. Multichill (talk) 21:21, 26 April 2014 (UTC)[reply]

  • I agree that the property proposal system needs change, so I added two proposals. However, please make this an RfC. Mushroom (talk) 21:56, 26 April 2014 (UTC)[reply]
    Well, instead a Request for votes was created. What's wrong with some discussions before we start to vote? -- Innocent bystander (talk) (The user previously known as Lavallen) 07:21, 27 April 2014 (UTC)[reply]
    Those are not votes, they are stances. Once we have a clear idea on what to propose and what is the criticism of each option, then it will be time for voting.--Micru (talk) 09:00, 27 April 2014 (UTC)[reply]
  • At that point I see a lot of against vote, and few for. Isn't that a sign that everyone is bored and unconviced by the current system ad that we need a bigger change to make things actually smoother ? TomT0m (talk) 10:21, 27 April 2014 (UTC)[reply]
    It's a sign of that we should have talked first and started to vote later, when we have found anything worth voting about. -- Innocent bystander (talk) (The user previously known as Lavallen) 13:03, 27 April 2014 (UTC)[reply]
    Again: support/oppose shouldn't be considered votes for now, just a points of view. When we have a general overview of what is acceptable, then we can vote. As for the support-oppose ratio, maybe it has to do with status quo bias (Q29598)? It is always easier to oppose some change than to propose it...--Micru (talk) 14:20, 27 April 2014 (UTC)[reply]
    And that people just usually support one option and oppose the others, which actually just add noise, I thought of that later. But still, there is problems in the property proposal organisation this discussion avoid : if we compare with the infobox organisation, you propose a parameter to the infobox, then it is added. I think we should do something similar in Wikidata using a class item as an equivalent of an infobox. You would propose to add a property to a class item, then put an announce in property proposal pages in a list item, it would be much more organised and clearer, and this would be a real change. TomT0m (talk) 14:38, 27 April 2014 (UTC)[reply]
    It is a good idea, but for having a proposal showing in different places then we should switch the system to one similar to the bot approval proces, that is, transcluding subpages. That would be also easier for archiving old proposals, but it would be hard to do the migration...--Micru (talk) 15:29, 27 April 2014 (UTC)[reply]
    Not really, we a a similar system in Wikipedia fr, and there is just and instruction, when someone uses the article fusion or deletion template, to copy/paste a template line in the main fusion page or deletion pages, and it works without problems for years. It's also possible to code a bot who tracks the announces with a hidden category and adds a line in the main page. see the code of this template.

Scores for property assessment[edit]

Since sometimes it is difficult to evaluate properties, I am considering to use these criteria to guide my s/o in unclear cases:

  • matches existing data fields on Wikimedia projects: 0-5
  • fulfills a structural WD/WP/task force need: 0-5
  • data availability for importing or generated value: 0 - 5 (hard to find PD/CC0 data)
  • easy to import or easy to understand: 0 (manual or complicated concept/structure) - 5 (automated or easy concept)
  • plans to re-use data: 0 (black-boxing) - 5 (template exists or solid re-use project)
  • property ownership: 0 ("someone may need it") - 5 (a group of users plans to take care of documentation, data import, maintenance, etc.)

Then 0-7 oppose, 7-15 weak oppose, 15-21 weak support, 21-30 support. Anything else to consider?--Micru (talk) 17:13, 29 April 2014 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Requests_for_comment/Clarifying_the_requirements_for_property_creation&oldid=604386692"