Meeting Agenda/Notes 9/24/2020 2PM EST
===

:::info
**Agenda**
* Introductions
- Name / Pronouns
- What you can offer
- How you came to be here
- General Availability
- Email 2-3 sentence bio 9/23 to [David](mailto:[e-mail])
* Critical Needs Mapping
* Secure Communication & Data Sharing Standards

**---------this is where we got to before mtg ended! --------**

* Process:
* Trello/Asana Team Dashboard
* How do we decide what we're working on?
* Agile?
* Onboarding
* General web upkeep (refreshing content, widgets)
* Project Updates
:::

Notes
--
**BIOS go here:**
**Alex** - (He/His)
Currently based in Senegal, working on GIS and satellite imagery. I can offer help with maps and data science but also happy to be on other projects as needed. Quite new to MADR as I only joined two weeks ago.

**Josh** - (He/His)
Based in Boston, infrastructure engineer building adhoc systems to support relief efforts - excited for more qualified ppl to join and help :)

**Silvena** - (They/Them)
Based in NYC/Lenapehoking. Machine learning/search/backend engineer. I can help with search, API, and general backend-y things.

**David** - (he/him)
Based in Maine. Have worked with MADR since 2017. Built/hosts website. Does design, tech. Addresses miscellaneous MADR tech, graphics, materials needs. Historically liases with external tech-related inquiries and/or groups seeking to connect! Reluctant ever and anon convener! Happy to dole out some responsibilites and help us achieve a sense of collective agency over being MADR tech support :)

**Leah** - (she/they)
Based in Ypsilanti, MI. UI/UX design experience. Currently working on Grassroots Disaster Relief Toolkit platform in collab with MADR: includes public forums, editable map of disasters, disaster profiles, group profiles, and resource library.

**Mal** - (They/them) Above-computer level, translates security does training, tech recommendations with non-profits and grassroots orgs. Happy to help with trainings or look into new platforms.

Jimmy - (He/Him) Tampa Florida. Original MADR member. Jimmy works on many elements of MADR, makes web content, participates in products like solar bike trailer.

**Tulsi** - (she/they)
Based in Missoula, MT/ Salish and Kalispel lands. Full stack software engineer, currently part time employed. Interested in mapping, critical communications technologies, and peer-to-peer open sourc tech

**Tim** - (he/him)
DevOps. Has worked with Josh and MADR for a few months. Worked with Josh on building a low-tech solution for mapping (see Critical Needs Mapping). Looking to work on information security side for MADR. Has been working on Hurricane Laura but shifted to PNW recently.

## CRITICAL NEEDS MAPPING

Gist: When there's a storm there's individuals who needs things (material/physical aid)

**Josh**:
In Hurricane Laura response a spreadsheet (via Google Form) was used to track inquiries, building supply routes based on sheet content and knowledge of local area. **Josh** and **Tim** built a Google Sheets plugins (dovetails with Maps). **Josh**: long term issue is ability to understand needs and where they are. broader info needs to be available to responders - individual/personal info **needs to be secured**. System presently works by dropping spreadsheet line to pin, and map access is limited. See also Leah's solution/work parallel to this.

**Leah**:
for last year platform we're creating's major difference is to support long term network building and archiving of disaster relief / preparation + recovery. acute "I have a need/ask" is not necessarily covered by this round of features. Have experimented with some feature support to address what Josh described above. Platform right now includes editable map of disasters. Forum boards relevant to disaster profile are enabled.
* group profile feature that enables groups to list needs
* individual users can have their own profiles
* resource library component
* Leah's going to send link for MADR Relief Platform (via Signal)

**Alex:**
**Alex** has experience making quick, interactive maps for mutual aid disaster response. has ideas on safe structuring. would recommend building something new/separate from ground-up. Alex would be happy to lead charge on conceptual architecture, draw maps. **Silvena** can help with API. **Josh** can build a cloud platform for us to host data (preferred linode, would have to check their security protocols)

**David**: contacted by a group offering to do custom code with HelpSupply that could help with this. Worth looking into. **David** will share a link in the notes. https://drive.google.com/file/d/1zwi8xk6DM2_eCXPCLIMv2G4EEH-W-S9w/view?usp=sharing

**Leah**: as tools are being developed, we've continued to build based on our unique goals. Encouragement for new projects to proof out need and unique value of project, especially as more similar apps are already being developed.

## SECURE COMMUNICATIONS

**Josh**:
- current system is based on controlling sharing on google docs.
- ease of use is important for folks on the ground. Googlesheet/doc mix is a good mix for ease of use

**David**:
- we have a group that is cognizant of risks, but not necessarily systems in place (David please help fill in when you can)

**Jimmy**:
- While our actions are legal, there are bad actors who will try to connect us to those they'd want to attack.
- Balance is important (barriers to users being able to access docs vs security)- example of a lost signal thread when trying to remove old messages.
- Peer to Peer toolkit could help with this and be a more robust option.

**Mal**:
- Security culture underpins everything and ease of use is still essential (likewise availability). As horrible as google is on privacy, it remains the most available. Continuing to use google for emergency scenarios is still forseeable, though not for long-term planning. We should mitigate the threat of our information living on google forever and adopt a strong policy of data hygeine (how long do we keep data for?). response-specific spreadsheets and call notes should be removed as quickly as possible.
- Gsuite is currently not used by MADR. **Mal**: But MADR could get a free license if we desired. Allows for automation of deleting old files. We don't love google but it could be a necessary evil. *LINK TO FREE G SUITE FOR NON PROFITS* https://support.google.com/nonprofits/answer/3367223?hl=en
- Happy to help with implementation.
- End to end encryption can be a working alternative to building our own server-system. Signal, for instance, might allow for a group call function. Wire allows encryption for voice calls. Keybase has great data storage options, but not as easy as signal.
- Jitsi is still in Beta, but mayfirst could be a good option.
- Cryptpad as a possible note taking/sharing system.

