Find It's Features and Functionality

Find It is a one-stop-shop for community-members to find opportunities for community engagement

Search a curated directory of events

• Filter results based on age, location, cost, activity, and schedule
• Click on a map to select which areas are accessible to you

Create a user account

• Set event reminders about interesting opportunities
• Receive notifications so that your Find It experience stays smooth.

Select a language

• Navigate the site in your language of choice
• Contribute improvements to the translations so that Find It can meet the needs of the diverse communities it serves

 

Find It makes it easier for government and non-profit organizations to reach the people they work to serve.

Log in with a service provider account

• Share information about your organization
• Post events and services for the residents of their community

 

Find It makes it easier for an individual or small team to make sure that members of the community they serve have access to all of the services they need.

Post information about public spaces

• Keep track of all of the available public spaces on a single platform
• Let residents know what public spaces are available as resources to them

Coordinate with all of the city's service providers together on one platform

• Add service providers to the platform so they can post information about what they offer
• Check for gaps and redundancies in services offered throughout your area in order to coordinate a more comprehensive set of services

Being able to share an article via a social network is a common request on a project.

Fortunately for Drupal 8 there is a module for that called Social Simple. This module allows you to display a share button on a node for the most popular social media networks:

• Twitter
• Facebook
• LinkedIn

Agaric proposes the creation of a new kind of workplace, essentially a Drupal commune, but really more like an open source free software idea & brainstorming commune, kind of along the same lines as an artist's or writer's colony.

Imagine a network of state-of-the-art green living spaces spread across the planet in the most beautiful locations that mother nature has to offer. Places filled with the best and the brightest drupalistas living and playing and growing together, and together developing Drupal and the various technologies that help it work. As an open source community, Drupal already possesses many of the cooperative qualities that would make this sort of commune possible. Just think of any Drupal meetup you've attended in the past. Some show up to demo their latest work, others to ask for help, others to give help... What if we had spaces where this sort of thing was constantly happening?

The Drupal commune would be open to whomever wanted to come join in for a period of time and help advance the cause. Every member of the community would provide a special skillset to the team, be it coding, theming, graphic design or documentation. Some people could be permanent residents at such places and others could come and go based on work available and projects being worked on. Of course at first, we think it would have to start as more of a couch-surfing type thing. People who have the space can offer it up, recruit and house a few drupalistas for the duration of a project, like contributed work, or payed client work. From there, teams could assemble all around the world, do the necessary work, and do it better than they could alone, all while being able to enjoy and explore the world. Then disband, these communes or colonies don't have to be permanent, although that is the eventual goal.

• The individual contributor gets a combination code sprint and couch surf experience.
• Drupal gets fantastic functionality or process improvements made in ideal productive circumstances.
• And everyone gets satisfaction of making something awesome and worthwhile, in community, while getting to see and explore planet Earth and do fun stuff.

This idea is nothing new and has recently been advocated by the brilliant physicist and surfer Garret Lisi. In his own words he says these places... "would essentially be large houses in beautiful locations where theorists could live and work." Citing his own experience living in Maui and the mountains of Tahoe and Colorado, Lisi says that for theoretical research it is good to have opportunities for hiking and things to do outside in attractive environments. Describing the idea more formally, Lisi says:

The physical requirements for conducting scholarly research have changed dramatically with the rise of the internet. It is now viable for researchers with laptop computers to work autonomously -- with access to current articles and communication channels on par with the resources available at large universities. These new circumstances motivate the creation of a new kind of research enterprise: a Science Hostel. By providing places to live and work with other researchers, in beautiful locations, a Science Hostel could increase creative productivity and overall quality of life for scholars in the internet age.

We believe the Drupal world currently developing before our eyes is especially well poised to embrace such an idea. We are a growing community of able, intelligent, free thinking, and like minded people. We all think Drupal has a lot to offer people, and we've all been making a living developing with Drupal, and we also all our own personalities and hobbies outside of work. We see a lot of people in this world showing up to "just a day job" or a "9 to 5". We don't like seeing Drupal applied to this model. We believe that satisfying work comes from truly embracing what you do and doing it to it's fullest. So it's not just your day job, but your lifestyle, something that is an essential part of your being. When focused on certain subjects with such passion, originality and creativity can flourish, sparks happen. Our proposition is that we really pursue this idea of combining our work lives with our personal ones, evolving things into a lifestyle of the future.

These communities could also include people who are interested in sustainable living, and/or off-the-grid living and promote these ideas as well. So not just Drupalers, but there could be specialists doing other things like growing food with aquaponics, creating mesh wireless networks, or harnessing solar and wind energy. Proving that people can create and shape their universe when they come together and cooperate.

