Testimonies. Field investigations. The voices of victims and witnesses continue to be the richest and most central source of information for human rights advocacy and research. Stories form the core of human rights data and the foundation for the human rights community’s demands for truth, redress and justice for the victims of gross abuses.

Human rights defenders often work in vulnerable environments: sometimes the same state agents whose crimes activists are documenting steal the activists’ computers or tap their Internet connections. Benetech (www.benetech.org) works with partners, as we develop Martus (Greek for “witness”, www.martus.org) to protect human rights activists, witnesses and victims in those environments.

Martus was designed to protect human rights defenders collecting information to support advocacy in dangerous contexts. Many HRP partners are involved in contentious debates about violence carried out by national security forces. Some are documenting violations during ongoing conflicts. Others have gathered extensive data about past abuses. These situations, and growing awareness of the risks to electronic data, have led human rights groups around the world to seek out Martus partnerships with us.

Private information is automatically encrypted by Martus on a user’s local computer, so that if an organization’s computers are lost or stolen, then sensitive information cannot be read without the authorization of the person who created it. Martus backs up the encrypted information to a network of secure servers around the world, so that if users’ computers are lost or stolen, then irreplaceable testimonies and investigations can be recovered.

Our task now is to rethink how the software contributes to human rights advocacy, maintaining our focus on security while adding new devices and architectures, better performance, and new analytic and visualization tools. We need to ensure that Martus does an even better job of advancing the cause of using human rights abuse stories for positive change.

THE NEED:

More and more human rights groups need help understanding patterns in large quantities of narrative text data that has been gathered, without using complex tools.  While Martus allows users to query, organize and do basic summaries of their collected data, we want to develop more robust tools for visualization and qualitative analysis of Martus data (e.g. "show me other bulletins like this one", clustering, word/tag clouds) that will integrate with the Martus client (Java, Windows/Mac).  This will help users discover patterns and relationships in their data, visually represent and communicate key aspects of complex data, dramatically improving their ability to tell more powerful stories.

TECH NOTES:

Martus is open source, written in Java, for Windows/Mac/Linux, so visualization/analysis tools should be able to integrate with this, and be developed using open-source libraries.

 

 

1-      Índice

 

Propuesta para sistema de tickets para Defensa Civil de Rosario

1- Índice

2- Requerimientos funcionales

3- Objetivos

4- Propuesta

4.1- Proceso interno

5- Implementación

5.1- Estados de los tickets

5.2- Pantallas

5.2.1- Alta de tickets

5.2.2- Vista de la historia de un ticket

5.2.3- Búsquedas de tickets

5.2.4- Estadísticas

5.3- Modificaciones al sistema

5.4- Integración con infomapas de MR

5.5- Formulario público de denuncias

5.6- Requerimientos no funcionales

6- Ventajas

7- Estimación

8- Futuras mejoras

 

 

2- Requerimientos funcionales

 

Defensa Civil necesita organizar su funcionamiento interno de recepción de denuncias, clasificación y derivación de incidentes.

Actualmente están llevando registro de los incidentes en planillas de Excel, lo cuál no les es lo suficientemente útil para organizarse, hacer el seguimiento de los mismo, detectar duplicados y para generar estadísticas.

Defensa Civil debe comunicarse a diferentes entes internos y externos para la realización de las tareas de resolución de los casos. Por ejemplo:

 

●     Cuadrilla propia

●     EPE

●     Parques y paseos

●     ASUS (área de servicios urbanos) una por distrito

●     Aguas santafesinas

●     Litoral gas

●     Policía

●     Bomberos

●     GUM

●     Alumbrado public

 

 

3- Objetivos

 

●     Simplificar la recepción de pedidos

○     Poder corroborar las direcciones durante la atención de la llamada

○     Poder identificar distrito al que corresponde, seccional de la policía, etc.

●     Simplificar la clasificación y priorización de denuncias

