[Freedombox-discuss] Working Groups Proposal

[James Vasile]

I discovered last night that my mail to this group has been disappearing
in to a hole, which explains why my recent emails have generated zero
response or discussion.

Here's the working group plan, generally described.  This is a proposal.
The people on this email list will decide how this actually works in
practice.

We can populate these groups on the mailing list and then those groups
will work via whatever mechanism they deem best.

Best regards,
James Vasile



## Promotion and Visual Identity

This team is the welcoming face we share with the world.

 * Logo and associated branding
 * Prettier website
 * Identifies conference and speaking opportunities
 * Organize hackfests
 * Encourage media coverage of the FreedomBox project
 * Recruit more people to the project
 
## User Experience

This working group will design the layer that the end user sees.
FreedomBox will live or die based on whether it is easy to use, and
ease of use for unsophisticated end users is this group's highest
priority.

The UX Working Group may also create mechanisms to serve advanced
users.  It might be the case that the FreedomBox will need a simple
configuration mode and also an expert mode that we don't expect mere
mortals to ever see.

Although UX is a separate Working Group, every aspect of this project
is connected to user experience.  As such, it is expected that this
Working Group's members will work closely with other Groups to produce
a consistent and simple user experience across the many parts of the
FreedomBox.

### Goals

 * Identification of UX priorities, goals and standards
 * UX conceptualization to serve those priorities, goals and standards
 * Execution of that concept in the browser and smart phones apps
 * Conduct real-world HID trials of the UI


## Network Protocols

This working group will develop the means by which FreedomBoxes will
talk to each other in a secure, anonymous and private fashion.  This
is a tremendously difficult project because there are so many
considerations and trade-offs.

### Goals

 * Evaluate mesh networking options
 * Evaluate DNS/routing options
 * Evaluate ways to find other FreedomBoxes and communicate with them,
   assuming TCP/IP connections.


## Peer Model

The FreedomBox has social built in to the stack at a low level.  What
that means is that it has a concept of who it (and its users) are
interacting with.  That knowledge should be available across the
device and allow the user to treat all interaction with people or
groups of people in context-sensitive ways.  That means the FreedomBox
will need a way to store and organize information about peers (both
boxes and users on those boxes).  It will also have to make that
information available to the applications on the FreedomBox, including
existing applications with their own user models.  Finally,
information interchange between FreedomBoxes will sometimes include
data stored in the peer model.  What are the concerns about this
interchange and what steps should we take to do this interchange while
protecting security, privacy and anonymity?

This Working Group will recommend a peer model and ways to integrate
that model into applications, both new and existing and also to
exchange data with other boxes.  It will possibly develop software to
implement its recommendations.

This Working Group can assume that data interchange will take place
over protocols selected or developed by the Network Protocols Working
Group.  This group should not develop protocols.

## Configuration

Beneath the user interface, there needs to exist a layer that actually
manages configuration.  This is the layer that edits text files to
enact user choices, sanity checks those choices, rolls back changes,
maybe files reports so we can identify option conflicts, etc.

This group might reasonably start by looking at Nick Daly's excellent
config work.

### Goals

 * Create an API for talking to the UI layer.
 * Prevent conflicts or breaking the box.
 * Enact config choices (edit text files, change db entries, run
   scripts, etc.)
 * Record new conflicts so we can prevent future conflicted config
   states.  Optionally report that data.
 
## Social and Applications

Decentralizing the web requires self-hosting the applications used by
so many people as part of their daily lives.  Email, (micro)blogs,
social networks, photo-sharing, shared whiteboards, file sharing, etc.
This group will evaluate existing software and identify software that
can be hosted on the FreedomBox in conformance with its goals and with
minimal changes to the software.

### Some Goals

 * Separate data from applications
 * Export/import/interoperation with existing services
 
## Security

This Working Group will identify the security concerns that plague any
effort like the FreedomBox.  They will review new code, review
existing software packages, and gently apply their paranoia for the
good of us all.  It is recommended that this group work closely with
the Network Protocols team.

There is a tradeoff between security and ease of use.  This group
seeks to illuminate rather than defeat that tradeoff.

### Goals

 * Allow as much communication as possible while protecting security,
   privacy, and anonymity.
 * Identify the trade-offs between security and ease of use and
   recommend points along the continuum FreedomBox might inhabit.
 * Allow security-minded users to have security while interoperating
   with users who choose less secure mdoes of operation.

## Documentation

This Working Group will develop documentation standards and execute
those standards to provide end users as well with all the information
they need to use a FreedomBox.  This Group may also create
documentation for developers.

The existence of a Documentation Working Group does not free others
from writing and maintaining documentation.  Documentarians will work
closely with other Working Groups to *help* with the documentation
effort and to standardize it across the project.  Responsibility for
documenting FreedomBox technology, though, remains with those who know
it best-- e.g. those who develop, customize and package it.


## Platform Group

The Platform Group tweaks Debian, packages software, studies
deployment, brainstorms the path from a stock Dream Plug to a working
FreedomBox, investigates other platforms and anything else involving
the layer from the OS on down.