The way we see it, this thing would be community managed and totally open, the way Drupal has always been, except now we'd really be starting to shape the material world using Drupal, creating a free culture. There are a lot of folks who are tirelessly spending nights and weekends coding masterpieces like CCK and Views and giving us the power to feed and clothe ourselves. We love seeing this happen, we love thinking about it. A person driven to create is a beautiful thing. We want to see more community forming around this stuff. Why should development be done in cooped up cubicle type spaces? Why have we let so many convince us that our time is best spent, and we are most useful and productive in offices and sitting in traffic? Would things evolve more organically, and would Drupal advance exponentially with the future of humanity if places like this existed? They don't even need to be permanent, we could organize and create them for certain collaborative projects and disband after the work is done and has been contributed back to the community.

There is a lot more that can be written about this, and all the details still need to be worked out. But we're confident that the community could organize enough to essentially allow for these "corporate retreats on acid" or "software development communes" to happen. Drupalistas could apply for internship type positions and get voted in, most likely through the Drupal Association or similar organizations. Teams of independent contractors could come together, share projects, split up the work, and live the good life. We could become the renaissance men and women of the future and break free of all the old, tired, hierarchical, institutionalized ways of being productive that have been shoved down our throats in the past. We can create community, developing our ideas, doing the work we love to do, and seeing and shaping the world into something better during our time here.

Sure it's not for everybody, but we have a feeling their might be other Drupal nomads out there...

Your e-mail address

Your name (optional)

Get notified

Leave this field blank

Throughout the series, we explored many migration topics. We started with an overview of the ETL process and workflows for managing migrations. Then, we presented example migrations for different entities: nodes, files, images, taxonomy terms, users, and paragraphs. Next, we shifted focus to migrations from different sources: CSV, JSON, XML, Google Sheet, Microsoft Excel, and LibreOffice Calc files. Later, we explored how to manage migrations as configuration, use groups to share configuration, and execute migrations from the user interface. Finally, we gave recommendations and provided tools for debugging migrations from the command line and the user interface. Although we covered a lot of ground, we only scratched the surface. The Migrate API is so flexible that its use cases are virtually endless. To wrap up the series, we present an introduction to a very popular topic: Drupal upgrades. Let’s get started.

Note: In this article, when we talk about Drupal 7, the same applies to Drupal 6.

What is a Drupal upgrade?

The information we presented in the series is generic enough that it applies to many types of Drupal migrations. There is one particular use case that stands out from the rest: Drupal upgrades. An upgrade is the process of taking your existing Drupal site and copy its configuration and content over to a new major version of Drupal. For example, going from Drupal 6 or 7 to Drupal 8. The following is an oversimplification of the workflow to perform the upgrade process:

• Install a fresh Drupal 8 site.
• Add credentials so that the new site can connect to Drupal 7’s database.
• Use the Migrate API to generate migration definition files. They will copy over Drupal 7’s configuration and content. This step is only about generating the YAML files.
• Execute those migrations to bring the configuration and content over to Drupal 8.

Preparing your migration

Any migration project requires a good plan of action, but this is particularly important for Drupal upgrades. You need to have a general sense of how the upgrade process works, what assumptions are made by the system, and what limitations exist. Read this article for more details on how to prepare a site for upgrading it to Drupal 8. Some highlights include:

• Both sites need to be in the latest stable version of their corresponding branch. That means the latest release of Drupal 7 and 8 at the time of performing the upgrade process. This also applies to any contributed module.
• Do not do any configuration of the Drupal 8 site until the upgrade process is completed. Any configuration you make will be overridden, and there is no need for it anyways. Part of the process includes recreating the old site’s configuration: content types, fields, taxonomy vocabularies, etc.
• Do not create content on the Drupal 8 site until the upgrade process is completed. The upgrade process will keep the unique identifiers from the source site: `nid`, `uid`, `tid`, `fid`, etc. If you were to create content, the references among entities could be broken when the upgrade process overrides the unique identifiers. To prevent data loss, wait until the old site's content has been migrated to start adding content to the new site.
• For the system to detect a module’s configuration to be upgraded automatically, it has to be enabled on both sites. This applies to contributed modules in Drupal 7 (e.g., link) that were moved to core in Drupal 8. Also to Drupal 7 modules (e.g. address field) that were superseded by a different one in Drupal 8 (e.g. address). In any of those cases, as long as the modules are enabled on both ends, their configuration and content will be migrated. This assumes that the Drupal 8 counterpart offers an automatic upgrade path.
• Some modules do not offer automatic upgrade paths. The primary example is the Views module. This means that any view created in Drupal 7 needs to be manually recreated in Drupal 8.
• The upgrade procedure is all about moving data, not logic in custom code. If you have custom modules, the custom code needs to be ported separately. If those modules store data in Drupal’s database, you can use the Migrate API to move it over to the new site.
• Similarly, you will have to recreate the theme from scratch. Drupal 8 introduced Twig which is significantly different to the PHPTemplate engine used by Drupal 7.

