RE: https://mastodon.nz/@strypey/117510315272781069
@smallcircles This could be a good project for a SX design ...
Discussion
RE: https://mastodon.nz/@strypey/117510315272781069
@smallcircles This could be a good project for a SX design ...
@smallcircles
> Git is good for code diffs, not really for text review and revision control
But ... source code is text. Revision control is *exactly* what Git is for, and the web forge on top provides the review layer (PRs/MRs, issue boards, etc). Using pre-BorgSoft GritHub worked fine for drafting the NZGOAL-SE, as mentioned in the thread.
(1/?)
@smallcircles
> But who can edit, who can/will review, and who is interested to read if there are countless branches?
As with use of Git forges for software (and other current uses like our websites), that would depend entirely on context. Some Gitocracy uses I anticipated;
* democratic political parties
* co-ops and other democratic social enterprises
* public service agencies (governmental or NGOs)
I've expanded on this here;
https://pad.disroot.org/p/gitocracy
(2/?)
@smallcircles
> you need good UI to make that intuitive
100%. The NZGOAL-SE consultation worked because those being consulted on GH were geeks familiar with its use. It was clear to me that a GH/GL style interface wouldn't cut it for general public use. This is where I got bogged down, investigating other collaborative authoring software for interface ideas;
https://wiki.p2pfoundation.net/Authoring_Platforms
(3/3)
You are excited about the idea. SX-wise you are at the start of the Ideation phase.
You have git, a technology. You should validate whether it is your ideal *enabling technology*. Does it solve the problem and fulfill stakeholder needs?
You are modeling a new solution in the domain of "Policy making", where git is just an impl. detail.
SX is needs-driven development. You defined 3 audiences that might benefit from your solution. Next step is to define stakeholder (groups), and find people who work in these roles to gather feedback from.
What are they using currently? What problems do they face? What is their domain / work process? How does gitocracy improve it? Do they see merit in the proposed solution?
The latter can be the hardest, as you propose/advocate a new way of working.
--
Tangential: Interesting to look at is Patchwork, malleable software ("software should adapt to your needs"), who are prototyping new ways to collaborate online.
YouTube
@strypey
Couple days ago NOYB launched a site where you can track amendments of European members of parliament, which were then ranked in a leaderboard on good/bad impact on privacy regulation in the EU (GDPR)..
https://mastodon.social/@noybeu/117426623731557738
The entries show the diff to regulatory text, so anyone can gauge their impact. I took opportunity to call out the only Dutch MEP privacy offender..
https://social.coop/@smallcircles/117426887909050528
The idea in itself is nice. But who can edit, who can/will review, and who is interested to read if there are countless branches? Certainly candidate for thorough SX design.
Long time ago I tried, with motivated people from Humane Tech Community, to set up collaborative editing of awareness campaigns on the basis of git-stored content and PR's. Indeed you need good UI to make that intuitive.
Git is good for code diffs, not really for text review and revision control. CMS'es are better here. Tech-wise you have Operational Transforms (OT) and (local-first) CRDT's working well.