Wikidata:Property proposal/Software quality assurance

Software quality assurance edit

Done: software quality assurance (P2992) (Talk and documentation)

Description	the quality assurance process in place for a particular software
Data type	Item
Domain	Wikidata property related to software (Q21126229)
Example	CKAN (Q977484) → continuous integration (Q965769)
Source	https://en.wikipedia.org/wiki/Software_quality_assurance

Motivation

The Software quality assurance process in place for a software plays a significant role in the stability of the software releases. When the software is modified to fix a bug, the quality assurance process verifies that it does not also breaks something that used to work. In the same way the license determines the legal stability of a software, the quality assurance process determines the stability of its behaviour.

The object item should be an instance of quality assurance (Q836575) (e.g. software testing (Q188522)). The reference URL should describe how the quality assurance process is applied to the software. Instead of stating that https://circleci.com/ is used, it should instead be the URL of the file that describes how circleci is being used, for instance https://github.com/ckan/ckan/blob/master/.circleci-matrix.yml.

The quality assurance (Q836575) item exists and is used for categories. It also is used as a workaround while this property is being discussed, for instance with Loomio (Q15975673), so that a bot can replace the existing values by selecting software for which there is a quality assurance value with a described at URL with the Software quality assurance property instead of the introduced feature property which is not appropriate.

Discussion

Comment the example given seems to be merely an index page for software documentation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:22, 29 June 2016 (UTC)[reply]
updated the example with a URL to the actual Software QA process (assuming the software used to run it can be added as a qualifier) Talk to Dachary; 1 july 2016
Support Of course, I support my own proposal. Talk to Dachary; 7 july 2016
Comment Not sure that the chosen name is very meaningful. What about "Continuous integration process description" or something like that? Tpt (talk) 09:19, 8 July 2016 (UTC)[reply]
are you suggesting that it would make sense to have CKAN (Q977484) → continuous integration (Q965769) with a reference set to reference URL (P854) with value https://github.com/ckan/ckan/blob/master/.circleci-matrix.yml instead ? I think it's sensible.
The type was changed from URL to Item as well as the example
Support Tpt (talk) 15:21, 11 July 2016 (UTC)[reply]
Comment I have some questions about this proposal. The name does not make sense to me - it should at least include the word "process". The word "software" seems ambiguous also - what items do we expect to be eligible to receive this property? Commercial products that run on personal computers? Smart phone apps? Websites? Server-side code? Code used for analysis or simulation in science? Open source projects? Is it intended to be retrospective, i.e. this web service was developed using xxx software Q-A process? Or prospective, i.e. future releases of this application are expected to be developed using yyyy Q-A process? Can it be applied to a company or organization's software culture as a whole, for example Google uses zzzz software Q-A process as a standard in its work? How does this relate to general corporate quality standards like 6-sigma etc.? I think this needs a bunch more discussion to better clarify the purpose and scope here... ArthurPSmith (talk) 20:38, 12 July 2016 (UTC)[reply]
Comment The name was chosen because https://en.wikipedia.org/wiki/Software_quality_assurance exists and that IEEE 730 defines it. Either Plan or Process could be append, but I figured it could be Plan sometimes, even though it's likely to be Process most of the time. Because it's limited to quality assurance applied to software, any subclass of software is eligible, i.e. all you've mentionned. The prospective / retrospective aspect is a very good point and I did not think of it. It is marginaly useful to know the SQA for a software that is deprecated. It is very useful to know the SQA for a stable version of a software from the point of view of the user because it determines the quality of the next stable release with security patches etc. It is very useful to know the SQA for the on-going development version when dealing with Free Software because it determines the ability of a contributor to verify that a patch does not introduce a regression. IMHO the relationship of an item with quality standards is a different problem. Here we're interested in the description of how SQA is involved, not about which QA certification has been obtained for which version of the software. Thanks for taking the time to look into this proposal :-) Talk to Dachary; 15 july 2016
Support I think a separate property is a good idea, because there also seems to be a lot of controlled vocabulary attached to it. --Tobias1984 (talk) 07:01, 17 July 2016 (UTC)[reply]

@Dachary, Tpt, Tobias1984: Done Now software quality assurance (P2992) --Lymantria (talk) 15:05, 23 July 2016 (UTC)[reply]