Customizing your migration

Note that the creation and execution of the migration files are separate steps. Upgrading to a major version of Drupal is often a good opportunity to introduce changes to the website. For example, you might want to change the content modeling, navigation, user permissions, etc. To accomplish that, you can modify the generated migration files to account for any scenario where the new site’s configuration diverts from the old one. And only when you are done with the customizations, you execute the migrations. Examples of things that could change include:

• Combining or breaking apart content types.
• Moving data about people from node entities to user entities, or vice versa.
• Renaming content types, fields, taxonomy vocabularies and terms, etc.
• Changing field types. For example, going from Address Field module in Drupal 7 to Address module in Drupal 8.
• Merging multiple taxonomy vocabularies into one.
• Changing how your content is structured. For example, going from a monolithic body field to paragraph entities.
• Changing how your multimedia files are stored. For example, going from image fields to media entities.

Performing the upgrade

There are two options to perform the upgrade. In both cases, the process is initiated from the Drupal 8 site. One way is using the Migrate Drupal UI core module to perform the upgrade from the browser’s user interface. When the module is enabled, go to `/upgrade` and provide the database credentials of the Drupal 7 site. Based on the installed modules on both sites, the system will give you a report of what can be automatically upgraded. Consider the limitations explained above. While the upgrade process is running, you will see a stream of messages about the operation. These messages are logged to the database so you can read them after the upgrade is completed. If your dataset is big or there are many expensive operations like password encryption, the process can take too long to complete or fail altogether.

The other way to perform the upgrade procedure is from the command line using Drush. This requires the Migrate Upgrade contributed module. When enabled, it adds Drush commands to import and rollback a full upgrade operation. You can provide database connection details of the old site via command line options. One benefit of using this approach is that you can create the migration files without running them. This lets you do customizations as explained above. When you are done, you can run the migrations following the same workflow of manually created ones.

Known issues and limitations

Depending on whether you are upgrading from Drupal 6 or 7, there is a list of known issues you need to be aware of. Read this article for more information. One area that can be tricky is multilingual support. As of this writing, the upgrade path for multilingual sites is not complete. Limited support is available via the Migrate Drupal Multilingual core module. There are many things to consider when working with multilingual migrations. For example, are you using node or field translations? Do entities have revisions? Read this article for more information.

Upgrade paths for contributed modules

The automatic upgrade procedure only supports Drupal core modules. This includes modules that were added to core in Drupal 8. For any other contributed module, it is the maintainers’ decision to include an automatic upgrade path or not. For example, the Geofield module provides an upgrade path. It is also possible that a module in Drupal 8 offers an upgrade path from a different module in Drupal 7. For example, the Address module provides an upgrade path from the Address Field module. Drupal Commerce also provides some support via the Commerce Migrate module.

Not every module offers an automated upgrade path. In such cases, you can write custom plugins which ideally are contributed back to Drupal.org ;-) Or you can use the techniques learned in the series to transform your source data into the structures expected by Drupal 8. In both cases, having a broad understanding of the Migrate API will be very useful.

Upgrade strategies

There are multiple migration strategies. You might even consider manually recreating the content if there is only a handful of data to move. Or you might decide to use the Migrate API to upgrade part of the site automatically and do a manual copy of a different portion of it. You might want to execute a fully automated upgrade procedure and manually clean up edge cases afterward. Or you might want to customize the migrations to account for those edge cases already. Michael Anello created an insightful presentation on different migration strategies. Our tips for writing migrations apply as well.

Drupal upgrades tend to be fun, challenging projects. The more you know about the Migrate API the easier it will be to complete the project. We enjoyed writing this overview of the Drupal Migrate API. We would love to work on a follow up series focused on Drupal upgrades. If you or your organization could sponsor such endeavor, please reach out to us via the site’s contact form.

What about upgrading to Drupal 9?

In March 2017, project lead Dries Buytaert announced a plan to make Drupal upgrades easier forever. This was reinforced during his keynote at DrupalCon Seattle 2019. You can watch the video recording in this link. In short, Drupal 9.0 will be the latest point release of Drupal 8 minus deprecated APIs. This has very important implications:

• When Drupal 9 is released, the Migrate API should be mostly the same as Drupal 8. Therefore, anything that you learn today will be useful for Drupal 9 as well.
• As long as your code does not use deprecated APIs, upgrading from Drupal 8 to Drupal 9 will be as easy as updating from Drupal 8.7 to 8.8.
• Because of this, there is no need to wait for Drupal 9 to upgrade your Drupal 6 or 7 site. You can upgrade to Drupal 8 today.

