FeedBaG++‎ > ‎

Event Types

This page provides technical details about the type of data that is generated as feedback. Every event type is introduced and both the intention and the captured data are described in details.

Bottom line is that we capture every command that you give to Visual Studio, e.g. by clicking a button or by pressing a shortcut. Every executed command generates an event. Every event contains general information and -depending on the concrete command- additional specific context information.

For example, a trigger of IntelliSense ("Code Completion") captures the following information:

  • General:
    • When was IntelliSense triggered?
    • How was it invoked?
    • How long was it open?
    • What was the current document/window?
    • In which session* was the event generated?
  • Specific:
    • Information about the surrounding source code, in which IntelliSense was triggered.
    • A list of all IntelliSense-Proposals
    • A list of the selected proposals, incl. viewing time and order
    • Result of the code completion (i.e., cancellation or selection)

(* The captured feedback does not contain information that allows us to identify developers. Therefore, we generate a unique session "Session ID" (per day and per installation) that is attached to each event. This allows us to group all events of this work day.)

The captured feedback structure was discussed with the privacy council of a large German IT company and complies to German privacy requirements. We only capture information about interactions with Visual Studio, we do not instrument other applications. We do not capture information that can be used to identify developers or that contain personal information.

Detailed Information about Events

All captured events include some basic information that allows us to get a feeling about the typical duration of specific tasks and the way the task was invoked (i.e., mouse click, shortcut, etc.). All events include a session ID. It is generated once a day and groups all events of that day together and brings them in a logical context.

{
    "IDESessionUUID": active session 
while the event occurred
    "KaVEVersion": version of the KaVE extension that generated this event
    "TriggeredAt": point in time when this event started

    "TriggeredBy": kind of action that triggered the event

    "Duration": period of time this event lasted

    "ActiveWindow": active window while the event occurred

    "ActiveDocument": 
active document while the event occurred
}

Please note: Events cannot be assigned to specific developers, neither can the sessions! As soon as the data is uploaded to our server, we do not have any information about the origin of the event anymore!

Each event contains information that is special to the concrete event type. The following list introduces each event and all captured information.

Current Events

Activity Event

An Activity Event is triggered whenever the user is active in the IDE, e.g., moves the mouse. It does not contain any specific content.

We capture this separately, because not everything a user does in the IDE fires one of the following special events  and we want to be able to differentiate phases of complete inactivity from "consuming" phases, e.g., reading and scrolling in a document.

Command Event

A Command Event is trigger whenever an action is invoked. For example, it is created when clicking a button in a menu, when invoking a command via shortcut, or when a ReSharper "Bulb Action" ist started.

{
    "Command-ID": identifies the action/command that was executed
}

Completion Event

A CompletionEvent is created whenever IntelliSense is triggered. The event contains information about the proposed items, the interactions with IntelliSense, and the context in which IntelliSense was triggered.

The context contains information about the type system in the TypeShape and an abstracted version of the source code under edit in the form of a Simplified Syntax Tree (SST).

Note: The prefix is no longer directly stored in the  CompletionEvent, but in a CompletionExpr that is stored in the captured SST. You just have to traverse the SST (with a visitor), just be aware that -depending on the trigger location- this expression might not always exist.

{
    "Context": information about the sourrounding code
    {
        "TypeShape": type system information (see "TypeShape")
        "SST": information about the code under edit (see "SST")
    }
    "ProposalCollection": list of all items proposed by IntelliSense
    "Selections": interactions of the user with the proposals
    [
        {
            "Proposal": which proposal was selected
            "SelectedAfter": duration after which the proposal was selected
        },
        ...
    ]
    "TerminatedBy": how was the completion ended (e.g., SHORTCUT, CLICK, ...)
    "TerminatedState": result of the completion (e.g., APPLY, CANCEL, ...)
}

TypeShape:

{
    "TypeHierarchy": information about the type hierarchy
    {
        "Element": fully-qualified name of the type that is being referenced
        "Extends": 
reference to the extended TypeHierarchy (recursive)
        "Implements":
        [
            { reference to an implemented TypeHierarchy (recursive) },
            ...
        ]

    }

    "MethodHierarchies":
    [
        {
            "Element": Name of a method defined in the type under edit
            "Super": method that is overridden by the "Element" (maybe null)
            "First": method that first defined the signature (maybe null)
        }
    ]

}

SST:

{
    "EnclosingType": typename of the type under edit
    "Fields": information about all fields
    "Delegates": information about all delegates
    "Events": information about all events
    "Methods": information about all methods, incl. their bodies
    "Properties": information about all properties, incl. getter/setter bodies
}

Build Event

{
    "Scope": scope of the build event (PROJECT, SOLUTION, …)

    "Action": action that was triggered (BUILD, BUILD_ALL, CLEAN, …)

    "Targets": all target projects of this build events
    [

        {
            "Name": name of the project, relative to the solution
            "ProjectConfiguration": configuration of the project
            "SolutionConfiguration": configuration of the solution
            "StartedAt": date when the build action started
            "Duration": duration it took to finish the build action
            "Successful": indication whether the action was successful
        },
        ...
    ]
}

