First steps toward federated project coordination

Published 14 Jul 2021
post image

tl;dr #

In March 2021, the Bonfire project was awarded a "Next Generation Search & Discovery" grant from NLNet Foundation, and since then the team has been working on a series of Bonfire extensions to help create the next generation of federated software.

This is the first of a series of posts discussing the development process, work coordination strategies and the challenges we are currently facing.

One of the funded milestones led us to build a project coordination app as a bonfire extension and flavour.

But wait: why are you building another project coordination app? #

Our coordination tool shares a lot of functionality with most to-do apps out there - you can create lists, add tasks to lists, commit to complete work, set a due date, and so on...

So how is this different?

1) We want to federate coordination between many people, groups and organisations on different instances #

On top of the usual features like writing posts, following users and browsing feeds, a Bonfire instance using the coordination extension will make it possible to create lists and tasks. Users can then favourite, boost, comment, flag and adjust the visibility settings (or in the case of a Bonfire instance, choose the boundaries and circles their lists and tasks are published to).

As soon as users start publishing tasks, a new type of activity appears in the feeds like below:

Users can interact with such activities by assigning a task to themselves, searching for tasks that fit with their skills or interests, or following a task to be notified about future discussions or progress.

Users from any instance can thus start planning together: sofware projects, events, creative collaborations, peer production, etc - without having to leave the app and with the same account they already use.

A user can decide to create a private list to share with specific people, or open it to all users of their instance or beyond. At every point the user will be able to control both the visibility (who can see todos or comments), as well as the permissions and roles for each list and task (who can add/edit/comment/vote/assign/etc).

2) We needed it #

We are always seeking to improve the coordination between contributors and the various projects linked to Bonfire. We aim to iterate on the design and build a p2p coordination system that we are happy to work with and would welcome other non-hierarchical and cooperative-minded groups to join us in designing and building these tools together.

3) Interoperability #

Powered by ValueFlows #

We are building upon a well designed and tested vocabulary to bring p2p coordination to a whole new level. In short, ValueFlows does for economic activities what ActivityStreams (the main vocabulary of the ActivityPub-powered fediverse) does for social activities. Using these standard vocabularies means that every feature and user interaction can federate not only with other Bonfire instances, but also with instances of other software which implement them.

Lists (which can represent projects or milestones within a larger project) can include dependencies from other lists, as well as tracking work, but also resources, shared inventories and needs (this ties in to our work around mutual aid, which will be the topic of a future blog post).

Users can have discussions around a task, as well as record different kinds of economic activities to keep track of physical or digital resources. They can also simply log the amount of hours or the outputs (eg. git commits) of their work on a specific task.

Furthermore, it will be possible to define formulas (aka value equations) to help calculate the distribution of value generated by a project to all of its participants, based on their recorded contributions and previous agreements.

So what looks on the surface like another to-do list app, is actually a small UI layer (the bonfire_ui_coordination extension, with only 1110 lines of code) on top of larger and more general economic extensions which are poised to be used for many different kinds of applications. These are bonfire_ui_valueflows (which currently has over 2500 lines of reusable UI components) and bonfire_valueflows (sitting at a whopping 16150 lines of database and API schemas and logic), and many more...

ForgeFed #

Besides ValueFlows, we plan to participate in the ForgeFed effort.

ForgeFed is an upcoming federation protocol for enabling interoperability between version control services. It is built as an extension to the ActivityPub protocol, allowing users of any ForgeFed-compliant service to interact with the repositories hosted on other instances.
The goal of the project is to support all of the major activities connected to project management, including bug reports, merge requests and notifications across instances.

Given that we are coordinating our development using this tool, it makes sense to connect the dots between issue reporting and work coordination, code contributions (version control and merge requests) and economic contributions (along with the related value calculations). We hope to implement ForgeFed functionality to do more of this and interoperate with other tools in the near future.

Join us! #

Would you be interested in trying alpha-stage software and participate in its design and creation process? These tools are still missing some important features, several of which we've committed to build as part of other milestones, and we greatly appreciate your input about how to design and build it futher according to your needs. Please get in touch.

Sign up to our newsletter for more stories

Your data is private and we will use it only for the purposes of contacting you about Bonfire.
You may unsubscribe at any time.