Samantha_Alipio_WMDE added a comment.
In T261292#6491001 <https://phabricator.wikimedia.org/T261292#6491001>, @Pintoch wrote: > It looks great! Here are a few comments: > > - I assume the constraint ids don't appear there because the quality constraints extension is not installed on this wiki, but would appear otherwise? > - In the manifests that we use, we have currently added a `maxlag` setting (to know which `maxlag=` is recommended when making edits). I don't know if that is worth including in your version or if it is actually always going to be 5 in all deployments… > > Also, there will inevitably be things that will need to be added to the manifest, as the tools ecosystem and the core platform evolves. For instance, say OpenRefine wants to display a note about the license used on the target Wikibase instance, to make sure users are aware of it. Assuming the WikibaseManifest extension has already been deployed on Wikidata and other Wikibase instances, what sort of process should we follow to add this? I imagine we need to file a Phabricator ticket to propose a syntax for the new field, submit a Gerrit patch to add it to the extension, wait for a new release and deployment? Do you already have some ideas about the sort of policy you would apply to these changes? I assume it would be legitimate for you to be reluctant to add fields which are overly tool-specific and therefore outside the scope of this project. > > With that in mind, what is your expectation for tool builders: > > - We rely entirely on the manifest exposed by Wikibase: users can configure a Wikibase instance just by adding the corresponding URL. It is clean, but relies on the assumption that all configuration parameters we will ever need will be available there (and puts pressure on the release and deployment process on your side to get new fields shipped quickly) > - We still use our own configuration format, which is stripped of all information we can extract from the Wikibase instance via the new extension. This is more flexible, but still requires users to write manifests manually (although they would be much smaller). @Pintoch I think I worded my question in a less-than-clear way -- I was wondering if the amount of entities (items, properties) that we loaded into the test Wikibase is sufficient to replicate a production WB. As you are correctly pointing out, the Manifest itself linked on the main page of the test Wiki is still a work in progress and has yet to reflect the changes we are making in response to earlier feedback and the OpenRefine manifest. This includes adding `maxlag` (see T263640 <https://phabricator.wikimedia.org/T263640>). In terms of incorporating additional feedback, that is the goal of this test system -- for tool builders to try out this first version while it is still under development, to incorporate any changes we can before first release, and then to continue collecting feedback to make the Manifest useful for the broadest range of tools before a second release/deployment to Wikidata. I'll shoot you an email later this week to see if we can connect and talk through some of these details in the near future. TASK DETAIL https://phabricator.wikimedia.org/T261292 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Tarrow, Samantha_Alipio_WMDE Cc: Pintoch, Aklapper, Samantha_Alipio_WMDE, Alter-paule, Beast1978, Un1tY, Akuckartz, Hook696, darthmon_wmde, Kent7301, joker88john, CucyNoiD, Nandana, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, QZanden, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs