Wikidata/Development/Issues

This page is for issues that have come up, and should be discussed in the sprint session, so we can decide on whether they should be turned into backlog items.

Week 6

• in the Content class, it would be nice to have a getSecondaryDataUpdates(), instead of having to use getParserOutput()->getSecondaryDataUpdates(). For non-flat formats, extracting the secondary data has nothign to do with creating html output.
  • getSecondaryDataUpdates() optionally takes the "previous" state. If given, it may generate updates that take into account the previous state and only update what actually changed.

Week 5

• Value update workflow: when a wikipedia editor sees a number in the info box and goes to change it, the new value should probably be added to the property (as visible per default?). Changing sources figures should be discouraged by the software in general - this should rarely be needed and is likely to be a mistake.

Week 4

• Wikipedia-Links have to be normalized wrt namespace aliases etc (in the db and when querying it) (5)
• When trying to save an edit that violates constrains (e.g. duplicate wiki link, conflicting with another item), how to handle the error? (8)
  • we'd need transactional logic across different storage systems
• decide caching/purging design... push or poll? db or http?
• start using bugzilla!
• spec the use of categories in wikidata
  • are categories items? or entities that may have a corresponding items?
• develop visual story boards (paper prototypes) for small-scale use cases like: (5)
  • "link a wikipedia article to an item"
  • "create an item for an existing wikipedia article"
  • "enter a reference to another item if that item doesn't yet exist."

Week 3

• Define a policy for copyright/authorship notices in wikibase code (send mail)
• check permissions when showing, creating, modifying and deleting items (?)
  • in the API
  • in the web interface
  • also check permissions to decide if the ajax edit interface should be enabled
  • use Title::userCan.
  • relevant permissions: view, edit, create, delete. Maybe also rename, etc
  • discuss and decide on a more fine grained design for permissions for data items.
• check if api for deleting and undeleting items (can we use the normal page-based api for this?)

• Discuss how references will be entered and formatted. Need form spec and rendering templates? (LATER)
• Plain aliases vs. properties as aliases (later)
• "Aspects" e.g. of UI: RTL, cross-browser, security, usability, etc -> definition of done
• Documentation?...
• <error code="internal_api_error_MWException" info="Exception Caught: Internal error in ApiFormatXml::recXmlPrint: (item, ...) has integer keys without _element value. Use ApiResult::setIndexedTagName()." xml:space="preserve" />
• Evaluate Deepa Mehta for modelling, etc
• Investigate integration with Deepa Mehta (use Wikidata as an external data source in DM)