[Freedombox-discuss] Working Groups

[James Vasile]

On Fri, 15 Jul 2011 10:12:28 +0200, Robert Martinez <mail at mray.de> wrote:
> When and how will it get decided what groups will be built?

I read through the Working Groups threads and assembled/organized the
suggestions.  I present it here for discussion.  After a bit of
discussion, I will propose some groups and see what gets populated.  We
can refine as we go.  I've listed a lot of groups!

Each Group, of course, should consider itself free to make its own
decisions as to its goals, process, mission, etc.  One thing I highly
recommend is that each group pull from this list's archives posts
relevant to their topic.  There's a *lot* of good information here and
on the wiki.

I welcome feedback on this doc and this structure.  I will, however, be
on vacation for a week starting Friday.  My wife informs me I will have
no internet access, and I think she's going to enforce that.  We might
not get this all done before then, but let's see what we can do.

Thanks to everybody for pitching in on the Working Group discussion.  If
you want to work on something and it's not covered by the groups below,
please tell me and we'll make it happen.


# Working Groups

Working Groups are the teams that design the FreedomBox.  Each group
will examine the available options, recommend the best for further
development and possibly execute on its own recommendations.

Each Working Group can establish a page on the Debian wiki.  The
FreedomBox Foundation will link to those pages.  Groups can fine-tune
their goals and working process as they please.  Mailing lists can be
created for Working Groups if they wish, although development on the
list is encouraged.

Working Groups are not dictatorial units.  Final decisions about what
goes in the Debian version of the box and what does not will fall to
the usual Debian mechanisms (e.g. individual package maintainers and
FTP masters).

## 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
 
## UI / UX / HID

This working group will design the layer that the end user sees.  This
project lives or dies based on whether it is easy to use.

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.

### Goals

 * Identification of UX priorities and goals
 * UX conceptualization to serve those priorities and goals
 * 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.

### 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.

## 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.

### Goals

 * Allow as much communication as possible while protecting security,
   privacy, and anonymity.

## Documentation

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


## 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.