:-) Congrats and more to come! :) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Director, Information Retrieval and Data Science Group (IRDS) Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA WWW: http://irds.usc.edu/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
On 6/21/16, 12:29 AM, "Poore, Joshua C." <jpo...@draper.com> wrote: >Wow. We’re so excited about this and we’re looking forward for the hard work >toward full foundation membership. Thanks all! > >Josh > >From: Lewis John Mcgibbney [mailto:lewis.mcgibb...@gmail.com] >Sent: Thursday, June 16, 2016 9:20 PM >To: general@incubator.apache.org >Cc: Poore, Joshua C. <jpo...@draper.com> >Subject: [RESULT] WAS Re: [VOTE] Accept SensSoft into the Apache Incubator WAS >Re: [VOTE] Accept > >Hi general@, >72 hours has come and gone I am therefore closing off this VOTE'ing thread. >Thank you to everyone that was able to VOTE. > >[4] +1 Accept SensSoft into the Apache Incubator >Lewis John Mcgibbney* >Chris A Mattmann* >Tom Barber* >Henry Saptura* > >[0] +/-0 Not overly bothered either way >[0] -1 DO NOT accept SensSoft into the Apache Incubator (please state why) >*IPMC binding >So great news, SensSoft is accepted into the Incubator :) :) :) >I'll progress with workflow. >Thanks folks. >Lewis > >On Mon, Jun 13, 2016 at 3:07 PM, Lewis John Mcgibbney ><lewis.mcgibb...@gmail.com<mailto: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<mailto: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<http://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<http://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<mailto:priv...@senssoft.incubator.apache.org> > * > d...@senssoft.incubator.apache.org<mailto:d...@senssoft.incubator.apache.org> > * > comm...@senssoft.incubator.apache.org<mailto: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<mailto:jpo...@draper.com>) > * Laura Mariano (lmari...@draper.com<mailto:lmari...@draper.com>) > * Clayton Gimenez (cgime...@draper.com<mailto:cgime...@draper.com>) > * Alex Ford (af...@draper.com<mailto:af...@draper.com>) > * Steve York (sy...@draper.com<mailto:sy...@draper.com>) > * Fei Sun (f...@draper.com<mailto:f...@draper.com>) > * Michelle Beard (mbe...@draper.com<mailto:mbe...@draper.com>) > * Robert Foley (rfo...@draper.com<mailto:rfo...@draper.com>) > * Kyle Finley (kfin...@draper.com<mailto:kfin...@draper.com>) > * Lewis John McGibbney (lewi...@apache.org<mailto:lewi...@apache.org>) > >== Affiliations == > * Draper > * Joshua Poore (jpo...@draper.com<mailto:jpo...@draper.com>) > * Laura Mariano (lmari...@draper.com<mailto:lmari...@draper.com>) > * Clayton Gimenez (cgime...@draper.com<mailto:cgime...@draper.com>) > * Alex Ford (af...@draper.com<mailto:af...@draper.com>) > * Steve York (sy...@draper.com<mailto:sy...@draper.com>) > * Fei Sun (f...@draper.com<mailto:f...@draper.com>) > * Michelle Beard (mbe...@draper.com<mailto:mbe...@draper.com>) > * Robert Foley (rfo...@draper.com<mailto:rfo...@draper.com>) > * Kyle Finley (kfin...@draper.com<mailto:kfin...@draper.com>) > > * NASA JPL > * Lewis John McGibbney (lewi...@apache.org<mailto: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 > > > >-- >Lewis >________________________________ >Notice: This email and any attachments may contain proprietary (Draper >non-public) and/or export-controlled information of Draper. If you are not the >intended recipient of this email, please immediately notify the sender by >replying to this email and immediately destroy all copies of this email. >________________________________ --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
