Wikidata talk:Property creators/Archive 1
|
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion. |
How to change the meaning of an existing property?
Is there a guide or policy on how to change the meaning of an existing property? Could we make a guide on this page? There seams to be consensus to change the meaning of Property:P423, see: Wikidata:Property_proposal/Person#Handedness. --Tobias1984 (talk) 09:48, 8 May 2013 (UTC)
Clean-up the use of Template:Property documentation
Could somebody please explain what is meant by "Clean-up the use of Template:Property documentation"? Preferably by editing the guidelines. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:23, 6 March 2015 (UTC)
See the above RFC for some proposals to reform the property creation process. MediaWiki message delivery (on behalf of Rschen7754) (talk) 06:29, 20 March 2016 (UTC)
Undiscussed changes
I restore the previous process as I don't have any recollection of people discussing and/or agreeing to the changes made.
--- Jura 11:25, 22 March 2016 (UTC)
- You have reverted a number of separate changes, wholesale. These changes fixed grammar, more accurately described the process, and reflected recent changes made to the
{{Property documentation}}template and the new "external ID" property type. Your revert is harmful, and the changes should be restored. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:04, 22 March 2016 (UTC)
- For additional discussion about problems with the changes, other readers may want to have a look at https://www.wikidata.org/w/index.php?title=Wikidata:Administrators'_noticeboard&oldid=314589668#Property_creator_rights_of_Pigsonthewing (last part of this lenghty thread).
--- Jura 12:16, 22 March 2016 (UTC)- Jura, this revert was not appropriate. Some of Andy's changes were helpful. He does seem to have been confused about the "clean up property documentation" piece however - Andy, we should NEVER alter what was in the original proposal discussion after property creation, that is intended as an archive and should have every piece of it, including whatever was in the documentation template. The cleanup that's needed is when adding that template to the property talk page. I will attempt to edit this to reflect that practice. ArthurPSmith (talk) 13:36, 22 March 2016 (UTC)
- Can you do a draft first? We can't just change this without making property creators aware of it. I doubt people will get it wrong because of a typo, but we need people who understand the process review and agree to it first.
--- Jura 13:45, 22 March 2016 (UTC)- I have made the update. I hope property creators review the steps here every time they work on proposals. I certainly do. I have made changes to this page before to better reflect the process that should be used. By the way, I don't believe Step 7 is useful or even exactly possible any more, so maybe we should discuss that along with other things. In any case the list now other than Step 7 reflects current best practice. ArthurPSmith (talk) 13:47, 22 March 2016 (UTC)
- Jura, you really are over-happy with the reverts. Fine, I have a draft here. It is clearly an improvement on the current page, which has the ambiguity that caused Andy to delete sections of property documentation on the proposal pages, which you complained about. ArthurPSmith (talk) 13:52, 22 March 2016 (UTC)
- Well, given the highly problematic change Pigsonthewing tried to introduce, I think you can understand my reluctance.
Actually I agree with most of your changes and deleting step 7 of this version. The list is now automatic. As for the archiving, I think it can be done right away, otherwise some people let them linger forever (not you though).
--- Jura 13:59, 22 March 2016 (UTC) - [ec] I oppose this draft, as it suggests that material which is held as properties should be left as unstructured raw text in a template. It would also leave material which is different (and often contradictory; and often changed during the discussion) to what is actually in the properties of the created property, or its subsequent revisions by the community at large, leading to confusion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:01, 22 March 2016 (UTC)
- Andy, once the property is created, the original copy of the property documentation template in the proposal is not where you go to find information about the property as it currently stands, it is where you go to find information about the proposal, whether it has been archived or not. After archiving in particular it obviously should not be changed. But even before then, suppose the property creator decides to use a different example than the one in the proposal, or a different formatter URL, or a different related item - that is important information that is LOST if the template in the proposal is "cleaned up" by removing those fields. I do not at all support your actions to remove that information in recently created properties, I think it is damaging to the record of the proposal process. In particular once archived, recovering the original proposal template would require tracking down the original proposal page to look through the edit history, effectively these things are being lost. ArthurPSmith (talk) 14:12, 22 March 2016 (UTC)
- That's not what this page said, even before my changes (see quotes which I have just posted elsewhere). If you wish to change the current process, I suggest you add your draft to the ongoing RfC, where its pros and cons can be discussed alongside other suggested changes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:23, 22 March 2016 (UTC)
- That's not how YOU interpreted what the page said, but in fact what it said was ambiguous. When it said to "clean up" the property documentation was it referring to the proposal, or just to what you need to do before inserting it into the property's talk page? I have always interpreted it as only the latter, partly for the above reasons of not losing important facets of the proposal. As just another reason, property creators usually only add the description in one language (only one is available in the initial creation interface) while the proposal may include a description in several, so deleting that from the original copy of the template in the proposal loses those translations. If you examine all the recently created properties in the archive you will notice that only the ones you created have the stripped down documentation template; everybody else has been leaving them alone. I believe the guidelines need to be clarified on this both to reflect current general practice and because it's the right thing to do. I don't understand your opposition to this. ArthurPSmith (talk) 15:43, 22 March 2016 (UTC)
- If you care to check my edits (e.g. [1], [2]), you will see that I usually add labels and descriptions in every language in which they were provided. If you have an example of me deleting one without doing so, please provide it. I'm not opposing clarification of the guidelines; indeed it is the revert of my attempt to do so which is being discussed here. You preciously accused me - on this page - of seeming "confused"; now you say the page was ambiguous. Would you like to withdraw the former? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:54, 22 March 2016 (UTC)
- Ambiguity results in confusion - of course it hadn't seemed ambiguous to me until I saw how you were reading it. It's a bit silly to be asking people to "withdraw" statements of that sort, but whatever. I know you have been conscientious in your work on properties, please take the combative tone down a notch. Can you explain why you think leaving the original property proposal as it was when discussed is a source of problems, particularly once it's been archived? As I said, I still don't understand why you are so opposed, I'm sure there's a good reason, I would like to hear the explanation perhaps with a good example. ArthurPSmith (talk) 16:08, 22 March 2016 (UTC)
- No example, then? I consider that ambiguity, if it exists, leads to differing views, not an individual's confusion. It's unfortunate that you consider my reasoned defence of my good-faith actions as "combative"; perhaps the beam in your own eye needs attention? I have given the explanation you request, above, starting "I oppose this draft, as...". As for examples to illustrate that, consider the many times properties are created with a different datatype to the one originally, and wrongly, proposed; or external IDs where the issuing body is wrongly entered by the proponent (and remains so during discussion) in the template as "represents". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:25, 22 March 2016 (UTC)
- I agree that there are certainly circumstances when the property documentation template in the proposal will look different from the actual created property - what I'm trying to understand is how that will cause a problem. For example, suppose the proposal has a datatype of "String", and the actual created property has the datatype "Quantity". If the property creator removes the original "String" datatype from the proposal that seems unhelpful - once the proposal is archived there is no record that the discussion was about a different datatype. Now I agree if the discussion led to a change in the agreed-upon datatype, then the proposal should reflect that. But it should reflect it BEFORE the property is created, I would not consider a proposal ready of the property documentation disagreed with the discussion. If the actual property datatype disagrees with the datatype in the proposal, that is useful information for anybody reviewing the history of the property. Why is removing it helpful? ArthurPSmith (talk) 17:31, 22 March 2016 (UTC)
- In the case you give, I generally add a closing comment to the discussion, "Done, but with datatype Foo". Now consider a template in an archive, where half of the displayed values remain from the property proposal, and the other half, blank in the template since the time of creation, are transcluded from the actual property's properties, and were added more recently. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:44, 22 March 2016 (UTC)
- Ah, I think I see what you are getting at. Some of the information displayed in the archive of the discussion is original, and some is pulled from the current property data. For an original property template that is reasonably filled out all the information shown (other than the header part) is original, but if something was missed it would change as the property data was altered. But I think an archive should be legitimately an archive - a faithful record of discussion. So the behavior of the template in this respect seems wrong to me. Maybe we need two slightly different templates, one for archival purposes? Or another template parameter to distinguish the two cases? ArthurPSmith (talk) 18:30, 22 March 2016 (UTC)
- I wouldn't object to a second template, providing their code was kept in sync, so that a PC only had to change the name and remove the unwanted lines. I think your other suggestion would be too cumbersome. In current practice, there are often some parameters which are not (or historically were not) completed; but may be later. For instance,
|source=,|filter=, and|robot and gadget jobs=. And most proponents can't write a regex. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:57, 22 March 2016 (UTC)
- I wouldn't object to a second template, providing their code was kept in sync, so that a PC only had to change the name and remove the unwanted lines. I think your other suggestion would be too cumbersome. In current practice, there are often some parameters which are not (or historically were not) completed; but may be later. For instance,
- Ah, I think I see what you are getting at. Some of the information displayed in the archive of the discussion is original, and some is pulled from the current property data. For an original property template that is reasonably filled out all the information shown (other than the header part) is original, but if something was missed it would change as the property data was altered. But I think an archive should be legitimately an archive - a faithful record of discussion. So the behavior of the template in this respect seems wrong to me. Maybe we need two slightly different templates, one for archival purposes? Or another template parameter to distinguish the two cases? ArthurPSmith (talk) 18:30, 22 March 2016 (UTC)
- In the case you give, I generally add a closing comment to the discussion, "Done, but with datatype Foo". Now consider a template in an archive, where half of the displayed values remain from the property proposal, and the other half, blank in the template since the time of creation, are transcluded from the actual property's properties, and were added more recently. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:44, 22 March 2016 (UTC)
- I agree that there are certainly circumstances when the property documentation template in the proposal will look different from the actual created property - what I'm trying to understand is how that will cause a problem. For example, suppose the proposal has a datatype of "String", and the actual created property has the datatype "Quantity". If the property creator removes the original "String" datatype from the proposal that seems unhelpful - once the proposal is archived there is no record that the discussion was about a different datatype. Now I agree if the discussion led to a change in the agreed-upon datatype, then the proposal should reflect that. But it should reflect it BEFORE the property is created, I would not consider a proposal ready of the property documentation disagreed with the discussion. If the actual property datatype disagrees with the datatype in the proposal, that is useful information for anybody reviewing the history of the property. Why is removing it helpful? ArthurPSmith (talk) 17:31, 22 March 2016 (UTC)
- No example, then? I consider that ambiguity, if it exists, leads to differing views, not an individual's confusion. It's unfortunate that you consider my reasoned defence of my good-faith actions as "combative"; perhaps the beam in your own eye needs attention? I have given the explanation you request, above, starting "I oppose this draft, as...". As for examples to illustrate that, consider the many times properties are created with a different datatype to the one originally, and wrongly, proposed; or external IDs where the issuing body is wrongly entered by the proponent (and remains so during discussion) in the template as "represents". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:25, 22 March 2016 (UTC)
- Ambiguity results in confusion - of course it hadn't seemed ambiguous to me until I saw how you were reading it. It's a bit silly to be asking people to "withdraw" statements of that sort, but whatever. I know you have been conscientious in your work on properties, please take the combative tone down a notch. Can you explain why you think leaving the original property proposal as it was when discussed is a source of problems, particularly once it's been archived? As I said, I still don't understand why you are so opposed, I'm sure there's a good reason, I would like to hear the explanation perhaps with a good example. ArthurPSmith (talk) 16:08, 22 March 2016 (UTC)
- If you care to check my edits (e.g. [1], [2]), you will see that I usually add labels and descriptions in every language in which they were provided. If you have an example of me deleting one without doing so, please provide it. I'm not opposing clarification of the guidelines; indeed it is the revert of my attempt to do so which is being discussed here. You preciously accused me - on this page - of seeming "confused"; now you say the page was ambiguous. Would you like to withdraw the former? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:54, 22 March 2016 (UTC)
- That's not how YOU interpreted what the page said, but in fact what it said was ambiguous. When it said to "clean up" the property documentation was it referring to the proposal, or just to what you need to do before inserting it into the property's talk page? I have always interpreted it as only the latter, partly for the above reasons of not losing important facets of the proposal. As just another reason, property creators usually only add the description in one language (only one is available in the initial creation interface) while the proposal may include a description in several, so deleting that from the original copy of the template in the proposal loses those translations. If you examine all the recently created properties in the archive you will notice that only the ones you created have the stripped down documentation template; everybody else has been leaving them alone. I believe the guidelines need to be clarified on this both to reflect current general practice and because it's the right thing to do. I don't understand your opposition to this. ArthurPSmith (talk) 15:43, 22 March 2016 (UTC)
- That's not what this page said, even before my changes (see quotes which I have just posted elsewhere). If you wish to change the current process, I suggest you add your draft to the ongoing RfC, where its pros and cons can be discussed alongside other suggested changes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:23, 22 March 2016 (UTC)
- Andy, once the property is created, the original copy of the property documentation template in the proposal is not where you go to find information about the property as it currently stands, it is where you go to find information about the proposal, whether it has been archived or not. After archiving in particular it obviously should not be changed. But even before then, suppose the property creator decides to use a different example than the one in the proposal, or a different formatter URL, or a different related item - that is important information that is LOST if the template in the proposal is "cleaned up" by removing those fields. I do not at all support your actions to remove that information in recently created properties, I think it is damaging to the record of the proposal process. In particular once archived, recovering the original proposal template would require tracking down the original proposal page to look through the edit history, effectively these things are being lost. ArthurPSmith (talk) 14:12, 22 March 2016 (UTC)
- Well, given the highly problematic change Pigsonthewing tried to introduce, I think you can understand my reluctance.
- I note that Jura has reverted you, restoring the incorrect, and out-of-date, pre-12 March version. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:26, 22 March 2016 (UTC)
- Jura, you really are over-happy with the reverts. Fine, I have a draft here. It is clearly an improvement on the current page, which has the ambiguity that caused Andy to delete sections of property documentation on the proposal pages, which you complained about. ArthurPSmith (talk) 13:52, 22 March 2016 (UTC)
- Points addressed in my comment above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:01, 22 March 2016 (UTC)
- I have made the update. I hope property creators review the steps here every time they work on proposals. I certainly do. I have made changes to this page before to better reflect the process that should be used. By the way, I don't believe Step 7 is useful or even exactly possible any more, so maybe we should discuss that along with other things. In any case the list now other than Step 7 reflects current best practice. ArthurPSmith (talk) 13:47, 22 March 2016 (UTC)
- Can you do a draft first? We can't just change this without making property creators aware of it. I doubt people will get it wrong because of a typo, but we need people who understand the process review and agree to it first.
- Jura, this revert was not appropriate. Some of Andy's changes were helpful. He does seem to have been confused about the "clean up property documentation" piece however - Andy, we should NEVER alter what was in the original proposal discussion after property creation, that is intended as an archive and should have every piece of it, including whatever was in the documentation template. The cleanup that's needed is when adding that template to the property talk page. I will attempt to edit this to reflect that practice. ArthurPSmith (talk) 13:36, 22 March 2016 (UTC)
Given comments above, I've re-added what I believe are the undisputed changes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:17, 22 March 2016 (UTC)
Property Template change?
Per above discussion, I took a look at Module:Property_documentation - there is already some logic in there that does different things depending on the 'namespace' value (Wikidata or Property:Talk). It seems to me it wouldn't be hard to modify it so that on property proposal pages (and in their archives) it cleanly separates those elements pulled from the property and its statements and those which are parameters of the template as it stands. It already does some of this. The question is whether this is agreeable to everybody... I don't want to break anything. I think a change to move anything pulled from the property & its statements to the upper box within the Wikidata namespace would take care of it with no loss of current functionality and more complete display of information. ArthurPSmith (talk) 20:13, 22 March 2016 (UTC)
- Could you mock this up in a sandbox, please? And make sure that the labels differ (e.g. "proposed datatype" vs "datatype", etc)? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:12, 22 March 2016 (UTC)
- sorry I don't have time to work on this myself right now, and I have never coded wikidata template modules before so there would be a learning curve. I do think this would be helpful, but I probably won't get a chance between now and May. Maybe somebody else in this discussion has more skill in this regard - I notice Jura has edited that module before. ArthurPSmith (talk) 21:01, 24 March 2016 (UTC)
- Could you please describe problems of the current implementation, then? I will be happy to help you if it's a "good thing". Matěj Suchánek (talk) 21:12, 24 March 2016 (UTC)
- Hi Matěj Suchánek thanks for the offer! The basic problem with the current template is that when it is used on the property proposal page after the property has been created (and linked via the number in the status= field) it doesn't clearly distinguish between information it is pulling from the property and its statements, and information it is pulling from the template as provided by the proposer. As it remains used in property proposal archives, the original proposed information for the property should be preserved, not replacecd by whatever the current values are on the property. See for example Wikidata:Property_proposal/Archive/46#TED_speaker_ID - it displays a number of aspects of the property (data type, example, formatter URL) that are pulled from the property statements, with no indication that they were not actually part of the original proposal. I believe those items pulled from the property statements should be moved to the top box or highlighted differently in such a case. ArthurPSmith (talk) 16:17, 25 March 2016 (UTC)
- Undestood. Changing it seems to be simple but the discussion should also take place on its talk page. Matěj Suchánek (talk) 16:26, 25 March 2016 (UTC)
- That is false. The current data type, example, formatter URL for TED speaker ID (P2611) were all part of the original proposal. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:44, 25 March 2016 (UTC)
- Hi Matěj Suchánek thanks for the offer! The basic problem with the current template is that when it is used on the property proposal page after the property has been created (and linked via the number in the status= field) it doesn't clearly distinguish between information it is pulling from the property and its statements, and information it is pulling from the template as provided by the proposer. As it remains used in property proposal archives, the original proposed information for the property should be preserved, not replacecd by whatever the current values are on the property. See for example Wikidata:Property_proposal/Archive/46#TED_speaker_ID - it displays a number of aspects of the property (data type, example, formatter URL) that are pulled from the property statements, with no indication that they were not actually part of the original proposal. I believe those items pulled from the property statements should be moved to the top box or highlighted differently in such a case. ArthurPSmith (talk) 16:17, 25 March 2016 (UTC)
- Could you please describe problems of the current implementation, then? I will be happy to help you if it's a "good thing". Matěj Suchánek (talk) 21:12, 24 March 2016 (UTC)
- sorry I don't have time to work on this myself right now, and I have never coded wikidata template modules before so there would be a learning curve. I do think this would be helpful, but I probably won't get a chance between now and May. Maybe somebody else in this discussion has more skill in this regard - I notice Jura has edited that module before. ArthurPSmith (talk) 21:01, 24 March 2016 (UTC)
Reading through the comments above: Personally, I believe the archived version of {{Property documentation}} should be more or less the final version of the discussion. The template on the property talk page, on the other hand, should be modified as needed. I also like the idea of splitting the template in two, maybe {{Proposed property}} and {{Property documentation}}, where each template has only the fields it needs and different logic. (The former could have very simple logic.) Keeping field names similar would allow us to still copy the old template over to the talk page, and just rename the template and then clean it up afterwards. --Srittau (talk) 01:29, 25 March 2016 (UTC)
- The former should be
{{Property proposal}}, so that it's easier to modify the name when moving the template. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:25, 25 March 2016 (UTC)- I agree and that is the name I usually chose. Unfortunately, there already is a
{{Property proposal}}. --Srittau (talk) 16:34, 25 March 2016 (UTC)- That's little used (fewer than 100 transclusions) and poorly named, so should be renamed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:00, 27 March 2016 (UTC)
- I agree and that is the name I usually chose. Unfortunately, there already is a
As described at Template talk:Property documentation#Change behavior on property proposal pages?, the template is currently broken. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:54, 5 April 2016 (UTC)
Reworked "Steps when creating properties"
I wasn't aware that there had been a heated discussion about this section on here just a few days before, before I made these changes. Nevertheless, to me as a new property creator, who tried to follow those instructions for the first time, they were a fair mess and pretty hard to follow. Therefore, I tried to group the instructions so they could be follow sequentially, and split and merged instructions that belong together. Please review and adapt. --Srittau (talk) 20:27, 24 March 2016 (UTC)
- @Srittau: well, the organization and order is somewhat better and clearer on the issues we have been debating. I agree with your changes EXCEPT that you removed the old Step 2 - to actually apply the property to the examples provided in the property proposal (if any, or to find a good example if not). It really is best if the property creator tries applying the property themselves for a few items to be sure it is working properly. Do you have a reason why you removed this step? Since Jura has already reverted similar changes I made here I'm not going to try to fix this myself, but I really think it is a mistake to remove that piece of the process. ArthurPSmith (talk) 21:04, 24 March 2016 (UTC)
- Ah, I misunderstood the point and thought it was a duplication with the point "add Wikidata property example (P1855) to the property". I am re-adding it. --Srittau (talk) 21:30, 24 March 2016 (UTC)
- I've made some changes to the new version; but it now fails to address the issues I highlighted above, about the template, in archives, showing properties added to or changed on a property-item, at a later date. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:37, 24 March 2016 (UTC)
- I never intended to make (big) content changes, so if you think I missed something, please add it again. --Srittau (talk) 01:22, 25 March 2016 (UTC)
- I didn't mean to suggest that you done either. I pointed out that your changes do not fix (though they may have slightly exacerbated) a particular pre-existing problem. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:21, 25 March 2016 (UTC)
- I never intended to make (big) content changes, so if you think I missed something, please add it again. --Srittau (talk) 01:22, 25 March 2016 (UTC)
- It's easier to read indeed. I'd keep the current sequence though. This avoid problems we currently have when people didn't follow it (users deleting part of proposals, property talk pages not linking to the proposal, closed discussions lingering forever on the proposal page).
--- Jura 13:32, 25 March 2016 (UTC)- Your sequence does not work and is illogical, though. This sequence was what caused me problems when trying to follow the instructions. It also fails, since usually after closing a discussion, it is not moved immediately to the archive, but only after a certain period of time. --Srittau (talk) 15:20, 25 March 2016 (UTC)
- I haven't seen anyone but Jura say that archiving should be done as soon as the property is created; nor have I seen anyone creating a property do so, in the last year. If I've missed either, I'm sure someone will soon correct me. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:26, 25 March 2016 (UTC)
- Your sequence does not work and is illogical, though. This sequence was what caused me problems when trying to follow the instructions. It also fails, since usually after closing a discussion, it is not moved immediately to the archive, but only after a certain period of time. --Srittau (talk) 15:20, 25 March 2016 (UTC)
I've reverted further changes, because they were not discussed and seem contrary to the consensus forming here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:01, 25 March 2016 (UTC)
- Ok. I will restore the last agreed version.
--- Jura 14:05, 25 March 2016 (UTC)
- This page probably should include
{{Policy}}- to perhaps limit some of the editing conflicts we've run into... ArthurPSmith (talk) 16:22, 25 March 2016 (UTC)- Agreed - bearing in mind that policies should reflect actual practice, and that that is where consensus is formed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:27, 25 March 2016 (UTC)
Straw poll
Straw poll: Use this version in the future? (Further changes to be discussed here)?
Support --Srittau (talk) 15:20, 25 March 2016 (UTC)- Support ArthurPSmith (talk) 16:19, 25 March 2016 (UTC)
- Support Without prejudice against incremental improvements and fixing the issue I describe above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:22, 25 March 2016 (UTC)
- Indeed. Editorial edits should be fine any time. Content changes should be discussed. (Sorry, I did not do that before my changes. I hadn't notice the big discussion just two days ago.) --Srittau (talk) 16:29, 25 March 2016 (UTC)
Per the consensus shown here, I've restored the agreed version. I note that, in the meantime, Jura has begun creating properties and archiving their proposals immediately (i.e. not following this process). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:46, 26 March 2016 (UTC)
Oppose see below. Pigsoonthewing: you are not qualified to restore this.
--- Jura 15:47, 26 March 2016 (UTC)- You are in no position to lecture me on what I am or am not qualified to do. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:49, 26 March 2016 (UTC)
| I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:59, 31 March 2016 (UTC) |
Evaluation of suggested update
Can we test this first? Currently neither the proposed procedure nor the current procedure seem to work that well. Maybe each attempts to follow their procedure and then we try to evaluate the result? Questions to use to evaluate: are the created properties being used? are all steps of the process being followed? how long does it take to do it?
--- Jura 15:47, 26 March 2016 (UTC)
- There is no "proposed" procedure. Just a reordering of points and clarification that the archiving is to be done after a few days, which is current practice. --Srittau (talk) 17:24, 26 March 2016 (UTC)
- It's a new compared to what was written there and to what I and some of the other creators are following. Apparently, it needs to be written in procedure that people shouldn't delete part of the proposal when it's not being archived (read the saga about that at Property_creator_rights_of_Pigsonthewing.
--- Jura 17:37, 26 March 2016 (UTC)
- It's a new compared to what was written there and to what I and some of the other creators are following. Apparently, it needs to be written in procedure that people shouldn't delete part of the proposal when it's not being archived (read the saga about that at Property_creator_rights_of_Pigsonthewing.
Change the suggested properties
Hello again. I would like to merge steps two and three of "Create the property" and add some properties as follows:
- ...
- Add appropriate statements to the property, including:
- instance of (P31) Wikidata property (Q18616576) (or appropriate subclass(es), mandatory)
- Wikidata property example (P1855) with the example item(s) as value(s) and the new property as a qualifier (recommended)
- formatter URL (P1630), format as a regular expression (P1793) (if applicable, for properties with "string" or "external ID" datatype)
- Wikidata item of this property (P1629), source website for the property (P1896), stability of property value (P2668) (if applicable)
- ...
- ...
I think this is not only better formatted, it also includes more useful properties, so it's harder to forget them. Also useful for new property creators that don't know the secret sauce yet. (Please add more if I forgot some.) Opinions? --Srittau (talk) 20:15, 4 April 2016 (UTC)
- Well, in principle this is a good idea, but it maybe shouldn't be too long so we don't scare people. Other ones to consider for your list: expected completeness (P2429), P1646 (P1646), inverse property (P1696) (all probably rather rarely needed), P2237 (P2237) for Quantity datatypes, Wikidata usage instructions (P2559) was recently added to remove some of the verbiage that's been put into descriptions on how to use properties... ArthurPSmith (talk) 21:00, 4 April 2016 (UTC)
- Yes, I can see the point about people getting scared. Also, the way properties are formatted makes it difficult to really recognize the properties. An alternative way is to list the properties one per bullet point, but that makes the list very long. Maybe we could hide them in a box, like this:
- ...
- Add appropriate statements to the property, including:
- instance of (P31) Wikidata property (Q18616576) (or appropriate subclass(es), mandatory)
- Wikidata property example (P1855) with the example item(s) as value(s) and the new property as a qualifier (recommended)
- formatter URL (P1630), format as a regular expression (P1793) (if applicable, for properties with "string" or "external ID" datatype)
- ...
- ...
| General: | Wikidata item of this property (P1629) · source website for the property (P1896) · Wikidata usage instructions (P2559) · P1646 (P1646) |
| Value properties: | stability of property value (P2668) · expected completeness (P2429) |
| Relationship to other properties: | inverse property (P1696) |
| Quantities: | P2237 (P2237) |
- Support for this change --Pasleim (talk) 12:04, 7 April 2016 (UTC)
Done --Srittau (talk) 17:28, 8 April 2016 (UTC)
Move P1630 and P1793
I would like to move formatter URL (P1630) and format as a regular expression (P1793) from step 2 of the property creation into the "Further suggested properties" box. The latter could go into "value properties", while the former would go under "general". --Srittau (talk) 21:38, 5 May 2016 (UTC)
- Ok with me, though then maybe the "further suggested properties" box should be immediately after step 2 rather than at the end of the first group of steps? ArthurPSmith (talk) 14:41, 6 May 2016 (UTC)
- While I agree with that (and actually tried to do that when I suggested the box), I can't make it work, at least not when using Wiki-syntax for the list. --Srittau (talk) 15:30, 6 May 2016 (UTC)
- Maybe then just replace the line mentioning those specific properties with something like "Add any of the further suggested properties below that are appropriate"? ArthurPSmith (talk) 16:08, 6 May 2016 (UTC)
- While I agree with that (and actually tried to do that when I suggested the box), I can't make it work, at least not when using Wiki-syntax for the list. --Srittau (talk) 15:30, 6 May 2016 (UTC)
Done --Srittau (talk) 21:00, 6 May 2016 (UTC)
Steps for archiving of property creation process
The section on the property proposal archival process, since we have moved to dedicated subpages, needs to change. I scolded Tobias earlier today (even though he may have been following the guideline on this page) when he blanked the subpage with the dedicated proposal.
However, I can't figure out how to edit around the translate extension... --Izno (talk) 16:55, 6 June 2016 (UTC)
- I edited, I just ignore the translate tags in preview mode - or you can edit the whole page in which case preview does work with translation I think. ArthurPSmith (talk) 19:33, 6 June 2016 (UTC)
- Well, I think we really need to move to subpages first. Currently some of us are doing it by hand, which is not the greatest and quite inconsistent. I wanted to work on this, but did not find the time yet. I think the main obstacle is that we need a bot to link newly created subpages to proposal pages automatically. --Srittau (talk) 21:58, 6 June 2016 (UTC)
- I've got a couple more main property proposal pages to work through; all the rest are either converted or "closing soon" and so I haven't taken the time to convert them. From what I can tell the /header template already allows for a preload proposal. What we should probably have
{{Property proposal}}do is automatically categorize itself based on the status, with a blank status as "property proposals needing categorizing" and everything else causing e.g. "property proposals in the ready state". --Izno (talk) 02:11, 7 June 2016 (UTC)
- I've got a couple more main property proposal pages to work through; all the rest are either converted or "closing soon" and so I haven't taken the time to convert them. From what I can tell the /header template already allows for a preload proposal. What we should probably have
Properties of datatype external-id
After creation of Help:Identifiers and discussion at WikidataCon 2017 (see my lightning talk) some of use decided that all properties with datatype external-id should be classified under Wikidata property for an identifier (Q19847637) or any of its subclasses. (Where) can this rule be added? -- JakobVoss (talk) 13:36, 31 October 2017 (UTC)
- I created Wikidata:WikiProject Properties/Reports/Unclassified identifier properties to check unclassified identifier properties. -- JakobVoss (talk) 18:58, 8 November 2017 (UTC)
"No less than one week"
The current policy states that "The period before a property can be created should be no less than one week." I find this inconveniently short, as I often find out about property proposals via the weekly summary, and proposals made on Mondays are often closed within hours after being posted in the weekly summary, so I miss the opportunity to comment. Anyone else have this issue? If so, might it be worthwhile to change extend the minimum by a day or two? --Yair rand (talk) 21:33, 14 January 2019 (UTC)
- I’m a very impatient property proposer, but I’d have no problem with extending the minimum period to 10 days (or even two weeks). - PKM (talk) 00:17, 7 March 2019 (UTC)
- It might be worth introducing a distinction between external ids and other properties if we go down that route. There are loads of very consensual external ids that are proposed and would deserve to be created before one week, I think. For many users, getting these identifiers created is already the longest step of their data import workflow. I would advocate to reduce the threshold for these to a few days. Raising the bar for other datatypes would not be a problem for me. − Pintoch (talk) 10:17, 7 March 2019 (UTC)
- Good distinction. - PKM (talk) 04:00, 8 March 2019 (UTC)
- It might be worth introducing a distinction between external ids and other properties if we go down that route. There are loads of very consensual external ids that are proposed and would deserve to be created before one week, I think. For many users, getting these identifiers created is already the longest step of their data import workflow. I would advocate to reduce the threshold for these to a few days. Raising the bar for other datatypes would not be a problem for me. − Pintoch (talk) 10:17, 7 March 2019 (UTC)
- Since the current 1 week was settled by RFC we might want another one to change it? However, we could probably defacto set this if those of us who are active just wait a few more days to set status to "ready". I'm willing to do wait longer on my part if it seems appropriate here. ArthurPSmith (talk) 16:24, 7 March 2019 (UTC)
- It seems to me that when it comes to external ID's it would sometimes be useful to be able to create the property in a shorter timespan. On the other hand, having a good discussion for clarifying the scope of non-external ID properties often takes longer. ChristianKl ❪✉❫ 14:44, 8 March 2019 (UTC)
Project pinging
Hi,
I think pinging the relevant project(s) when proposing properties is generally done, however it happens every now and then that the proposer does not do it (forget or does not know it’s a thing).
To take my personal example, I’m active in WikiProject Video games, have submitted dozens of property proposals and always ping the project. I have noticed several cases where the project was not pinged, have very low engagement (which is IMO linked) and created: Wikidata:Property proposal/cpcrulez, Wikidata:Property proposal/Queerly Represent Me identifier, Wikidata:Property proposal/speedrun.com game ID, Wikidata:Property proposal/Bahamut Gamer's Community ACG Database, Wikidata:Property proposal/IGDB game ID − and just now Wikidata:Property proposal/Itch.io ID (where even the participants to another, ongoing proposal for the same ID were not notified).
Therefore, how would we feel about the following: before creating a property, property creators should make sure that the relevant project was pinged (whether by doing it themselsves or by requiring it from the proposer)
Jean-Fred (talk) 21:04, 8 September 2019 (UTC)
- The way Wikidata:Property proposal/Itch.io ID was handled is odd .. not sure if that would have solved it. In any case, we seem to have now what most people wanted .. --- Jura 23:22, 8 September 2019 (UTC)
- Well Wikidata:Property proposal/Itch.io ID is not really my concern here (I also agree that the outcome is good, it could have used some more communication but that’s not a big issue). I am more concerned about eg Wikidata:Property proposal/Bahamut Gamer's Community ACG Database, because it did not get enough scrutiny (the example of Revisions (Q54985788) → 94686;103119 is not valid, what is meant is that there are two distinct identifiers). I understand that only a few people care about games or anime IDs, but they can’t chime in if they don’t know about the proposals :) Jean-Fred (talk) 11:18, 12 September 2019 (UTC)
External identifiers
Hi All,
I wrote a proposal about expanding the statements regarding external identifiers, please have a look and add your opinions: https://www.wikidata.org/wiki/Wikidata:Project_chat#External_Identifiers_-_expanding_statements,_best_practice --Adam Harangozó (talk) 19:55, 2 November 2019 (UTC)
No longer creating properties with my script
Hi all,
For quite some time I have been creating properties using a script, to transfer automatically the information from the property proposal template to the property itself. Over the past few months I had less time to dedicate to this activity, so I only helped to clear the backlog every two weeks. Recently, it has been harder and harder to run scripts and bots on Wikidata because of scalability issues (maxlag being above 5 very often). Today I tried to reduce the backlog, as many properties are ready to be created. But maxlag was above 20, 4 times the value above which all bots should (supposedly) stop. In these conditions, I cannot run my script and still respect the policy. Given that this has been a recurrent issue I will now stop creating any properties: as far as I am concerned, Wikidata is no longer usable. I have tried to encourage communication between WMDE and the community about the sustainability of mass imports, specifically of scientific articles, which now amount to nearly half of Wikidata's items. I am sorry that this has not succeeded and that we now find ourselves in this situation. Thank you to all property creators and reviewers for your tireless work, it has been great to work with you all. − Pintoch (talk) 19:44, 28 February 2020 (UTC)
- Thanks for all your work to run these, it was really very much appreciated. I can't imagine property creation is an activity that would cause trouble for the query servers, so I personally wouldn't object if you ran it any time you like. People are constantly editing Wikidata anyway independent of maxlag (and I read somewhere recently that non-bot edits are still about 1/2 of all edits here, though that is presumably not accounting for Quickstatements/WIDAR activity which may be very bot-like while attributed to non-bots). Also, as I noted here, the query server lags (which control maxlag) for the last week have been quite peculiar; for long periods of time the servers seemed able to all keep up quite handily, but then things broke down again... ArthurPSmith (talk) 20:26, 29 February 2020 (UTC)
- Thanks Arthur! Yes I do not think property creation adds much to the WDQS lag either - it's more of a matter of principle: if I have to breach the policy to help clear administrative backlogs like this one, then Wikidata has a problem, and hiding the problem by taking on the responsibility to ignore maxlag on my side does not feel right. − Pintoch (talk) 19:39, 1 March 2020 (UTC)
Criteria for creation
Closed discussion is here. Please do not edit.
Hey, as a recently approved property creator I propose that we more clearly define (and revisit) a list of the criteria a proposal must meet before creation can occur in a new section on this page. Below is a draft of what that could look like based on the existing writing at the top of the page (we can update this as discussion takes place). --SilentSpike (talk) 18:28, 2 April 2020 (UTC)
Draft
Properties can only be created by a property creator when all of the following conditions are met:
- A formal property proposal has been made via WD:PP
- The proposal was made by somebody other than the property creator
- The proposal has received consensus in favour of creation. It is the job of the property creator to weigh consensus, but generally:
- All opposing points of discussion should be addressed before creation occurs. If there is still disagreement, it is up to the property creator to consider the thoughtfulness and logic behind points of discussion (i.e. an opposing voice with no thought behind it should not block creation, but a single reasonable opposing voice against many supporters may do so).
- The creator themselves should remember their responsibility to participate. If they disagree with consensus support or opposition, they should first participate rather than make a judgement call.
- The proposal was first made over a week ago.
Criteria Discussion
I think it would be good to add as a condition obligation to ping relevant Wikidata WikiProject (if it exists).--Jklamo (talk) 08:46, 3 April 2020 (UTC)
- I do like this idea, it helps with the point of consensus knowing that interested parties have been given their chance to voice any opposing opinions --SilentSpike (talk) 11:31, 3 April 2020 (UTC)
Consensus
The page currently says "Property creators must not create new properties unless consensus exists", which is open to interpretation. Meanwhile, WD:PP says "When after some time there are some supporters, but no or very few opponents". This is a little more clear, but I think we could quantify explicitly what consensus means here. Perhaps a required number of proposal participants and a percentage of those must be in favour of creation (then again, this could hinder proposals for more niche subjects, however that's where the property creator responsibility to participate should come in). --SilentSpike (talk) 18:28, 2 April 2020 (UTC)
Not sure if it's clear or not, but the consensus should be to create the proposed property, not some property the creator has in mind. Further, it means that potential concerns raised in the discussion are addressed or it's clear from the participants comments that they are aware of that. Is this covered by the new wording? --- Jura 18:45, 2 April 2020 (UTC)
- I assume by creator here you refer to proposal creator and not property creator (although both would be true). This is definitely something that could be clarified in the consensus bullet-point. --SilentSpike (talk) 21:17, 2 April 2020 (UTC)
- My general assessment regarding numbers has been: for external id's 3 independent supporters are needed, which including the proposer and property creator means at least one positive show of support from somebody else. For other datatypes I've set that number at 4 (so 2 support votes from others). If there are any oppose votes, or comments that don't clearly indicate support for the proposal in its current form, then those need to be addressed in some way. If after a significant amount of discussion there are still both support and oppose votes, then I've looked for at least 75% approval (i.e. if 4 total, 3 support and 1 oppose allows for creation). But I may weigh some votes less depending on what looks like the thoughtfulness or experience associated with the comment, so in some cases even a large number of simple support votes may not be enough to justify creation if there is a clearly well-thought-out opposing position. I think it usually doesn't hurt to just give it more time to see if better arguments come along or consensus otherwise emerges. – The preceding unsigned comment was added by ArthurPSmith (talk • contribs).
- This raises a valid point that had crossed my mind, perhaps we cannot strictly quantify what qualifies as consensus in cases where there's a difference in the quality of arguments expressed opposing vs supporting. Even with that in mind, I like the numbers you've been using as they line up with what I would consider to be consensus and are along the lines of what I think would be good to have in writing for property creators to reference as general guidelines. I'll update the draft above to see whether I can succinctly capture something along these lines. --SilentSpike (talk) 21:17, 2 April 2020 (UTC)
- I'd rather avoid quantification.--- Jura 21:26, 2 April 2020 (UTC)
- For what purpose? I don't think it has to be a strict rule, just a guidelines to give an idea of what actually qualifies as consensus so all creators are operating on the same judgements. I've updated the draft above, do you find it disagreeable? --SilentSpike (talk) 21:31, 2 April 2020 (UTC)
- Given the level of participation in these discussions, I don't see much benefit. Occasionally, we get some random opposes from users I'd have a hard time naming where they contributed constructively to the project. However, I do think it's important to try to think these proposals through. --- Jura 21:37, 2 April 2020 (UTC)
- For what purpose? I don't think it has to be a strict rule, just a guidelines to give an idea of what actually qualifies as consensus so all creators are operating on the same judgements. I've updated the draft above, do you find it disagreeable? --SilentSpike (talk) 21:31, 2 April 2020 (UTC)
- I'd rather avoid quantification.--- Jura 21:26, 2 April 2020 (UTC)
- This raises a valid point that had crossed my mind, perhaps we cannot strictly quantify what qualifies as consensus in cases where there's a difference in the quality of arguments expressed opposing vs supporting. Even with that in mind, I like the numbers you've been using as they line up with what I would consider to be consensus and are along the lines of what I think would be good to have in writing for property creators to reference as general guidelines. I'll update the draft above to see whether I can succinctly capture something along these lines. --SilentSpike (talk) 21:17, 2 April 2020 (UTC)
- Very interesting. I would like to add a little flat. Calling external-IDs "easy" seems a little quick to me. Knowing that, these properties are a little more likely to affect sister projects, we should not denigrate the importance of an external-ID-prop to other creations, IMHO. Knowing that Wikidata Projects relating to future properties must be contacted, there may be a support avalanche on a bad proposal (perhaps partisan or perhaps arising from a lack of knowledge of the passage from the proposal to the creation). So much comes into play, that it should not favor one type over another, but make a global decision on all types. Beyond the "quantity" of support, there is also the "quality" of the opposition comment(s). If there is an opponent who writes "this is not the right type" or "your examples do not match this or that", there is no question of a creation, because it is the only opponent who is right, according to his comment and even if the proposal collects 10 supporters. In summary, at the beginning, I also had difficulties. Using WD:UCS and taking the time to read the proposal… let's base it on that. Same for the period before creation. —Eihel (talk) 01:47, 3 April 2020 (UTC)
- You raise some very good points. I think there are some common themes in all the feedback here and have updated the suggested draft to try and better capture them (particularly appealing to WD:UCS). Perhaps using numbers is not the way to go. --SilentSpike (talk) 11:31, 3 April 2020 (UTC)
- I oppose any requirements involving number of votes, as property proposal is not a vote. I instead think property may still be created if no concern or issue is raised in a considerable time (and the proposal is mature enough without requirement of additional discussion) even without support other than proposer as all proposals represents a need by someone.--GZWDer (talk) 04:42, 3 April 2020 (UTC)
- Let me know how you feel about the updated draft, no more mention of numbers. I would be interested to know others' thoughts on your reply here (as to my interpretation, a lack of participation prevents a consensus from existing - but that's kind of what inspired me to start this discussion). --SilentSpike (talk) 11:31, 3 April 2020 (UTC)
Period before creation
This page currently says "The period before a property can be created should be no less than one week". Again, this is a little unclear, is this a week since first proposed or a week since there appears to be consensus (to give time for opposing views)? I see there has also been talk on whether this should be slightly longer with weekly summaries in mind, as well as whether there should be an exception for external identifiers where it's often quick to see whether they are suitable or not. --SilentSpike (talk) 18:28, 2 April 2020 (UTC)
- I believe this has always been interpreted as a week since the proposal was created. ArthurPSmith (talk) 20:59, 2 April 2020 (UTC)
- This matches my interpretation, that point was more about clarifying the wording. The discussion about whether this time-span should be changed is probably of more interest here. Personally I'm okay with slightly longer before creation of regular properties and would also be okay with it being possible to create external ID properties slightly faster provided there is clear consensus. --SilentSpike (talk) 21:04, 2 April 2020 (UTC)
- I'd rather do the opposite: wait two weeks for external-ids. This way users have ample time to prepare the 50 candidates and we are sure there wont be any dormant ones. I think the recently created P7902 was created too earlier and needed countless edits to correct and deleted incorrect statements. --- Jura 21:12, 2 April 2020 (UTC)
For external ids require that an item in the itemspace is created first that describes the id. If it is that notable to be included as a property, then it certainly is notable for itemspace. Then the data is properly structured and can be reviewed via sparql. The current process by doing it via templates is very backward. MrProperLawAndOrder (talk) 23:12, 3 April 2020 (UTC)
Voting
Support Assuming we can clarify these points, I proposed this and obvious support the change --SilentSpike (talk) 18:28, 2 April 2020 (UTC)
- For external-id properties, I think it could be helpful to request 50 uses through described at URL (P973). For property creators this has the advantage they wont waste their time for a property that remains dormant. For the proposer, this has the advantage that they see that they can already contribute and wont be stopped by the property creation process taking time to complete. Once the property is created, the bot that regularly converts P973 can include them. --- Jura 18:45, 2 April 2020 (UTC)
- An interesting idea, I can see the logic in it. The only real case I could see against this is, if someone proposes a property with clear value, but without a specific use case in mind. Then the creation process is unnecessarily held up adding those statements to items only to be replaced upon creation. --SilentSpike (talk) 21:41, 2 April 2020 (UTC)
- There is nothing being held up as the statements can be added. We just avoid the many dormant ones Wikidata:Property proposal/Archive/2019/12 or Wikidata:Property proposal/Archive/2019/11. If there is a good reason to go ahead, obviously we still could. --- Jura 21:53, 2 April 2020 (UTC)
- I would on board with this, however I think such a change would need to be proposed to a wider audience (project chat) since it changes the property proposal process itself rather than just the creation process guidelines. However, I would also support upping the minimum time before creation to two weeks in the draft here. --SilentSpike (talk) 22:19, 2 April 2020 (UTC)
- There is nothing being held up as the statements can be added. We just avoid the many dormant ones Wikidata:Property proposal/Archive/2019/12 or Wikidata:Property proposal/Archive/2019/11. If there is a good reason to go ahead, obviously we still could. --- Jura 21:53, 2 April 2020 (UTC)
- An interesting idea, I can see the logic in it. The only real case I could see against this is, if someone proposes a property with clear value, but without a specific use case in mind. Then the creation process is unnecessarily held up adding those statements to items only to be replaced upon creation. --SilentSpike (talk) 21:41, 2 April 2020 (UTC)
Comment maybe I am missing something - one purpose of having an external identifier property is that we can manage URL pattern changes in one place. Adding 50 “described at URL” statements that will be made redundant by the proposed property seems like make-work to me. So what am I missing? - PKM (talk) 00:01, 3 April 2020 (UTC)
- I've removed Jura's addition to the draft here as I believe this idea is too large a change to include in my proposed clarification of the guidelines here and should probably be discussed in a new topic to avoid confusion. --SilentSpike (talk) 11:31, 3 April 2020 (UTC)
- @PKM: There is nothing really redundant about it. As mentioned above, it has advantages for the proposer and the creator/project. For proposers who would contribute 50, it doesn't involve any additional work. For the project, it also avoids overhead due to unused properties. --- Jura 12:26, 3 April 2020 (UTC)
- Support I slightly edited the proposal for clarity - mostly changing "create" to "made" when referring to the proposal, reserving "create" as the term for actually creating a new property. Also I slightly reworded point 2 and the first sentence to be clearer who the "property creator" is. ArthurPSmith (talk) 14:13, 3 April 2020 (UTC)
- Support —Eihel (talk) 10:19, 8 April 2020 (UTC)
- @Eihel, ArthurPSmith, Jura1, PKM, GZWDer: I've gone ahead and applied the draft to the page now as there seems to be no objections to its current form (no criteria have been changed, just clarified). If anyone reading this does not agree with them don't hesitate to revert and contribute to the discussion here. --SilentSpike (talk) 21:56, 9 April 2020 (UTC)
- Thanks SilentSpike. I would put the tags for the translation and I would mark the page to translate in a while (in case there is "a stir" on this modification and not to propagate modifications spaced little in time to the translated pages). Also following this discussion and the resulting change, this deletion should interest you. Warmest regards. —Eihel (talk) 01:16, 10 April 2020 (UTC)
Should the new properties be altered from how they were proposed (in the creation process)
I find it questionable that @UWashPrincipalCataloger: decided to
- change a property in the creation process that was not part of the original proposal and then even
- enforce his new rule without consensus
He could have participated in the property proposal, but he rather decided to change the property on his own. The ID property as it is now, is in a way useless to me because in some cases it only resolved one way. 😒
I hereby I suggest this page should have a paragraph along the lines of a property should not be substantially changed during creation. --Shisma (talk) 08:24, 28 February 2021 (UTC)
- I left a note for the new creator at User_talk:UWashPrincipalCataloger#Problematic_property_creation. --- Jura 09:21, 28 February 2021 (UTC)