Thank you!

And that concludes the #31DaysOfMigration series. For joining us in this learning experience, thank you very much! ¡Muchas gracias! Merci beaucoup! :-D We are also very grateful to Agaric.coop, Drupalize.Me, and Centarro.io for sponsoring this series.

What did you learn in today’s blog post? Did you know the upgrade process is able to copy content and configuration? Did you know that you can execute the upgrade procedure either from the user interface or the command line? Share your answers in the comments. Also, we would be grateful if you shared this blog post with others.

This blog post series, cross-posted at UnderstandDrupal.com as well as here on Agaric.coop, is made possible thanks to these generous sponsors: Drupalize.me by Osio Labs has online tutorials about migrations, among other topics, and Agaric provides migration trainings, among other services.  Contact Understand Drupal if your organization would like to support this documentation project, whether it is the migration series or other topics.

Monday night before the "Super Tuesday" primary, I'm searching for "does the bernie sanders app help you offer rides to polls to people" and finding no answer. (It does not.)

All I found was Lyft offering ride codes to for a handful of non-partisan non-profits to distribute. If Lyft can realize that simple physical access to vote is a barrier that affects different groups of people unequally and cite the facts about youth not voting, it surely came up on the Bernie Sanders Slack.

Yet in this highly online-connected campaign, some of the basic steps to winning (asking everyone: Do you have a plan to vote? Do you need help getting to the polls?) didn't make it into the official app, nor in any public side efforts.

There are a huge number of thoughtful, dedicated people working on the Bernie Sanders campaign (and in other political campaigns), but as in every movement I've witnessed I'm convinced that not all the best ideas are bubbling up.  This is especially true for communities like Drupal where even the idea of shared goals, let alone the mechanism for identifying and realizing them, can seem to disappear when you look for them directly.

Even when a goal is simple (get this one person elected president) the tactics are likely to need to be varied and complex.

This is vastly more true when we're talking about a movement. Even in a presidential campaign like for Sanders, the the goals behind the goal—health care, living wages, lots more jobs for everyone because we're putting people to work reversing global warming—are many, multifaceted, and cannot possibly be achieved only through electing someone, even to an office like the United State's imperial presidency.

After getting over my personal hangup of asking people for something without having at least the barest offer of help (a ride to go vote), I did start texting a few people to encourage them to vote. But as I texted my brother in New York, I'm still bummed we're organizing in the context of political campaigns, instead of having huge movements that, as an afterthought, choose our politicians.

I'm not making (or necessarily opposing) the argument that electoral organizing distracts from more important grassroots organizing.

I have gotten involved with a local solidarity network which focuses on direct action to help people with immediate problems— frequently a dozen people helping just one person or a few people at a time win livable spaces from landlords (or get security deposits back), or get stolen wages from an employer.

This sort of deep organizing—really only medium deep, but it's using available resources to nearly their maximum capacity—does not have the breadth of the typical mayoral campaign.

We need breadth as well as depth. There are many problems that can't be solved on a case by case basis. Although the type of organizing local solidarity networks engage in builds the capacity to take on bigger problems, it doesn't necessarily scale fast enough, or have clear mechanisms to translate built power and solidarity in one area to others.

The question of translating power built in one sphere to another is even more pressing for the election campaigns.

It's no secret, as Frank Chapman of the National Alliance Against Racist and Political Repression reminded people in Minneapolis when he visited from Chicago, that you build political power by going door to door and finding supporters.

What would our political movements be able to do if we didn't have to redo all the grunt work every time?

Or if people weren't canvassed only by campaigns (electoral or otherwise), but asked about their needs?

There are enough people who give a damn.

We could build immensely powerful movements from the ground up, if we had a way to agree how shared resources of movements—including communication channels—would be controlled.

To be a movement for, among other things, democracy, we need to be democratic ourselves. The DSA is probably farthest along in reach and democratic mechanisms, and so a natural place to join.

We need better technology to coordinate to achieve justice, liberty, and better lives for all. I don't mean merely a better canvassing app.

We need approaches and tools that let us share power. Then we can truly build power together.

