Introduction

This work is in progress. Here I will list all the additional data I'm considering it could be fine that sensors extract and SensorBase stores. Every data listed is expected to be included into the generic field 'Properties' in order to not require changes to data structures currently in use.

• This list is in the form of: key - value.
• The character '|' means 'or' to list possible alternatives for a given value.
• Characters used to separate values are firstly a simple space ' ' and then a double underscore __. They're either easily modifiable because are defined as static final constants within the code, in a unique dedicated class (as SEPARATOR1_ID and SEPARATOR2_ID). The SEPARATOR2_ID is used to replace all slashes within those URIs which contain full paths. I ALWAYS check if there's more than one value separated in this manner, with the except for some key values here highlighted in bold.

User

profileVisibility - 0(accessible only to admin or the user himself) | 1(accessible to any Hackystat registered user)

sensorDataVisibility - 0(accessible only to admin or the user himself) | 1(accessible to any Hackystat registered user)

Note: a user's role (retrievable into the already existing dedicated field 'role') could be 'Developer' or 'ProgectManager'. Otherwise a generic 'person' is referenced.

Project

profileVisibility - 0(accessible only to admin or the user himself) | 1(accessible to any Hackystat registered user)

developersList - email1 email2 ... emailn

maintainersList - email1 email2 ... emailn

testersList - email1 email2 ... emailn

helpersList - email1 email2 ... emailn

documentersList - email1 email2 ... emailn

translatorsList - email1 email2 ... emailn

repositoryAnonymousRoot - repForAnonymousAccess

repositoryWebInterface - webBrowserInterfaceToRepository

repositoryLocation - uri

repositoryType - type (e.g. cvs)

downloadPage - url1 url2 ... urln

mirrorList - url1 url2 ... urln

wiki - url1 url2 .. urln

bugDatabase - name1__url1 name2__url2 ... namen__urln

operatingSystem - name1 name2 ... namen

programmingLanguage - name1 name2 ... namen

testIdPurposeList - id1__keyWord1 id2__keyWord2 ... idn__keyWordn

Sensor Data

I'm trying to avoid to add necessary additional data to the SensorData's Properties field, because to retrieve a value in that field, I have to browse the whole, enormous SD set. So the few additional data expected and listed below, are going to be deeply motivated and these motivations are included here.

Only for "CLI" SDT:

machine - name

operatingSystem - name

command - commandStr

arguments - paramValue1 paramValue2 ... paramValuen

result - resultInFreeText1__resultInFreeText2__...resultInFreeTextn

Motivation: links to results got by others for the same command on the same OS and machine, with the same types of parameters

The following data are already provided by the new Issue sensor designed by Shaoxuan during these days.

issueType - type (because there could be lots of types of issues, such as enhancement, defect, etc.)

status - status

priority - priority

milestone - targetMilestone

owner - email

I've asked Shaoxuan if also the following data are provided by his new Issue sensor

reporter - email

assignedTo - email1 email2 ... emailn

interested - email1 email2 ... emailn (users interested in changes to this issue)

comments - uri1 uri2 ... urin (uri of comments posted on this issue)

dependsOn - issueId1 issueId2 ... issueIdn

causes - issueId1 issueId2 ... issueIdn

operatingSystem - name

environment - environmentDescription

votes - numberOfVotes

resolvedWith - patchId1 patchId2 ... patchIdn

Future directions

A new SDT proposal for future directions: "Test" SensorDataType

----------------Test Profile

testIdentifier - id

testTitle - title

testPurpose - purpose

testDescription - description

testStatus - status

testSpecRef - linkToSpecificationTested

testPreconditions - preconditionsInFreeText (It might be necessary that a network connection be available or a server process be running before the test is executed)

testInputs - paramType1__paramName1__paramValue1 paramType2__paramName2__paramValue2 ... paramTypen__paramNamen__paramValuen

testExpectedResultsDescription - expectedResultsInFreeText

testExpectedResults - paramType1__rangeStart1__rangeEnd1 paramType2__rangeStart2__rangeEnd2 ... paramTypen__rangeStartn__rangeEndn

testGroup - nameOfTheGroupToWhichThisTestBelongs

testSeeAlso - uri1 uri2 ... urin (Can help to clarify the intent or usefulness of the test. For example a pointer to an item in an issue-tracking system or to a mailing list thread in which the justification for this test is discussed).

--------------------------SD coming from a Test instance

testIdentifier - testId

testVersion - versionNumber (e.g. from a cvs)

testContributor - email1 email2 ... emailn

testResults - paramType1__value1 paramType2__value2 ... paramTypen__valuen

Motivation:

• tracking tests during development and review process
• filtering tests according to a variety of criteria (for example, whether or not they are applicable for a particular profile or optional feature)
• identifying the area of the specification that is tested by the tests
• constructing a test harness to automatically execute the tests
• formatting test results so that they are easily understood