Debugger Event

{
    "Mode": debugger mode (DESIGN, RUN, BREAK, …)

    "Reason": cause of this event (e.g., BREAKPOINT, EXCEPTION, STEP, …)
    "Action": action of this event (e.g., DEFAULT, IGNORE, BREAK, …)
}

Document Event

{
    "DocumentName": file name of the dokument, relative to the solution

    "DocumentAction": action that took place (i.e., OPEN, SAVE, CLOSE)
}

Edit Event

We keep track of edits by a developer in source files. Sometime multiple edits happen at once (e.g., in case of a refactoring command), so these edits are aggregated in the data and the number of affected locations is stored.

{
    "NumberOfChanges": number of locations that changed

    "SizeOfChanges": rough estimation of the number of changed characters
}

Find Event

Find Events represent searches triggered within the IDE. We do not track concrete search queries, we are only interested if the search was successful or if it was cancelled.

{
    "Cancelled": was the find 
}

IDEState Event

Developers perform several tasks to change their work environment, e.g. rearranging windows, open new views, etc. IDEState events represent these actions.

{
    "LifecyclePhase": the current IDE state (i.e., 
STARTUP, RUNTIME, SHUTDOWN)

    "OpenWindows": list of open windows
    [

        {
            "WindowName": name of the window
        },

        ...

    ],

    OpenDocuments:
    [

        {
            "DokumentName": name of the document, relative to the solution
        },

        ...

    ]
}

Solution Event

{
    "Action": action that was performed (e.g., OpenSolution, RenameSolution, ...)
    "Target": IDE component on which the action was performed
}

Window Event

{
    "Window": name of active window
    "Action": action that was performed (e.g., MOVE, CLOSE, ...)
}

Version Control Event

We capture interactions with version control systems like Github that happen outside of the IDE. This is used to identify stable versions of the code (e.g., those that are committed) and versions that should be ignored (e.g., those that happen before a reset). 

For technical reasons, a single event might contain multiple actions.

{
    "Solution": the name of the solution which is related to this event
    "Actions" : [
        {
            "ExecutedAt": the timestamp when this action was executed
            "ActionType": the kind of action that was executed (e.g. commit)
        }

    ]

}

User Profile Event

We are super excited to learn more about our users! On the first upload, we kindly ask our users to provide some information about themselves and/or to create a unique profile id, which helps us making sense of our collected data. We also use these events as a simple mechanism to allow users sending comments and suggestions when uploading their data.

If the users volunteers to provide this data, User Profile Events are then attached to every upload of the user that contain the following information:

{
    "ProfileId": an optional unique id that a user can freely choose
    "Education": information about the highest degree a user holds
    "Position": information about the current job position of a user
    "Projects": in which kind of projects did the user work, recently?
    "Teams": in which kind of teams did the user work, recently?
    "CodeReviews": does the user regularly participate in code reviews?
    "ProgrammingGeneral": self-estimation of the general programming skills
    "ProgrammingCSharp":
 self-estimation of the C# programming skills
    "Comment": free text form for feedback and suggestions
}

Please note: Providing this information is completely optional. The profile id is unique, but anonymous.

Navigation Event

We monitor how users navigate in the source code. Therefore, we capture the location in the code, i.e. the surrounding method declaration, as well as jumps to new locations, e.g., by control-clicking a reference. This information is encoded like this:

{
    "TypeOfNavigation": what kind of navigation was performed (e.g., ctrl-click)
    "Location": where was the user working
    "Target": in case of a jump, where did the user want to go?
}

System Event

We monitor system relevant changes, e.g., when your mobile computer is sent to sleep or when the user locks the screen. This helps us to identify active periods in our event stream.

{
    "Type": What kind of event happenend? For example, screen was locked.
}

Test Run Event

We monitor which tests are run. This includes the duration of the run and the outcome.

{
    "WasAborted": Was the execution aborted?
    "Tests": [
        {
            "TestMethod": Which test was run?
            "Parameters": Parameterized tests are marked here.
            "Duration": How long did the test run?
            "Result": What was the result of the test run?
        }
    ]
}

Info Event

We use info events for logging and debugging purposes.

{
    "Info": arbitrary information, used for logging and debugging purposes
}

Error Event

Sometimes, things break. We use error events as a tool to store crashes of our own code base in the event stream. This allows us to analyze these errors later on.

{
    "Content": some error message or information about the current context
    "StackTrace": the stack-trace of the occurred error
}

Please note: The stored stack trace contains only frames that point to ReSharper and KaVE classes.

Deprecated Events

The project evolved over time. Some events that made sense back then, do not make sense any more. Our data model still contains bindings for the following events, but we do not generate them anymore in up-to-date installations.

Install Event

Install events represent the initial installation of  the KaVE extension.

{
    "PluginVersion": version of the KaVE plugin for an initial installation
}

Update Event

Update events are stored to identify updates of  the KaVE extension.

{
    "OldPluginVersion": version of the KaVE plugin before the update
    "NewPluginVersion": version of the KaVE plugin after the update
}