Toronto Workers Co-op offline.systems Process Meetings
======================================================

[TOC]

---

# 14 Sept 2018 16:30-18:00 ET Notes

## Attendees

Aaron, Benedict, Dawn, Garry, Elon??

## Agenda

1. Protocol Labs RFP drafting retrospective
1. Open work model
1. Document policies
1. Project management tools
1. Review potential actionable items from last meeting
1. Budget
1. November in-person meeting plans

## Notes

### Protocol Labs RFP drafting retrospective

* Evan is on vacation but has a review committee looking at proposal:
* small review committee will start looking at it, we don't really know their process otherwise
* Evan will be back in two weeks
* 1 month after the date of submission, there will be a decision
* it would be nice to plan a call with people who have weighed in on our proposal
* since they seem to be making up this process as they go along, maybe we will have more ability to ask for things
* Matt wanted to be involved somehow, but he's balancing many things
* drafting process retrospective
* call with Evan (context missing from Ben, Juan, and Matt)
* 5K for 2018, what is appropriate to ask for 2019? what is interesting to the review committee?
* publicly visible projects are appealing
* committed to a timeframe which was not ideal. missed involvement in early calls. how to move forward?
- open up to reflections on process:
* a: trying to balance with other committments (conf, work), hard to follow the chat at first. Now in position to look ahead and plan for the next while. Will make things easier
* g:
* trying to find the right thins to review... seemed the doc was already fleshed out when review. Unclear what/where feedback was needed, given timeframe.
* how doc was structured, expectations unclear
* gdocs was a good environment to work in
* not having single author proposal and then follow through on
* OKRs!!!!
* b:
* evolved to be a lot bigger than when started (and initial expectation)
* d:
* would have been nice to be involved in an earlier, more collaborative stage
* timeframe was difficult because of travel, bad data availability (i can't do those short turnarounds in general due to other committments)
* how often to be available in chat (riot feels like a waterfall sometimes)
* g: notified if mentioned, but not checking channels on the regular
* b: a lot of people are having trouble keeping up with riot
* was the call with evan the time to involve people? should we have regrouped before committing to anything?
* actionable understanding on peoples' avail to help guide turnaround?
* d: used to practice of always sharing in advance if a call is being set up (not expecting folks to attend)
* d: EDGI consensus/non-hierarchical model means that there is always a regroup period (or things that folks can't agree on alone)
* low-noise signal:
* e-mail ?
* calendar for shared visibility of calls and deadling
* invite workflow for communication ?
* setting a standing time
* d: best-effort (generally available time (GAT))
* d: set up a poll?

_Ben was taking notes in another place in the doc :(_
* benhylau: should have involved more contributors when first spoke with evan
* ansuz: hard time following chat (also personal bad timing)
* garry: timeframe to review long document was tight, but we talked through it
* garry: Google Doc format is good but need more collaboration early on
* dcwalk: need more lead-time, context, where to provide feedback, and earlier involvement
* dcwalk: we seem to have slightly different ideas of an OKR
* dcwalk: Riot is a struggle
* ansuz: idea about people's turn-around time
* dcwalk: announce a call even though it's last minute
* dcwalk: do not commit anything without at least two people on a call (this is EDGI's model)
* benhylau: set a weekly standing time block

### Open work model

* Availability expectations
* General Availability Time
* Part-Time/Full-Time
* current availability expectations
* when nobody is working full time
* d: not going to have a lot of time to be generally available
* b: at least $days notice
* Response lead time
* d: how available am I for urgent decisions, how available am I for general questions
* generally avoid same-day decision requirements
* NYC-time
* how do we notify people that their input is required?
* escalating model?
* people have different means of communicating (riot, signal, etc)
* make a riot URGENT channel
* email? (ben hates email, dawn lives in email, garry also lives in email)
* Content details are on riot, but ping people on email for urgent matters
*

### Document policies

* d: Garry said Google docs was a familiar editing workflow, why don't we make a shared folder?
* how are we going to organize things across google-docs, hackmd, hackfolders ?
* what services are we comfortable relying on for the long term
* self-hosting ? are we more reliable than google?
* what about migrating meeting notes into .git when they stop changing?
* print it out onto archival paper?
* microfiche?
* backup to tape
* are we committing to using google docs?
* not necessarily, but it's easy
* we can export to *
* +1 to exportable content in standard file formats
* pdf, markdown

### Project management tools

* riot
* email (urgent things, if necessary for correspondance externally)
* google docs (as staging area)
* hackmd
* google calendar
* .git backups `rm -rf .git`
* kanban ?
* who are the haters?
* let's hold off on this for now?
* github project management?
* crazy spreadsheet setup? `<!-- you mean nothing to me -->`
* ben says no
* the example is work-related and can't be shared
* dawn has used spreadsheets
* so has Aaron

### November meeting plans

* meet for a weekend, have two weeks of async to form working groups
* what about Patcon? we have to plan around some remote participation (probably)
* Patcon's contract is full time, indicated that he won't be available (on the table)
* what about low-commitment involvement?
* hopes and dreams?
* let's reach out to people but not pressure them to be available
* a: can't necessarily commit to being there in person
* let's poll for a tentative date
* synchronous/async
* there are a lot of topics which will be better communicated by having people in the same room
* two weeks for a retreat is huge
* a few days or a number of 3-4 hour sessions
* d: maybe we want to set up a planning board for this? dawn just finished planning a one-year thing, so she's tired of it.
* b: spread work among three people?
* d: always good to spread the work
* udit and rob should be involved in planning (across project areas)
* should we plan time for async actions?
* it will probably be helpful for people to just have some time to think about particular issues, so that they can come back with ideas..
* reading network (for the coop?)
* not necessarily papers or news, but general content which we should have all reviewed

### Budget

* Potential grant money allocation

<did not discuss>

## Review potential Actionable items

Recall..
- establish shared calendar
- establish shared email
- crm/spreadsheet of contacts
- top-level coordination tool
- establish how we plan to be self-sustainable (financially)
- keep this in mind for our future grant processes
- service business? (we act as contractors)
- diversify income sources (Rob and Udit) in the future

## Actionable items

* dawn: set up a poll to arrive at a _Generally Available Time_ so we know when to schedule things
* there are several scheduling questions
* Poll: https://www.when2meet.com/?7093076-eOJLY (ET)
* ansuz: set up a google docs shared folder
* ansuz: make a git repository with a (possibly self-hosted) upstream
* ansuz: set up a mailing list?
* mailing list with cryptography.dog
* get emails from the offline.networks proposal
* ben: loop Rob and Udit into the planning process for coop meeting
* project board?
* shouldn't live only in Meeting notes!
* d: let's start planning **now** (I can share old docs)
* b: can't foresee people being available _now_ because we planned to start in November
* d: if we can't plan now, we shouldn't schedule now.
* _give people time to be successful_ --d
* ben: plan another meeting for next week?
* to catch up on status of actionable items
* future: Talk about our plan for what we do if we don't get the grant
* this informs how much time we ought to allocate towards coop activity before we know the status of the grant
* create a policy for a coop _reading networks_
* name the organization
* buy a domain?

---

# 10 Sept 2018 16:30-18:00 ET Notes

## Attendees

benhylau, yurko, ansuz, elon, dcwalk

## Agenda

1. offline.systems proposal timeline and PL review process
1. Share things that only benhylau knows at the moment
1. Establish mutual understanding about who we serve as contributors to offline.systems
1. Value proposition for offline.systems
1. Discuss risks in our submitted RFP

## Notes

- [Proposal](https://docs.google.com/document/d/1bkIegOqDUE8C3Cj6yO8Hi9X8oYCFiEqLglpjqXjI7Ac/edit#)
- [OKRs](https://docs.google.com/spreadsheets/d/17q0rQQ4fLxsef7PRh8L3dogXOowf8r45fVYuV7Sy3kw/edit#gid=0)

### offline.systems proposal timeline and PL review process

- Submitted date: Sept 4
- Didn't recieve any feedback from Matt Z. or Evan M. about the draft. Do not expect further feedback
- One month from submission date (Oct 2, 2018)
- **This phase mid-Sept to mid Oct**:
- Questions we can respond to on the Google Doc
- Can have a hosted call to discuss questions
- Shared calendar + cc'd email (decide on org/process call)
- _Note_:
- _Drafting process was semi public_
- _Tuesday was the final submission_
- A: do we know amount of funding? success factors? etc...?
- So far the grants have been small (<$10,000)
- This would be the largest grant, unclear how many submissions they recieved, lots of discussion at lab day

### _Who_ do we serve as contributors to offline.systems

benhylau:
>Had nicopace look over our proposal, his feedback:
>
> like the offline.systems proposal.
i feel that it is lacking a little bit of background... what motivates for this to happen
what bring you to the conclusion that these needs to happen
...
who are you solving an issue to...
not who can benefit, but who are you working for
there is a slight difference there
...
yes... it feels broad
that I feel needs to be clear
you as a collective need to have a clear understanding of that too
...
some references:
https://www.uxpin.com/studio/blog/the-practical-guide-to-empathy-maps-creating-a-10-minute-persona/
https://www.mindtheproduct.com/2017/11/step-step-guide-constructing-persona-workshop/

#### Objective 1

- Each place need similar things... something buy cheaply....
- examples
- Altermundi
- Guifi (very little software capability)
- post-referendum: local networks have strong appeal
- very established hardware network
- Pre Telefonica: "heavily guifi" communities versus post-ISP expansion (some people don't even know they are part of a commons-based network)
- Luandro in Brazil is working with basic versions of software trying to put something together
- Mexico? Cuba?
- Yet, Victor deploying IPFS on the network is finding he can't reach stuff far away.
- Evolution of mesh stream, moving into live deployment
- A: if our "runway" is whatever we get from Protocol Labs what happens after?
- What is the plan after?
- Ben: reputation for further funding, how do we stop being a consultant
- Dawn (paraphrased by Aaron): trying to serve many distant groups is going to be very challenging, and we may not be able to do that well within 6 months
- every community has their own little quirks, trying to generalize across all is likely to lead us in the wrong direction
- how is Toronto tied into this
- dependence on "grant cycles" is scary and unpleasant
- Dawn: I think we need a really clear sense of the case/context a thing is being built for
- Benhylau: see (1) as building a bunch of things that benefits a range of communities
- Dawn: <wierd example of 8 modules and how we prioritize>
- Ansuz: what stood out from the example from guifi-- can't even build a website... touches on usability considerations. Will they have someone able to fire up the terminal? If all modules are unix-based maybe not great
- B: discussed with garry, did break up design
- B: guifi: cli vs. js... guifi command line no problem
- B: infra to build nodes on router, existing network
- Aaron: can we identify why the other raspberry pi platforms have not been successful ? are there any which have been ?
- https://yunohost.org/#/
- https://www.reddit.com/r/selfhosted/comments/9evzzx/help_needed_running_yunohost_and_pihole/
- portable network kit
- mazi toolkit
- librerouter ?
- D: how do we think about parallel projects in this space? Not just "yet another platform" especially if we are interested in sustainability
- What have we done so far (that others have not)?
- investigation into problems with p2p application deployment in offline networks
- ntp, ..., ?
- Toronto mesh knows a lot about hardware development?
- Engage with at least two communities and support their development
- do we all agree what a "community" is ?
- let's all get on the same page with how much effort will go into this
- D: I think developing a workplan as the grant goes ahead will be critical to refer back to and learn from

#### Objective 2

- See the workshop as the key part? The audience/use case that we should see as a priority

##### Aaron's proposal:

1. get the innovative tech done as fast as possible so we can hand it off
- generate leads on community integration while this is in progress
2. hand off deployment to objective 2 facilitators
- review deployment process with communities in order to better serve objective 3
3. post-mortem deployment, unforeseen user requirements, etc.
- facilitator program takes over here?
4. invisible step to account for going over-time on other steps

Maybe let's plan this out as a tree to see what depends on other objectives to see what we can parallelize, what we can reasonably accomplish within a period

### Value proposition for offline.systems

udit:
>I’m not totally certain who’s reading this and perhaps I’m off about the baseline knowledge and values the reader may hold. My immediate thoughts are that the high-level framing can have more clarity. Some thoughts:
>
>1. Clear value proposition of an “offline system”:
>
> 1.1 Can brings current communication technologies to locations that the market does not consider to be profitable
1.2 Alternative during service breakdown during or in situations of network congestion
1.3 Independently run local offline systems can be tailored to serve the needs of a community better than any top-down network
>
>2. It’s also not obvious why an offline system needs to be peer-to-peer. Perhaps we could make this more explicit and succinct:
>
> 2.1 Secure p2p networks change the ownership model in favour of the users and are effective at limiting authoritarian control and censorship
2.2 Grassroots p2p networks are able to diffuse technical know-how rapidly empowering the whole community
2.3 Re-affirms the original vision of the web as a people’s platform

### Share things that only benhylau knows at the moment

* we have contact with vendors for adding board support to workshop (Alpha, Drago?)
* contacts for workshop facilitator
* Hank and Yurko in FL workshop expansion
* Bkyn school workshop expansion
* Guifi workshop expansion
* Oslo hackerspace, stig

### Discuss risks in our submitted RFP

- sequence of deployment and technical work
- contacts and timeline working across organization
- organization between each other (segregated knowledge)
- people available to do work (do we have 2 full-time people?)
- track things in a way that allows part-time people to easily follow (kanban?)
- unexpected delay on any part of the project
- misfit between what we think communities need and what they need
- hardware sourcing will be a fun one
- Dawn: find the best, cheapest thing for a community to use (locally)
- we all hate each other unforeseenably :D
- unexpected operating overhead
- unclear allocation of funds toward Facilitator Program

## TODOs

- establish shared calendar
- establish shared email
- crm/spreadsheet of contacts
- top-level coordination tool
- establish how we plan to be self-sustainable (financially)
- keep this in mind for our future grant processes
- service business? (we act as contractors)
- diversify income sources (Rob and Udit) in the future

## Off-topic chat (Sept 10)

* Guifi network legal structure (anybody can be an ISP, anyone can switch)
* rulings re: network exclusivity made it possible for condos to host mesh nodes, and much of the challenge is convincing condo boards that it's ok
* lostpacket (formerly lenovo infrastructure)
* it's difficult to tether antennae on rooftops, because existing tethers are already certified (we don't have anyone certified for this kind of thing)
* 6 euros per meter of fiber (in Spain)
* cost is eaten by ISPs for the promise of future customers
* creating a structure which other parties can easily interface with can make the project more sustainable
* BUT you may lose out on the community aspect because they deal with a service representative
* Guifi users in remote regions are loyal because Guifi was their first experience (connecting to the internet from home)
* Guifi is not using one standard protocol except BGP linking things together
* not a lot of redundancy on clients, mostly star topology
* BMX6, other protocols
* one person currently building tooling for visualization of fiber
* Some local interest to get off ubiquiti
* flashing is hard
* proprietary
* perhaps more flexible devices?
* yurko: tomesh prototype is more like a product than a dev platform at this point