**Josh**:
- Gsuite helps with a lot of our immediate needs in a secure environment(security, not social!). Allows for an easy delegation of access.

**leah**
- MADR organizers store some meeting notes on google drive, but response-specific information (addresses, resource caches, contact info) is usually coordinated elsewhere, instead of MADR spaces. Developing pointers on the security risks to allied organizations could go a long way in improving data security.

**Mal**
- risks of right-wing violence may not be confined to PNW

**Tim**:
- Risks range from doxing to being subject to physical violence when transporting supplies
- Need to consolidate certain communications and bridge disparate local groups (increase visibility)
- Suggestion is Keybase (although acquired by company with checkered past) to open a line of communication
- Security policy probably won't work for different groups with different tech, but security culture is valuable (ex. only those who need the information can access it, like having less sensitive versions)
- Possibly making templates with secure sheets that automatically create versions with less information available (ex. address --> zip codes)
- An example is a huge mutual aid group with a huge database of undocumented folks. Not very accessible, but what's happening with it? There needs to be a way to age out anything that is not needed. If any of this got leaked, it would be really bad.

**Alex:**
- sensitive information is stored by the local groups, so any approaches to protecting data might not affect everyone
- Do we have a group that is working on this? (Tim says him, Mal, some other folks. Fire relief keybase is having this conversation)
- Let's make the discussion happen with the interested folks and make a plan.

-----MEETING ENDING - we'll port AGENDA items following Security/Communications

:white_check_mark: Tasks (from notes above)
--
### Critical Needs Mapping TASKS
- [x] David shares link re: Help.Supply info (https://drive.google.com/file/d/1zwi8xk6DM2_eCXPCLIMv2G4EEH-W-S9w/view?usp=sharing) -*just updated, in case you tried to look. now accessible if you have the link (no sign-in required)*
- [Help.Supply Github](https://github.com/helpsupply)
- [ ] Leah will reach out to DevTeam (MADR Toolkit)
- [ ] Alex will reach out to Silvena/Josh re: map-making

### Security/Communication TASKS
- [ ] investigate G-Suite as free for non-profits. Also possibly ZOHO as an alternative!
- [ ] Create document that explains/introduces a general protocol related to MADR's security suggestions/practices. Develop recommendations.
- [ ] Will shoot for keybase for the next meeting. **Mal** will send invite.
- [ ] we are already hooked up with non-profit via Google (re: ads), but let's try upgrading to G-Suite for non-profits. Jimmy will investigate, will tap David if necessary
- [ ] Tim will link up with Mal & Josh to talk about this and come up with a plan

### Process Tasks
- [ ] Make a git repo for documentation (validate that this is accessible for folks in the group in Signal. If it is, make it. But if it's not, let's look into how to make it more accessible). If we host the MD files elsewhere on a static site, they can be edited more easily by folks less familiar with markdown.
- [ ] Come up with a list of documents we need: Ex. How to create a new group, security how-tos, what kinds of docs do we need/what is the top priority?
- [ ] document existing projects and working groups
- [ ] reach out to those already using the Asana/Trello and figure out how it could/should interact with groups/documentation.
---
### MISC TOPICS NOTES (CARRY TO NEXT MEETING):

* david learned about disaster respond cellular band prioritization, let's investigate!
* solar trailer router progress
* Mal: free G-Suite account available to non-profit.

---
# NEXT MEETING

**THURSDAY** 10/1 @ 2pm EST
assuming regular Thursdays unless conflicts seem to arise

agenda (resuming from last time)
* Process:
* Trello/Asana Team Dashboard
* How do we decide what we're working on?
* Agile?
* Onboarding
* General web upkeep (refreshing content, widgets)
* Project Updates
---
# Process Notes

**Silvena**
- Would be best to wait for Tim and Josh, who have put in a lot of work on the Asana/Trello before anything formalized.
- As of now, we have an informal system of working groups but no method for people to express interest and join those working groups.
- Maybe we can come up with a way to list the things we are currently working on and accomplish more as a group. Right now, group work is splintered.

**Tim**
- Security vs. Speed tradeoff

**Alex**:
- Could be valuable to have a list of things that people are doing, even if not an intense dashboard

**Tulsi**:
- Really helpful to have a place where we have documentation (private or not), with how we worked and what we're working on, how to get involved. Ex. an organization called Cooperative Gardens Commission distributes food production labor and resources like community gardens, small farms. Divide that work. Have an extensive working group set up, what the groups are, when the meetings are, how to join.
- Have a template for describing working groups, but each group can have different processes, like a more secure group will have different join/contribution processes.

**Tim**:
- Could be set up like an open source project. If the repo is public, anyone can see issues and contribute, can fork. Grows organically, but there isn't a hierarchy. But the open source community looks at it and dictates how it ends up going.
- A backbone could be a github repo with encrypted files.

**Alex**:
- Really likes the templates idea. Doesn't impose structure

**Tulsi**:
- A lot of what we might create as a group might be documentation templates/guides for other organizations to take and follow as their own, like security best practices and google sheets templates.
- This group is sort of like tech support for other groups in MADR.

**Tim**:
- First q when joining was where are the docs
- "Best practices" is a good framework
- Josh & Tim were working on Ansible ... (missed it) before they saw Leah's toolkit. Tim will put a blurb on this if folks are curious

**Tulsi**:
- People's time/commitment ebbs & flows and having things be more organized will help maintain momentum