A positive spin on this extremely spun election: media coverage has meant a ton but advertising has not. And the national, corporate media (which, if for instance you haven't checked who owns your local newspaper, if you even have one, is nearly all of the news media) is the sworn enemy to economic fairness and equal political power. No one with resources should put a cent into our enemies pockets by buying ads, especially when it doesn't even work.

It's a perfect opportunity to build institutions that work for us, rather than pouring resources and energy into institutions that are getting us killed.

We can build a communication network through which we collectively decide what we want, and then figure out how to coordinate to get it— whether it's electing someone or holding politicians or businesses accountable with direct action or forming ourselves into a giant cooperative corporation to negotiate as workers and buyers more equally with the huge corporations we deal with on a day-to-day basis.

If you're in the position to connect us to campaigns, cooperatives, parties, or other organizations who see a need for communication tools controlled by all the people in an organization or movement, where the ideas and control of resources can build from below, please contact Agaric.

E-mail address:

Name:

What online or website goals does your group have?

Share your need

Leave this field blank

Sobre el Mapa

El Mapa de Acción de Justicia Climática (CJAM) es una herramienta de mapeo personalizada que extrae 350 eventos y grupos de múltiples fuentes de datos (por ejemplo: ActionKit, EveryAction, CiviCRM) y muestra un mapa interactivo que los partidarios pueden usar para involucrarse.

Se puede incrustar en sitios web con muchas opciones de personalización (por ejemplo: preestablecer el centro del mapa en una ubicación, mostrar el texto y los botones del mapa en un idioma diferente, mostrar solo eventos relacionados con una campaña en particular, etc.).

Utiliza Mapbox para el mapa, OpenStreetMaps para el conjunto de mosaicos y Google Maps para la búsqueda.

La aplicación CJAM Extract, Transform Load (ETL) es un procesador de datos escrito en Python que se ejecuta cada 15 minutos y extrae datos de esas muchas fuentes (por ejemplo: EveryAction, CiviCRM) a través de API y consultas directas de SQL. Escribe el evento combinado y los datos del grupo en un archivo de datos JSON alojado en Amazon S3, que luego es consumido por el JavaScript CJAM.

Nuestro Enfoque

Nos reunimos con 350 a mediados de junio, con las huelgas programadas para el 20 de septiembre y organizando impulsos en julio y agosto. Con plazos ajustados, un nuevo equipo y una nueva base de código, rápidamente nos pusimos manos a la obra para comprender los objetivos del mapa, su implementación actual y lo que había que hacer para cada hito.

Los Usuarios Primero: Aclarar los Objetivos

En los proyectos que requieren cambios rápidos, es tentador sumergirse primero en la cola de problemas. Sin embargo, sabemos que un proyecto solo tiene éxito si todos están alineados con los objetivos generales del proyecto. Afortunadamente, el equipo del producto ya tenía una excelente documentación (¡incluso tenían una presentación de diapositivas!) Sobre cuál es el propósito del mapa de acción climática y sus audiencias clave.

350.org tuvo una presentación de diapositivas que detalla los objetivos y el público, lo que nos ayudó a obtener los conocimientos básicos necesarios para colaborar de manera efectiva.

Objetivos

1. Para demostrar la escala geográfica de nuestro trabajo a los visitantes.
2. Para conectar a los visitantes del sitio a las siguientes actividades:
   
   - Asistir a un evento
   
   - Participe con un grupo local
   
   - Conozca nuestro trabajo regional
3. Para dar al personal la capacidad de incrustar el mapa en diferentes sitios y personalizarlo para adaptarse a los propósitos de las páginas en las que se está incrustando.

Audiencias Primarias

• Visitante del sitio

• Insertador de mapas

Fue genial tener estos documentos en nuestra llamada inicial.

Refactor Mientras Aprende

Familiarizarse con el funcionamiento interno del mapa de acción climática fue particularmente desafiante porque el código estaba esencialmente en dos estados: la rama principal con el JavaScript personalizado original y una rama refactorizadora donde estaba ocurriendo la transición a React.js. React es uno de los frameworks más populares y ampliamente utilizados. La conversión de la aplicación a React hizo que el código fuera más fácil de mantener y desarrollar. El desarrollador voluntario original había comenzado este proceso de conversión y había nuevas características escritas en la nueva forma Reaccionar, no disponibles hasta que se completara la refactorización.

Mauricio y Chris se reunieron con él para aclarar cómo ver la transición hasta el final. Luego se familiarizaron con la base de código y refactorizaron en el camino. Al comprender, por ejemplo, una función larga y compleja, y luego reescribirla en funciones discretas más pequeñas, pudimos simplificar el código, comprender nuestro funcionamiento interno y facilitar el trabajo para que el próximo desarrollador se una al proyecto .

Depuración de Problemas

Cuando se trabaja por primera vez con una base de código, lleva tiempo entender por qué un nuevo cambio no se mantiene o por qué se produce un error. Los registros son el mejor amigo de un desarrollador cuando se trata de depuración. Desafortunadamente, el registro disponible fue marcado. El ETL tenía un registro en ejecución, pero no se guardaba en un archivo para referencia futura o recuperación fácil. Chris mejoró el registro de errores e incluso agregó la integración de Slack enviando un mensaje al equipo cada vez que ocurría un error, ayudando a las personas a responder rápidamente a los problemas.

Ataque Global, Movilización Local

350.org tiene cientos de capítulos, repartidos en siete continentes, con miembros que hablan docenas de idiomas. Su herramienta de mapeo fue construida con esta diversidad en mente. Sirve como un poderoso dispositivo para contar historias (objetivo número uno), con un solo mapa que transmite el impresionante alcance del movimiento y no hace suposiciones sobre dónde está un visitante o qué está buscando.

Por otro lado, la movilización es más efectiva cuando proviene de personas que conocemos, de comunidades de las que formamos parte. Como tal, el mapa puede vivir en contextos más localizados, mostrando solo eventos y grupos relevantes para un escenario particular. Por ejemplo, el capítulo 350 Colorado puede mostrar un mapa ampliado en Mountain West, mientras que 350 Francia puede mostrar un mapa con solo eventos en francés.

Estos mapas personalizados se crean utilizando parámetros de inserción. Para hacer esto, un organizador de 350.org pegó el mapa en una página usando un iframe, pasando parámetros como el idioma, la ubicación y la fuente de datos al incluir un parámetro de consulta en la url.

Sin embargo, este enfoque era engorroso, técnicamente prohibitivo y propenso a errores. Descartamos el enfoque de iframe y lo reemplazamos con una serie de códigos cortos, un método más intuitivo, que realiza llamadas directas a la API de Mapa de Acción Climática para representar un mapa específico para las necesidades de un organizador.

Agregamos soporte para los siguientes códigos cortos:

• data-src-search: pase un término de búsqueda de ubicación y el mapa realizará una búsqueda previa a esa campaña de evento de ubicación: muestra solo los resultados etiquetados con una campaña específica, por ejemplo: "ataque climático"
• date-range-start - muestra eventos que comienzan en o después de una fecha determinada
• date-range-end: muestra eventos que finalizan antes o en una fecha determinada
• data-src-lang - muestra el texto del mapa en un idioma determinado
• data-src-latlong: centra el mapa en cierto punto de latitud y longitud
• data-src-zoom: establece el nivel de zoom predeterminado
• data-src-layers: especifique qué tipo de datos mostrar (campaña, evento, grupo)

Ahora los organizadores pueden crear cualquier cantidad de mapas con criterios que satisfagan las necesidades específicas de su campaña o comunidad.

¿Qué es exactamente el "futuro"? - Cálculo de Zonas Horarias con Python

With so many different events happening at any given time, the map risked overwhelming visitors looking to get involved. 350.org's designer Matthew Hinders-Anderson came up with the solution of applying different map pin styles to events depending on when they were happening. Past events have a subdued teal, while current and future events have a strong teal. To emphasize the storytelling (goal number) of the map, current events throb.

Para lograr esto, necesitábamos calcular la fecha y hora de un evento en relación con la hora actual. Desafortunadamente, muchos de los eventos no tenían zona horaria asociada a ellos. Sin embargo, todos tenían alguna forma de ubicación disponible. Chris encontró una práctica herramienta de Python llamada timezonefinder que calcula la zona horaria de un evento en función de la latitud y la longitud.

Con la zona horaria en la mano, Mauricio podría aplicar los diferentes colores (y parpadear) en función del tiempo del evento en relación con ahora.

 

Utilizamos Python para calcular la zona horaria de un evento en función de su latitud y longitud.

Incorporación Perfecta

Con tantos eventos organizados, queríamos que los posibles huelguistas encontraran un evento para asistir rápidamente. Sin embargo, se encontraron embebedores de mapas, que a veces las búsquedas daban como resultado un mapa vacío, a pesar de que los eventos estaban cerca. Este es uno de los muchos desafíos de diseñar mapas interactivos. Un ejemplo fue un visitante que vivía en un suburbio cercano de Boston. Una búsqueda de Allston no resultaría nada, a pesar de que haya múltiples eventos dentro de un radio de 5 millas. Ajustamos el comportamiento del zoom para mostrar mejor los eventos cercanos.

Sin embargo, todavía había casos extremos. Abordamos esto mostrando un botón de "Alejar" si un visitante aparecía vacío. Al hacer clic, se aleja a un usuario al resultado más cercano.

Si un visitante no obtiene resultados de su búsqueda, puede alejarse al evento o grupo más cercano.

Los Resultados

El plan de movilización era presionar a activistas y organizadores para que planificaran eventos de junio a agosto. Luego reúna a tantas personas para confirmar su asistencia a los eventos recién creados desde agosto hasta los grandes días: 20 de septiembre y 27 de septiembre. En agosto, implementamos la funcionalidad de código de inserción que los organizadores utilizaron bien, incorporando mapas específicos locales y regionales en 350 páginas grupales locales y sitios web específicos sobre el impacto climático que habían construido.

El mapa era tan popular que otras organizaciones preguntaron si podían insertarlo en sus propios sitios, aumentando los puntos de movilización y el público alcanzado. El hecho de que pudiéramos hacer esto habla de la importancia de defender la web abierta y el software libre y de código abierto que permite compartir y utilizar herramientas de forma descentralizada.

El primer día de las huelgas, los estilos de alfileres cobraron vida, iluminando las numerosas huelgas, manifestaciones y protestas que ocurrieron ese día. Fue un gráfico para periodistas y simpatizantes en las redes sociales para compartir cuando informaban sobre una participación sin precedentes.

En última instancia, los números que vimos fueron un testimonio de los largos y arduos esfuerzos que los organizadores trabajan constantemente y la urgencia del momento en que nos encontramos. Sin embargo, con herramientas como el Mapa de Acción de Justicia Climática, creado por activistas tecnológicos junto con los organizadores que los utilizan, profundizamos y ampliamos la movilización posible. Y en estos tiempos de desigualdad masiva de la riqueza, profunda corrupción política y cierre de la ventana de tiempo para la acción audaz que necesitamos, interrumpir el statu quo es más importante que nunca.

Name

Email

Submit

Leave this field blank

Micky is a highly active and dedicated individual who is deeply involved in various movements and networks related to free software, cooperative business models, and community building. She is a worker/owner of Agaric, a member of numerous "free software" networks and movements, and actively uses tools like BigBlueButton, Drupal, and the GNU/Linux operating system to promote and introduce people to the world of free software.

Micky plays a crucial role in connecting different organizations and networks and she serves on the board of May First Movement Technology (MFMT), The US Solidarity Economy Network (SEN) and, SnowDrift.coop. As a member of The Tech Workers Peer Network a coalition of the US Federation of Worker Cooperatives (USFWC), she works to foster ongoing dialogues and collaborations in building a new economy network rooted in community-based, shared ownership. She also works with organizations like, Platform Cooperativism Consortium, The Free Software Foundation, The Center for Global Justice, The Greater Boston Chamber of Cooperatives, Restore the Fourth, and MassMesh, among others, to raise awareness about free software, cooperative business models, privacy protection, plus local and global opportunities to share knowledge. She has been a Keynote speaker, lecturer and panel member at conferences over the past 20 years.

As a member of the May First Movement Technology board, Micky actively collaborates with technical activists to provide people with the necessary information and tools to transition from being a local or small global network to becoming part of a global movement based on solidarity and cooperative principles. She strongly believes that the workers' economy requires free software tools to protect our freedoms, and she combines the principles of free software liberation and cooperative development in her presentations and talks.

Micky is also an active member of the Drupal community, an international group centered around a free software content management system. She has contributed to the Drupal community as a writer and has shared her experiences as a contributing author in the book "Ours to Hack and to Own," which is considered the handbook for the Platform Cooperativism Movement. The book was initiated by Trebor Scholz and Nathan Schneider at the New School in NYC and was listed as one of the top tech books of 2017 by Wired magazine.

As a public speaker, Micky passionately delivers the message of cooperative software development to various networks and movements. Her presentations cover a wide range of topics, including free software, cooperative tech development, personal digital privacy, worker-owned cooperatives, artificial intelligence, surveillance and capitalism, introduction to web technology, and the incorporation of the seven cooperative principles using Sociocracy, into work and living environments. Additionally, she provides software training for free tools such as BigBlueButton, Signal Instant Messenger, NextCloud, and encrypted email, and she can offer advice on alternatives to proprietary software.

Outside of her professional endeavors, Micky has a rich personal history. She was a resident of Weston, CT in the 50s, 60s, and 70s and currently resides in Boston, MA with her long-time partner John M. Crisman. Micky was a member of a few bands in Boston, MA during the 1970’s through the 90’s, such as The Phantoms. The band is featured in the book "Hit Girls" by Jen B. Larsen, a compendium of female-led punk bands in the USA during the late 70s and early 80s as well as an exhibit at Harvard's Loeb Music Library in 2024-2025.

Micky's dedication to her work and her commitment to promoting free software, cooperative business models, art, music and community building make her a valuable asset to the movements and networks she is involved in. She continues to make a positive impact in the world through her activism, public speaking engagements, and the creation of site like CommunityBridge, which prioritize privacy and provide a more secure environment for meaningful video chats between individuals who share a passion for education and activism.

 

Here is a trailer for a video documentary about Micky's High School days  - It is Rock and Roll History - The High School that ROCKED.

Request an interview, presentation or workshop with Micky

Presentations and Workshops:

*Updated list and references available upon request.  

2021

• Live interview - Sweden CivicTech Lab - The Two Money Problems

2020

• Hosted workshop: Surveillance Capitalism, Predictive Analysis and YOU at HOPE 2020  (Hackers on Planet Earth)
• Live interview on Radio Statler at the HOPE 2020 conference
• Libreplanet LIVE online 3/14/2020. We hosted a discussion at 4:20 ET on fsf.org - Libreplanet 2020
• Surveillance Capitalism, Predictive Analysis and YOU - Lecture, Biblioteque, San Miguel de Allende
• Internet Security - Workshops - Biblioteque, San Miguel de Allende
• Boston College - presentation on AI and Predictive analysis
• Colorado.edu online interview on Cooperative development and Agaric values

2019

• Platform Cooperativism 2019 - Who Owns the World? - New School, NYC
• BADcamp 2019 - San Francisco

• Mass Pirate Party - Ring Doorbell Surveillance
• Keynote - LibrePlanet 2019 - M.I.T.
• Micky's Resource Links from LibrePlanet Keynote
  • How can we prevent the Orwellian 1984 digital world? - March 2019 - M.I.T. Boston, MA USA
• Keynote - NERDsummit - UMASS Amherst
• UjimaBoston
  • Series of four workshops on Free Software and Platform Cooperativism in January 2019
• Chris and Micky present at Boston College on AI and Free Software
• Micky and Ben present at DrupalCon Seattle on Scaling Community Decision Making

2018

• 3rd Regional Workers Encuentro
  • "Communications & the Workers' Economy" (workshop) Mexico City CDMX
• Center for Global Justice Assembly
  • "Securing your devices and using free software" (workshop) San Miguel de Allende, Mexico
• LibrePlanet 2018
  • Connecting communities with schools and free tools (workshop) M.I.T. Boston, MA USA, Facilitators: Micky Metts, Chris Thompson
• New Economy Coalition's CommonBound - St. Louis, MO USA
  • Technology for the New Economy

 

2017

• Open.coop 2017 - London University, London, UK
  • Panel: Empowering digital collaboration: Introducing the open app ecosystem
  • Workshop: Designing interoperable apps for the open app ecosystem

Learning Objectives

• Understanding the ETL process
• Writing your first migration from a CSV file
• YAML syntax and migration errors
• Introduction to process plugins
• Understanding migration workflows
• Migrating data into nodes and files
• Migration syntax for multivalue fields
• Migrating dates and times
• Migrating addresses and validation considerations
• Migrating taxonomy terms with entity_generate plugin
• Source constants, pseudofields, and the process pipeline
• Migration dependencies
• Introduction to paragraph migrations
• Migrating from JSON endpoints
• Defining migrations as configuration entities
• Running migrations from the user interface

Prerequisites

Although no prior Migrate module knowledge is required, it is expected that you have a basic understanding of nodes, content types, and fields. We offer a getting started with Drupal training that covers all that is needed to take this course.

Setup instructions

Installing Drupal or 11 locally using composer is required. You can use the quick-start command that comes with Drupal core. Alternatively, you can use a tool like DrupalVM, Lando, DDEV, or Docksal. Drush needs to be installed in order to run migrations from the command line. You can learn more about the prerequisites for the training visiting https://agaric.coop/migration-training-resources

This training will be provided over Zoom. You can ask questions via text chat or audio. Sharing your screen, but you might want to do it to get assistance on a specific issue. Sharing your camera is optional.

What to expect

Prior to the training

Attendees will receive detailed instructions on how to setup their development environment. In addition, they will be able to join a support video call days before the training event to make the the local development environment is ready. This prevents losing time fixing problems with environment set up during the training.

On the days of the training

• The training totals 7 hours of instruction, which we usually split into 2 sessions.
• A team of developers available to answer questions and help with training-related issues.

After the training

• Attendees will receive copies of the training recordings.
• Attendees will receive a free copy of the 31 days of migrations book.
• Attendees will receive a certificate of completion.

Follow-up resources

• Slide deck
• Migrating Drupal 8 with Confidence slide deck
• Our migration-related blog posts
• Drupal 8 Migrations by Example Course - Includes a demo module and session recording to follow along to.
• Customize migrations when upgrading to Drupal 8

Taxonomy term migrations

Taxonomy terms, as very simple content usually directly associated with nodes, are amenable to two main approaches of migrating.

Migrate first in a true migration, similar to the entity_references example from the training, or create the taxonomy terms during the node migration.

Full migration approach

See Migrate Plus for examples, specifically the submodule migrate_example_advanced.

Create terms as-you-go approach

This approach means you can't clean them up easily with a migrate rollback but it can be suitable when you are confident of not needing to roll back or being able to delete all terms in the vocabulary if you need to do the migration fresh.

This was shown in the training in the professors example.  There is also community documentation of the entity generate plugin that we make use of there; it is provided by Migrate Plus.

Upcoming trainings