Note: This is an application for retroactive funding.
Overview
Yorgos’s team helped build an initial pass at an issues board.
I (Bordumb) am posting this retroactive notes on their behalf to be transparent about the work done and grant funding being put forth.
Project Details
Issue Boards are a fundamental part of software tools, and can be seen across tools such as GitHub’s Issue Boards, Jira’s Scrum Boards, and other development and planning software.
This looks really cool! I’d be interested in understanding a breakdown of how it’s being/was built. Whether it builds on top of the protocol using COBs or it doing some trickery with existing COBs. Can others build similar products using CLIs instead on top of this design?
yes, this prototype is built on top of the Radicle protocol, using entirely existing Collaborative Objects (COBs) for persistence: we’re essentially using the labels of Radicle Issues to store the column the issue should appear in (and status for “done” issues).
Having said that, this was not intended as a long-term solution for this application. It just served the needs of this prototype which had a different goal: explore whether it was even possible / feasible to implement the planning boards as a separate client-side application to radicle-interface and how well this approach could work in terms of UX, etc.
For those needs, using the labels was convenient, but if we do get approval to move forward with further iterations of the Radicle Planning Boards application (through future Grants), a protocol extension would probably make more sense… the current persistence scheme is a little awkward / ugly ( essentially a label with value: RPBː"column"ː"string"ː"To-Do"). And it gets even clunkier if we want to persist order-within-a-column, which we haven’t yet in this prototype, exactly to leave time for this discussion to happen.
Whether or not the protocol is extended in the future however, yes, a Command Line Interface (CLI) tool could also be built to display this same information, as long as the two are using the same persistence scheme, of course.
I think this brings with it an interesting use-case in non-protocol designed features. My thinking is that the issue board can be designed as its own COB – using the Issue COB identifiers to link to issues. This COB will still be transferred between nodes through the protocol as long is it is stored under the cob (possibly cobs) refs hierarchy. It is up to the user to have the correct tooling to interpret this data then, e.g. rad kan could be a separate binary (an executable named rad-kan) which can be picked up by the rad binary.
All that said, it could be part of the protocol at the same time, but this would need to be proposed and critiqued I imagine uses of Radicle will want different styles of issue organisation and that’s why I think it’s a great way to experiment with using the “extension” approach.
I imagine uses of Radicle will want different styles of issue organisation and that’s why I think it’s a great way to experiment with using the “extension” approach.