| SMWCon Fall 2015 | |
|---|---|
| Semantic MediaWiki issues triage | |
| Talk details | |
| Description: | This workshop aims to triage, fill in blanks and even solve some of the existing issues filed for Semantic MediaWiki |
| Speaker(s): | Jeroen De Dauw, Karsten Hoffmeyer |
| Type: | Workshop, Hackathon |
| Audience: | Developers, Community, Admins |
| Event start: | 2015/10/28 11:15:00 AM |
| Event finish: | 2015/10/28 03:30:00 PM |
| Length: | 165 minutes |
| Video: | not available |
| Keywords: | issue triage, issues, bugs, Semantic MediaWiki, semantic extension |
| Give feedback | |
This workshop aims to triage, fill in blanks and even solve some of the existing issues filed for Semantic MediaWiki at GitHub (enhancements, bugs). It also intends to involve more people and help them make the first step in contributing, so everyone is welcome to participate.
Objective[edit]
Semantic MediaWiki issue list has ~130 entries with some classified as features others tagged as legitimate issue so the triage session can be used
- to sort out and improve the description of an issue
- add examples to clarify the intent and
- verify that an issue is still valid for the current SMW 2.3 (+ 2.4-alpha)
Add your issue! (that is a known issue on the SMW list)[edit]
In the run-up of this workshop people are invited to add up to three of their most important bugs or issues for Semantic MediaWiki. This will help kick-starting this workshop.
- Result column duplicaton on "further results ..." --[[kgh]] (talk) 19:53, 18 September 2015 (CEST)
- Enable "Category" as a possible value for the "sort" parameter of ask queries. Lex Sulzer (talk) 10:10, 8 October 2015 (CEST)
Non SMW-core issues[edit]
- If a tokens field has its "values from concept=" then its autocompletion seems not to drill down on matching values by hiding non-matching values, but only highlights the matching string in a list of all values. This behaviour doesn't occur e.g. for "values from category=". (MW:1.25.2, SMW:2.2.2, SF:3.3.1) Lex Sulzer (talk) 10:30, 8 October 2015 (CEST)
- If the "tree input" is used in "multiple" templates embedded in a "main" template, then the tree input seems to behave as follows: 1) it doesn't accept clicks right after having been instantiated in an added "multiple" template, 2) the first instantiation will accept clicks upon the second "edit" activity, i.e. "edit with form" showing an already instantiated "multiple" template, 3) upon adding a further instance of the "multiple" template, only the first instance's tree input accepts clicks, etc. It seems that the added tree input's DOM registration is not working correctly. (MW:1.25.2, SMW:2.2.2, SF:3.3.1) Lex Sulzer (talk) 11:30, 8 October 2015 (CEST)