●     Simplificar el seguimiento de los mismos

●     Poder detectar denuncias duplicadas

●     Poder brindar mejor información a las cuadrillas de trabajo

●     Poder brindar información a los denunciantes

●     Poder sacar estadísticas

 

 

4- Propuesta

 

Se propone la utilización de algún sistema de tickets online Open Source. Al ser Open Source, no tiene costo de licencias ni de utilización. Al ser online, permitiría independizarse de la ubicación física desde la cual se accedería.

Además, se propone integrar el sistema de tickets con el sistema de mapas de la municipalidad de rosario (http://www.rosario.gov.ar/infomapas/) para integrar las direcciones y potencialmente mostrarla en un mapa.

La implementación de sistema de tickets requerirá un cambio en la metodología de trabajo del equipo de defensa civil.

 

4.1- Proceso interno

 

Se propone implementar un proceso con 3 niveles de atención:

1.    Nivel 1: Son los telefonistas que atienden los llamados, cargan el ticket con la información requerida y lo pasan al Nivel 2.

2.    Nivel 2: Son los que toman los tickets, los priorizan y clasifican y lo derivan al área de Nivel 3 que corresponda.

3.    Nivel 3: Son los que hacen la gestión de los tickets comunicándose con los entes internos y externos. Podrían estar divididos en diferentes equipos que se ocupen de diferentes cosas.

Potencialmente, en caso de que las personas ocupadas en estas tareas sean pocas, las mismas personas pueden llegar a cubrir diferentes niveles, pero es importante tener bien separados los roles.

 

 

5- Implementación

 

Se propone utilizar el sistema RT (Request Tracker, http://bestpractical.com/rt/) o algún otro similar, que pueda ser de fácil implementación.

El sistema RT permite la adaptación para agregar campos personalizados a los tickets de modo de poder almacenar la información relevante para Defensa Civil de cada uno de los tickets.

Además, este sistema se puede configurar para estar completamente en idioma castellano.

En el sistema tiene el concepto de Colas que sirven para listar los tickets derivados en cada sección. Las colas a crear serían, por ejemplo, las siguientes:

●     Service Desk: En esta cola se guardan los tickets que la gente de Nivel 2 debe tomar para priorizar. Una vez que el ticket se priorizó y clasificó, la persona de Nivel 2 lo debe pasar a una cola de Nivel 3 para ser trabajado.

●     Una cola por cada grupo diferente de nivel 3.

●     Una cola por cada equipo de trabajo interno o ente externo.

Cuando un ticket que se encuentra en nivel 3, requiere participación de varios equipos de trabajo o entes externos, se podría crear sub-tickets asociados al ticket inicial, para derivar a cada entidad de trabajo. Para el cierre definitivo del ticket inicial, todos sus sub-tickets deben estar cerrados. Con la correcta configuración, el sistema RT soporta esta funcionalidad.

 5.1- Estados de los tickets

 

Los tickets podrían estar en uno de los siguientes estados:

●     Nuevo: El ticket recién fue creado y aún no ha sido priorizado.

●     Pendiente: El ticket ya ha sido priorizado, pero aún no se ha realizado ni derivado.

●     Cancelado: El ticket se dio de baja por ser falso o duplicado.

●     Derivado: El ticket ya está siendo trabajado por el área correspondiente.

●     Realizado: El área correspondiente ha completado su tarea, pero Defensa Civil aún no dio por cerrado el ticket. Al comienzo, sería Nivel 3 quien pasa los tickets del estado Derivado al estado Realizado; en el futuro, si los equipos de trabajo tienen acceso a la herramienta, serían ellos quienes puede dar por Realizado el ticket. En este caso, Nivel 3 puede volver a derivar el ticket a otro ente o, si no hay más tareas que ejecutar, puede cerrar el tiket poniéndolo en estado Terminado.

●     Terminado: Todas las tareas han sido completas y se dio por cerrado el ticket. Solo la gente de Nivel 3 puede dar por Terminado un ticket, para asegurar que el trabajo a sido realizado completamente.

 

 

 

5.2- Pantallas 5.2.1- Alta de tickets

El alta de ticket del RT es similar a la siguiente pantalla. De todas maneras, hay que tener en cuenta que se puede personalizar para solicitar la información que sea necesaria.

 

 5.2.2- Vista de la historia de un ticket

 

5.2.3- Busquedas de tickets

 

5.2.4- Estadísticas

5.3- Modificaciones al sistema

 

●     Implementación look & feel apropiado

●     Configuración de correo electrónico

●     Creación de las coles necesarias

●     Agregar los estados definidos

●     Agregar los campos personalizados para cada cola

●     Implementar mecanismos para aumentar la prioridades automáticamente para los tickets abiertos

●     Implementación de un campo de dirección u ubicación que permita ser autocompletado en la medida que se escribe, que obtenga la información desde el sitio de infomapas de MR. De esta forma se podrá almacenar información del distrito, seccional de policía y coordenadas geográficas.

●     Modificar la visualización de los tickets para que permita mostrar en algún lado, de forma sencilla, la ubicación del incidente.

●     Dar de alta los usuarios iniciales.

 

5.4- Integración con infomapas de MR

 

Actualmente, la municipalidad de rosario tiene el sistema de infomapas que permite buscar por dirección y obtener la información de seccional de policía y distrito y la ubicación en el mapa.

Esta aplicación está desarrollada para usuarios finales, pero debería ofrecer esta información por medio de una Interfaz de Programación de Aplicaciones (API) para poder ser consultada por el sistema de tickets más fácilmente.

Por lo tanto, habría que solicitar el desarrollo de de esta API a la municipalidad. Este desarrollo debería ser fácilmente implementada por ellos, ya que disponen de la tecnología y la información necesaria para hacerlo.

 5.5- Formulario público de denuncias

 

Se recomienda realizar un formulario en el que se permita al público la carga de incidentes vía internet, facilitando el trabajo de carga de la información. El formulario podría ser similar al siguiente:

 

Dadas las facilidades del sistema RT, este formulario solo debería enviar un correo electrónico a una dirección específica y automáticamente, el sistema de tickets crearía el ticket en el estado apropiado para ser revisado por la gente de Nivel 2.

Una vez que el sistema creó el ticket, enviaría un correo electrónico al solicitante para que este pueda notificarse de la creación del mismo y agendar el núrmero de ticket.

 

 

5.6- Requerimientos no funcionales

 

El sistema RT tiene los siguientes requerimientos, según lo que figura en el sitio web oficial (http://bestpractical.com/rt/requirements.html):

●     Un servidor web, por ejemplo Apache.

●     Un servidor de base de datos, por ejemplo MySQL.

●     Sistema operativo Linux.

Potencialmente, reconociendo las necesidades de Defensa Civil, con un solo servidor físico se podría soportar toda la infraestructura.

El servidor debería estar hosteado en internet para poder se accesible desde diferentes ubicaciones.

Cada oficina debe contar con el acceso a internet correspondiente y terminales necesarias para el acceso al sistema.

 

 

6- Ventajas

 

La implementación de este sistema traería las siguientes ventajas:

●     Reducir la carga de trabajo a las personas que atienden el teléfono permitiendo que no se interrumpa la atención mientras que las denuncias comienzan a ser atendidas sin demoras.

●     Se puede corroborar las direcciones automáticamente mientras se atiende el llamado, identificando automáticamente distrito correspondiente y seccional policial.

●     Poder descartar fácilmente reclamos duplicados.

●     Ver visual y rápidamente en un mapa la ubicación del incidente.

●     Optimizar la forma de priorizar los incidentes, para poder facilitar la atención de aquellos que son más urgentes.

●     Mejorar la logística para organizar las tareas a realizar por grupos (por zona, equipo, etc).

●     Posibilitar el seguimiento de los equipos de trabajos y entes externos, para evaluar sus rendimientos.

●     Posibilitar la obtención de estadísticas sobre tipos de denuncias, zonas de la ciudad, tiempos de respuestas, etc.

●     Poder obtener información útil y a tiempo para brindar sobre el estado de los incidentes, tiempos posibles de resolución, etc.

 

 

7- Estimación

 

El proyecto podría realizarse por una sola persona con conocimientos de RT en las siguientes etapas:

●     Relevamiento funcional e instalación inicial: 60 horas.

●     Configuraciones y modificaciones al sistema: 80 horas.

●     Integración con infomapas: 40 horas.

●     Capacitación de uso para usuarios finales (Nivel 1, 2 y 3): 40 horas.

Se asume que se dispone de la API de infomapas disponible antes del comienzo de la etapa correspondiente. Se podría enviar una información técnica de lo que se necesita antes del comienzo del proyecto, para que la municipalidad de Rosario lo pueda implementar en fecha.

  8- Futuras mejoras

 

Además de lo propuesto, se pueden implementar las siguientes futuras mejoras:

●     Brindar acceso a las entidades externas a los tickets de la colas que le correspondan, de modo que ellos puedan cargar el reporte o las respuestas, directamente en cada ticket.

●     Implementar un cliente para Mobile que permita a las cuadrillas obtener el listado de tickets pendientes priorizados para mejorar su organización de trabajo.

●     Implementar 1 interfaz web para que los denunciantes puedan ver el seguimiento de sus tickets.

●     Mostrar estadísticas en un mapa general para ver tickets abiertos o cerrados.

 

The RESTful Hacks of Kindness project unites different rhok projects under a single RESTful architecture. It is written in webpy over python.

 

An example project we build over RESTful Hacks of Kindness is tincan.

 

Tincan transforms unsmart phones into smartphones by enabling them to interact with served smart data via SMS (text) and voice.

 

There are still several problems which need better definitions and implementations. These include:

 

- transportation checking

- local food

- multi-cast distress signal triggering

- a syncrhonized, proximity checkin system

 

https://github.com/codesf/tincan

  

Blackball is a free tool to help anyone with debts wishing to get back in control of their finances and life. By providing a simple interface for tracking bills that need to be paid, and when income will be arriving, to get on with their day to day activities and achieve their financial or life goals. Timely text message reminders ensure bills are paid before those red letters arrive.

New Hampshire Public Radio would like to provide a mobile app for iPhone and Android to help residents of the state stay on top of the weather and emergency information.

This app would allow for understanding current weather, weather forecasts, receiving emergency weather alerts, contact information for N.H. emergency services, 911, power outage information and link to NHPR's twitter feed, where the updates on latest status of the weather event information would be available.

 

http://www.slideshare.net/RHoK-Manchester/nh-alert-hub-10458532

Using Sahana building assesments plugin working on mobile app

Understanding trends in beepopulations is critical to decifering environmental and ecological changes effecting the health of the planet.

 

We know the insect Pollinator population is in decline so empowering the new Urban Beekeeper with a tool that educates them, creates standardization and tracks information so patterns and trends can become more apparnet. Hopefully resulting in a rebound of the population or at least an increase in the genetic strains of bees

 

Global resource for flood analysis & prediction

 

What are we doing?

Bringing together in an easily accessible form records of past floods and the weather that preceded the flood. This will allow others to design and trial flood forecast models.

The data - we're bringing together data from

• Dartmouth Flood Observatory

• 20th Century Reanalysis

Though we're ensuring that what we do could work with other data sources. How about crowdsourcing flood observations.

There are examples of access to the reanalysis data at http://mike.saunby.net

 

Who is this for?

Right now we are aiming at researchers, particularly those in flood prone countries who might not normally be able to access large datasets (NetCDF anyone?).