> "Human Static" sensor data has not yet been collected at all, and forms an interesting area for future research.
Actually, I'm sure Christoph Aschwanden would agree that Human Stat data, demographics, experience, and other groupings, were exactly what our idea ( http://csdl.ics.hawaii.edu/Publications/MasterList.html#csdl2-02-10) was based on. I suppose we had no idea on how to apply it to Hackystat correctly. In that paper, we allowed students to complete a questionnaire to obtain demographic and experience information to try to determine if there differences in the data. Our motivation was to start to understand the differences in the Hackystat user community.
>Zorro DevEvent Data Examples - ProgramUnit:*
Do these events capture the addition, rename, etc of lines of code? I guess, I'm not sure what 'etc', means in the description. .
Furthermore, I'm not sure why these types are not of type Edit:*. What is the difference between ProgramUnit and Edit?
>Zorro DevEvent Data Examples - Edit:StateChange
If I'm reading this correctly, the pMap data is a snapshot of the current number of statements, methods, and test methods. Thus, unlike all the other 'types', one would have to compare two Edit:StateChange entries to determine what was actually added. I'm not sure if this is good or bad. I'm just pointing that out.
>Zorro DevEvent Data Examples
How about something that indicates an execution, ie running from Eclipse.
> Code Reading - Inferred when there is behavior occuring but no Edit:StatChange events.
Ok. So, does that mean there is something like File:Open or File:Close? I'm not sure if we are totally replacing Activity or not.
> HPC DevEvent data examples
Should the Compile and Edit types be Build:Compile and Edit:StateChange? Furthermore, should the types be prefixed by "HPC"? I'm not sure what happens if I have HPC and Zorro DevEvent entries mixed together. They have different pMap data and one would hope that you wouldn't have to check the optional attributes to determine the type of particular DevEvent entry.
thanks, aaron
At 11:02 AM 12/13/2005, you wrote:
A revised version of the DevEvent SDT requirements specification is now available at:
< http://hackydev.ics.hawaii.edu/hackyDevSite/doc/DevEvent.html>
I've rewritten the introduction to more clearly indicate the scope of the DevEvent SDT, revised the "Zorro" research project description, and most importantly, added a new section to incorporate a submission by Lorin Hochstein on their research project at the University of Maryland and how it would leverage this representation.
Please take a look and provide your comments. We can continue to revise and improve this document even as we move into concrete implementation, as it will provide guidance on improvements and future applications.
In terms of next steps, we are now initiating development activity related to DevEvent. First up, of course, will be the hackySdt_DevEvent module, containing the basic definition of DevEvent. Concurrently, we are working on a new module called hackySensor_IdeFramework, which will provide a higher level platform for use by Java-based IDEs along with an initial application of this framework to the IntelliJ IDE (which will be encapsulated in the hackySensor_IntelliJ module). Thanks to Greg Bylenok for contributing the code forming the basis for these modules. Once that is in place, we will start migrating our other Java-based IDE sensors (JBuilder, Eclipse) to this new framework, and introducing DevEvent sensor data collection at that time. There are some interesting design issues that we will face as a result of the requirements document regarding how and when a user can select which of the possible DevEvent 'families' of events to generate.
Cheers,
Philip
