Hi! > (1) Statement- and property-level watching for changes (seeing > problematic changes should come before disallowing them)
This might be harder to do as it's not really possible - internally - to edit just one statement. It looks like editing one statement, but the data for the whole entity is stored together, so you are actually always edit the whole entity. Which means additional code is needed to filter the watches. Though if the number of watches is small it may be fine. Additional question is what exactly is "statement"? We do not have any user-exposed identity for statement, and internal identity can change with each edit. So if you edit the statement - for how long it is the same statement as before? (Ship of Theseus problem :) > (2) Statement- and property-level history (it's currently really hard to > find out who last changed a property, e.g., to contact the person or to > look at their other edits) Again, due to the above two it may be a bit hard to construct - though we do have diffs, relating diffs to specific statement may be tricky. Property, though, probably is much easier since they have clear identity. It should be possible at least to have some code allowing to answer questions like "which edit was the last one to touch this property" and "which edits changed this property's statements" though it is not trivial and I don't think it exists now. > (3) Statement- and property-level protection (for the hard cases, mostly > temporarily, same policies as for page-level protection) > (4) Statement-level patrolling (can I approve a more recent change to > P31 without approving an older change to P580?) This may be possible but I'm not sure it's necessary. The watch approach below may be more effective and more consistent with the project spirit, I think. > (5) Query-based watching: if you want to watch all property changes for > a large set of articles, you need better tools I think a tool that takes a query and creates a list, and allows to: 1. See how the list changes over time 2. Mark some items on the list as "ok" and some as "not ok" 3. Alert people on changes in the list would make watching for such changes much easier. > (6) More work on edit filters (preventing some edits based on content, > e.g., the use of shortened URLs as a homepage) > (7) Better UIs to prevent accidental edits (e.g., I can see a lot of > cases where people have entered qualifier information as new statement > values) That's a good case for watching too - we have properties that are predominantly used in qualifiers, and even marked so. It should not be hard to make auto-lists with violations and have people to look at it. > (8) Further work on easy-to-customise quality analysis and display of > related results (the constraint service is great, but hard to use in a > targeted way to find errors in a specific area). While data-vandalism > can have far-reaching consequences, it also is much harder to hide if > the community has the right tools at hand. > (9) Better data importing infrastructures (some problems mentioned in > this thread seem to be caused by a multi-stage data import approach that > only works if nothing changes in the meantime; I am sure one could get > this fixed without relying on user-editable data). -- Stas Malyshev smalys...@wikimedia.org _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
