+1 Sent from my iPhone
> On Jun 13, 2016, at 4:34 PM, Lewis John Mcgibbney <lewis.mcgibb...@gmail.com> > wrote: > > Title here should be [VOTE] Accept SensSoft into the Apache Incubator > > On Mon, Jun 13, 2016 at 10:55 AM, Lewis John Mcgibbney < > lewis.mcgibb...@gmail.com> wrote: > >> Hi general@, >> Since I am back from a bit of vacation and it seems the discussion has >> died down, I am now calling a vote on accepting SensSoft into the Apache >> Incubator. >> >> For those who are interested the DISCUSS thread can be found at >> https://s.apache.org/senssoft_discuss >> >> This vote will run for the usual 72 hours. >> >> Please VOTE as follows >> >> [ ] +1 Accept SensSoft into the Apache Incubator >> [ ] +/-0 Not overly bothered either way >> [ ] -1 DO NOT accept SensSoft into the Apache Incubator (please state why) >> >> Thanks everyone who contributed to DISCUSS and is able to participate in >> VOTE >> >> Best >> Lewis >> P.S. Here is my +1 >> >> ##################### >> >> = SensSoft Proposal = >> >> == Abstract == >> The Software as a Sensor™ (SensSoft) Project offers an open-source (ALv2.0) >> software tool usability testing platform. It includes a number of >> components that work together to provide a platform for collecting data >> about user interactions with software tools, as well as archiving, >> analyzing and visualizing that data. Additional components allow for >> conducting web-based experiments in order to capture this data within a >> larger experimental framework for formal user testing. These components >> currently support Java Script-based web applications, although the schema >> for “logging” user interactions can support mobile and desktop >> applications, as well. Collectively, the Software as a Sensor Project >> provides an open source platform for assessing how users interacted with >> technology, not just collecting what they interacted with. >> >> == Proposal == >> The Software as a Sensor™ Project is a next-generation platform for >> analyzing how individuals and groups of people make use of software tools >> to perform tasks or interact with other systems. It is composed of a number >> of integrated components: >> * User Analytic Logging Engine (User ALE) refers to a simple Application >> Program Interface (API) and backend infrastructure. User ALE provides >> “instrumentation” for software tools, such that each user interaction >> within the application can be logged, and sent as a JSON message to an >> Elasticsearch/Logstash/Kibana (Elastic Stack) backend. >> * The API provides a robust schema that makes user activities human >> readable, and provides an interpretive context for understanding that >> activity’s functional relevance within the application. The schema provides >> highly granular information best suited for advanced analytics. This >> hierarchical schema is as follows: >> * Element Group: App features that share function (e.g., map group) >> * Element Sub: Specific App feature (e.g., map tiles) >> * Element Type: Category of feature (e.g., map) >> * Element ID: [attribute] id >> * Activity: Human imposed label (e.g., “search”) >> * Action: Event class (e.g., zoom, hover, click) >> * The API can either be manually embedded in the app source code, or >> implemented automatically by inserting a script tag in the source code. >> * Users can either setup up their own Elastic stack instance, or use >> Vagrant, a virtualization environment, to deploy a fully configured Elastic >> stack instance to ship and ingest user activity logs and visualize their >> log data with Kibana. >> * RESTful APIs allow other services to access logs directly from >> Elasticsearch. >> * User ALE allows adopters to own the data they collect from users >> outright, and utilize it as they see fit. >> * Distill is an analytics stack for processing user activity logs >> collected through User ALE. Distill is fully implemented in Python, >> dependent on graph-tool to support graph analytics and other external >> python libraries to query Elasticsearch. The two principle functions of >> Distill are segmentation and graph analytics: >> * Segmentation allows for partitioning of the available data along >> multiple axes. Subsets of log data can be selected via their attributes in >> User ALE (e.g. Element Group or Activity), and by users/sessions. Distill >> also has the capability to ingest and segment data by additional attributes >> collected through other channels (e.g. survey data, demographics).This >> allows adopters to focus their analysis of log data on precisely the >> attributes of their app (or users) they care most about. >> * Distill’s usage metrics are derived from a probabilistic >> representation of the time series of users’ interactions with the elements >> of the application. A directed network is constructed from the >> representation, and metrics from graph theory (e.g. betweenness centrality, >> in/out-degree of nodes) are derived from the structure. These metrics >> provide adopters ways of understanding how different facets of the app are >> used together, and they capture canonical usage patterns of their >> application. This broad analytic framework provides adopters a way to >> develop and utilize their own metrics >> * The Test Application Portal (TAP) provides a single, user-friendly >> interface to Software as a Sensor™ Project components, including >> visualization functionality for Distill Outputs leveraging Django, React, >> and D3.js. It has two key functions: >> * It allows adopters to register apps, providing metadata regarding >> location, app name, version, etc., as well as permissions regarding who can >> access user data. This information is propagated to all other components of >> the larger system. >> * The portal also stages visualization libraries that make calls to >> Distill. This allows adopters to analyze their data as they wish to; it’s >> “dashboard” feel provides a way to customize their views with >> adopter-generated widgets (e.g., D3 libraries) beyond what is included in >> the initial open source offering. >> * The Subject Tracking and Online User Testing (STOUT) application is an >> optional component that turns Software as a Sensor™ Technology into a >> research/experimentation enterprise. Designed for psychologists and HCI/UX >> researchers, STOUT allows comprehensive human subjects data protection, >> tracking, and tasking for formal research on software tools. STOUT is >> primarily python, with Django back-end for authentication, permissions, and >> tracking, MongoDB for databasing, and D3 for visualization. STOUT includes >> a number of key features: >> * Participants can register in studies of software tools using their own >> preferred credentials. As part of registration, participants can be >> directed through human subjects review board compliant consent forms before >> study enrollment. >> * STOUT stores URLs to web/network accessible software tools as well as >> URLs to third party survey services (e.g., surveymonkey), this allows >> adopters to pair software tools with tasks, and collect survey data and >> comments from participants prior to, during, or following testing with >> software tools. >> * STOUT tracks participants’ progress internally, and by appending a >> unique identifier, and task identifier to URLs. This information can be >> passed to other processes (e.g., User ALE) allowing for disambiguation >> between participants and tasks in experiments on the open web. >> * STOUT supports between and within-subjects experimental designs, with >> random assignment to experimental conditions. This allows for testing >> across different versions of applications. >> * STOUT can also use Django output (e.g., task complete) to automate >> other processes, such as automated polling applications serving 3rd party >> form data APIs (e.g.,SurveyMonkey), and python or R scripts to provide >> automated post-processing on task or survey data. >> * STOUT provides adopters a comprehensive dashboard view of data >> collected and post-processed through its extensions; in addition to user >> enrollment, task completion, and experiment progress metrics, STOUT allows >> adopters to visualize distributions of scores collected from task and >> survey data. >> >> Each component is available through its own repository to support organic >> growth for each component, as well as growth of the whole platform’s >> capabilities. >> >> == Background and Rationale == >> Any tool that people use to accomplish a task can be instrumented; once >> instrumented, those tools can be used to report how they were used to >> perform that task. Software tools are ubiquitous interfaces for people to >> interact with data and other technology that can be instrumented for such a >> purpose. Tools are different than web pages or simple displays, however; >> they are not simply archives for information. Rather, they are ways of >> interfacing with and manipulating data and other technology. There are >> numerous consumer solutions for understanding how people move through web >> pages and displays (e.g., Google Analytics, Adobe Omniture). There are far >> fewer options for understanding how software tools are used. This requires >> understanding how users integrate a tool’s functionality into usage >> strategies to perform tasks, how users sequence the functionality provided >> them, and deeper knowledge of how users understand the features of software >> as a cohesive tool. The Software as a Sensor™ Project is designed to >> address this gap, providing the public an agile, cost-efficient solution >> for improving software tool design, implementation, and usability. >> >> == Software as a Sensor™ Project Overview == >> >> {{attachment:userale_figure_1.png}} >> >> Figure 1. User ALE Elastic Back End Schema, with Transfer Protocols. >> >> Funded through the DARPA XDATA program and other sources, the Software as a >> Sensor™ Project provides an open source (ALv2.0) solution for instrumenting >> software tools developed for the web so that when users interact with it, >> their behavior is captured. User behavior, or user activities, are captured >> and time-stamped through a simple application program interface (API) >> called User Analytic Logging Engine (User ALE). User ALE’s key >> differentiator is the schema that it uses to collect information about user >> activities; it provides sufficient context to understand activities within >> the software tool’s overall functionality. User ALE captures each user >> initiated action, or event (e.g., hover, click, etc.), as a nested action >> within a specific element (e.g., map object, drop down item, etc.), which >> are in turn nested within element groups (e.g., map, drop down list) (see >> Figure 1). This information schema provides sufficient context to >> understand and disambiguate user events from one another. In turn, this >> enables myriad analysis possibilities at different levels of tool design >> and more utility to end-user than commercial services currently offer. >> Once instrumented with User ALE, software tools become human signal sensors >> in their own right. Most importantly, the data that User ALE collects is >> owned outright by adopters and can be made available to other processes >> through scalable Elastic infrastructure and easy-to-manage Restful APIs. >> Distill is the analytic framework of the Software as a Sensor™ Project, >> providing (at release) segmentation and graph analysis metrics describing >> users’ interactions with the application to adopters. The segmentation >> features allow adopters to focus their analyses of user activity data based >> on desired data attributes (e.g., certain interactions, elements, etc.), as >> well as attributes describing the software tool users, if that data was >> also collected. Distill’s usage and usability metrics are derived from a >> representation of users’ sequential interactions with the application as a >> directed graph. This provides an extensible framework for providing insight >> as to how users integrate the functional components of the application to >> accomplish tasks. >> >> {{attachment:userale_figure_2.png}} >> >> Figure 2. Software as a Sensor™ System Architecture with all components. >> >> The Test Application Portal (TAP) provides a single point of interface for >> adopters of the Software as a Sensor™ project. Through the Portal, adopters >> can register their applications, providing version data and permissions to >> others for accessing data. The Portal ensures that all components of the >> Software as a Sensor™ Project have the same information. The Portal also >> hosts a number of python D3 visualization libraries, providing adopters >> with a customizable “dashboard” with which to analyze and view user >> activity data, calling analytic processes from Distill. >> Finally, the Subject Tracking and Online User Testing (STOUT) application, >> provides support for HCI/UX researchers that want to collect data from >> users in systematic ways or within experimental designs. STOUT supports >> user registration, anonymization, user tracking, tasking (see Figure 3), >> and data integration from a variety of services. STOUT allows adopters to >> perform human subject review board compliant research studies, and both >> between- and within-subjects designs. Adopters can add tasks, surveys and >> questionnaires through 3rd party services (e.g., SurveyMonkey). STOUT >> tracks users’ progress by passing a unique user IDs to other services, >> allowing researchers to trace progress by passing a unique user IDs to >> other services, allowing researchers to trace form data and User ALE logs >> to specific users and task sets (see Figure 4). >> >> {{attachment:userale_figure_3.png}} >> >> Figure 3. STOUT assigns participants subjects to experimental conditions >> and ensures the correct task sequence. STOUT’s Django back end provides >> data on task completion, this can be used to drive other automation, >> including unlocking different task sequences and/or achievements. >> >> {{attachment:userale_figure_4.png}} >> >> Figure 4. STOUT User Tracking. Anonymized User IDs (hashes) are >> concatenated with unique Task IDs. This “Session ID” is appended to URLs >> (see Highlighted region), custom variable fields, and User ALE, to provide >> and integrated user testing data collection service. >> >> STOUT also provides for data polling from third party services (e.g., >> SurveyMonkey) and integration with python or R scripts for statistical >> processing of data collected through STOUT. D3 visualization libraries >> embedded in STOUT allow adopters to view distributions of quantitative data >> collected from form data (see Figure 5). >> >> {{attachment:userale_figure_5.png}} >> >> Figure 5. STOUT Visualization. STOUT gives experimenters direct and >> continuous access to automatically processed research data. >> >> == Insights from User Activity Logs == >> >> The Software as a Sensor™ Project provides data collection and analytic >> services for user activities collected during interaction with software >> tools. However, the Software as a Sensor™ Project emerged from years of >> research focused on the development of novel, reliable methods for >> measuring individuals’ cognitive state in a variety of contexts. >> Traditional approaches to assessment in a laboratory setting include >> surveys, questionnaires, and physiology (Poore et al., 2016). Research >> performed as part of the Software as a Sensor™ project has shown that the >> same kind of insights derived from these standard measurement approaches >> can also be derived from users’ behavior. Additionally, we have explored >> insights that can only be gained by analyzing raw behavior collected >> through software interactions (Mariano et al., 2015). The signal processing >> and algorithmic approaches resulting from this research have been >> integrated into the Distill analytics stack. This means that adopters will >> not be left to discern for themselves how to draw insights from the data >> they gather about their software tools, although they will have the freedom >> to explore their own methods as well. >> Insights from user activities provided by Distill’s analytics framework >> fall under two categories, broadly classified as functional workflow and >> usage statistics: >> Functional workflow insights tell adopters how user activities are >> connected, providing them with representations of how users integrate the >> application’s features together in time. These insights are informative for >> understanding the step-by-step process by which users interact with certain >> facets of a tool. For example, questions like “how are my users, >> constructing plots?” are addressable through workflow analysis. Workflows >> provide granular understanding of process level mechanics and can be >> modeled probabilistically through a directed graph representation of the >> data, and by identification of meaningful sub-sequences of user activities >> actually observed in the population. Metrics derived provide insight about >> the structure and temporal features of these mechanics, and can help >> highlight efficiency problems within workflows. For example, workflow >> analysis could help identify recursive, repetitive behaviors, and might be >> used to define what “floundering” looks like for that particular tool. >> Functional workflow analysis can also support analyses with more breadth. >> Questions like, “how are my users integrating my tools’ features into a >> cohesive whole? Are they relying on the tool as a whole or just using very >> specific parts of it?” Adopters will be able to explore how users think >> about software as cohesive tools and examine if users are relying on >> certain features as central navigation or analytic features. This allows >> for insights into whether tools are designed well enough for users to >> understand that they need to rely on multiple features together. >> Through segmentation, adopters can select the subset of the data -software >> element, action, user demographics, geographic location, etc.- they want to >> analyze. This will allow them to compare, for example, specific user >> populations against one another in terms of how they integrate software >> functionality. Importantly, the graph-based analytics approach provides a >> flexible representation of the time series data that can capture and >> quantify canonical usage patterns, enabling direct comparisons between >> users based on attributes of interest. Other modeling approaches have been >> utilized to explore similar insights and may be integrated at a later date >> (Mariano, et al., 2015). >> Usage statistics derive metrics from simple frequentist approaches to >> understanding, coarsely, how much users are actually using applications. >> This is different from simple “traffic” metrics, however, which assess how >> many users are navigating to a page or tool. Rather usage data provides >> insight on how much raw effort (e.g., number of activities) is being >> expended while users are interacting with the application. This provides >> deeper insight into discriminating “visitors” from “users” of software >> tools. Moreover, given the information schema User ALE provides, adopters >> will be able to delve into usage metrics related to specific facets of >> their application. >> Given these insights, different sets of adopters—software developers, >> HCI/UX researchers, and project managers—may utilize The Software as a >> Sensor™ Project for a variety different use cases, which may include: >> * Testing to see if users are interacting with software tools in expected >> or unexpected ways. >> * Understanding how much users are using different facets of different >> features in service of planning future developments. >> * Gaining additional context for translating user/customer comments into >> actionable software fixes. >> * Understanding which features users have trouble integrating to guide >> decisions on how to allocate resources to further documentation. >> * Understanding the impact that new developments have on usability from >> version to version. >> * Market research on how users make use of competitors’ applications to >> guide decisions on how to build discriminating software tools. >> * General research on Human Computer Interaction in service of refining UX >> and design principles. >> * Psychological science research using software as data collection >> platforms for cognitive tasks. >> >> == Differentiators == >> >> The Software as a Sensor™ Project is ultimately designed to address the >> wide gaps between current best practices in software user testing and >> trends toward agile software development practices. Like much of the >> applied psychological sciences, user testing methods generally borrow >> heavily from basic research methods. These methods are designed to make >> data collection systematic and remove extraneous influences on test >> conditions. However, this usually means removing what we test from dynamic, >> noisy—real-life—environments. The Software as a Sensor™ Project is designed >> to allow for the same kind of systematic data collection that we expect in >> the laboratory, but in real-life software environments, by making software >> environments data collection platforms. In doing so, we aim to not only >> collect data from more realistic environments, and use-cases, but also to >> integrate the test enterprise into agile software development process. >> Our vision for The Software as a Sensor™ Project is that it provides >> software developers, HCI/UX researchers, and project managers a mechanism >> for continuous, iterative usability testing for software tools in a way >> that supports the flow (and schedule) of modern software development >> practices—Iterative, Waterfall, Spiral, and Agile. This is enabled by a few >> discriminating facets: >> >> {{attachment:userale_figure_6.png}} >> >> Figure 6. Version to Version Testing for Agile, Iterative Software >> Development Methods. The Software as a Sensor™ Project enables new methods >> for collecting large amounts of data on software tools, deriving insights >> rapidly to inject into subsequent iterations >> >> * Insights enabling software tool usability assessment and improvement can >> be inferred directly from interactions with the tool in “real-world” >> environments. This is a sea-change in thinking compared to canonical >> laboratory approaches that seek to artificially isolate extraneous >> influences on the user and the software. The Software as a Sensor™ Project >> enables large scale, remote, opportunities for data collection with minimal >> investment and no expensive lab equipment (or laboratory training). This >> allows adopters to see how users will interact with their technology in >> their places of work, at home, etc. >> >> * Insights are traceable to the software itself. Traditionally laboratory >> measures—questionnaires, interviews, and physiology—collect data that is >> convenient for making inferences about psychological states. However, it is >> notoriously difficult to translate this data into actionable “get-well” >> strategies in technology development. User ALE’s information schema is >> specifically designed to dissect user interaction within the terminology of >> application design, providing a familiar nomenclature for software >> developers to interpret findings with. >> >> * Granular data collection enables advanced modeling and analytics. User >> ALE’s information schema dissects user interaction by giving context to >> activity within the functional architecture of software tools. Treating >> each time-series of user activity as a set of events nested within >> functional components provides sufficient information for a variety of >> modeling approaches that can be used to understand user states (e.g., >> engagement and cognitive load), user workflows (e.g., sub-sequences), and >> users’ mental models of how software tool features can be integrated (in >> time) to perform tasks. In contrast, commercial services such as Google >> Analytics and Adobe Analytics (Omniture) provide very sparse options for >> describing events. They generally advocate for using “boiler plate” event >> sets that are more suited to capturing count data for interactions with >> specific content (e.g., videos, music, banners) and workflows through >> “marketplace” like pages. User ALE provides content agnostic approaches for >> capturing user activities by letting adopters label them in domain specific >> ways that give them context. This provides a means by which identical user >> activities (e.g. click, select, etc.) can be disambiguated from each other >> based on which functional sub-component of the tool they have been assigned >> to. >> >> * Adopter-generated content, analytics and data ownership. The Software as >> a Sensor™ Project is a set of open-source products built from other >> open-source products. This project will allow adopters to generate their >> own content easily, using open source analytics and visualization >> capabilities. By design, we also allow adopters to collect and manage their >> own data with support from widely used open source data architectures >> (e.g., Elastic). This means that adopters will not have to pay for >> additional content that they can develop themselves to make use of the >> service, and do not have to expose their data to third party commercial >> services. This is useful for highly proprietary software tools that are >> designed to make use of sensitive data, or are themselves sensitive. >> >> == Current Status == >> >> All components of the Software as a Sensor™ Project were originally >> designed and developed by Draper as part of DARPA’s XDATA project, although >> User ALE is being used on other funded R&D projects, including DARPA >> RSPACE, AFRL project, and Draper internally funded projects. >> Currently, only User ALE is publically available, however, the Portal, >> Distill, and STOUT will be publically available in the May/June 2016 >> time-frame. The last major release of User ALE was May, 2015. All >> components are currently maintained in separate repositories through GitHub >> (github.com/draperlaboratory). >> Currently, only software tools developed with Javascript are supported. >> However, we are currently working on pythonQT implementations for User ALE >> that will support many desktop applications. >> >> == Meritocracy == >> The current developers are familiar with meritocratic open source >> development at Apache. Apache was chosen specifically because we want to >> encourage this style of development for the project. >> >> == Community == >> The Software as a Sensor™ Project is new and our community is not yet >> established. However, community building and publicity is a major thrust. >> Our technology is generating interest within industry, particularly in the >> HCI/UX community, both Aptima and Charles River Analytics, for example are >> interested in being adopters. We have also begun publicizing the project to >> software development companies and universities, recently hosting a public >> focus group for Boston, MA area companies. >> We are also developing communities of interested within the DoD and >> Intelligence community. The NGA Xperience Lab has expressed interest in >> becoming a transition partner as has the Navy’s HCIL group. We are also >> aggressively pursuing adopters at AFRL’s Human Performance Wing, Analyst >> Test Bed. >> During incubation, we will explicitly seek to increase our adoption, >> including academic research, industry, and other end users interested in >> usability research. >> >> == Core Developers == >> The current set of core developers is relatively small, but includes Draper >> full-time staff. Community management will very likely be distributed >> across a few full-time staff that have been with the project for at least 2 >> years. Core personnel can be found on our website: >> http://www.draper.com/softwareasasensor >> >> == Alignment == >> The Software as a Sensor™ Project is currently Copyright (c) 2015, 2016 The >> Charles Stark Draper Laboratory, Inc. All rights reserved and licensed >> under Apache v2.0. >> >> == Known Risks == >> >> === Orphaned products === >> There are currently no orphaned products. Each component of The Software as >> a Sensor™ Project has roughly 1-2 dedicated staff, and there is substantial >> collaboration between projects. >> >> === Inexperience with Open Source === >> Draper has a number of open source software projects available through >> www.github.com/draperlaboratory. >> >> == Relationships with Other Apache Products == >> Software as a Sensor™ Project does not currently have any dependences on >> Apache Products. We are also interested in coordinating with other projects >> including Usergrid, and others involving data processing at large scales, >> time-series analysis and ETL processes. >> >> == Developers == >> The Software as a Sensor™ Project is primarily funded through contract >> work. There are currently no “dedicated” developers, however, the same core >> team does work will continue work on the project across different contracts >> that support different features. We do intend to maintain a core set of key >> personnel engaged in community development and maintenance—in the future >> this may mean dedicated developers funded internally to support the >> project, however, the project is tied to business development strategy to >> maintain funding into various facets of the project. >> >> == Documentation == >> Documentation is available through Github; each repository under the >> Software as a Sensor™ Project has documentation available through wiki’s >> attached to the repositories. >> >> == Initial Source == >> Current source resides at Github: >> * https://github.com/draperlaboratory/user-ale (User ALE) >> * https://github.com/draperlaboratory/distill (Distill) >> * https://github.com/draperlaboratory/stout (STOUT and Extensions) >> * https://github.com/draperlaboratory/ >> >> == External Dependencies == >> Each component of the Software as a Sensor™ Project has its own >> dependencies. Documentation will be available for integrating them. >> >> === User ALE === >> * Elasticsearch: https://www.elastic.co/ >> * Logstash: https://www.elastic.co/products/logstash >> * Kibana (optional): https://www.elastic.co/products/kibana >> === STOUT === >> * Django: https://www.djangoproject.com/ >> * django-axes >> * django-custom-user >> * django-extensions >> * Elasticsearch: https://www.elastic.co/ >> * Gunicorn: http://gunicorn.org/ >> * MySQL-python: https://pypi.python.org/pypi/MySQL-python >> * Numpy: http://www.numpy.org/ >> * Pandas: http://pandas.pydata.org/ >> * psycopg2: http://initd.org/psycopg/ >> * pycrypto: https://www.dlitz.net/software/pycrypto/ >> * pymongo: https://api.mongodb.org/python/current/ >> * python-dateutil: https://labix.org/python-dateutil >> * pytz: https://pypi.python.org/pypi/pytz/ >> * requests: http://docs.python-requests.org/en/master/ >> * six: https://pypi.python.org/pypi/six >> * urllib3: https://pypi.python.org/pypi/urllib3 >> * mongoDB: https://www.mongodb.org/ >> * R (optional): https://www.r-project.org/ >> === Distill === >> * Flask: http://flask.pocoo.org/ >> * Elasticsearch-dsl: https://github.com/elastic/elasticsearch-dsl-py >> * graph-tool: https://git.skewed.de/count0/graph-tool >> * OpenMp: http://openmp.org/wp/ >> * pandas: http://pandas.pydata.org/ >> * numpy: http://www.numpy.org/ >> * scipy: http://www.numpy.org/ >> === Portal === >> * Django: https://www.djangoproject.com/ >> * React: https://facebook.github.io/react/ >> * D3.js: https://d3js.org/ >> >> === GNU GPL 2 === >> >> >> === LGPL 2.1 === >> >> >> === Apache 2.0 === >> >> >> === GNU GPL === >> >> >> == Required Resources == >> * Mailing Lists >> * priv...@senssoft.incubator.apache.org >> * d...@senssoft.incubator.apache.org >> * comm...@senssoft.incubator.apache.org >> >> * Git Repos >> * https://git-wip-us.apache.org/repos/asf/User-ALE.git >> * https://git-wip-us.apache.org/repos/asf/STOUT.git >> * https://git-wip-us.apache.org/repos/asf/DISTILL.git >> * https://git-wip-us.apache.org/repos/asf/TAP.git >> >> * Issue Tracking >> * JIRA SensSoft (SENSSOFT) >> >> * Continuous Integration >> * Jenkins builds on https://builds.apache.org/ >> >> * Web >> * http://SoftwareasaSensor.incubator.apache.org/ >> * wiki at http://cwiki.apache.org >> >> == Initial Committers == >> The following is a list of the planned initial Apache committers (the >> active subset of the committers for the current repository on Github). >> >> * Joshua Poore (jpo...@draper.com) >> * Laura Mariano (lmari...@draper.com) >> * Clayton Gimenez (cgime...@draper.com) >> * Alex Ford (af...@draper.com) >> * Steve York (sy...@draper.com) >> * Fei Sun (f...@draper.com) >> * Michelle Beard (mbe...@draper.com) >> * Robert Foley (rfo...@draper.com) >> * Kyle Finley (kfin...@draper.com) >> * Lewis John McGibbney (lewi...@apache.org) >> >> == Affiliations == >> * Draper >> * Joshua Poore (jpo...@draper.com) >> * Laura Mariano (lmari...@draper.com) >> * Clayton Gimenez (cgime...@draper.com) >> * Alex Ford (af...@draper.com) >> * Steve York (sy...@draper.com) >> * Fei Sun (f...@draper.com) >> * Michelle Beard (mbe...@draper.com) >> * Robert Foley (rfo...@draper.com) >> * Kyle Finley (kfin...@draper.com) >> >> * NASA JPL >> * Lewis John McGibbney (lewi...@apache.org) >> >> == Sponsors == >> >> === Champion === >> * Lewis McGibbney (NASA/JPL) >> >> === Nominated Mentors === >> * Paul Ramirez (NASA/JPL) >> * Lewis John McGibbney (NASA/JPL) >> * Chris Mattmann (NASA/JPL) >> >> == Sponsoring Entity == >> The Apache Incubator >> >> == References == >> >> Mariano, L. J., Poore, J. C., Krum, D. M., Schwartz, J. L., Coskren, W. D., >> & Jones, E. M. (2015). Modeling Strategic Use of Human Computer Interfaces >> with Novel Hidden Markov Models. [Methods]. Frontiers in Psychology, 6. >> doi: 10.3389/fpsyg.2015.00919 >> Poore, J., Webb, A., Cunha, M., Mariano, L., Chapell, D., Coskren, M., & >> Schwartz, J. (2016). Operationalizing Engagement with Multimedia as User >> Coherence with Context. IEEE Transactions on Affective Computing, PP(99), >> 1-1. doi: 10.1109/taffc.2015.2512867 >> >> >> >> -- >> Lewis > > > > -- > *Lewis* --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
