FAQ

1. Check out the overall plan.
2. Assess how you want to contribute. Some options are:
   • Coordinator: 5 – 10 hours a month. We’ll provide the tasks, you schedule time with your organization, administer tasks, and return the results.
   • Participant: 2 – 4 hours a month. You show up and provide input on tasks.
   • Project Team: Time commitment varies. We need folks who want to help us formalize activities, take on project management, communication, provide feedback, big picture or whatever you want to contribute.
   • Ad Hoc: Roll your own involvement. Perhaps you share coordinator responsibilities with someone else or only have time to provide feedback on something one time. Whatever it is, we’ll take it.
3. Let us know how you want to contribute.
4. Receive contribution prompts from us according to what you indicated in #3.
5. Respond to the prompts on your own or with collaborators at your organization. The more minds, the better.
6. Submit your contributions.
7. Join in on an optional monthly debrief of each design cycle.

After extensive research into options for replacing the languishing Robot (our open-source food logistics software), we are developing new software. We’ll collectively design it as a primary organizing tool for our local communities, bringing along all that we’ve learned using/building previous software.

High-functioning software reallocates time from managing redistribution logistics to un-automatable tasks. Tasks like building relationships, supporting communities, and building our ability to impact regional conversations collectively around the gaps within our existing food system.

Outcomes of the product are 1) more resources for organizations to build and leverage relationships within their communities and 2) stronger relationships between our organizations.

In line with our core values of community-driven collaboration and participation, the design and development of the new software will utilize participatory practices. It makes sense the people who use the software, are the people who design it. Through the duration of the project, we’ll be calling on you to assess your capacity, in terms of time, interest, skills, and experience, to participate in the design process.

Participation does not necessitate software use and using the software also does not necessitate being a cooperative owner of the software. You can participate in this initiative in order to better understand your workflow, needs, and challenges, and connect with other FRA members without needing to commit to using the software.

Be transparent with the people who engage with participatory efforts. People who use the software should know how decisions are made, how they can participate and provide input, and whom they can talk to about their concerns. There should be many ways to learn about these things.

Increase ownership through participation. The central objective for participation efforts should ultimately be transferring power, control, and influence to the people who use the software.

Engage a variety of organizations; engage a variety of stakeholders within the organization. Organizations know their own needs the best. We want to engage staff, volunteers, recipient site representatives, and board members. Which of these groups can your organization bring into the conversation?

Make participation accessible. We need to offer accommodations for making participation more accessible and flexible. It is advantageous to engage a diverse population in participation and to expend resources to make participation accessible for people who are disproportionately affected by systemic oppression. To do this, we need to know what the barriers to participation are for organizations and work to ameliorate those barriers. Do you want to participate and have a barrier? Reach out and let us know.

Leverage existing assets of the community. All communities are full of assets, knowledge, resources, and expertise. A person or organization engaged in the daily logistics of food rescue know the problem most intimately, know their own needs most directly, and know how their needs can best be met. If you have an asset that would be useful for this project, reach out and let us know.

Meaningful systems of participation are built on relationships with people.
Healthy relationships are built on mutual trust and respect. Think about ways to ensure that participation does not feel transactional, but instead focuses on the relationships between everyone involved. Outcomes of the product are 1) more resources for organizations to build and leverage relationships within their communities and 2) stronger relationships between our organizations.

A meaningful product is the result of collective sense-making. This project will not simply collect information about your needs and make sense of that information without you. Your input is desired at every level you’re willing to offer it: creating the activities, information gathering, making sense of the information, prioritization of needs, and project design.

Our fundamentals are wrapped up in the ideas of emergent strategy. The most pertinent of those ideas, when it comes to growth, is “move at the speed of trust,” “small is good, and the small informs the big,” and “what you pay attention to grows.” We are not aiming to automate food salvage and redistribution to replace humans. We are building software to support human activities.

Growth, for us, is sustaining software that enables time for human activities. Activities that lead to more opportunities for listening, like participatory research. Or, as a national alliance, engaging in critical conversations about our processes, shared ownership, and decision making power. We envision that this will mobilize action based on the actual, existing and emerging needs of food rescues and recipient communities and significantly deepen root-cause advocacy work addressing systems that create food insecurity and waste.

Software is risky, and nonprofits’ risk tolerance is low. We will use modular contracting to break up this large, complex product into multiple, tightly-scoped projects. This approach reduces vendor lock-in, shortens our learning curve, and encourages the delivery of working software quicker. Additional risk mitigation tactics include using professional development and a software pattern that plans a gradual migration from legacy systems, avoiding “big bang” deployments.

Cooperative software requires the coordination of multiple organizations. Nonprofit staff are very busy and may not have time to contribute significantly. If the software is unsupported, it will be less relevant to the organizations’ needs. We will use our significant experience in participatory design research to enable varying levels of participation, depending on an individuals’ capacity. Additional risk mitigation tactics include setting realistic expectations, clarifying timelines, standardizing when appropriate while leaving lots of room for localization, and utilizing established communication channels with FRA members.